On Fri, May 09, 2014 at 08:38:22PM +0200, Pieter Wuille wrote: > On Fri, May 9, 2014 at 8:13 PM, Peter Todd <p...@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. > > 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. > > 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. > > It's also compatible with doing multiple payments in one Bitcoin > transaction - you can ask for ACKs from multiple parties before > signing the transaction. > > 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. -- 'peter'[:-1]@petertodd.org 00000000000000007cf5744be694eea2f20501e6db9d3362428aabd63dda4151
Description: Digital signature
------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs
_______________________________________________ Bitcoin-development mailing list Bitcoinemail@example.com https://lists.sourceforge.net/lists/listinfo/bitcoin-development