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
::
Re: [unSYSTEM] Mike Hearn's article…
