Tier Nolan [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-11 📝 Original message:On Thu, Aug 11, 2016 at ...

📅 Original date posted:2016-08-11
📝 Original message:On Thu, Aug 11, 2016 at 2:55 PM, Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Sorr, I thought there was some BIP for a public seed such that someone can
> generate new random addresses, but cannot trivially verify whether an
> address was derived from the seed.
>

If you take a public key and multiply it by k, then the recipient can work
out the private key by multiplying their master private key by k.

If k is random, then the recipient wouldn't be able to work it out, but if
it is non-random, then everyone else can work it out. You need some way to
get k to the recipient without others figuring it out.

This means either the system is interactive or you use a shared secret.

The info about the shared secret is included in the scriptPubKey (or the
more socially conscientious option, an OP_RETURN).

The address would indicate the master public key.

master_public = master_private * G

The transaction contains k*G.

Both sides can compute the shared secret.

secret = k*master_private*G = master_private*k*G

<encode(k*G)> DROP DUP HASH160 <hash160(encode(secret + pub key))>
EQUALVERIFY CHECKSIG

This adds 34 bytes to the scriptPubKey.

This is pretty heavy for scanning for transactions sent to you. You have
to check every transaction output to see if it is the given template. Then
you have to do an ECC multiply to compute the shared secret. Once you have
the shared secret, you need to do an ECC addition and a hash to figure out
if it matches the public key hash in the output.

This is approx one ECC multiply per output and is similar CPU load to what
you would need to do to actually verify a block.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160811/7ac1043e/attachment.html>;