[Bitcoin-development] ECDH in the payment protocol

[Bitcoin-development] ECDH in the payment protocol

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 3907 bytes --]

I wrote an article about an ECDH extension for BIP 70:

   https://medium.com/p/cb2f81962c1b

The article is meant for people who don't follow bitcoin-development so
I'll summarise it here:

   - The notion of being able to publish a piece of data once and use it to
   receive lots of payments without any coordination is really useful. This is
   the idea behind the stealth address proposal.

   - Stealth addresses don't fit with the payment protocol, because they're
   a new kind of address (obviously).

   - Stealth addresses are not backwards compatible. If you give someone a
   stealth address and their wallet doesn't support it, they can't pay you,
   not even with worse privacy. Sometimes people may optionally want that
   behaviour but stealth addresses have it all the time.

   - The proposed stealth address design makes huge sacrifices to try and
   keep everything within the block chain. It bloats the chain with OP_RETURN
   stuff that isn't a part of the validation. But more seriously, the only way
   to make it efficient enough for lightweight clients is to reduce the
   "stealthyness". The more efficient you make your address the less private
   it becomes. This is somewhat similar to the dilemma we have with Bloom
   filtering, except Bloom filters are transient and can only be used to link
   addresses by someone who observes them on the wire. Stealth addresses
   record the relationship in the block chain forever.

   - The design makes these sacrifices to avoid moving data around outside
   the block chain. But with BIP 70 that's the direction we're heading in
   anyway. So by adding ECDH to the payment protocol and putting our effort
   into making BIP 70 work really well for everyone, we end up killing
   multiple birds with one stone. The same work that resolves the privacy
   problems inherent in the stealth address design also allows us to attach
   messages to payments and other commonly requested features.

There's a straw man in the article that I recreate here:

message Output {
   optional uint64 amount = 1 [default = 0];
   optional bytes script = 2;
   *optional boolean accept_ecdh = 3;  // Requires script to be a
pay-to-pubkey output.*
}

message Payment {
   optional bytes merchant_data = 1;
   repeated bytes transactions = 2;
   repeated Output refund_to = 3;
   optional string memo = 4;
   *repeated bytes ecdh_nonces = 5;*
}

The way the nonces are combined to arrive at the address could be the same
as in the current stealth address spec. A wallet that doesn't understand
ECDH but does understand raw BIP 70 would deliver the money to the base
address, which receiving wallets would look for too - so it's backwards
compatible. The nonces stay out of the block chain. The transactions are
delivered directly to the recipient so there's no problems with trying to
make it fit with Bloom/prefix filtering.

To make this work there obviously has to be a backchannel from payer to
payee. BIP 70 is mostly used by web shops today so that back channel is
just HTTPS to the website itself, but shops benefit less from ECDH than
others do. So we need a simple email-like store and forward network where
HTTP POSTs to a server get queued up and delivered later (or possibly
forwarded to another store-and-forward network like the Android push
network). Most of the article discusses how best to build such a thing.

The justification for the original stealth address design can be summed up
as "it's easier to [ab]use the Bitcoin network for delivery of short
messages than use a different system". But there are just so many features
we may want to add into the Payment message in future it seems better to
crack the SaF problem earlier rather than continue trying to jam a square
peg into a round hole. There are lots of very reliable SAF networks around
(email, instant messaging, etc) so it doesn't seem infeasible.

Thoughts welcome!

[-- Attachment #2: Type: text/html, Size: 5004 bytes --]

Re: [Bitcoin-development] ECDH in the payment protocol

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

On Fri, May 09, 2014 at 02:05:24PM +0200, Mike Hearn wrote:

It's always interesting to see the reinvention cycle happen in the
Bitcoin space as ideas get proposed over and over again; I'm sure Amir
Taaki will be pleased to read this as it is a slightly less
sophisticated version of what he originally proposed to me for the
design of what became stealth addresses.

Of course we quickly rejected the idea of depending solely on a
communications backchannel to retrieve funds. Any communications medium
that isn't the blockchain makes the payment non-atomic, and thus creates
opportunities for it to fail. Fortunately we already have the necessary
ephemeral keys in standard Bitcoin transactions in pay-to-pubkey-hash
and pay-to-script-hash spending scriptSigs so you don't need to
compromise on reliability in exchange for transaction size as you're
mistakingly assuming. You should re-read my original stealth address
discussion with Gregory Maxwell on IRC if this is unclear.

In any case it's a mistake to argue that some times of data in the
blockchain are "bloat" by virtue of whether or not they happen to be
executed in a script. Multisig addresses use an extra ~107 bytes of data
per signature per txout spend to make it less likely for the user to
lose their funds under certain conditions; op-return-using stealth
addresses use an extra ~50 bytes of data per txout spend to make the
user less likely to lose their funds and make their transactions more
private under certain conditions.(1) Ultimately the resource being used
is the same, making it silly to try to dictate the right trade-offs by
brushing certain solutions as anti-social "bloat" and others not based
on top-down edict; let the free market for fees do its job.


1) Note that the recent advancements in ECDH multi-party signing are
   limited in the cases they can cover; there still is a strong need for
   discrete key multisig, e.g. for Greenaddress.it

