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. -- Pieter ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
