On Thu, May 09, 2013 at 02:07:23PM +0200, Adam Back wrote:
> I have to say I do not think you want to have it be random as to who gets
> paid (by having conflicting double spends floating around with different
> payee & change addresses all from the same sending address.)

Indeed. That's the point of the blockchain, to take all those potential
inconsistencies and vote on a true transaction history to achieve
consensus.

> About current defacto no replacement: it is the best bitcoin currently has,
> and it has value, with it you need to do a net-split to attack eg
> 1-confirmation, and this proposal weakens it.  Net-splits are possible but
> not trivial.  This proposal moves them into spec - ie free.

Right now we don't have double-spend proof propagation, so the
"net-split" attack is actually totally trivial: just broadcast two
different, mutually incompatible, transactions at the same time. About
half the time the recipient will get the payment, the other half of the
time the payment they thought they were going to get is invalidated.

It's very, very rare for sites to have protection against that;
blockchain.info's shared-send mixer is one of the few exceptions. But
the have access to a whole network monitoring service with connections
to nodes all over the planet.

> About privacy: I think you are going to inherently disclose which is the
> change address, because you will decrease the change when you increase the
> fee.  There is no coin management in the client, and as far as I saw so far,
> no privacy management of which coins to reduce coin cross linking.  Who's to
> say the client has 100s of times as many coins as the payment.
>
> If people dont want to reveal which is change and which payment, they need
> to put a big enough fee up front based on a margin over prevailing fee
> statistics.

It's not ideal, but it still protects against after-the-fact blockchain
analysis.

Statistics is hard - you can't get it right all the time. Besides, what
happens when everyone adds a safety margin? Some people can afford to
wait, so for them starting at a low bid and raises it makes a lot of
sense.

> Also if the bids are too flexibly different how do you stop both bids being
> processed (eg one in a block, the next in the next block).

Think about that problem a bit harder. :)

-- 
'peter'[:-1]@petertodd.org
00000000000000220dc3b283e651068535f8e934096cfef35342bc688d8ee578