-- 
'peter'[:-1]@petertodd.org
00000000000000003581a7e5d0e10205803803466240668215d178b216837386

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] ECDH in the payment protocol

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

>
> Of course we quickly rejected the idea of depending solely on a
> communications backchannel to retrieve funds. Any communications medium
> that isn't the blockchain makes the payment non-atomic


Yes, I know you rejected this design, which is why I'm now proposing it
instead. I think you made the wrong design call, but at any rate, it's
something reasonable people can disagree on.

Payment messages are sent directly to the merchant, who takes
responsibility for broadcast. Once you delivered transactions to the
merchant successfully, from your perspective the payment is made. A good
store and forward network doesn't allow messages to go missing - email is
an example of that (ignoring spam filters that explicitly want messages to
go missing). It either gets delivered or it doesn't. So I'm not worried
about atomicity.

[-- Attachment #2: Type: text/html, Size: 1110 bytes --]

Re: [Bitcoin-development] ECDH in the payment protocol

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]

On Fri, May 09, 2014 at 05:15:52PM +0200, Mike Hearn wrote:
> >
> > Of course we quickly rejected the idea of depending solely on a
> > communications backchannel to retrieve funds. Any communications medium
> > that isn't the blockchain makes the payment non-atomic
> 
> 
> Yes, I know you rejected this design, which is why I'm now proposing it
> instead. I think you made the wrong design call, but at any rate, it's
> something reasonable people can disagree on.
> 
> Payment messages are sent directly to the merchant, who takes
> responsibility for broadcast. Once you delivered transactions to the
> merchant successfully, from your perspective the payment is made. A good
> store and forward network doesn't allow messages to go missing - email is
> an example of that (ignoring spam filters that explicitly want messages to
> go missing). It either gets delivered or it doesn't. So I'm not worried
> about atomicity.

Ah, you're still misunderstanding my point: You can get atomicity in the
worst-case where the communications medium fails *and* stealth payments
that use up no extra space in the blockchain. This gives you the best of
both worlds.

I haven't yet specified that mode of operation in the current draft
stealth address standard, however I do plan on adding it. Notably the
standard is designed to allow exactly that feature to be added in a
backwards compatible way - senders who don't implement that feature, or
choose not to use it, simply fall back to op-return.

-- 
'peter'[:-1]@petertodd.org
00000000000000004d25218420094fda0891fe1d734e1a8df581bd6de7f2d0cd

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] ECDH in the payment protocol

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

>
> Ah, you're still misunderstanding my point: You can get atomicity in the
> worst-case where the communications medium fails *and* stealth payments
> that use up no extra space in the blockchain. This gives you the best of
> both worlds.


Sounds great! How does a lightweight client identify such transactions
without any markers?

Regardless, there are lots of other useful features that require BIP70 to
work well person to person, like messages, refund addresses, etc. So
extending it with ECDH makes sense in the end anyway no matter what.

[-- Attachment #2: Type: text/html, Size: 896 bytes --]

Re: [Bitcoin-development] ECDH in the payment protocol

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

On Fri, May 09, 2014 at 05:34:07PM +0200, Mike Hearn wrote:
> >
> > Ah, you're still misunderstanding my point: You can get atomicity in the
> > worst-case where the communications medium fails *and* stealth payments
> > that use up no extra space in the blockchain. This gives you the best of
> > both worlds.
> 
> 
> Sounds great! How does a lightweight client identify such transactions
> without any markers?

The exact same way you're proposing: via the payment protocol.

If something goes wrong and a payment gets lost, that's where you
implement a last-ditch "scan for stealth payments" button or similar
that either just asks a semi-trusted server to scan the blockchain for
you, or accepts the bandwidth hit and does so itself. (note that the
scan pubkey used to find payments is unable to spend those payments)

-- 
'peter'[:-1]@petertodd.org
000000000000000074d6fdc4442dae1b7273f77f2deec988daf63d3e1ec6eeea

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] ECDH in the payment protocol

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 265 bytes --]

>
> The exact same way you're proposing: via the payment protocol.
>

Ah, I see, that's what I was missing. So rather than have an explicit
repeated field for nonces, have an algorithm for extracting randomness from
one of the scriptSigs. I guess that makes sense.

