From: Peter Todd <pete@petertodd•org>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] ECDH in the payment protocol
Date: Mon, 12 May 2014 09:07:44 -0400 [thread overview]
Message-ID: <20140512130744.GC12679@savin> (raw)
In-Reply-To: <CAPg+sBiSkeoD-Rxkoo+Dp8vTt0hE4FGLVxrdqTox6Njo8Mk5pw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3153 bytes --]
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.
>
> 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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2014-05-12 13:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-09 12:05 Mike Hearn
2014-05-09 15:03 ` Peter Todd
2014-05-09 15:15 ` Mike Hearn
2014-05-09 15:27 ` Peter Todd
2014-05-09 15:34 ` Mike Hearn
2014-05-09 15:43 ` Peter Todd
2014-05-09 16:12 ` Mike Hearn
2014-05-09 15:50 ` Pieter Wuille
2014-05-09 18:13 ` Peter Todd
2014-05-09 18:38 ` Pieter Wuille
2014-05-12 13:07 ` Peter Todd [this message]
2014-05-12 22:40 ` Chris Pacia
2014-05-13 10:29 ` Mike Hearn
2014-05-13 9:19 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140512130744.GC12679@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox