:: Re: [unSYSTEM] Mike Hearn's article…
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Robert Williamson
日付:  
To: System undo crew
題目: Re: [unSYSTEM] Mike Hearn's article RE stealth addresses
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@???> 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
> 00000000000000006d5945d2dddece39487c36673e56a292b619b1929ff3b40f
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
>