[-- Attachment #2: Type: text/html, Size: 515 bytes --]

Re: [Bitcoin-development] ECDH in the payment protocol

[Pieter Wuille]

I believe stealth addresses and the payment protocol both have their
use cases, and that they don't overlap.

If you do not want to communicate with the receiver, you typically do
not want them to know who is paying or for what (otherwise you're
already talking to them in some way, right?). That's perfect for
things like anonymous donations.

In pretty much every other case, communicating directly with the
receiver has benefits. Negotiation of the transaction details,
messages associated with the transaction, refund information, no need
to scan the blockchain for incoming transaction... and the ability to
cancel if either party doesn't agree.

Instead of adding stealth functionality to the payment protocol as a
last resort, I'd rather see the payment protocol improve its
atomicity. Either you want the data channel sender->receiver, or you
don't. If it isn't available and you want it, things should fail. If
you don't want it, you shouldn't try to use it in the first place.

On Fri, May 9, 2014 at 5:34 PM, Mike Hearn <mike@plan99.net> wrote:
>> Ah, you're still misunderstanding my point: You can get atomicity in the
>> worst-case where the communications medium fails *and* stealth payments
>> that use up no extra space in the blockchain. This gives you the best of
>> both worlds.
>
>
> Sounds great! How does a lightweight client identify such transactions
> without any markers?
>
> Regardless, there are lots of other useful features that require BIP70 to
> work well person to person, like messages, refund addresses, etc. So
> extending it with ECDH makes sense in the end anyway no matter what.
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> &#149; 3 signs your SCM is hindering your productivity
> &#149; Requirements for releasing software faster
> &#149; 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
>

Re: [Bitcoin-development] ECDH in the payment protocol

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]

On Fri, May 09, 2014 at 05:50:33PM +0200, Pieter Wuille wrote:
> I believe stealth addresses and the payment protocol both have their
> use cases, and that they don't overlap.
> 
> If you do not want to communicate with the receiver, you typically do
> not want them to know who is paying or for what (otherwise you're
> already talking to them in some way, right?). That's perfect for
> things like anonymous donations.
> 
> In pretty much every other case, communicating directly with the
> receiver has benefits. Negotiation of the transaction details,
> messages associated with the transaction, refund information, no need
> to scan the blockchain for incoming transaction... and the ability to
> cancel if either party doesn't agree.
> 
> Instead of adding stealth functionality to the payment protocol as a
> last resort, I'd rather see the payment protocol improve its
> atomicity. Either you want the data channel sender->receiver, or you
> don't. If it isn't available and you want it, things should fail. If
> you don't want it, you shouldn't try to use it in the first place.

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.

OTOH if we base the atomicity of payment on whether or not a specific
txout exists everything those edge cases don't exist. Yes, that might
force us to expose transaction fees to the user, but after all it's the
user who has control over those fees.

A separate issue is IsStandard() rules, and a near-term project for me
is to write a much relaxed version of them based on soft-fork safe
whitelisting/blacklisting of opcodes, version numbers, mutability etc.
We can definitely get to the point where those rules will change very
little.

-- 
'peter'[:-1]@petertodd.org
00000000000000006d5945d2dddece39487c36673e56a292b619b1929ff3b40f

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] ECDH in the payment protocol

[Pieter Wuille]

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.

-- 
Pieter

Re: [Bitcoin-development] ECDH in the payment protocol

[Peter Todd]

[-- 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 --]

Re: [Bitcoin-development] ECDH in the payment protocol

[Chris Pacia]

Just a thought. Using the payment protocol for stealth would mean we
would likely have to return to backing up wallets all the time would it not?

The nonces cannot be derived from your wallet seed and, since they
aren't in the blockchain, would have to be stored in your wallet. I
suppose they could be stored on the server, but you would probably want
a backup for that anyway. So we would end up having to back up all the
time, something we're trying to get away from. Am I correct about this?

On 05/09/2014 02:38 PM, 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.
>

Re: [Bitcoin-development] ECDH in the payment protocol

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 774 bytes --]

On Tue, May 13, 2014 at 12:40 AM, Chris Pacia <ctpacia@gmail.com> wrote:

> Just a thought. Using the payment protocol for stealth would mean we
> would likely have to return to backing up wallets all the time would it
> not?
>

I think you are right. Awkward.

Wallets could auto-respend transactions to a plain (private) HD derived key
to make them findable again. But that gets us back to using block space
inefficiently.

Over time I think wallet backups will get more valuable anyway, as they
will start containing more and more essential data that isn't in the block
chain: receipts, messages, exchange rate records for tax purposes etc. But
being able to get access to your money with just the 12 words (+a date for
SPV wallets) is a pretty desirable safety feature.

[-- Attachment #2: Type: text/html, Size: 1142 bytes --]

Re: [Bitcoin-development] ECDH in the payment protocol

[Jeff Garzik]

On Fri, May 9, 2014 at 11:03 AM, Peter Todd <pete@petertodd.org> wrote:
> Of course we quickly rejected the idea of depending solely on a
> communications backchannel to retrieve funds. Any communications medium
> that isn't the blockchain makes the payment non-atomic, and thus creates
> opportunities for it to fail.

This is extremely simple-minded logic that encourages ephemeral, junk
data in the blockchain.  Not a scalable approach.

The implication is to put the communications medium in the blockchain
itself, which is wrong.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/