Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

2014-02-27 Thread Troy Benjegerdes 
To each his own, but if I say "Please don't charge me for YOUR privacy
by putting junk like stealth addresses in the blockchain", I think I'd
get laughed out of most rooms.

Either the transaction fees are sufficient to pay the cost for whatever
random junk anyone wants to put there, or they are not, and if they are
not, then I suggest you re-think the fee structure rather than trying
to pre-regulate me putting 80 character pithy quotes in the blockhain.


On Mon, Feb 24, 2014 at 09:23:12AM -0800, Mark Friedenbach wrote:
> Given our standardization on 128-bit security / 256-bit primitives, I
> can't think of any crypto related data payload which requires more than
> 40 bytes. Even DER encoded compressed public keys will fit in there. A
> signature won't fit, but why would you need one in there?
> 
> There's no need to design for 64-byte hashes, and the 80-char line
> length comparison is a good point. As an Engineer I'd want to have a
> little more room as a 32-byte hash or EC point + 8 bytes identifying
> prefix data is the bare minimum, but it is also very important that we
> send a message: This is for payment related applications like stealth
> addresses only. Don't burden everybody by putting your junk on the block
> chain.
> 
> On 02/24/2014 08:39 AM, Wladimir wrote:
> > 
> > On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik  > > wrote:
> > 
> > A common IRC proposal seems to lean towards reducing that from 80.
> > I'll leave it to the crowd to argue about size from there. I do think
> > regular transactions should have the ability to include some metadata.
> > 
> > 
> > I'd be in favor of bringing it down to 40 for 0.9.
> > 
> > That'd be enough for <8 byte header/identifier><32 byte hash>.
> > 
> > 80, as the standard line length, is almost asking for "insert your
> > graffiti message here". I also see no need for 64 bytes hashes such as
> > SHA512 in the context of bitcoin, as that only offers 256-bit security
> > (at most) in the first place.
> > 
> > And if this is not abused, these kind of transactions become popular,
> > and more space is really needed, the limit can always be increased in a
> > future version.
> > 
> > Wladimir
> > 
> > 
> > --
> > Flow-based real-time traffic analytics software. Cisco certified tool.
> > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> > Customize your own dashboards, set traffic alerts and generate reports.
> > Network behavioral analysis & security monitoring. All-in-one tool.
> > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> > 
> > 
> > 
> > ___
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > 
> 
> --
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-- 

Troy Benjegerdes 'da hozer'  ho...@hozed.org
7 elements  earth::water::air::fire::mind::spirit::soulgrid.coop

  Never pick a fight with someone who buys ink by the barrel,
 nor try buy a hacker who makes money by the megahash


--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fee drop

2014-02-27 Thread Troy Benjegerdes 
On Mon, Feb 24, 2014 at 11:41:16PM -0500, Peter Todd wrote:
> So, just to be clear, we're adding, say, a memory limited mempool or
> something prior to release so this fee drop doesn't open up an obvious
> low-risk DDoS exploit right? As we all know, the network bandwidth
> DoS attack mitigation strategy relies on transactions we accept to
> mempools getting mined, and the clearance rate of the new low-fee
> transactions is going to be pretty small; we've already had problems in
> the past with mempool growth in periods of high demand. Equally it
> should be obvious to people how you can create large groups of low-fee
> transactions, and then cheaply double-spend them with higher fee
> transactions to suck up network bandwidth - just like I raised for the
> equally foolish double-spend propagation pull-req.
> 
> Of course, there's also the problem that we're basically lying to people
> about whether or not Bitcoin is a good medium for microtransactions.
> It's not. Saying otherwise by releasing software that has known and
> obvious DoS attack vulnerabilities that didn't exist in the previous
> version is irresponsible on multiple levels.

Well, if your investors take money with market manipulating news stories,
this is absolutely the responsible thing to do to increase shareholder
value with a future opportunity to cause a crash-on-demand.

Besides, if you really want microtransactions, you should be using an
altcoin with faster block times, smaller market cap, and larger 'human'
readable currency supply.

That being said, I'd say include the change, we all know about it. What
would be nice would be some exploits and attack signatures for what the
DOS will look like when it hits so that those of us paying attention
can make some money trading in anticipation of the market crash instead
of just the guys paying for the attack.

The real killer feature of Bitcoin is that we can learn from it's mistakes
(and bitcoin can learn from the copycatcoins), instead of one-size-fits
all fiat.

-- 

Troy Benjegerdes 'da hozer'  ho...@hozed.org
7 elements  earth::water::air::fire::mind::spirit::soulgrid.coop

  Never pick a fight with someone who buys ink by the barrel,
 nor try buy a hacker who makes money by the megahash


