[Bitcoin-development] ECDH in the payment protocol

[Peter Todd]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140509/ecab7668/attachment.sig>