Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.56 as permitted sender)
	client-ip=62.13.149.56; envelope-from=pete@petertodd.org;
	helo=outmail149056.authsmtp.com; 
Date: Thu, 9 May 2013 08:20:05 -0400
From: Peter Todd <pete@petertodd.org>
To: Adam Back <adam@cypherspace.org>
Message-ID: <20130509122005.GA6645@savin>
References: <CAPaL=UVY4q6+BTtDy3Hy6OVhCB2oTSr2w+nMxyegW5Bpp=+c2A@mail.gmail.com>
	<20130509111913.GA15870@netbook.cypherspace.org>
	<20130509114605.GA28133@savin>
	<20130509120722.GA16188@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf"
Content-Disposition: inline
In-Reply-To: <20130509120722.GA16188@netbook.cypherspace.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] An initial replace-by-fee implementation
 is now available
Precedence: list


--zhXaljGHf11kAtnf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 ha=
s,
> 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 f=
ar,
> 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 bei=
ng
> processed (eg one in a block, the next in the next block).

Think about that problem a bit harder. :)

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

--zhXaljGHf11kAtnf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJRi5R0AAoJECSBQD2l8JH7/4gIAID/ZYCL+Ec4Z5u02cRJhFX3
4ETNF06m35OvvVqA75dN7tmosxWe+eQhAWNMY/EYhlXzK3JC32TY/DGoNIHJ7bVu
EYSyqdoVjYHllVjDZcQAHofe4nVpFuyuOKtAzierGECpY4U11uf1kcsYxnc9vHxf
MxtlIICpGKpAQeQu2J29YYfgT/rhdp0WEBxrfo4dXFmUHRZ8BGwUlQSNCGtiWwm7
fdfiZSqXb+ZKwxNGu36TWKazc+re8GhwE8G+vPtT+2vLccf7USNjzdMZg7GBShp+
Zq+SyMYTMoNMU1mqf2m/UstvF5Zd3xgpZXPdxhh1mnc4j6tFuXDXgSD/JcV8muA=
=EO6X
-----END PGP SIGNATURE-----

--zhXaljGHf11kAtnf--