Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.113 as permitted sender)
	client-ip=62.13.148.113; envelope-from=pete@petertodd.org;
	helo=outmail148113.authsmtp.com; 
Date: Mon, 12 May 2014 09:07:44 -0400
From: Peter Todd <pete@petertodd.org>
To: Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20140512130744.GC12679@savin>
References: <CANEZrP3VNXSc2cd3b9pz9iC2BR0-vG=tfYwMyUGBGaWPq+geXQ@mail.gmail.com>
	<20140509150325.GA30436@savin>
	<CANEZrP1m=-GWD5rLRe9vrx0JYKeKXghNw-a47ZbJTd1h3ngFww@mail.gmail.com>
	<20140509152715.GA12421@savin>
	<CANEZrP0Yom_JjN2PnPsfKV5S4wZSze4XTcJJU2ZWee4VGo20tw@mail.gmail.com>
	<CAPg+sBh-OA7xSp3=SEGS1fP-d2CDMzMy_=S_jOs1hvdaWTw0mA@mail.gmail.com>
	<20140509181353.GB27819@savin>
	<CAPg+sBiSkeoD-Rxkoo+Dp8vTt0hE4FGLVxrdqTox6Njo8Mk5pw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="HG+GLK89HZ1zG0kk"
Content-Disposition: inline
In-Reply-To: <CAPg+sBiSkeoD-Rxkoo+Dp8vTt0hE4FGLVxrdqTox6Njo8Mk5pw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] ECDH in the payment protocol
Precedence: list


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

On Fri, May 09, 2014 at 08:38:22PM +0200, Pieter Wuille wrote:
> On Fri, May 9, 2014 at 8:13 PM, Peter Todd <pete@petertodd.org> wrote:
> > I don't think we're going to find that's practical unfortunately due to
> > change. Every payment I make ties up txouts, so if we try to base the
> > atomicity of payments on whether or not the payee decides to broadcast
> > the transaction the payor is stuck with txouts that they can't use until
> > the payee makes up their mind. That leads to lots and lots of nasty edge
> > cases.
>=20
> I haven't talked much about it except for on IRC, but my idea was this:
> * PaymentACK messages become signed (with the same key as the payment
> request, or using some delegation mechanism, so that the same key
> doesn't need to remain online).
> * Instead of a full Bitcoin transaction, a Payment message contains a
> scriptSig-less Bitcoin transaction + a limit on its byte size (and
> perhaps a limit on its sigop count).
> * The sender sends such a Payment to the receiver before actually
> signing the transaction (or at least, before revealing the signed
> form).
> * The receiver only ACKs if the transaction satisfies the request, is
> within time limits, isn't unlikely to confirm.
> * If the sender likes the ACK (the refund and memo fields are intact,
> the transaction isn't changed, the signature key is valid, ...), he
> either sends the full transaction (with receiver taking responsibility
> for broadcasting) or broadcasts it himself.
>=20
> Together, this means that a paymentACK + a confirmed matching Bitcoin
> transaction can count as proof of payment. Both parties have a chance
> to disagree with the transaction, and are certain all communicated
> data (apart from transaction signatures) in both directions happened
> correctly before committing. It would completely remove the chance
> that the Bitcoin transaction gets broadcast without the receiver
> liking it (for legitimate or illegitimate reasons), or without the
> backchannel functioning correctly.
>=20
> It's also compatible with doing multiple payments in one Bitcoin
> transaction - you can ask for ACKs from multiple parties before
> signing the transaction.
>=20
> Of course, the sender can still withhold the signed transaction (in
> which case nothing happened, but we probably need a second timeout),
> or the receiver can always claim to have never received the
> transaction. The sender can broadcast the transaction himself in order
> to prevent that, after obtaining an ACK.

Yeah, with the receiver specifically signing off on the tx I think
that's fine. OTOH you still gotta ask if this process is really worth
it; do you really need this level of signing off for payments that are
only going to be considered fully valid after a confirmation? That's
always going to be the case for a large proportion of Bitcoin
transactions, and sticking to that model makes upgrades easier and
reduces the reasons why receivers would want to reimplement a bunch of
Bitcoin-related logic.

--=20
'peter'[:-1]@petertodd.org
00000000000000007cf5744be694eea2f20501e6db9d3362428aabd63dda4151

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

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

iQGrBAEBCACVBQJTcMebXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA3Y2Y1NzQ0YmU2OTRlZWEyZjIwNTAxZTZkYjlkMzM2MjQy
OGFhYmQ2M2RkYTQxNTEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsobgf/YjH8RXfrzm8DtqA78oAfIduF
y1l533YnAsBD2H/eXMBDxsTdmJRLp1ebfjC8fOJHXchvjfw0kKjq3NJlZUPxjqeI
+OmqLXJQbE3pg+gMKxc4Y8uJCAzcJ/GPgiAtQ4Rn7e7gfGgteCbT4lg+FsxhL46a
U375rZpFbYNG8Y09qe+QCpu77t7b2Zm0HqktiPfeBPYazRtxb/39nbxUM93aUHOL
5TybCuBVrgblACziFp47ONaKL4v+t1cobgyP1eEfj5eaZfjdLauTn8/8/2P3tLn6
b5rI0jFZOeypwhX1vAQl2fVigxBLjje789dhuRVwlwZs0cvzaFlXcfye5e3vnA==
=QNRc
-----END PGP SIGNATURE-----

--HG+GLK89HZ1zG0kk--