:: Re: [unSYSTEM] Mike Hearn's article…
Página Principal
Delete this message
Reply to this message
Autor: Mike Gogulski
Data:  
Para: System undo crew
Assunto: Re: [unSYSTEM] Mike Hearn's article RE stealth addresses
Money serves to facilitate interactions between people who don't trust
each other. For the most part, we don't trust each other. At least, not
yet.


On 05/22/2014 12:27 PM, Marvin Fernandes wrote:
> Why are we actualy Working on bitcoin And payments while we are moving
> toward An economy of GIVING AWAY FOR FREE?
>
> Middelerwijl een schoon wees
> gegroet,
> Marvin Fernandes
> 0624559753
>
>
> Verstuurd vanaf mijn Sinclair Spectrum
>
> Op 14 mei 2014 om 12:04 heeft Robert Williamson <bobalot@???
> <mailto:bobalot@gmail.com>> het volgende geschreven:
>
>> I liked your response, from reading Hearns post it seems he's trying
>> to mix ECDH/stealth/reusable addressees with the payment protocol,
>> when their advantages are entirely separate.
>>
>> ECDH/stealth is good for repeated payments between people. Payment
>> protocol is good for when you want a signed receipt/invoice from a
>> person and then both parties can prove to the public that funds are
>> present in the blockchain to the receiving address.
>>
>> If DH is used in the payment protocol, neither the sender or the
>> receiver can prove the determined address without revealing one of
>> their secrets to the public and it essentially comes back to the
>> problem now, of he said/she said, when it comes to sending funds to
>> an address, there's no proof of purchase or receipt which you can
>> show others to prove a service was purchased.
>>
>>
>> But instead of inserting a new public key after OP_RETURN for ECDH,
>> can't we use well known public keys of others and then build a
>> deterministic-style wallet for them.
>>
>> eg.
>>
>> alice_pub = G(alice_priv)
>> bob_pub = G(bob_priv)
>>
>> shared_secret = ECDH(alice_priv, bob_pub) = ECDH(bob_priv, alice_pub)
>>
>> When alice wants to send funds to bob;
>>
>> bob_priv = bob_priv + Hash("stealth:" + shared_secret + n)
>> bob_public = bob_pub + G(Hash("stealth:" + shared_secret + n))
>>
>> increment n for each new address needed
>>
>> Then you don't need to embed any data into the blockchain or have a
>> look-up service, as long as alive and bob "know" each others public
>> keys and have them stored in a address book they can subscribe to the
>> next 5 unused addresses in the electrum deterministic-style branch.
>>
>> The Hash is used to prevent people easily tracking back over the
>> public key space, as you could do with just adding 1 onto the private
>> key each time, without a secure hash function.
>>
>> The "stealth:" term is used so we don't get a collision with any
>> other services using ECDH on those keys and end up with that
>> potentially identifying data in the blockchain.
>>
>> This still suffers from some of the problems already known about
>> deterministic style wallets, if you give someone a deterministic wif
>> at offset n and your public key they can find out your master private
>> key. In this setup they only the person with a copy of the shared
>> secret could do that, which should only be the peer we're exchanging
>> with.
>>
>>
>> Thanks
>> Bob
>>
>>
>>
>> On 9 May 2014 19:04, Peter Todd <pete@???
>> <mailto:pete@petertodd.org>> wrote:
>>
>>     On Sat, May 10, 2014 at 02:04:52AM +1000, Washington Sanchez wrote:
>>     > https://medium.com/p/cb2f81962c1b
>>     >
>>     > Any thoughts?

>>
>>     my tl;dr: on reddit:

>>
>>         What's interesting about Mike's proposal is it's a slightly less
>>         sophisticated, and somewhat more centralized, version of what
>>     Amir Taaki
>>         originally proposed to me. The current stealth address
>>     mechanism was
>>         created to fix the problems in that original proposal with
>>     regard to
>>         privacy and reliability.

>>
>>         My reply on the mailing list is worth reading:

>>
>>     http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05324.html

>>
>>     --
>>     'peter'[:-1]@petertodd.org <http://petertodd.org>
>>     00000000000000006d5945d2dddece39487c36673e56a292b619b1929ff3b40f

>>
>>     _______________________________________________
>>     unSYSTEM mailing list: http://unsystem.net
>>     https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem

>>
>>
>> _______________________________________________
>> unSYSTEM mailing list: http://unsystem.net
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem