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
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ 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
