From: Peter Todd <pete@petertodd•org>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] ECDH in the payment protocol
Date: Fri, 9 May 2014 11:03:25 -0400 [thread overview]
Message-ID: <20140509150325.GA30436@savin> (raw)
In-Reply-To: <CANEZrP3VNXSc2cd3b9pz9iC2BR0-vG=tfYwMyUGBGaWPq+geXQ@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2014-05-09 15:03 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 [this message]
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
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=20140509150325.GA30436@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/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