--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-02-27 Thread Peter Todd 
On Fri, Feb 28, 2014 at 12:48:33AM +0100, Jorge Timón wrote:
> First of all, sorry for the delayed answer.
> 
> On 2/10/14, Peter Todd  wrote:
> > Got this:
> [...]
> Thank you, I knew this wasn't new for us but I doubted we had written
> it anywhere.
> As said in those mails, being only able to offer AAA for BTC and not
> BTC for AAA nor AAA for BBB is enough of a limitation to justify a
> hardfork IMO.

As usual, you don't need a hardfork.

Anyway, one-sided trade is sufficient to get a functioning marketplace
up and running and test out the many other issues with this stuff prior
to forking anything.

> On 2/14/14, Peter Todd  wrote:
> > You're assuming the seller cares about fairness - why should they? They
> > offered a price for an asset and someone bought it; exactly which buyer
> > willing to buy at that price was able to complete the trade is
> > irrelevant to them. What they do care about is being sure that at
> > whatever given price they offered 100% of the buyers willing to buy at
> > that price actually see the offer in a reasonable amount of time - at
> > the best price the seller will get there will be only a single buyer
> > after all so you need that solid proof that said buyer was actually able
> > to get the offer.
> 
> In fact, I don't think the seller will care enough about this to pay
> the proof of publication fee either. Assuming sellers can either
> broadcast the order on a bitmessage-like network or use your proof of
> publication scheme, the later will be always be more expensive. So my
> prediction is that most people will just use the simplest, fastest and
> cheapest method, but I guess only time can tell.

You can make the same argument against Bitcoin itself you know...

A Bitmessage-like network would be trivial to front-run via a sybil
attack. It's the fundemental problem with marketplaces - the data
they're trying to publish has to be public.

> I don't think this will be a tragedy, because like we discussed on
> IRC, I don't think the primary goal of markets is price discovery, but
> trade itself.
>
> About historic data, the actual trades are always public, and some
> kind of "archivers" could collect and maintain old orders for historic
> bid and asks, etc.

And again, how do you know that record is honest? Fact is without
proof-of-publication you just don't.

> As an aside, nLockTime would be nice not to always have to
> double-spend the inputs of an order to cancel it.

You mean a reverse nLockTime that makes a transaction invalid after a
certain amount of time - that's dangerous in a reorg unfortunately as it
can make transactions permenantly invalid.

-- 
'peter'[:-1]@petertodd.org
b52709f0485161e764ac0198960885ccab019a978322cc6e


signature.asc
Description: Digital signature
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-02-27 Thread Jorge Timón 
First of all, sorry for the delayed answer.

On 2/10/14, Peter Todd  wrote:
> Got this:
[...]
Thank you, I knew this wasn't new for us but I doubted we had written
it anywhere.
As said in those mails, being only able to offer AAA for BTC and not
BTC for AAA nor AAA for BBB is enough of a limitation to justify a
hardfork IMO.

On 2/17/14, Troy Benjegerdes  wrote:
> Is there a simple way to do cross-chain trades that doesn't need a third
> chain to somehow facilitate things?

These are the two methods I know for cross-chain trading (no third
chain needed in any of them):

https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
https://bitcointalk.org/index.php?topic=321228

On 2/14/14, Peter Todd  wrote:
> You're assuming the seller cares about fairness - why should they? They
> offered a price for an asset and someone bought it; exactly which buyer
> willing to buy at that price was able to complete the trade is
> irrelevant to them. What they do care about is being sure that at
> whatever given price they offered 100% of the buyers willing to buy at
> that price actually see the offer in a reasonable amount of time - at
> the best price the seller will get there will be only a single buyer
> after all so you need that solid proof that said buyer was actually able
> to get the offer.

In fact, I don't think the seller will care enough about this to pay
the proof of publication fee either. Assuming sellers can either
broadcast the order on a bitmessage-like network or use your proof of
publication scheme, the later will be always be more expensive. So my
prediction is that most people will just use the simplest, fastest and
cheapest method, but I guess only time can tell.
I don't think this will be a tragedy, because like we discussed on
IRC, I don't think the primary goal of markets is price discovery, but
trade itself.

About historic data, the actual trades are always public, and some
kind of "archivers" could collect and maintain old orders for historic
bid and asks, etc.

As an aside, nLockTime would be nice not to always have to
double-spend the inputs of an order to cancel it.

-- 
Jorge Timón

http://freico.in/

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development