[Bitcoin-development] Stealth Addresses

[Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 9862 bytes --]

* Abstract

A Stealth Address is a new type of Bitcoin address and related
scriptPubKey/transaction generation scheme that allowers payees to
publish a single, fixed, address that payors can send funds efficiently,
privately, reliably and non-interactively. Payors do not learn what
other payments have been made to the stealth address, and third-parties
learn nothing at all. (both subject to an adjustable anonymity set)


* Acknowledgments

Credit goes to ByteCoin for the original idea.(1) Gregory Maxwell, Adam
Back, and others on #bitcoin-wizards contributed valuable input on the
implementation. Finally thanks goes to Amir Taaki for input on the
general idea of stealth addresses and use-cases.


* Background

Viewed generally a Bitcoin address is a mechanism by which a payee
instructs a payor to create a transaction such that the payee can spend
one or more of the transaction outputs. Of course, typically the address
is simply the hash of a pubkey, and the mechanism by which the funds are
made available to the payee is to simply create a scriptPubKey of the
following form:

    DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG

The problem however is address reuse: it is convenient for payees to
give one or more payor a single address and use it multiple times for
various purposes. This results in all those payments becoming trivially
linkable to each other by an attacker - a threat not only to the privacy
of the user, but also to all users of Bitcoin.(2)

BIP32 hierarchical deterministic wallets are frequently proposed as a
solution. Now an address is a chain code and the mechanism by which a
scriptPubKey is generated is to derive a one-time-use pubkey from that
chain code and some index i. However, this quickly runs into two main
problems:

1) Lack of privacy: While someone not in possession of the address can't
   link payments together, someone who is can.

2) State: If the index is not to be re-used wallets must either maintain
   per-address state, or somehow query for already used indexes, or
   somehow generate them in a sufficiently small range that the payee
   can recover the indexes. All these solutions are problematic.

A good example of where the BIP32-derivation solutions fails come up at
the Dark Wallet Hackathon where it was suggested by the author that for
the purpose of securing person-to-person payments OpenPGP public keys
and X.509 certificates be extended with a new user-id field containing a
Bitcoin address. Wallet software could then use either certificate
system to ensure funds were being sent to the intended recipients -
essentially a non-interactive way of solving what the BIP70 payment
protocol solves interactively. Of course, without stealth addresses the
scheme would likely have little or no privacy.


* Requirements

1) Generated scriptPubKey must be globally unique

2) Must be only spendable by payee

3) scriptPubKey and associated transaction must be indistinguishable to
   third-parties from other transactions in some anonymity set.

4) Method must be fully deterministic and funds recoverable from a
   wallet seed and blockchain data for both payee and payor.

5) Funds must be efficiently recoverable by payee with reasonable, and
   configurable, computation and bandwidth costs.

6) Must be compatible with CoinJoin/Must not leak information to payee
   about what txins were used to pay them.

7) Must be compatible with multisig-protected wallets.

8) Must not make assumptions about txin scriptSig form.

9) Must be possible to prove to third parties that payment was made in
   accordance to instructions without revealing any other information.


** Payment Reliability

Schemes for making payments by transmitting nonces to the recipient
through some other medium, such as Bitmessage, were discussed at the
Dark Wallet Hackathon. However using any medium but the blockchain
itself for the communication means that the reliability of the payment
getting to the recipient is less than that of a standard transaction.
For instance Bitmessage nodes only keep messages for two weeks. We
decided that anything less than reliable atomic transactions was
unacceptable.


* Applying encryption to payments, simple explanation

Using Elliptic curve Diffie-Hellman (ECDH) we can generate a shared
secret that the payee can use to recover their funds. Let the payee have
keypair Q=dG. The payor generates nonce keypair P=eG and uses ECDH to
arrive at shared secret c=H(eQ)=H(dP). This secret could be used to
derive a ECC secret key, and from that a scriptPubKey, however that
would allow both payor and payee the ability to spend the funds. So
instead we use BIP32-style derivation to create Q'=(Q+c)G and associated
scriptPubKey.

As for the nonce keypair, that is included in the transaction in an
additional zero-valued output:

    RETURN <P>

The payee recovers the funds by scanning the blockchain for candiate P's
in transactions, regenerating the scriptPubKey, and finally checking if
any txouts in the transactions match. Note the close similarity of this
technique to how the Bitmessage network functions - an initial
implementation of the idea will find the Bitmessage code a suitable
starting point.


* Trading off anonymity set size for decreased bandwidth/CPU

By taking advantage of prefix filters(3) we can choose a tradeoff
between anonymity set size and bandwidth/CPU usage if the payee
specifies that payments to them are to match some short prefix k. There
are a few possibilities for how the prefix is to the applied - the most
simple is if per-block indexes of scriptPubKeys are available:

    RETURN <k> <P>

Alternatively if per-block indexes of H(scriptPubKeys) are only
available the wallet software can grind the scriptPubKey with nonce i
until it matches the specified prefix:

    RETURN <i> <P>

Furthermore as symmetric ciphers are quite cheap we might as well hide
the purpose of the OP_RETURN txout and encrypt the pubkey P using H(Q)
as a symmetric key. This gives us a slightly larger anonymity set.


* Advantages of using a separate output

An alternative would be to either re-use a pubkey or signature nonce
value from a transaction input, saving about 45 bytes per txout. An
absolute minimum sized Bitcoin transaction is 166 bytes(4) so at best we
have a 27% savings in tx fees, and more typically around ~15%. (modulo
mass-payments from a single txin)

However using an explicit prunable OP_RETURN output to store the pubkey
rather than re-using one from a txin or txin signature has a number of
advantages:

1) The txin's owned by the payor are not revealed to the payee. In fact,
   they could be held by a third-party who simply makes a transaction
   with the appropriate txouts on behalf of the payee.

2) Less information about the txouts is leaked. The statistical
   distribution of txouts remains unchanged - not possible in re-use
   schemes because they need to grind the payee scriptPubKey's for the
   sake of the prefix filters.

3) If required the nonce secret can be revealed to prove that a payment
   was made to a third-party, e.g. for dispute resolution.


* Bare CHECK(MULTI)SIG output alternative

An alternative with better efficiency could be to use bare
OP_CHECK(MULTI)SIG outputs to hold the nonce pubkey - generally a second
output is needed anyway for change. The most simple would be to use Jeff
Garzik's OP_DROP proposal(5) for the prefix:

  <prefix> DROP n <pubkey>...<pubkey> m CHECKMULTISIG

  or

  <prefix> DROP <pubkey> CHECKSIG

The payor pubkey is in the *change* txout, and the payee's ECDH-derived
pubkey in the other txout. By setting the prefix to be the same on both
txouts and using the same basic scriptPubKey form the relationship of
change and payment is still hidden; CoinJoin-using implementations can
adopt even more sophisticated approaches.

If IsStandard() rules remain the same and using OP_DROP is impractical,
we can also grind the change pubkey to match the prefix in a
deterministic manner so the wallet can still be recovered from a seed.
More costly, but maybe still acceptable for reasonably short prefixes.
Either way the result is transactions that are actually smaller and
cheaper than standard transactions, although without the advantage of
pushing scriptPubKey size payment to the receiver. (a pity we didn't
spend the extra time to adopt OP_EVAL)

A disadvantage is that revealing the nonce secret to prove a payment was
made is more problematic - either the txout needs to be spent first, or
we need a CHECKMULTISIG.


* Address format

To be decided. To support mulisig we probably want the ability to
specify n-of-m master pubkeys, using the nonce to generate derived ones.
For the single pubkey case the addresses will be a little longer than
standard Bitcoin addresses:

  s9KND3vfXjs3YqfZp86Acce3bM7Mhuptwh6mjeDnThsDei9Z2ZZcU

  vs.

  1LZn91ynrA6BCmoUKwnV3Ygk4FQMfPxLbg


1) ByteCoin, Untraceable transactions which can contain a secure message
   are inevitable, https://bitcointalk.org/index.php?topic=5965.0

2) Gregory Maxwell, Dark Wallet Certification discussions, also
   http://snowdenandthefuture.info/PartIII.html

3) Peter Todd, [Bitcoin-development] Privacy and blockchain data,
   http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03612.html

4) Bitcoin Wiki, Maximum transaction rate,
   https://en.bitcoin.it/w/index.php?title=Maximum_transaction_rate&oldid=36983

5) Jeff Garzik, Add small-data OP_DROP transactions as standard
   transactions, https://github.com/bitcoin/bitcoin/pull/1809

-- 
'peter'[:-1]@petertodd.org
0000000000000002861ee0919fc86990573ac360820766dc1b9ba580e5ccf7b6

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

Thanks Peter for the paper!

I'm just going to restate your 'simple explanation' to make sure I got  
it...

The payee publishes a public key of theirs, which will be a long-standing  
identifier, public key = 'Q', corresponding private key = 'd'.

To pay them, payee generate a keypair, private key = 'e' public key of  
'P'. Publish 'P' in the transaction.

The payer can calculate S = eQ, where S is a shared secret between  
payer/payee. The payee calculates the same S as S = dP. So the payee sees  
'P' in a transaction, and multiplies by their private key, to get S.

Now that we have the shared secret, either side can calculate an offset to  
Q which becomes the pay-to-address. When you say BIP32-style derivation,  
Q' = H(S) + Q, does this mean Q + SHA256(33-byte S)?

A payee has to check each transaction (or every transaction of a fixed  
prefix) with 'P', calculate Q' = Q + H(dP) and see if that transaction  
pays to Q'. If the address matches, then the payee can spend it with  
private key of d + H(dP).

One downside is that you have to hold your private key in memory  
unencrypted in order to identify new payments coming in. So  
stealth-addresses may not be suitable for receiving eCommerce payments,  
since you can't implement a corresponding watch-only wallet, e.g. there's  
no way to "direct-deposit into cold storage."

Hope I got that right...

On Mon, 06 Jan 2014 04:03:38 -0800, Peter Todd <pete@petertodd.org> wrote:

> Using Elliptic curve Diffie-Hellman (ECDH) we can generate a shared
> secret that the payee can use to recover their funds. Let the payee have
> keypair Q=dG. The payor generates nonce keypair P=eG and uses ECDH to
> arrive at shared secret c=H(eQ)=H(dP). This secret could be used to
> derive a ECC secret key, and from that a scriptPubKey, however that
> would allow both payor and payee the ability to spend the funds. So
> instead we use BIP32-style derivation to create Q'=(Q+c)G and associated
> scriptPubKey.
>
> As for the nonce keypair, that is included in the transaction in an
> additional zero-valued output:
>    RETURN <P>

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]

On Wed, Jan 08, 2014 at 02:20:57AM -0800, Jeremy Spilman wrote:
> Thanks Peter for the paper!
> 
> I'm just going to restate your 'simple explanation' to make sure I
> got it...
> 
> The payee publishes a public key of theirs, which will be a
> long-standing identifier, public key = 'Q', corresponding private
> key = 'd'.
> 
> To pay them, payee generate a keypair, private key = 'e' public key
> of 'P'. Publish 'P' in the transaction.
> 
> The payer can calculate S = eQ, where S is a shared secret between
> payer/payee. The payee calculates the same S as S = dP. So the payee
> sees 'P' in a transaction, and multiplies by their private key, to
> get S.
> 
> Now that we have the shared secret, either side can calculate an
> offset to Q which becomes the pay-to-address. When you say
> BIP32-style derivation, Q' = H(S) + Q, does this mean Q +
> SHA256(33-byte S)?

I think that's correct, but my ECC math is a bit shakey... In any case,
what's important is that you can derive a pubkey such that only the
recipient has the privkey, and without knowledge of the shared secret
you can't determine what the recipients master pubkey was.

> A payee has to check each transaction (or every transaction of a
> fixed prefix) with 'P', calculate Q' = Q + H(dP) and see if that
> transaction pays to Q'. If the address matches, then the payee can
> spend it with private key of d + H(dP).

Yup, you're understanding matches mine. (no guarantee if my
understanding is correct!)

> One downside is that you have to hold your private key in memory
> unencrypted in order to identify new payments coming in. So
> stealth-addresses may not be suitable for receiving eCommerce
> payments, since you can't implement a corresponding watch-only
> wallet, e.g. there's no way to "direct-deposit into cold storage."

Oh, sorry, I forgot to mention it in my first write-up but you can
easily make stealth addresses include a second pubkey for the purpose of
the communication that either isn't used in the scriptPubKey at all, or
is part of a n-of-m multisig. (n>=2) Interestingly that also means you
can give a third-party that key and out-source the effort of scanning
the blockchain for you.

-- 
'peter'[:-1]@petertodd.org
00000000000000028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Drak]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

On 10 January 2014 10:20, Peter Todd <pete@petertodd.org> wrote:

> Oh, sorry, I forgot to mention it in my first write-up but you can
> easily make stealth addresses include a second pubkey for the purpose of
> the communication that either isn't used in the scriptPubKey at all, or
> is part of a n-of-m multisig. (n>=2) Interestingly that also means you
> can give a third-party that key and out-source the effort of scanning
> the blockchain for you.


That seems pretty exciting to me. What is the chance of this becoming a BIP?

Drak

[-- Attachment #2: Type: text/html, Size: 962 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

On Fri, Jan 10, 2014 at 11:28:33AM +0000, Drak wrote:
> On 10 January 2014 10:20, Peter Todd <pete@petertodd.org> wrote:
> 
> > Oh, sorry, I forgot to mention it in my first write-up but you can
> > easily make stealth addresses include a second pubkey for the purpose of
> > the communication that either isn't used in the scriptPubKey at all, or
> > is part of a n-of-m multisig. (n>=2) Interestingly that also means you
> > can give a third-party that key and out-source the effort of scanning
> > the blockchain for you.
> 
> 
> That seems pretty exciting to me. What is the chance of this becoming a BIP?

Needs a prototype implementation first. The version with no prefix is
the simple one and doesn't have any other dependencies; the prefix
version is harder because it isn't clear yet what's the best way to
force the prefix, or for that matter whether scriptPubKey or
H(scriptPubKey) indexes will be available.

It's on my todo list, but as you've probably noticed my todo list is
rather long. :)

-- 
'peter'[:-1]@petertodd.org
00000000000000028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

> Oh, sorry, I forgot to mention it in my first write-up but you can
> easily make stealth addresses include a second pubkey for the purpose of
> the communication that either isn't used in the scriptPubKey at all, or
> is part of a n-of-m multisig. (n>=2) Interestingly that also means you
> can give a third-party that key and out-source the effort of scanning
> the blockchain for you.

Great point. Even if it's not a 3rd party, I think it's really important  
to be able to scan for transactions with a key which can't actually spend  
the funds.

The first approach is just one-pass ECDH. I think you're saying the second  
approach is two rounds of ECDH but re-using the same e/P (usually referred  
to as r/R in ECIES). I think this is safe, unlike reusing an ephemeral key  
for signing operations.

   Payee: Publish Q, Q2                     [d, d2 are privkeys, Q, Q2 are  
pubkeys]
   Payer: 1) Generate ephemeral key: e / P  [e is privkey, P is pubkey]
          2) S = e * Q                      [first shared secret]
          3) S2 = e * Q2                    [second shared secret, reusing  
'e']
          4) Q' = Q + H(S)                  [pay-to stealth address]
          5) Q2' = Q2 + H(S2)               [stealth 'marker']

   Watch: 1) Look for TxOut with OP_RETURN <P>
          2) Q2' = Q2 + H(d2 * P)
          3) Check for Q2' elsewhere in the Tx

S/MIME for example, allows reuse of the ephemeral keypair. When reusing an  
ephemeral keypair where A reuses (x, X) to encrypt different messages to  
more than one user, A should verify the static public keys to prevent  
small-subgroup attacks.[1][2]

Let's say you pay-to Q' and then Q2' value has to be somewhere else in the  
transaction. You could put it next to the shared P in OP_RETURN. OP_RETURN  
<P> <Q2'> would be 66 bytes.

But then Mallory could generate transactions with the right Q2' but with  
his own pubkey in Step 2 instead of Q. So your scanner would detect a  
payment, but you wouldn't be able to spend it, and Mallory could.

That's a good argument for putting Q2' in a 2-of-2 multisig so that  
pulling this trick would at least make the transaction unspendable for  
both parties, which may be good enough deterrent, but you're still going  
to want to check it against your 'd' before fulfilling a large order. Your  
online watch process could queue the matching transactions, which you  
could move to your offline machine, decrypt your key, and verify the  
transactions are spendable.

Now, you would need to get two pubkeys to the payer, throw in a prefix to  
help standardize it, and end up with addresses that could look like (for  
example):

xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX
tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba

Those addresses are 74 bytes:  
<Prefix><CompressedPubKey1><CompressedPubKey2><Checksum>

   xSTL Prefix = 0xC0CB9270
   tSTL Prefix = 0xB2E27D50
   NOTE: I do NOT have the corresponding privkeys for these four pubkeys!

Those just happened to be the first matching prefixes I found for 74 byte  
addresses. I could try to find ones which start with a specific byte if  
that's somehow better, like 0x04 to match BIP32.

Unfortunately, I don't think you can just derive a second public key from  
the first to keep the address shorter, and still keep the first private  
key secure, even if the second private key is stolen. You only get  
equivalent security as BIP32 public derivation, where you can't lose a  
child private key.

Do we also want xSTL (or whatever user friendly string) prefixes for  
single pubkey (41 byte) stealth addresses?

I'll wait a couple days for feedback, then I'll try to implement the  
following prototypes:

1) Pay to STL addresses
2) Watcher process to detect and queue STL payments for a given d2/Q2
3) Offline verifier to take output from Watcher and verify spendable given  
encrypted d/d2

Obviously extending QT directly for #1 would be ideal, I may even be able  
to do that since supporting a new address type should be fairly contained.  
But if not I'll punt to writing a node.js or python script which connects  
to bitcoind via RPC.

Thanks,
Jeremy

[1] - On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols
       http://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf

[2] - Validation of Elliptic Curve Public Keys
       http://www.iacr.org/archive/pkc2003/25670211/25670211.pdf

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 5991 bytes --]

You can always just extend the payment protocol with the new fields as
well, vs making very long addresses. If this technique can be made to work
well, it would have applicability in both fixed textual address context,
and for a fixed/upload-once payment protocol file. That has the advantage
of backwards compatibility as well - the new addresses would not be
clickable or acceptable by old wallets, but with the payment protocol you
can always craft a bitcoin URI that contains a regular current style
address, and a link to a fixed payment protocol file (uploaded to a
pastebin type site), and modern wallets would ignore the address and use
the ECDH based system instead.



On Sun, Jan 12, 2014 at 11:33 AM, Jeremy Spilman <jeremy@taplink.co> wrote:

> > Oh, sorry, I forgot to mention it in my first write-up but you can
> > easily make stealth addresses include a second pubkey for the purpose of
> > the communication that either isn't used in the scriptPubKey at all, or
> > is part of a n-of-m multisig. (n>=2) Interestingly that also means you
> > can give a third-party that key and out-source the effort of scanning
> > the blockchain for you.
>
> Great point. Even if it's not a 3rd party, I think it's really important
> to be able to scan for transactions with a key which can't actually spend
> the funds.
>
> The first approach is just one-pass ECDH. I think you're saying the second
> approach is two rounds of ECDH but re-using the same e/P (usually referred
> to as r/R in ECIES). I think this is safe, unlike reusing an ephemeral key
> for signing operations.
>
>    Payee: Publish Q, Q2                     [d, d2 are privkeys, Q, Q2 are
> pubkeys]
>    Payer: 1) Generate ephemeral key: e / P  [e is privkey, P is pubkey]
>           2) S = e * Q                      [first shared secret]
>           3) S2 = e * Q2                    [second shared secret, reusing
> 'e']
>           4) Q' = Q + H(S)                  [pay-to stealth address]
>           5) Q2' = Q2 + H(S2)               [stealth 'marker']
>
>    Watch: 1) Look for TxOut with OP_RETURN <P>
>           2) Q2' = Q2 + H(d2 * P)
>           3) Check for Q2' elsewhere in the Tx
>
> S/MIME for example, allows reuse of the ephemeral keypair. When reusing an
> ephemeral keypair where A reuses (x, X) to encrypt different messages to
> more than one user, A should verify the static public keys to prevent
> small-subgroup attacks.[1][2]
>
> Let's say you pay-to Q' and then Q2' value has to be somewhere else in the
> transaction. You could put it next to the shared P in OP_RETURN. OP_RETURN
> <P> <Q2'> would be 66 bytes.
>
> But then Mallory could generate transactions with the right Q2' but with
> his own pubkey in Step 2 instead of Q. So your scanner would detect a
> payment, but you wouldn't be able to spend it, and Mallory could.
>
> That's a good argument for putting Q2' in a 2-of-2 multisig so that
> pulling this trick would at least make the transaction unspendable for
> both parties, which may be good enough deterrent, but you're still going
> to want to check it against your 'd' before fulfilling a large order. Your
> online watch process could queue the matching transactions, which you
> could move to your offline machine, decrypt your key, and verify the
> transactions are spendable.
>
> Now, you would need to get two pubkeys to the payer, throw in a prefix to
> help standardize it, and end up with addresses that could look like (for
> example):
>
>
> xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX
>
> tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba
>
> Those addresses are 74 bytes:
> <Prefix><CompressedPubKey1><CompressedPubKey2><Checksum>
>
>    xSTL Prefix = 0xC0CB9270
>    tSTL Prefix = 0xB2E27D50
>    NOTE: I do NOT have the corresponding privkeys for these four pubkeys!
>
> Those just happened to be the first matching prefixes I found for 74 byte
> addresses. I could try to find ones which start with a specific byte if
> that's somehow better, like 0x04 to match BIP32.
>
> Unfortunately, I don't think you can just derive a second public key from
> the first to keep the address shorter, and still keep the first private
> key secure, even if the second private key is stolen. You only get
> equivalent security as BIP32 public derivation, where you can't lose a
> child private key.
>
> Do we also want xSTL (or whatever user friendly string) prefixes for
> single pubkey (41 byte) stealth addresses?
>
> I'll wait a couple days for feedback, then I'll try to implement the
> following prototypes:
>
> 1) Pay to STL addresses
> 2) Watcher process to detect and queue STL payments for a given d2/Q2
> 3) Offline verifier to take output from Watcher and verify spendable given
> encrypted d/d2
>
> Obviously extending QT directly for #1 would be ideal, I may even be able
> to do that since supporting a new address type should be fairly contained.
> But if not I'll punt to writing a node.js or python script which connects
> to bitcoind via RPC.
>
> Thanks,
> Jeremy
>
> [1] - On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols
>        http://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf
>
> [2] - Validation of Elliptic Curve Public Keys
>        http://www.iacr.org/archive/pkc2003/25670211/25670211.pdf
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 7459 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

[-- Attachment #1: Type: text/plain, Size: 3384 bytes --]


> You can always just extend the payment protocol with the new fields as  
> well, vs making very long addresses.

I should have mentioned that as Task #4. Agree it could be an optional  
extension and backward compatible. I think for displaying the payment in  
the UI after it's been made via PP, we have to fully support sending to a  
new standard address type anyway. Probably easiest to implement in PP  
after the address and transaction building code is done.

So '4a' would be building a static PP file given the necessary inputs.  
When I get to that point, I'll send out a draft PP extension with  
fields/formats if someone else hasn't already. '4b' would be actually  
adding support for parsing those fields and generating the new transaction  
type into bitcoind.

Any thoughts on the prefix, and one vs two pubkey approach? First of all,  
do we try to support both equally, or favor one over the other? I was  
thinking we could have two different 4 byte prefixes but that both render  
as xSTL/tSTL in Base58 but correspond to the one vs two pubkeys expected.  
I think the chance of finding a single prefix which looks like xSTL for  
both address lengths is 1 in (58^4)^2, so that's probably not going to  
happen.

 From the payer/user perspective, short stealth vs. long stealth is  
irrelevant; they both have the same usability properties from the payer  
perspective. So giving them the same Base58 prefix seems like a good plan.

The full 4-byte prefix seems worth the usability trade-off versus 1-byte  
prefix, especially since it will impact the ability to lookup the  
transaction on an outside service, which I think a lot of people do to  
verify their payments. IMO a longer prefix isn't "wasting bytes" anywhere  
that it really counts.

We could save two bytes in the address if we required both pubkeys to  
start with '03', or save one byte if we required they both start with the  
same byte, but again doesn't seem worth it (to me) for the arbitrary  
restriction.

The actual internal wallet code for *receiving* STL payments and updating  
balances is more tricky and probably not something I can personally tackle  
for bitcoind. Assuming we even want first-class support for generating STL  
addresses and receiving STL payments in a standard user wallet, someone  
has to decide if the STL 'd' / 'd2' keys should be...

   1) Encrypted as usual, and then keep a list of blocks with interesting  
transactions, and go through them when the user enters their password?   
This would cause balances to update differently than how they do now, but  
perhaps be more secure.

   2) Kept unencrypted to allow live scanning as usual? Or keep just 'd2'  
unencrypted, with some new concept of 'unconfirmed' until the user enters  
their password to prove they can spend that TX? That kind of extra step  
seems OK for a merchant but sounds very scary for an average user.

   3) Kept encrypted under a separate password? Meh...

And last thought for now... At some point, we might want to decide on a  
convention to highlight these STL addresses as 'reusable' -- but similar  
questions around revocability remain. I hope we don't need anything like a  
UTC expiration time baked in to the address. A static PP file will have an  
expiration date either in the certificate or in 'expires' field, so I  
think if you want it to expire then use PP?

[-- Attachment #2.1: Type: text/html, Size: 3859 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

On Sun, Jan 12, 2014 at 7:20 PM, Jeremy Spilman <jeremy@taplink.co> wrote:

>  I think for displaying the payment in the UI after it's been made via
> PP, we have to fully support sending to a new standard address type anyway.
>

Why? Showing an address is meaningless, especially if the user didn't type
it in or see it somewhere else. It's just an opaque random number, all
putting it in the UI can do is make it look scarier :)

Part of the point of the payment protocol is it lets merchants provide
human readable text for transactions instead of addresses.

[-- Attachment #2: Type: text/html, Size: 986 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

On Sun, Jan 12, 2014 at 7:20 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
> > I think for displaying the payment in the UI after it's been made via  
> PP, we have to fully
> > support sending to a new standard address type anyway.

On Sun, 12 Jan 2014 10:26:18 -0800, Mike Hearn <mike@plan99.net> wrote:
> Why? Showing an address is meaningless, especially if the user didn't  
> type it in or see
> it somewhere else. It's just an opaque random number, all putting it in  
> the UI can do is
> make it look scarier :)
>
> Part of the point of the payment protocol is it lets merchants provide  
> human readable text
> for transactions instead of addresses.

Of course you're right, moving away from addresses is definitely part of  
the point of PP.

On Sun, 12 Jan 2014 13:18:33 -0800, Gavin Andresen  
<gavinandresen@gmail.com> wrote:
> No, please. Make it easy for non-geeks, extend the payment protocol, or  
> we'll spend the next
> two years writing code that tries to ignore linebreaks and spaces and  
> changing <input> in HTML
> forms to <textarea>...

Agreed, it's long enough to be even more problematic than usual. If the  
general consensus is that there should not even be a standardized address  
form, then I can skip that entirely, and go straight to trying to extend  
PP.

It's a given this will be implemented for Payment Protocol. The question  
is whether it's also usable outside of PP.

I was kind of imagining that we could encourage people to replace all  
their static address text that live on Github pages, and README.me, and  
forum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention  
could be to require only transporting xSTL addresses within a URI, even  
going so far as to not support them copy/pasted. 101 characters is not  
much longer (and sometimes shorter) than PaymentRequest URIs end up being.

I think there are ways to make stealth addresses easy enough to use that  
people actually prefer using them for P2P payments which do not involve a  
full-stack merchant. In that case, if it was a PaymentRequest it would  
almost certainly not be signed, and would be more easily shared over email  
or SMS as a URI than as a file attachment or, even worse, putting the  
unsigned PR file up on a third-party server which probably won't do a good  
job securing it.

* PP Implementation Overview *

The basic PaymentRequest>PaymentDetails is expecting 'output' containing  
one or more TxOuts with script and amount. I believe the general approach  
is to put a fallback address into 'output' for backward compatibility, and  
put Q and Q2 into an extension field.

So we add a new optional field to PaymentDetails which contains the one or  
two PubKeys. Not sure if we want different protobuf tags, or if the  
difference in length of the value makes it obvious enough which approach  
is being used;

    optional bytes stealthOnePubKey = 1000
    optional bytes stealthTwoPubKey = 1001

or just

    optional bytes stealth = 1000

* User Interaction / Flow *

Lets follow this through from the user perspective, starting with what it  
looks like today. I'm having a hard time finding screenshots of what PP  
looks like in BitcoinQT, so I built from HEAD and using Gavin's  
Handy-Dandy PaymentRequest Generator  
(https://bitcoincore.org/~gavin/createpaymentrequest.php):

Screenshots: http://imgur.com/a/k6j9D

Image 1 - 'Send' screen after clicking a PR URI with a small transaction  
and auto-calculated fee
Image 2 - System Tray notification after clicking 'Send'
Image 3 - Transaction List showing partially confirmed transaction
Image 4 - Transactions details popup

We see 'Pay To' (Common Name from the cert) and 'Memo' on the Send screen.  
The System Tray notification popup and Transaction List shows just the  
address string. The 'Transaction details' window shows 'Merchant' which I  
think is the same as 'Pay To'. You also have 'Copy address' option in the  
right-click menu.

Memo seems not to be saved, or at least not visible in the UI after  
sending a payment.

* Transaction Display *

The address string is fairly pervasive, which is why I was originally  
thinking it would make sense to implement all the address handling first,  
so all those screens would continue to work as specified, without trying  
to hack something different in those fields.

Without digging too far into the code, it looks like "address" displayed  
is derived from the TxOut -- e.g. script.cpp:ExtractDestination. This  
could be a bit problematic depending on what we really want to show to the  
user -- the stealth multisig, or the pubkeys?

Part of the point of stealth addresses is actually making them reusable.  
So if you're the originator of the payment, you might want the wallet to  
tag that transaction somehow with the pubkeys used to generate it.

Also, ideally I think I would want multiple different stealth payments  
within a single wallet to the same merchant / pubkeys to be identifiable  
as such.

* Sample Code *

Will follow in another email, to be sent shortly!

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 4945 bytes --]

On Mon, Jan 13, 2014 at 01:13:08AM -0800, Jeremy Spilman wrote:
> It's a given this will be implemented for Payment Protocol. The question  
> is whether it's also usable outside of PP.

I think what stealth addresses is showing is that the concept of an
address being "instructions on how to generate a txout/tx that results
in me getting Bitcoins" is actually quite valuable; it and
BIP32-derivation addresses with chaincodes are pretty clear cases where
just replacing address with scriptPubKey isn't sufficient.

> I was kind of imagining that we could encourage people to replace all  
> their static address text that live on Github pages, and README.me, and  
> forum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention  
> could be to require only transporting xSTL addresses within a URI, even  
> going so far as to not support them copy/pasted. 101 characters is not  
> much longer (and sometimes shorter) than PaymentRequest URIs end up being.

Yeah, I don't see anything wrong with stealth addresses whatever length
they wind up being. It's a good intermediate step, and without them
people will just pass around unsigned payment requests and other stuff.

> I think there are ways to make stealth addresses easy enough to use that  
> people actually prefer using them for P2P payments which do not involve a  
> full-stack merchant. In that case, if it was a PaymentRequest it would  
> almost certainly not be signed, and would be more easily shared over email  
> or SMS as a URI than as a file attachment or, even worse, putting the  
> unsigned PR file up on a third-party server which probably won't do a good  
> job securing it.

At the DarkWallet hackathon we had discussed how to integrate stealth
addresses into OpenPGP keys as a new user id type for instance, and
similarly into x.509 certs.

The big advantage here is the identity of *who* you are paying is
important, not just "I got this signed payment request". Basically the
concept becomes "identity signed payment address" and the signature
binding the identity to the address is a one time and offline thing; an
issue with the payment protocol as it stands is that it encourages
signing keys to be kept online to issue payment requests. If you have a
scheme where the private keys that bound the identity to the address can
be kept offline you're much better off, because the attacker can only
create a fake payment request, they can't divert the funds to
themselves.

So with that in mind, I strongly suggest sticking with defining a
reasonable stealth address spec. But when you do, keep in mind that you
may want to upgrade it in the future, preferably in a backwards
compatible way. Also, it shouldn't be limited to exactly 2-of-2
CHECKMULTISIG, there's no reason why n and m can't be picked as needed.
Sure, it means the addresses are not fixed length, but for something
that is mostly an internal detail and only occasionally visible to
advanced users, I see no issues there.

Along those lines: what would a BIP32 chain code address look like? What
happens when you want to use that with a multisig-protected wallet?

> * PP Implementation Overview *
> 
> The basic PaymentRequest>PaymentDetails is expecting 'output' containing  
> one or more TxOuts with script and amount. I believe the general approach  
> is to put a fallback address into 'output' for backward compatibility, and  
> put Q and Q2 into an extension field.
> 
> So we add a new optional field to PaymentDetails which contains the one or  
> two PubKeys. Not sure if we want different protobuf tags, or if the  
> difference in length of the value makes it obvious enough which approach  
> is being used;
> 
>     optional bytes stealthOnePubKey = 1000
>     optional bytes stealthTwoPubKey = 1001

I think you're missing the bigger picture here, not least of which is
that backwards compatibility is a bit of a misnomer for an unreleased
standard. :)

Why put this into the PaymentDetails? That a stealth address is to be
used for the payment is a property of the outputs being requested, not
the payment itself. We're better off if that goes into the Output
message, and further more it suggests that the Output message shouldn't
contain raw scriptPubKey's but rather addresses. After all, IsStandard()
means we have to inspect the scriptPubKey to see if we can even pay to
what the sender is requesting.

Once you establish that it's addresses that Outputs specify, then it's
easy enough to make a stealth address type, or a BIP32-chain-code
address type, or whatever else comes up in the future.


> Also, ideally I think I would want multiple different stealth payments  
> within a single wallet to the same merchant / pubkeys to be identifiable  
> as such.

Agreed.

-- 
'peter'[:-1]@petertodd.org
00000000bda8ab55740699711a11572c4eec9dc9f714e4896559aac310a115ff

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Odinn Cyberguerrilla]

Hello Peter et. al.

As I read more into this stealth discussion I am curious to know what you
think of the background microdonation concept I posted recently.

It is shown in full here
http://sourceforge.net/mailarchive/message.php?msg_id=31837430

Given the lengthy nature of the concept as presented I would be happy to
distill it further, but I am interested in your thoughts as to the idea
generally and how to further present it.

-Odinn

> On Mon, Jan 13, 2014 at 01:13:08AM -0800, Jeremy Spilman wrote:
>> It's a given this will be implemented for Payment Protocol. The question
>> is whether it's also usable outside of PP.
>
> I think what stealth addresses is showing is that the concept of an
> address being "instructions on how to generate a txout/tx that results
> in me getting Bitcoins" is actually quite valuable; it and
> BIP32-derivation addresses with chaincodes are pretty clear cases where
> just replacing address with scriptPubKey isn't sufficient.
>
>> I was kind of imagining that we could encourage people to replace all
>> their static address text that live on Github pages, and README.me, and
>> forum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention
>> could be to require only transporting xSTL addresses within a URI, even
>> going so far as to not support them copy/pasted. 101 characters is not
>> much longer (and sometimes shorter) than PaymentRequest URIs end up
>> being.
>
> Yeah, I don't see anything wrong with stealth addresses whatever length
> they wind up being. It's a good intermediate step, and without them
> people will just pass around unsigned payment requests and other stuff.
>
>> I think there are ways to make stealth addresses easy enough to use that
>> people actually prefer using them for P2P payments which do not involve
>> a
>> full-stack merchant. In that case, if it was a PaymentRequest it would
>> almost certainly not be signed, and would be more easily shared over
>> email
>> or SMS as a URI than as a file attachment or, even worse, putting the
>> unsigned PR file up on a third-party server which probably won't do a
>> good
>> job securing it.
>
> At the DarkWallet hackathon we had discussed how to integrate stealth
> addresses into OpenPGP keys as a new user id type for instance, and
> similarly into x.509 certs.
>
> The big advantage here is the identity of *who* you are paying is
> important, not just "I got this signed payment request". Basically the
> concept becomes "identity signed payment address" and the signature
> binding the identity to the address is a one time and offline thing; an
> issue with the payment protocol as it stands is that it encourages
> signing keys to be kept online to issue payment requests. If you have a
> scheme where the private keys that bound the identity to the address can
> be kept offline you're much better off, because the attacker can only
> create a fake payment request, they can't divert the funds to
> themselves.
>
> So with that in mind, I strongly suggest sticking with defining a
> reasonable stealth address spec. But when you do, keep in mind that you
> may want to upgrade it in the future, preferably in a backwards
> compatible way. Also, it shouldn't be limited to exactly 2-of-2
> CHECKMULTISIG, there's no reason why n and m can't be picked as needed.
> Sure, it means the addresses are not fixed length, but for something
> that is mostly an internal detail and only occasionally visible to
> advanced users, I see no issues there.
>
> Along those lines: what would a BIP32 chain code address look like? What
> happens when you want to use that with a multisig-protected wallet?
>
>> * PP Implementation Overview *
>>
>> The basic PaymentRequest>PaymentDetails is expecting 'output' containing
>> one or more TxOuts with script and amount. I believe the general
>> approach
>> is to put a fallback address into 'output' for backward compatibility,
>> and
>> put Q and Q2 into an extension field.
>>
>> So we add a new optional field to PaymentDetails which contains the one
>> or
>> two PubKeys. Not sure if we want different protobuf tags, or if the
>> difference in length of the value makes it obvious enough which approach
>> is being used;
>>
>>     optional bytes stealthOnePubKey = 1000
>>     optional bytes stealthTwoPubKey = 1001
>
> I think you're missing the bigger picture here, not least of which is
> that backwards compatibility is a bit of a misnomer for an unreleased
> standard. :)
>
> Why put this into the PaymentDetails? That a stealth address is to be
> used for the payment is a property of the outputs being requested, not
> the payment itself. We're better off if that goes into the Output
> message, and further more it suggests that the Output message shouldn't
> contain raw scriptPubKey's but rather addresses. After all, IsStandard()
> means we have to inspect the scriptPubKey to see if we can even pay to
> what the sender is requesting.
>
> Once you establish that it's addresses that Outputs specify, then it's
> easy enough to make a stealth address type, or a BIP32-chain-code
> address type, or whatever else comes up in the future.
>
>
>> Also, ideally I think I would want multiple different stealth payments
>> within a single wallet to the same merchant / pubkeys to be identifiable
>> as such.
>
> Agreed.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000bda8ab55740699711a11572c4eec9dc9f714e4896559aac310a115ff
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Re: [Bitcoin-development] Stealth Addresses

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

On Sun, Jan 12, 2014 at 5:33 AM, Jeremy Spilman <jeremy@taplink.co> wrote:

> ...
> Now, you would need to get two pubkeys to the payer, throw in a prefix to
> help standardize it, and end up with addresses that could look like (for
> example):
>
>
> xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX
>
> tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba
>

No, please. Make it easy for non-geeks, extend the payment protocol, or
we'll spend the next two years writing code that tries to ignore linebreaks
and spaces and changing <input> elements in HTML forms to <textarea> ....

-- 
--
Gavin Andrese

[-- Attachment #2: Type: text/html, Size: 1093 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Gregory Maxwell]

On Sun, Jan 12, 2014 at 1:18 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> No, please. Make it easy for non-geeks, extend the payment protocol, or
> we'll spend the next two years writing code that tries to ignore linebreaks
> and spaces and changing <input> elements in HTML forms to <textarea> ....

However, if you're able to use the payment protocol then you probably
don't need stealth addresses to prevent reuse.

E.g. What can I put for a donation address on a totally static
webpage? or on a billboard?

At least thats what I understood these things were trying to solve—
fix privacy where realtime two way communication just isn't available.

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

>
> However, if you're able to use the payment protocol then you probably
> don't need stealth addresses to prevent reuse.
>

I was thinking that people could upload a payment protocol file somewhere
once (like to their personal web page, or shared via dropbox or google
drive or some custom new pastebin style service), and then just encode a
regular bitcoin URI into the qrcode on the billboard.

Likewise, I could attach a payment request to an email and send it to you,
and now you can pay me whenever you want forever.

Getting a little static piece of data to someone *once* should be something
we can make easy. Constantly refreshing it, on the other hand ...

[-- Attachment #2: Type: text/html, Size: 958 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

> I was thinking that people could upload a payment protocol file somewhere
> once (like to their personal web page, or shared via dropbox or google
> drive or some custom new pastebin style service), and then just encode a
> regular bitcoin URI into the qrcode on the billboard.

That does require trusting the third party not to later tamper with
the payment request, though.  (I'm assuming that a signed payment
request is not always going to be all that useful in the case of
private individuals, even assuming the payee is willing to sign up for
one.)

> Likewise, I could attach a payment request to an email and send it to you,
> and now you can pay me whenever you want forever.

That certainly sounds like a plausible use case.  You do still have
the problem that e-mail is an insecure channel, but it's no worse than
exchanging Bitcoin addreses over e-mail as things stand at the
moment.

roy

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]

On Mon, Jan 13, 2014 at 2:37 PM, Roy Badami <roy@gnomon.org.uk> wrote:

> That does require trusting the third party not to later tamper with
> the payment request, though.


You have to trust the billboard owner too. If you're relying on a third
party to relay a payment instruction, that will always be an issue, hence
the signing.

Signing a payment request for an individual is easy, anyway, depending on
the kind of ID you want. If you want to sign with an email address, just go
here with a browser like Chrome/Safari/IE that uses the system keystore:

   http://www.comodo.com/home/email-security/free-email-certificate.php

They'll send you an email, you click the link to verify, and a cert will be
generated and installed by your web browser. It's actually easier than
signing up for a website. There are lots of other places that do it for
free too, I just picked the first one from a google search for [free email
certificate].

Once you've got that in your keystore, a wallet app can quite easily be
told to sign payment requests with your email address.

For a billboard I guess you'd probably be an organisation or company
instead, though an email address can work there too as long as you have a
well known domain name.

[-- Attachment #2: Type: text/html, Size: 1910 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
> Signing a payment request for an individual is easy, anyway, depending on
> the kind of ID you want. If you want to sign with an email address, just go
> here with a browser like Chrome/Safari/IE that uses the system keystore:
> 
>    http://www.comodo.com/home/email-security/free-email-certificate.php
> 

Ok, cool, I wasn't aware of such services, and I can certainly see
they could be useful.  But it's not that great for the business card
scenario.

As far as I can see, using it in that scenario would have to rely on
the payer scanning the QR code on the business card, and then check
that the email address displayed by their wallet matched the email
address printed on the business card.

roy

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
> 
> Signing a payment request for an individual is easy, anyway, depending on
> the kind of ID you want. If you want to sign with an email address, just go
> here with a browser like Chrome/Safari/IE that uses the system keystore:
> 
>    http://www.comodo.com/home/email-security/free-email-certificate.php

Having now read that page, I'll just leave you with the first bullet
point from it:

 * Digital signature ensures confidentiality

(I'm not trying to make any particular point here - I just couldn't resist)


roy

Re: [Bitcoin-development] Stealth Addresses

[Drak]

[-- Attachment #1: Type: text/plain, Size: 166 bytes --]

Sorry this is possibly OT, but someone posted this thread to r/bitcoin and
it's gone straight to position 1. People are really enthusiastic about this
feature.

Drak

[-- Attachment #2: Type: text/html, Size: 288 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Ben Davenport]

[-- Attachment #1: Type: text/plain, Size: 2350 bytes --]

Love what's happening here, and how quickly things are moving, from initial
concept, to first implementation, to first transaction.

But may I suggest we consider changing the name "stealth address" to
something more neutral?

Already, many people on Reddit and elsewhere are misinterpreting the
purpose of such addresses, whether for tax evasion, criminal activity, or
who knows what. Bitcoin already has plenty of political hurdles based
sheerly on the technology. We don't need to make life harder for ourselves.
Even forgetting about politics, the "stealth" association just seems to
imply something secretive going on. Is a Fortune 500 company or worldwide
charity going to want to use something called a "stealth address"?

I'd propose the alternate term "routing address".

- It's a descriptive, neutral term
- It accurately describes what the address is: it's a way to route payment
to a recipient, but not the actual final address
- It can be analogized to a bank's routing number: It is uniquely, publicly
and persistently tied to the receiving institution. The payor and payee
knows when payment is made using it, but it's not publicly visible.

That's the best I've got, but here are some alternate terms in case that
doesn't work:

- reusable public address
- permanent public address
- permanent address
- static address

I don't like these quite as much because they're not as clear. Normal
addresses are all reusable, permanent and static -- they just _shouldn't_
be used that way.

Ben


On Tue, Jan 14, 2014 at 4:19 PM, Drak <drak@zikula.org> wrote:

> Sorry this is possibly OT, but someone posted this thread to r/bitcoin and
> it's gone straight to position 1. People are really enthusiastic about this
> feature.
>
> Drak
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 3471 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Gregory Maxwell]

On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport <bendavenport@gmail.com> wrote:
> But may I suggest we consider changing the name "stealth address" to
> something more neutral?

ACK.  Regardless of the 'political' overtones, I think stealth is a
little cringe-worthy.

"Private address" would be fine if not for confusion with private-keys.

"Static address" is perhaps the best in my view. (also helps improve
awareness that normal addresses are intended to be more one-use-ness)

Re: [Bitcoin-development] Stealth Addresses

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

"static address" seems like a reasonable attempt at describing intended
use/direction.



On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport <bendavenport@gmail.com>
> wrote:
> > But may I suggest we consider changing the name "stealth address" to
> > something more neutral?
>
> ACK.  Regardless of the 'political' overtones, I think stealth is a
> little cringe-worthy.
>
> "Private address" would be fine if not for confusion with private-keys.
>
> "Static address" is perhaps the best in my view. (also helps improve
> awareness that normal addresses are intended to be more one-use-ness)
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

[-- Attachment #2: Type: text/html, Size: 2278 bytes --]

[Bitcoin-development] Static addresses on chains encouraging address *RE* use

[Troy Benjegerdes]

Let's suppose I have an alternate blockchain that specifically encourages
address *RE* use, and charges those that desire privacy higher transaction
fees to cover the network cost in computation and storage.

Does the static address privacy system still work, or does it fall apart
because 95% of the transactions re-use addresses, making them 'effectively 
static', just like my DHCP IP that has not changed as long as I've used it?


On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> "static address" seems like a reasonable attempt at describing intended
> use/direction.
> 
> 
> 
> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> 
> > On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport <bendavenport@gmail.com>
> > wrote:
> > > But may I suggest we consider changing the name "stealth address" to
> > > something more neutral?
> >
> > ACK.  Regardless of the 'political' overtones, I think stealth is a
> > little cringe-worthy.
> >
> > "Private address" would be fine if not for confusion with private-keys.
> >
> > "Static address" is perhaps the best in my view. (also helps improve
> > awareness that normal addresses are intended to be more one-use-ness)
> >

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

Do any people who aren't computer programmers or physicists ever use the
term "static"?

I liked routing address.


On Wed, Jan 15, 2014 at 9:44 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:

> "static address" seems like a reasonable attempt at describing intended
> use/direction.
>
>
>
> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell@gmail.com>wrote:
>
>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport <bendavenport@gmail.com>
>> wrote:
>> > But may I suggest we consider changing the name "stealth address" to
>> > something more neutral?
>>
>> ACK.  Regardless of the 'political' overtones, I think stealth is a
>> little cringe-worthy.
>>
>> "Private address" would be fine if not for confusion with private-keys.
>>
>> "Static address" is perhaps the best in my view. (also helps improve
>> awareness that normal addresses are intended to be more one-use-ness)
>>
>>
>> ------------------------------------------------------------------------------
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critical Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 3810 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> "static address" seems like a reasonable attempt at describing intended
> use/direction.

...as opposed to an address configured by DHCP?

More seriously, I don't think a typical user will understand anything from
the phrase "static address".  But it is a neutral name, and it is shorter
than "address-of-a-type-for-which-reuse-is-not-deprecated". :-)

-roy

Re: [Bitcoin-development] Stealth Addresses

[Jeff Garzik]

"Routing address" is pretty good too.  Unsure whether the synergy and
familiarity with bank routing numbers improves the situation, or
not...


On Wed, Jan 15, 2014 at 6:04 PM, Roy Badami <roy@gnomon.org.uk> wrote:
> On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
>> "static address" seems like a reasonable attempt at describing intended
>> use/direction.
>
> ...as opposed to an address configured by DHCP?
>
> More seriously, I don't think a typical user will understand anything from
> the phrase "static address".  But it is a neutral name, and it is shorter
> than "address-of-a-type-for-which-reuse-is-not-deprecated". :-)
>
> -roy



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

How about just calling them 'type S addresses'?

Not sure any other name will in reality convey much more meaning than
that.

On Wed, Jan 15, 2014 at 06:07:28PM -0500, Jeff Garzik wrote:
> "Routing address" is pretty good too.  Unsure whether the synergy and
> familiarity with bank routing numbers improves the situation, or
> not...
> 
> 
> On Wed, Jan 15, 2014 at 6:04 PM, Roy Badami <roy@gnomon.org.uk> wrote:
> > On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> >> "static address" seems like a reasonable attempt at describing intended
> >> use/direction.
> >
> > ...as opposed to an address configured by DHCP?
> >
> > More seriously, I don't think a typical user will understand anything from
> > the phrase "static address".  But it is a neutral name, and it is shorter
> > than "address-of-a-type-for-which-reuse-is-not-deprecated". :-)
> >
> > -roy
> 
> 
> 
> -- 
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
> 

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

On Wed, Jan 15, 2014 at 11:17:33PM +0000, I wrote:
> How about just calling them 'type S addresses'?

(Assuming they're encoded in such as way that they actually start with 's'.
Otherwise whatever prefix is actually used, obviously.)

[Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)

[Adam Back]

So I like static address name too.  In the write up for my variant I called
it something less sexy than stealth "unlinkable public address":

https://bitcointalk.org/index.php?topic=317835.msg4103530#msg4103530

(there are 3 variants that are approximately the same thing).

Maybe we could call it an unlinkable static address.  Otherwise static
addresses are maybe too synonymous with reused addresses a bad practice we
have been complaining about users and wallet authors incorrectly doing.

But to explain, in Peter Todds (and Amir Taaki also?) variant stealth refers
to an actual useful security criteria.  Stealth objective actually means
"looks like a normal bitcoin payment to the outside observer".  You
generally want that to be the case for fungibility reasons.  Its like
browser cookie state, the more things that are unusual about your
transaction, the more your transactions identify you in the public
block-chain.  Statistics are cumulative so it matters.


And is an actual element of stealthiness (hence the name) in this variant
that Peter Todd proposed, at least as an objective, though I think the
stealthiness somewhat fails because the P parameter is extra and not present
in a normal transaction.

Unfortunately so far removing P and using an input in its stead breaks
CoinJoin which is also necessary for fungibility.  Maybe there is another
way to make an extended CoinJoin that can mix inputs and unlinkable static
addresses.


I was meaning to comment on the SPV privacy properties.

For full-node use these unlinkable static addresses have quite nice
properties.  It also nicely solves the problem of having to educate users
and wallet authors to not reuse addresses.  But for SPV nodes they have no
direct-way to find the payments.  So then in Peter Todd's variant (maybe it
was suggested by Greg Maxwell?) there is a second address so that the SPV
client can delegate detection to a full node without giving it the private
key allowing it to spend!  (This is something analogous to bloom filtering). 
But I think its moderately expensive for the full node because it has to do
a DH calculation per transaction and its not precomputable so there is IO
per query.  (In the P version in fact only payments which are thereby
reconizable as unlinkable static need to be processed).

Then an artificial prefix is proposed to constrain the query to a subset,
however that leaks to everyone so in some wayts its a worse privacy leak
than bloom filtering.  It can be used to rule out recipients and could be
quite a powerful extra lever for statistical analysis.  (And also there is
proposed a version of the prefix computed via brute-force to make it
somewhat stealthy still).


So I also am quite enthusiastic about the possiblity to fix this address
reuse problem, but there remain a few open problems in my view, for SPV
uses.  Not nay-saying, I spent quite a bit of time trying to solve this for
my variant, its a tricky problem, or basically we wouldnt have one-use
addresses and bloom filtering.


But maybe its intereting enough already for full-node uses.  Many processors
and businesses are full nodes.  Many power users run full-nodes  The data
isnt lost, you just need to scan a full-node.

It could help the related problem of paying the wrong person.  Ie deposit
address given by merchant.  If the deposit address is static, and the used
address user derived from it, then that itself is an assurance to the user
that they are paying an address at least owned by the service.  (As opposed
to someone who hacked the web site or MITM the link).  Of course for users
probably the main likelihood is they have malware on their machine, but that
is what offline wallets are for.  A smartphone is maybe a little less
hackable and could be trained to store the static address and warn if its
not the same as the last time they used the site.  (TOFU for bitcoin
addresses, or at least be able to call someone you know who also uses the
service and compare static addresses).

Maybe in the payment address case the service should choose the derivation
factor and communicate it and the client with the static address, as
suggeste by Alan Reiner because then it can also serve the function of
allowing the service to tie the payment to the users account.

People also mention payment protocol for certifying addresses however I
think it is useful to have address level TOFU / static to principal
verification because it is simpler for harware wallets, maps to account
number concept users understand, and doesnt rely on the CA infrastructure. 
Also the typical payment protcol is talking about a message constructed by a
web app.  Thats millions of lines of web server, script language, db code
etc in play on an online server.  The static address private key would be
airgapped from that mess.  

Mike Hearn proposed if I understand that you could something analogous and
upload in batches signed payment protocol sub-messages from a different CA
certificate key.  But I think the above is simpler, and its useful to have
something that works at the low level.  What we have now is like SSH without
the knownhosts cache.  Lets add it.  It can then play with the payment
protocol at the address level.

Adam

On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
>   "static address" seems like a reasonable attempt at describing intended
>   use/direction.
>
>   On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell
>   <[1]gmaxwell@gmail.com> wrote:
>
>   On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport
>   <[2]bendavenport@gmail.com> wrote:
>   > But may I suggest we consider changing the name "stealth address" to
>   > something more neutral?
>
>     ACK.  Regardless of the 'political' overtones, I think stealth is a
>     little cringe-worthy.
>     "Private address" would be fine if not for confusion with
>     private-keys.
>     "Static address" is perhaps the best in my view. (also helps improve
>     awareness that normal addresses are intended to be more
>     one-use-ness)
>
>   -----------------------------------------------------------------------
>   -------
>   CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>   Learn Why More Businesses Are Choosing CenturyLink Cloud For
>   Critical Workloads, Development Environments & Everything In Between.
>   Get a Quote or Start a Free Trial Today.
>   [3]http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ost
>   g.clktrk
>   _______________________________________________
>   Bitcoin-development mailing list
>   [4]Bitcoin-development@lists.sourceforge.net
>   [5]https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>   --
>   Jeff Garzik
>   Bitcoin core developer and open source evangelist
>   BitPay, Inc.      [6]https://bitpay.com/
>
>References
>
>   1. mailto:gmaxwell@gmail.com
>   2. mailto:bendavenport@gmail.com
>   3. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>   4. mailto:Bitcoin-development@lists.sourceforge.net
>   5. https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>   6. https://bitpay.com/

>------------------------------------------------------------------------------
>CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>Learn Why More Businesses Are Choosing CenturyLink Cloud For
>Critical Workloads, Development Environments & Everything In Between.
>Get a Quote or Start a Free Trial Today.
>http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)

[Jeremy Spilman]

On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back <adam@cypherspace.org> wrote:
> I was meaning to comment on the SPV privacy properties.
>
> For full-node use these unlinkable static addresses have quite nice
> properties.  It also nicely solves the problem of having to educate users
> and wallet authors to not reuse addresses.  But for SPV nodes they have  
> no direct-way to find the payments.  So then in Peter Todd's variant  
> (maybe it was suggested by Greg Maxwell?) there is a second address so  
> that the SPV
> client can delegate detection to a full node without giving it the  
> private key allowing it to spend!  (This is something analogous to bloom  
> filtering).

The second pubKey is useful for delegating scanning, or even just being  
able to scan for transactions yourself without keeping bitcoin-encumbered  
private keys decrypted in memory. So even while running your own full node  
there are good reasons to use a second pubKey to derive the shared secret.

> But I think its moderately expensive for the full node because it has to  
> do a DH calculation per transaction and its not precomputable so there  
> is IO
> per query.  (In the P version in fact only payments which are thereby
> reconizable as unlinkable static need to be processed).

And of course, if you have multiple reuseable addresses, then you're doing  
this calculation separately to check each one.

So the load on a popular centralized service would be quite high, which  
you may consider a feature.

>
> Then an artificial prefix is proposed to constrain the query to a subset,
> however that leaks to everyone so in some ways its a worse privacy leak
> than bloom filtering.  It can be used to rule out recipients and could be
> quite a powerful extra lever for statistical analysis.

Choosing how many bits to put in the prefix may be difficult, particularly  
if transaction load changes dramatically over time. 0 or 1 bits may be  
just fine for a single user running their own node, whereas a central  
service might want 4 or 5 bits to keep their computation costs scalable.

But I think it's great people can choose how to trade privacy for  
computation/bandwidth however they want, and services can compete to offer  
monitoring for 0+ bit prefixes.

> (And also there is proposed a version of the prefix computed via
> brute-force to make it somewhat stealthy still).

I think in this case the hash grinding of the prefix would only being used  
if thats how transactions are being indexed. I don't think it adds any  
privacy, it's just added work we're forced to do in order for the prefix  
to work as designed. Peter, please correct me if I'm wrong.


>
> Maybe in the payment address case the service should choose the  
> derivation factor and communicate it and the client with the static
> address, as suggested by Alan Reiner because then it can also serve
> the function of allowing the service to tie the payment to the users
> account.

I think any change which requires more than a single published public  
message (e.g. a posting in a forum, or in a README.me in Github) should be  
seen as solving an entirely different problem.

If you have directed communication from payee->payer, I think there's  
simply no reason to do it this way. (By "this way" I mean ECDH with  
OP_RETURN P).

We could try to define a different reusable address type, for when you can  
make a single directed message from payer->payee, and in that case there's  
probably no need for ECDH or the prefix, like Alan's proposal.

But once you admit having that directed communication, then you are  
swimming very close to the payment protocol.

Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)

[Gregory Maxwell]

On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
> Choosing how many bits to put in the prefix may be difficult, particularly
> if transaction load changes dramatically over time. 0 or 1 bits may be
> just fine for a single user running their own node, whereas a central
> service might want 4 or 5 bits to keep their computation costs scalable.

Ignoring prefixes the cost for each reusable address is only a small
percentage of the full node cost (rational: each transaction has one
or more ECDSA signatures, and the derivation is no more expensive), so
I would only expect computation to be an issue for large centralized
services. (non-full nodes suffer more from just the bandwidth impact).

I'd point out that regardless of how long the desired prefix is, the
encoded prefix should probably always be constant length in all
reusable addresses. If you don't want a particular prefix then the
sender should just pick random data for the rest of the space. There
is no need to publish any additional distinguishing data in the form
of how long the prefix is.

Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)

[Troy Benjegerdes]

On Wed, Jan 15, 2014 at 05:32:31PM -0800, Gregory Maxwell wrote:
> On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
> > Choosing how many bits to put in the prefix may be difficult, particularly
> > if transaction load changes dramatically over time. 0 or 1 bits may be
> > just fine for a single user running their own node, whereas a central
> > service might want 4 or 5 bits to keep their computation costs scalable.
> 
> Ignoring prefixes the cost for each reusable address is only a small
> percentage of the full node cost (rational: each transaction has one
> or more ECDSA signatures, and the derivation is no more expensive), so
> I would only expect computation to be an issue for large centralized
> services. (non-full nodes suffer more from just the bandwidth impact).

I have not seen anyone address my high-level question to (somewhat) complicated
mechanisms to keep coin flows private.

Who pays for it? From what I see it's going to double the amount of data 
needed per address, further centralizing 'full' nodes. I'm fine if the NSA
is paying for privacy (I actually trust them more than banks and advertisers),
but let's just be honest, okay?

If socializing the cost of privacy is Bitcoin's goal, and giving the benefits
to a few that understand it and/or have the resources to determine privacy
providers that won't scam them, then say so, so I can get on with launching
a 'transparencycoin' with a modified code that explicitly ALWAYS re-uses
addresses, and has miners and pools that charge more for addresses they have
never seen before. I bet it will be more distributed and have about half the
average transaction cost of Bitcoin, because most people *just don't care*
about privacy if they get cheap and/or free services.


-- Troy, transparency advocate who is quite transparent that if you buy me
farmland, I'll shut up about transparency, because I'll be too busy growing
food and giving part of it away.

Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)

[Christophe Biocca]

Like any other mechanism that puts extra data in the blockchain, the
sender pays the fees.

This mechanism is to improve privacy for static addresses (donation
links on websites and so on). I personally don't think it will be used
nearly as much as BIP0032 or the payment protocol (both of which don't
need on-blockchain data), precisely because it increases the fees
required to send funds, but this doesn't externalize costs anymore
than any other use of the blockchain does.

People who don't care about privacy and want smallest cost and maximum
convenience already use SPV nodes. Their resource usage will not be
affected in the least.

On Sat, Jan 18, 2014 at 12:44 PM, Troy Benjegerdes <hozer@hozed.org> wrote:
> On Wed, Jan 15, 2014 at 05:32:31PM -0800, Gregory Maxwell wrote:
>> On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
>> > Choosing how many bits to put in the prefix may be difficult, particularly
>> > if transaction load changes dramatically over time. 0 or 1 bits may be
>> > just fine for a single user running their own node, whereas a central
>> > service might want 4 or 5 bits to keep their computation costs scalable.
>>
>> Ignoring prefixes the cost for each reusable address is only a small
>> percentage of the full node cost (rational: each transaction has one
>> or more ECDSA signatures, and the derivation is no more expensive), so
>> I would only expect computation to be an issue for large centralized
>> services. (non-full nodes suffer more from just the bandwidth impact).
>
> I have not seen anyone address my high-level question to (somewhat) complicated
> mechanisms to keep coin flows private.
>
> Who pays for it? From what I see it's going to double the amount of data
> needed per address, further centralizing 'full' nodes. I'm fine if the NSA
> is paying for privacy (I actually trust them more than banks and advertisers),
> but let's just be honest, okay?
>
> If socializing the cost of privacy is Bitcoin's goal, and giving the benefits
> to a few that understand it and/or have the resources to determine privacy
> providers that won't scam them, then say so, so I can get on with launching
> a 'transparencycoin' with a modified code that explicitly ALWAYS re-uses
> addresses, and has miners and pools that charge more for addresses they have
> never seen before. I bet it will be more distributed and have about half the
> average transaction cost of Bitcoin, because most people *just don't care*
> about privacy if they get cheap and/or free services.
>
>
> -- Troy, transparency advocate who is quite transparent that if you buy me
> farmland, I'll shut up about transparency, because I'll be too busy growing
> food and giving part of it away.
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

On Sat, Jan 18, 2014 at 11:44:52AM -0600, Troy Benjegerdes wrote:
> > Ignoring prefixes the cost for each reusable address is only a small
> > percentage of the full node cost (rational: each transaction has one
> > or more ECDSA signatures, and the derivation is no more expensive), so
> > I would only expect computation to be an issue for large centralized
> > services. (non-full nodes suffer more from just the bandwidth impact).
> 
> I have not seen anyone address my high-level question to (somewhat) complicated
> mechanisms to keep coin flows private.
> 
> Who pays for it? From what I see it's going to double the amount of data 
> needed per address, further centralizing 'full' nodes. I'm fine if the NSA

Actually the exact encoding is still undetermined - other encodings I
proposed in my original paper are the same size or even smaller than a
standard transaction.

-- 
'peter'[:-1]@petertodd.org
000000000000000190a2900f1a25c507a999fa11116f7bd0126618c1ebc4f5fb

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)

[Jeremy Spilman]

On Wed, 15 Jan 2014 17:32:31 -0800, Gregory Maxwell <gmaxwell@gmail.com>  
wrote:
> I'd point out that regardless of how long the desired prefix is, the
> encoded prefix should probably always be constant length in all
> reusable addresses.

I might be misunderstanding, but I think prefix length must be specified  
in the reusable address, however I agree the prefix actually published to  
the blockchain should be constant length.

> If you don't want a particular prefix then the
> sender should just pick random data for the rest of the space. There
> is no need to publish any additional distinguishing data in the form
> of how long the prefix is.

Let's say the payee's reusable address is '<version> <prefix> <Q1> <Q2>  
...', where <prefix> is 2 bytes. Without any length indicator. What's the  
payer going to put on the blockchain? How would they know what the 'rest  
of the space' is? They would have to put the whole <prefix> verbatim into  
the OP_RETURN without knowing how many bits of <prefix> the payee actually  
wants to see there.

If instead, the address is '<version> <prefix> <prefixLen> <Q1> <Q2> ...'  
where <prefix> is 2 bytes, and <prefixLen> is 1 byte, representing number  
of bits of prefix that should be fixed.

Then payer will know how much of <prefix> from the address should be taken  
verbatim, and the rest of the two bytes would be replaced with random  
data, and exactly two bytes would be put in the OP_RETURN.

If <prefixLen> was zero, the 2 byte prefix in the reusable address must be  
ignored, and an entirely random 2 byte prefix would be put into the  
OP_RETURN.

I'm a bit worried about broken implementations copying the <prefix> from  
the reusable address into OP_RETURN when <prefixLen> is 0, and ending up  
basically identifying the payee. That's the only reason I can think of to  
make '<prefix> <prefixLen>' optional in the reusable address, to prevent  
the opportunity to screw it up. You would *still* put a 2-byte random  
prefix in the OP_RETURN, even if the fields weren't in the address at all.  
It's just a minor concern though.

Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]

On Mon, Jan 20, 2014 at 08:00:05PM -0800, Jeremy Spilman wrote:
> Let's say the payee's reusable address is '<version> <prefix> <Q1> <Q2>  
> ...', where <prefix> is 2 bytes. Without any length indicator. What's the  
> payer going to put on the blockchain? How would they know what the 'rest  
> of the space' is? They would have to put the whole <prefix> verbatim into  
> the OP_RETURN without knowing how many bits of <prefix> the payee actually  
> wants to see there.
> 
> If instead, the address is '<version> <prefix> <prefixLen> <Q1> <Q2> ...'  
> where <prefix> is 2 bytes, and <prefixLen> is 1 byte, representing number  
> of bits of prefix that should be fixed.
> 
> Then payer will know how much of <prefix> from the address should be taken  
> verbatim, and the rest of the two bytes would be replaced with random  
> data, and exactly two bytes would be put in the OP_RETURN.
> 
> If <prefixLen> was zero, the 2 byte prefix in the reusable address must be  
> ignored, and an entirely random 2 byte prefix would be put into the  
> OP_RETURN.
> 
> I'm a bit worried about broken implementations copying the <prefix> from  
> the reusable address into OP_RETURN when <prefixLen> is 0, and ending up  
> basically identifying the payee. That's the only reason I can think of to  
> make '<prefix> <prefixLen>' optional in the reusable address, to prevent  
> the opportunity to screw it up. You would *still* put a 2-byte random  
> prefix in the OP_RETURN, even if the fields weren't in the address at all.  
> It's just a minor concern though.

Something to keep in mind is that it's quite likely that the indexes
available will be over H(scriptPubKey). There's really good engineering
reasons for doing this: you need to be able to create succinct proofs of
fraud in indexes, miner committed and otherwise, and the only way they
are succinct is if you limit the length. Hashes naturally do that
because it's so expensive to generate partial collisions.

If you don't do this on the other hand now you have a situation where
the usual case - max 16 level deep tree -  and worst case - hundreds or
even thousands of levels deep - are vastly different. That's hard to
test for and likely to reveal implementation-specific limits in nasty
ways.

Anyway, grinding nonces isn't much of a burden given it's fast hash
functions. The prefixes in question are fairly small and will be small
for the forseeable future. As I said elsewhere in this thread, even
Javascript has performance that's perfectly adequate for the task.

-- 
'peter'[:-1]@petertodd.org
00000000000000003590a8a20ec9ff5b1c1af3f046a1f62dc1ac9a464721fd8f

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)

[Adam Back]

On Wed, Jan 15, 2014 at 05:02:10PM -0800, Jeremy Spilman wrote:
>The second pubKey is useful [...] even just being able to scan for
>transactions yourself without keeping bitcoin-encumbered private keys
>decrypted in memory.

Agreed.

>On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back <adam@cypherspace.org> wrote:
>>But I think its moderately expensive for the full node because it has to
>>do a DH calculation per transaction and its not precomputable so there is
>>IO per query.  (In the P version in fact only payments which are thereby
>>reconizable as unlinkable static need to be processed).
>
>And of course, if you have multiple reuseable addresses, then you're 
>doing this calculation separately to check each one.
>
>So the load on a popular centralized service would be quite high, 
>which you may consider a feature.

Well only a linear increase, which is not any kind of realistic security
defense for even an academic researcher analysing flows.  More concern is
that it could be expensive enough discourage adoption by full-nodes as an
open/free service to support SPV clients in finding their reusable address
payments.  Its possibly an I/O DoS multiplier: send requests to the full
nodes at a moderate network rate and and watch as its disk thrashes.

>But I think it's great people can choose how to trade privacy for 
>computation/bandwidth however they want, and services can compete to 
>offer monitoring for 0+ bit prefixes.

Its not a decision with user localised effect.  If most users use it with
parameters giving high elimination probability, that affects everyone else's
privacy also.  Also statistical effects are accumulative as more plausibly
related addresses are eliminated at each potentially linked transaction.  I
think once the network flow analysis guys are done with incorporating it,
and if reusable addresses saw significant use, my prediction is the result
will be pretty close to privacy game over and it will undo most if not all
of the hard-won privacy benefit of CoinJoin.  (Recalling CoinJoin is only
adding a bit or two of entropy per join, this elimination effect could
easily undo more than that).

>>(And also there is proposed a version of the prefix computed via
>>brute-force to make it somewhat stealthy still).
>
>I think in this case the hash grinding of the prefix would only being 
>used if thats how transactions are being indexed. I don't think it 
>adds any privacy, it's just added work we're forced to do in order 
>for the prefix to work as designed. 

The point of the stealth security objective is to avoid creating a new and
smaller anonymity set.  If all reusable addresses are easily recognizable as
reusable, thats far more revealing and useful to the network flow analysis.

Adam

Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)

[Troy Benjegerdes]

> >But I think it's great people can choose how to trade privacy for 
> >computation/bandwidth however they want, and services can compete to 
> >offer monitoring for 0+ bit prefixes.
> 
> Its not a decision with user localised effect.  If most users use it with
> parameters giving high elimination probability, that affects everyone else's
> privacy also.  Also statistical effects are accumulative as more plausibly
> related addresses are eliminated at each potentially linked transaction.  I
> think once the network flow analysis guys are done with incorporating it,
> and if reusable addresses saw significant use, my prediction is the result
> will be pretty close to privacy game over and it will undo most if not all
> of the hard-won privacy benefit of CoinJoin.  (Recalling CoinJoin is only
> adding a bit or two of entropy per join, this elimination effect could
> easily undo more than that).

You've got a major social engineering problem here. 

1) who is marketing privacy 
2) how do you validate 'privacy providers' 

Just like all the scamcoins, there will be scamprivacy providers, which will
drive the market price of privacy down to zero.

Who's paying the network/development/bandwidth/etc cost for privacy?

I'd guess 85% of real users don't really care about some abstract 'privacy'
ideal, they just want payments to work and to download cat pictures.

If you say 'regular address re-use is deprecated, and the top 1% in bitcoin
weatlh who own 95% of the miners want privacy', well fine. But you just 
opened yourself up to 'OccupyBitcoin', and an altcoin that ENCOURAGES plain
old regular address re-use and transparency.

Does this stuff still work if regular address re-use is a transparency feature
and not a bug?

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

Might I propose "reusable address".

I think that describes it best to any non-programmer, and even more so  
encourages wallets to present options as 'one time use' vs 'reusable'.

It definitely packs a marketing punch which could help drive adoption. The  
feature is only useful if/when broadly adopted.

I think it meets all the criteria required:

   - Communication between parties is a single message from the payee,  
which may be public
   - Multiple payments to the same address are not publicly linkable on the  
blockchain
   - The payee has explicitly designated they expect to receive more than  
one payment at that address
   - Payer can publicly prove they made a payment to the reusable address  
by revealing a secret

I have high hopes for this feature. The war *against* address reuse may  
soon be a distant memory.

On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik <jgarzik@bitpay.com> wrote:
> "static address" seems like a reasonable attempt at describing intended  
> use/direction.
>
> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell@gmail.com>  
> wrote:
>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport  
>> <bendavenport@gmail.com> wrote:
>>> But may I suggest we consider changing the name "stealth address" to
>>> something more neutral?
>>
>> ACK.  Regardless of the 'political' overtones, I think stealth is a
>> little cringe-worthy.
>>
>> "Private address" would be fine if not for confusion with private-keys.
>>
>> "Static address" is perhaps the best in my view. (also helps improve
>> awareness that normal addresses are intended to be more one-use-ness)

[-- Attachment #2.1: Type: text/html, Size: 2369 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Gregory Maxwell]

On Wed, Jan 15, 2014 at 4:05 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
> Might I propose "reusable address".

I like this too.

Re: [Bitcoin-development] Stealth Addresses

[Mark Friedenbach]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/15/2014 04:05 PM, Jeremy Spilman wrote:
> Might I propose "reusable address".

Say it like it is. This is the only suggestion so far that I really like.

No amount of finger wagging got people to stop using the block chain
for data storage, but news of the OP_RETURN change to relay rules in
0.9 got people to at least be less damaging in how they do it.

Having an officially named "reusable address" format won't stop people
from doing dumb things (e.g. vanity addresses), but at least maybe
they'll stop using traditional addresses for it.

Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS1yafAAoJEAdzVfsmodw40ccQAI0EFAyODzx7yXvlq9idctSd
xisH4xsOMlsW4lV7xReMnhQsCZ5A+qTMcCd7n7a0bveAxWg1srqBDONLXtHZfwiN
Px/TfoJKPt1oIHnCoyN8G6pcuHhbUbL3lV19sH02dGnM9Ystf9F4oeqwDTITYb5i
huqShMfaTdLEig76zPCLQcOT88deIWZgIxc3R4Do4aCDoyh//2LVZKfzQyEJzVms
njgxcVLVRlomofPW+a+60zm/iLsrbmDjwvWSH8IB4d5ik1aO3732pWgNz3X4HSLk
1s9hVEnpN3GLIWmCcPkbrE9RZtcitghjwrt/xOMKQaqprUuFW4COc0fsfzdLIRtP
bhrA/dnhVSxiUnjc7gLJBnB9+udVKdk2aTdJvSMB1PvhW9QKPjU/H4AW/yQYmism
rSr9imurbi3WosTewtwdcQD47SNS4ALMh//3MeHWOBUMEHP7Tki6i8qR+/xOK+vx
zMc4dnnTQsbgu9bKhrU7ia4eoe/UDvPoLck5cb2+PwYTInfdYBWn1ivbHO7S5ppP
R+/Tc8h3TyLLcPQmH0tpSX+C/YwvctiGsd+iXBRfSTe7o+0wLn8NcDNGi7QI0ipQ
iCHJup9K0FJqf9OuH9qYeaWht7cyuRJ5H4P/HNESGZaPSdTHDpStSmAzdtbBZOkI
qrFg7irL2+CxXwI4H6vC
=XEtz
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Stealth Addresses

[Eric Martindale]

[-- Attachment #1: Type: text/plain, Size: 2778 bytes --]

One variation of this, "recycled address", might avert misconceptions that
the "re-use" is exclusive to one's own identity.


Eric Martindale, relentless maker.
http://www.ericmartindale.com
+1 (919) 374-2020 | *BitMessage: *BM-2cWCmYBpV64FRSJpHHKWi1Cfc9W52jydwe
*Note:* Beginning December 11th, 2013, I will only be intermittently
available via email, SMS, and BitMessage.  As a courtesy, please leave a
detailed message so that I can respond in kind.  Thanks!


On Wed, Jan 15, 2014 at 7:05 PM, Jeremy Spilman <jeremy@taplink.co> wrote:

>  Might I propose "reusable address".
>
> I think that describes it best to any non-programmer, and even more so
> encourages wallets to present options as 'one time use' vs 'reusable'.
>
> It definitely packs a marketing punch which could help drive adoption. The
> feature is only useful if/when broadly adopted.
>
> I think it meets all the criteria required:
>
>   - Communication between parties is a single message from the payee,
> which may be public
>   - Multiple payments to the same address are not publicly linkable on the
> blockchain
>   - The payee has explicitly designated they expect to receive more than
> one payment at that address
>   - Payer can publicly prove they made a payment to the reusable address
> by revealing a secret
>
> I have high hopes for this feature. The war *against* address reuse may
> soon be a distant memory.
>
> On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik <jgarzik@bitpay.com>
> wrote:
>
> "static address" seems like a reasonable attempt at describing intended
> use/direction.
>
> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell@gmail.com>wrote:
>
>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport <bendavenport@gmail.com>
>> wrote:
>> > But may I suggest we consider changing the name "stealth address" to
>> > something more neutral?
>>
>> ACK.  Regardless of the 'political' overtones, I think stealth is a
>> little cringe-worthy.
>>
>> "Private address" would be fine if not for confusion with private-keys.
>>
>> "Static address" is perhaps the best in my view. (also helps improve
>>  awareness that normal addresses are intended to be more one-use-ness)
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 4621 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 3693 bytes --]

I like "reusable address".

It is very clear what the intended purpose is and gives a subtle hint that
other types of address should not be re-used.



On 16 January 2014 00:44, Eric Martindale <eric@ericmartindale.com> wrote:

> One variation of this, "recycled address", might avert misconceptions that
> the "re-use" is exclusive to one's own identity.
>
>
> Eric Martindale, relentless maker.
> http://www.ericmartindale.com
> +1 (919) 374-2020 | *BitMessage: *BM-2cWCmYBpV64FRSJpHHKWi1Cfc9W52jydwe
> *Note:* Beginning December 11th, 2013, I will only be intermittently
> available via email, SMS, and BitMessage.  As a courtesy, please leave a
> detailed message so that I can respond in kind.  Thanks!
>
>
> On Wed, Jan 15, 2014 at 7:05 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
>
>>  Might I propose "reusable address".
>>
>> I think that describes it best to any non-programmer, and even more so
>> encourages wallets to present options as 'one time use' vs 'reusable'.
>>
>> It definitely packs a marketing punch which could help drive adoption.
>> The feature is only useful if/when broadly adopted.
>>
>> I think it meets all the criteria required:
>>
>>   - Communication between parties is a single message from the payee,
>> which may be public
>>   - Multiple payments to the same address are not publicly linkable on
>> the blockchain
>>   - The payee has explicitly designated they expect to receive more than
>> one payment at that address
>>   - Payer can publicly prove they made a payment to the reusable address
>> by revealing a secret
>>
>> I have high hopes for this feature. The war *against* address reuse may
>> soon be a distant memory.
>>
>> On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik <jgarzik@bitpay.com>
>> wrote:
>>
>> "static address" seems like a reasonable attempt at describing intended
>> use/direction.
>>
>> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell@gmail.com>wrote:
>>
>>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport <bendavenport@gmail.com>
>>> wrote:
>>> > But may I suggest we consider changing the name "stealth address" to
>>> > something more neutral?
>>>
>>> ACK.  Regardless of the 'political' overtones, I think stealth is a
>>> little cringe-worthy.
>>>
>>> "Private address" would be fine if not for confusion with private-keys.
>>>
>>> "Static address" is perhaps the best in my view. (also helps improve
>>>  awareness that normal addresses are intended to be more one-use-ness)
>>
>>
>>
>> ------------------------------------------------------------------------------
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critical Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 6318 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

On Thu, Jan 16, 2014 at 7:26 AM, Gary Rowe <g.rowe@froot.co.uk> wrote:

> I like "reusable address".
>

Simple and clear, I like it too.

I see the term is routing is used in finance in the USA, but as a Dutch
person I associate "routing address" with network routing, not with
banking. It's non-trivial to translate to a local term.

Wladimir

[-- Attachment #2: Type: text/html, Size: 770 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Odinn Cyberguerrilla]

Yes. Good idea(s).

> Might I propose "reusable address".
>
> I think that describes it best to any non-programmer, and even more so
> encourages wallets to present options as 'one time use' vs 'reusable'.
>
> It definitely packs a marketing punch which could help drive adoption. The
> feature is only useful if/when broadly adopted.
>
> I think it meets all the criteria required:
>
>    - Communication between parties is a single message from the payee,
> which may be public
>    - Multiple payments to the same address are not publicly linkable on
> the
> blockchain
>    - The payee has explicitly designated they expect to receive more than
> one payment at that address
>    - Payer can publicly prove they made a payment to the reusable address
> by revealing a secret
>
> I have high hopes for this feature. The war *against* address reuse may
> soon be a distant memory.
>
> On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik <jgarzik@bitpay.com>
> wrote:
>> "static address" seems like a reasonable attempt at describing intended
>> use/direction.
>>
>> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell@gmail.com>
>> wrote:
>>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport
>>> <bendavenport@gmail.com> wrote:
>>>> But may I suggest we consider changing the name "stealth address" to
>>>> something more neutral?
>>>
>>> ACK.  Regardless of the 'political' overtones, I think stealth is a
>>> little cringe-worthy.
>>>
>>> "Private address" would be fine if not for confusion with private-keys.
>>>
>>> "Static address" is perhaps the best in my view. (also helps improve
>>> awareness that normal addresses are intended to be more
>>> one-use-ness)------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Re: [Bitcoin-development] Stealth Addresses

[Drak]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

On 16 January 2014 00:05, Jeremy Spilman <jeremy@taplink.co> wrote:

>  Might I propose "reusable address".
>
> I think that describes it best to any non-programmer, and even more so
> encourages wallets to present options as 'one time use' vs 'reusable'.
>

The problem is all addresses are reusable and to an average user, addresses
are already reusable so there is little to distinguish the address format.
It might be better to call it a "public address" in common terminology.

Drak

[-- Attachment #2: Type: text/html, Size: 988 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]

I think we have a winner in "reusable address". Yes an existing address can
be reused and will superficially appear to work, it just won't work well.
Calling them reusable addresses helps reinforce the idea in peoples mind
that the other kind shouldn't be reused.


On Thu, Jan 16, 2014 at 11:14 AM, Drak <drak@zikula.org> wrote:

> On 16 January 2014 00:05, Jeremy Spilman <jeremy@taplink.co> wrote:
>
>>  Might I propose "reusable address".
>>
>> I think that describes it best to any non-programmer, and even more so
>> encourages wallets to present options as 'one time use' vs 'reusable'.
>>
>
> The problem is all addresses are reusable and to an average user,
> addresses are already reusable so there is little to distinguish the
> address format.
> It might be better to call it a "public address" in common terminology.
>
> Drak
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 2630 bytes --]

[Bitcoin-development] reusable address privacy problems & fuzzy bait limitations (Re: Stealth Addresses)

[Adam Back]

On Thu, Jan 16, 2014 at 10:14:24AM +0000, Drak wrote:
>   On 16 January 2014 00:05, Jeremy Spilman <[1]jeremy@taplink.co> wrote:
>   > Might I propose "reusable address".
>
>   The problem is all addresses are reusable and to an average user,
>   addresses are already reusable so there is little to distinguish the
>   address format.
>   It might be better to call it a "public address" in common terminology.

Yeah I called my variant "(unlinkable) public" but I also think I prefer
Jeremy's "reusable address" which has the added bonus of being yet another
implied admonishment not to reuse the non-reusable ones :)

Anyway my primary concern so far is that the reusable addresses/(unlinkable)
public addresses are actually worse for privacy than SPV bloom mechanism by
any reasonable definition.  So I think we have some work to do yet, on a
tough problem which may not have an efficient index precomputable solution
(or a solution period.)  I would also have been promoting this as an
alternative solution to bloom privcy mechanism and address-reuse, if I
could've found a mechansim for the unlinkable public proposal...

Whats different so far I think is that Peter just went with it anyway
despite that problem, where as I put it in the pile of interesting but not
quite workable for privacy reasons ideas.  (Bearing in mind that my bloom
bait concept is the same as the prefix concept so I had functional
equivalence).  The additional feature of Peter's variant is to stealthify
the payment, which I do think is a useful additioanl consideration, however
as I said I think its fair to say it so far largely fails to do that,
because the exposed P parameter.  (And using the input instead of the P
parameter breaks CoinJoin, which is also thereby damaging to privacy).

So also about Greg Maxwell's improved prefix/bloom bait (lets call it fuzzy
bloom bait), while I agree that H(nonce)[rand(32)] ^ prefix is an
interesting incremental improvement, over raw bloom bait/prefix (with an
example 8-bit prefix, and [] being byte index, ^=xor), it is
index-precomputable, but it still publicly allows statistical elimination
which is still nearly as dangerous in lieu of the remarkable success people
have had doing statistical network flow analysis.  ie with probability
(255/256)^32=88% it eliminates you as a payee of any given reusable payment. 
(And that effect remains with any parameter set and conflicts with bandwidth
efficiency for the requestor - ie lower elimination probability seems
unavoidably to imply higher false positive match, right down to the point of
downloading the entire set, giving with 0 probability).

Thinking-hats time people.

(As I said I still like reusable-addr for full-node recipient scenarios.)

Adam

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2979 bytes --]

On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
> Might I propose "reusable address".
> 
> I think that describes it best to any non-programmer, and even more
> so encourages wallets to present options as 'one time use' vs
> 'reusable'.
> 
> It definitely packs a marketing punch which could help drive
> adoption. The feature is only useful if/when broadly adopted.

I'm very against the name "reusable addresses" and strongly belive we
should stick with the name stealth addresses.

You gotta look at it from the perspective of a user; lets take standard
pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
times as I want and everything works just great. I also can enter the
address on blockchain.info's search box, and every transaction related
to the address, and the balance of it, pops up immediately.

What is that telling me? A: Addresses starting with "1" are reusable. B:
Transactions associated with them appear to be public knowledge.

Now I upgrade my wallet software and it says I now have a "reusable"
address. My reaction is "Huh? Normal addresses are reusable, what's
special about this weird reusable address thing that my buddy Bob's
wallet software couldn't pay." I might even try to enter in a "reusable"
address in blockchain.info, which won't work, and I'll just figure
"must be some new unsupported thing" and move on with my life.

On the other hand, suppose my wallet says I now have "stealth address"
support. I'm going to think "Huh, stealth? I guess that means privacy
right? I like privacy." If I try searching for a stealth address on
blockchain.info, when it doesn't work I might think twig on "Oh right!
It said stealth addresses are private, so maybe the transactions are
hidden?" I might also think "Maybe this is like stealth/incognito mode
in my browser? So like, there's no history being kept for others to
see?" Regardless, I'm going to be thinking "well I hear scary stuff
about Bitcoin privacy, and this stealth thing sounds like it's gonna
help, so I should learn more about that"

Finally keep in mind that stealth addresses have had a tonne of very
fast, and very wide reaching PR. The name is in the public conciousness
already, and trying to change it now just because of vague bad
associations is going to throw away the momentum of that good PR and
slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
based on conversations there with people there, technical and
non-technical, almost everyone had heard about them and almost everyone
seemed to understand the basic idea of why they were a good thing. That
just wouldn't have happened with a name that tried to hide what stealth
addresses were for, and by changing the name now we risk people not
making the connection when wallet software gets upgraded to support
them.

-- 
'peter'[:-1]@petertodd.org
0000000000000001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Johnathan Corgan]

[-- Attachment #1.1: Type: text/plain, Size: 638 bytes --]

On 01/16/2014 01:28 PM, Peter Todd wrote:

> I'm very against the name "reusable addresses" and strongly belive we
> should stick with the name stealth addresses.

I agree wholeheartedly against using "reusable address".  I personally
am fine with "stealth address", but can see where there might be a
negative connotation.

Might I suggest "master address", which is neutral in connotation, but
indicates both that it is fixed and that payment addresses are generated
as needed from it.

But please, no "reusable address."

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com

[-- Attachment #1.2: johnathan.vcf --]
[-- Type: text/x-vcard, Size: 335 bytes --]

begin:vcard
fn:Johnathan Corgan
n:Corgan;Johnathan
org:Corgan Enterprises LLC dba Corgan Labs
adr:;;6081 Meridian Ave. Suite 70-111;San Jose;CA;95120;United States
email;internet:johnathan@corganlabs.com
title:Managing Partner
tel;work:+1 408 463 6614
x-mozilla-html:FALSE
url:http://corganlabs.com
version:2.1
end:vcard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

I hear you, and I really don't care that much what it's called, as much as, does it work and how!

> I might even try to enter in a "reusable" address in blockchain.info, which won't work, and I'll just figure
> "must be some new unsupported thing" and move on with my life.
> 

Regardless of what it's called, Blockchain.info should tell the user, hey this address doesn't let the whole world see every single payment that's made to it! If you paid something to this address, only you know how to find the payment - look for the stealth address in your transaction list. 

So if we call the address that has the pubKeys the "reusable address" and the address that's generated from the shared secret the "stealth address" then is everyone happy? :-)

Re: [Bitcoin-development] Stealth Addresses

[Drak]

[-- Attachment #1: Type: text/plain, Size: 3946 bytes --]

Peter I agree with you about  "reusable addresses", but aren't we also
trying to get away from the word "address" entirely?  How about calling it
a "payment key" or "reusable payment key" instead? using "stealth" is just
asking for bad press imo.


On 16 January 2014 21:28, Peter Todd <pete@petertodd.org> wrote:

> On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
> > Might I propose "reusable address".
> >
> > I think that describes it best to any non-programmer, and even more
> > so encourages wallets to present options as 'one time use' vs
> > 'reusable'.
> >
> > It definitely packs a marketing punch which could help drive
> > adoption. The feature is only useful if/when broadly adopted.
>
> I'm very against the name "reusable addresses" and strongly belive we
> should stick with the name stealth addresses.
>
> You gotta look at it from the perspective of a user; lets take standard
> pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
> times as I want and everything works just great. I also can enter the
> address on blockchain.info's search box, and every transaction related
> to the address, and the balance of it, pops up immediately.
>
> What is that telling me? A: Addresses starting with "1" are reusable. B:
> Transactions associated with them appear to be public knowledge.
>
> Now I upgrade my wallet software and it says I now have a "reusable"
> address. My reaction is "Huh? Normal addresses are reusable, what's
> special about this weird reusable address thing that my buddy Bob's
> wallet software couldn't pay." I might even try to enter in a "reusable"
> address in blockchain.info, which won't work, and I'll just figure
> "must be some new unsupported thing" and move on with my life.
>
> On the other hand, suppose my wallet says I now have "stealth address"
> support. I'm going to think "Huh, stealth? I guess that means privacy
> right? I like privacy." If I try searching for a stealth address on
> blockchain.info, when it doesn't work I might think twig on "Oh right!
> It said stealth addresses are private, so maybe the transactions are
> hidden?" I might also think "Maybe this is like stealth/incognito mode
> in my browser? So like, there's no history being kept for others to
> see?" Regardless, I'm going to be thinking "well I hear scary stuff
> about Bitcoin privacy, and this stealth thing sounds like it's gonna
> help, so I should learn more about that"
>
> Finally keep in mind that stealth addresses have had a tonne of very
> fast, and very wide reaching PR. The name is in the public conciousness
> already, and trying to change it now just because of vague bad
> associations is going to throw away the momentum of that good PR and
> slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
> based on conversations there with people there, technical and
> non-technical, almost everyone had heard about them and almost everyone
> seemed to understand the basic idea of why they were a good thing. That
> just wouldn't have happened with a name that tried to hide what stealth
> addresses were for, and by changing the name now we risk people not
> making the connection when wallet software gets upgraded to support
> them.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 5297 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 5173 bytes --]

I must say, this shed is mighty fine looking. It'd be a great place to
store our bikes. But, what colour should we paint it?

How about we split the difference and go with "privacy address"? As Peter
notes, that's what people actually like and want. The problem with stealth
is it's got strong connotations with American military hardware and perhaps
thieves sneaking around in the night:

   https://www.google.com/search?tbm=isch&q=stealth

But everyone loves privacy.


On Fri, Jan 17, 2014 at 8:49 AM, Drak <drak@zikula.org> wrote:

> Peter I agree with you about  "reusable addresses", but aren't we also
> trying to get away from the word "address" entirely?  How about calling it
> a "payment key" or "reusable payment key" instead? using "stealth" is just
> asking for bad press imo.
>
>
> On 16 January 2014 21:28, Peter Todd <pete@petertodd.org> wrote:
>
>> On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
>> > Might I propose "reusable address".
>> >
>> > I think that describes it best to any non-programmer, and even more
>> > so encourages wallets to present options as 'one time use' vs
>> > 'reusable'.
>> >
>> > It definitely packs a marketing punch which could help drive
>> > adoption. The feature is only useful if/when broadly adopted.
>>
>> I'm very against the name "reusable addresses" and strongly belive we
>> should stick with the name stealth addresses.
>>
>> You gotta look at it from the perspective of a user; lets take standard
>> pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
>> times as I want and everything works just great. I also can enter the
>> address on blockchain.info's search box, and every transaction related
>> to the address, and the balance of it, pops up immediately.
>>
>> What is that telling me? A: Addresses starting with "1" are reusable. B:
>> Transactions associated with them appear to be public knowledge.
>>
>> Now I upgrade my wallet software and it says I now have a "reusable"
>> address. My reaction is "Huh? Normal addresses are reusable, what's
>> special about this weird reusable address thing that my buddy Bob's
>> wallet software couldn't pay." I might even try to enter in a "reusable"
>> address in blockchain.info, which won't work, and I'll just figure
>> "must be some new unsupported thing" and move on with my life.
>>
>> On the other hand, suppose my wallet says I now have "stealth address"
>> support. I'm going to think "Huh, stealth? I guess that means privacy
>> right? I like privacy." If I try searching for a stealth address on
>> blockchain.info, when it doesn't work I might think twig on "Oh right!
>> It said stealth addresses are private, so maybe the transactions are
>> hidden?" I might also think "Maybe this is like stealth/incognito mode
>> in my browser? So like, there's no history being kept for others to
>> see?" Regardless, I'm going to be thinking "well I hear scary stuff
>> about Bitcoin privacy, and this stealth thing sounds like it's gonna
>> help, so I should learn more about that"
>>
>> Finally keep in mind that stealth addresses have had a tonne of very
>> fast, and very wide reaching PR. The name is in the public conciousness
>> already, and trying to change it now just because of vague bad
>> associations is going to throw away the momentum of that good PR and
>> slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
>> based on conversations there with people there, technical and
>> non-technical, almost everyone had heard about them and almost everyone
>> seemed to understand the basic idea of why they were a good thing. That
>> just wouldn't have happened with a name that tried to hide what stealth
>> addresses were for, and by changing the name now we risk people not
>> making the connection when wallet software gets upgraded to support
>> them.
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 0000000000000001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
>>
>>
>> ------------------------------------------------------------------------------
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critical Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 7309 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Mark Friedenbach]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/17/2014 01:15 AM, Mike Hearn wrote:
> I must say, this shed is mighty fine looking. It'd be a great place
> to store our bikes. But, what colour should we paint it?
> 
> How about we split the difference and go with "privacy address"?
> As

Too close to private key, IMHO.

> Peter notes, that's what people actually like and want. The problem
> with stealth is it's got strong connotations with American military
> hardware and perhaps thieves sneaking around in the night:

And ninjas.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS2PWHAAoJEAdzVfsmodw4QKoP/iCB62bthf+VyOAZFtP/LbU3
op//I06zOd6oj3zSM0B3Qwz0+H3L9OqWeo9yP1KzYb8YG7RelGf6KOh0LBQoo0bY
eEv8EqvJiW0JOi7gmMsaBgxtZ99TKibGVWMramAV+pSOkKbbbQ23O8a3Y2uopZIg
eypB9sUO9STTc/vwEKZRtefoXHWDUF8bXel/YfTGJQjOuxN/z6gsXRPp4xDvySL3
Ll3OvgEGrqIjIodvMZY+V5wzxj/TlU5kCKS6Vug/JEM1U0DmiBBikaR6Yus5m/fC
yyxEQH8jATLZVsAac4Z16rQXj1nTRh4w6X9KCTynEaba5Z8fz38habUNxyjT8JG+
cP+QDQac9Nnxuw6gzM4QRkOiQas5eVNRdzNJ48k2SGDLb7AYPBO/URAV8Cd05caY
Gx1ruC3MVGu7Fu1/9rtKeWMcNyAvpklzs9DhHfqNmYcRCl6NcoaCvxfq3NesI4Z9
uQrTfL9VBUXJJ2z8ZLe3ZAdBz46159JXCBKHIWwZ+fm0uPkelvoUo8oP+OdxwP1x
wGCYmfvuf8lSnud8WM5EDDGo4+7GUU5Pnh9p+o6Lyp4d0WoplUmSvz2XriiANQjq
z/Xo3B321sdLOEI/Nrqnn3S/hMveru7HO7xQx1aUATvYga4ZyFZh/Yp0bwOAESBZ
GoG0piwQbQhoQZMslV4T
=40o3
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Stealth Addresses

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 6179 bytes --]

So far I've only liked the original name "Stealth address" and the
suggestion "routing address".

Should we put this up for some kind of informal vote with comments allowed?
Like a Google docs form?

- Sent from my phone
Den 17 jan 2014 10:18 skrev "Mike Hearn" <mike@plan99.net>:

> I must say, this shed is mighty fine looking. It'd be a great place to
> store our bikes. But, what colour should we paint it?
>
> How about we split the difference and go with "privacy address"? As Peter
> notes, that's what people actually like and want. The problem with stealth
> is it's got strong connotations with American military hardware and perhaps
> thieves sneaking around in the night:
>
>    https://www.google.com/search?tbm=isch&q=stealth
>
> But everyone loves privacy.
>
>
> On Fri, Jan 17, 2014 at 8:49 AM, Drak <drak@zikula.org> wrote:
>
>> Peter I agree with you about  "reusable addresses", but aren't we also
>> trying to get away from the word "address" entirely?  How about calling it
>> a "payment key" or "reusable payment key" instead? using "stealth" is just
>> asking for bad press imo.
>>
>>
>> On 16 January 2014 21:28, Peter Todd <pete@petertodd.org> wrote:
>>
>>> On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
>>> > Might I propose "reusable address".
>>> >
>>> > I think that describes it best to any non-programmer, and even more
>>> > so encourages wallets to present options as 'one time use' vs
>>> > 'reusable'.
>>> >
>>> > It definitely packs a marketing punch which could help drive
>>> > adoption. The feature is only useful if/when broadly adopted.
>>>
>>> I'm very against the name "reusable addresses" and strongly belive we
>>> should stick with the name stealth addresses.
>>>
>>> You gotta look at it from the perspective of a user; lets take standard
>>> pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
>>> times as I want and everything works just great. I also can enter the
>>> address on blockchain.info's search box, and every transaction related
>>> to the address, and the balance of it, pops up immediately.
>>>
>>> What is that telling me? A: Addresses starting with "1" are reusable. B:
>>> Transactions associated with them appear to be public knowledge.
>>>
>>> Now I upgrade my wallet software and it says I now have a "reusable"
>>> address. My reaction is "Huh? Normal addresses are reusable, what's
>>> special about this weird reusable address thing that my buddy Bob's
>>> wallet software couldn't pay." I might even try to enter in a "reusable"
>>> address in blockchain.info, which won't work, and I'll just figure
>>> "must be some new unsupported thing" and move on with my life.
>>>
>>> On the other hand, suppose my wallet says I now have "stealth address"
>>> support. I'm going to think "Huh, stealth? I guess that means privacy
>>> right? I like privacy." If I try searching for a stealth address on
>>> blockchain.info, when it doesn't work I might think twig on "Oh right!
>>> It said stealth addresses are private, so maybe the transactions are
>>> hidden?" I might also think "Maybe this is like stealth/incognito mode
>>> in my browser? So like, there's no history being kept for others to
>>> see?" Regardless, I'm going to be thinking "well I hear scary stuff
>>> about Bitcoin privacy, and this stealth thing sounds like it's gonna
>>> help, so I should learn more about that"
>>>
>>> Finally keep in mind that stealth addresses have had a tonne of very
>>> fast, and very wide reaching PR. The name is in the public conciousness
>>> already, and trying to change it now just because of vague bad
>>> associations is going to throw away the momentum of that good PR and
>>> slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
>>> based on conversations there with people there, technical and
>>> non-technical, almost everyone had heard about them and almost everyone
>>> seemed to understand the basic idea of why they were a good thing. That
>>> just wouldn't have happened with a name that tried to hide what stealth
>>> addresses were for, and by changing the name now we risk people not
>>> making the connection when wallet software gets upgraded to support
>>> them.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0000000000000001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>> Critical Workloads, Development Environments & Everything In Between.
>>> Get a Quote or Start a Free Trial Today.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critical Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 8817 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Drak]

[-- Attachment #1: Type: text/plain, Size: 5451 bytes --]

That could also work. Still, didn't we want to ditch the word address?
Could be a privacy key...
On 17 Jan 2014 09:15, "Mike Hearn" <mike@plan99.net> wrote:

> I must say, this shed is mighty fine looking. It'd be a great place to
> store our bikes. But, what colour should we paint it?
>
> How about we split the difference and go with "privacy address"? As Peter
> notes, that's what people actually like and want. The problem with stealth
> is it's got strong connotations with American military hardware and perhaps
> thieves sneaking around in the night:
>
>    https://www.google.com/search?tbm=isch&q=stealth
>
> But everyone loves privacy.
>
>
> On Fri, Jan 17, 2014 at 8:49 AM, Drak <drak@zikula.org> wrote:
>
>> Peter I agree with you about  "reusable addresses", but aren't we also
>> trying to get away from the word "address" entirely?  How about calling it
>> a "payment key" or "reusable payment key" instead? using "stealth" is just
>> asking for bad press imo.
>>
>>
>> On 16 January 2014 21:28, Peter Todd <pete@petertodd.org> wrote:
>>
>>> On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
>>> > Might I propose "reusable address".
>>> >
>>> > I think that describes it best to any non-programmer, and even more
>>> > so encourages wallets to present options as 'one time use' vs
>>> > 'reusable'.
>>> >
>>> > It definitely packs a marketing punch which could help drive
>>> > adoption. The feature is only useful if/when broadly adopted.
>>>
>>> I'm very against the name "reusable addresses" and strongly belive we
>>> should stick with the name stealth addresses.
>>>
>>> You gotta look at it from the perspective of a user; lets take standard
>>> pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
>>> times as I want and everything works just great. I also can enter the
>>> address on blockchain.info's search box, and every transaction related
>>> to the address, and the balance of it, pops up immediately.
>>>
>>> What is that telling me? A: Addresses starting with "1" are reusable. B:
>>> Transactions associated with them appear to be public knowledge.
>>>
>>> Now I upgrade my wallet software and it says I now have a "reusable"
>>> address. My reaction is "Huh? Normal addresses are reusable, what's
>>> special about this weird reusable address thing that my buddy Bob's
>>> wallet software couldn't pay." I might even try to enter in a "reusable"
>>> address in blockchain.info, which won't work, and I'll just figure
>>> "must be some new unsupported thing" and move on with my life.
>>>
>>> On the other hand, suppose my wallet says I now have "stealth address"
>>> support. I'm going to think "Huh, stealth? I guess that means privacy
>>> right? I like privacy." If I try searching for a stealth address on
>>> blockchain.info, when it doesn't work I might think twig on "Oh right!
>>> It said stealth addresses are private, so maybe the transactions are
>>> hidden?" I might also think "Maybe this is like stealth/incognito mode
>>> in my browser? So like, there's no history being kept for others to
>>> see?" Regardless, I'm going to be thinking "well I hear scary stuff
>>> about Bitcoin privacy, and this stealth thing sounds like it's gonna
>>> help, so I should learn more about that"
>>>
>>> Finally keep in mind that stealth addresses have had a tonne of very
>>> fast, and very wide reaching PR. The name is in the public conciousness
>>> already, and trying to change it now just because of vague bad
>>> associations is going to throw away the momentum of that good PR and
>>> slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
>>> based on conversations there with people there, technical and
>>> non-technical, almost everyone had heard about them and almost everyone
>>> seemed to understand the basic idea of why they were a good thing. That
>>> just wouldn't have happened with a name that tried to hide what stealth
>>> addresses were for, and by changing the name now we risk people not
>>> making the connection when wallet software gets upgraded to support
>>> them.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0000000000000001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>> Critical Workloads, Development Environments & Everything In Between.
>>> Get a Quote or Start a Free Trial Today.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critical Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 7726 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Cameron Garnham]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

One of the possible words that haven't been proposed is 'personal' where
bitcoin addressed are commonly incorrectly called public address.

Maybe 'personal account' or even 'personal address' would imply that the
balance on such an account shouldn't be assumed to be public knowledge.

Cam.


On 17/01/2014 5:59 pm, Drak wrote:
> That could also work. Still, didn't we want to ditch the word address?
> Could be a privacy key...
> 
> On 17 Jan 2014 09:15, "Mike Hearn" <mike@plan99.net
> <mailto:mike@plan99.net>> wrote:
> 
>     I must say, this shed is mighty fine looking. It'd be a great place
>     to store our bikes. But, what colour should we paint it?
> 
>     How about we split the difference and go with "privacy address"? As
>     Peter notes, that's what people actually like and want. The problem
>     with stealth is it's got strong connotations with American military
>     hardware and perhaps thieves sneaking around in the night:
> 
>        https://www.google.com/search?tbm=isch&q=stealth
> 
>     But everyone loves privacy.
> 
> 
>     On Fri, Jan 17, 2014 at 8:49 AM, Drak <drak@zikula.org
>     <mailto:drak@zikula.org>> wrote:
> 
>         Peter I agree with you about  "reusable addresses", but aren't
>         we also trying to get away from the word "address" entirely?
>          How about calling it a "payment key" or "reusable payment key"
>         instead? using "stealth" is just asking for bad press imo.
> 
> 
>         On 16 January 2014 21:28, Peter Todd <pete@petertodd.org
>         <mailto:pete@petertodd.org>> wrote:
> 
>             On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
>             > Might I propose "reusable address".
>             >
>             > I think that describes it best to any non-programmer, and
>             even more
>             > so encourages wallets to present options as 'one time use' vs
>             > 'reusable'.
>             >
>             > It definitely packs a marketing punch which could help drive
>             > adoption. The feature is only useful if/when broadly adopted.
> 
>             I'm very against the name "reusable addresses" and strongly
>             belive we
>             should stick with the name stealth addresses.
> 
>             You gotta look at it from the perspective of a user; lets
>             take standard
>             pay-to-pubkey-hash addresses: I can tell my wallet to pay
>             one as many
>             times as I want and everything works just great. I also can
>             enter the
>             address on blockchain.info <http://blockchain.info>'s search
>             box, and every transaction related
>             to the address, and the balance of it, pops up immediately.
> 
>             What is that telling me? A: Addresses starting with "1" are
>             reusable. B:
>             Transactions associated with them appear to be public knowledge.
> 
>             Now I upgrade my wallet software and it says I now have a
>             "reusable"
>             address. My reaction is "Huh? Normal addresses are reusable,
>             what's
>             special about this weird reusable address thing that my
>             buddy Bob's
>             wallet software couldn't pay." I might even try to enter in
>             a "reusable"
>             address in blockchain.info <http://blockchain.info>, which
>             won't work, and I'll just figure
>             "must be some new unsupported thing" and move on with my life.
> 
>             On the other hand, suppose my wallet says I now have
>             "stealth address"
>             support. I'm going to think "Huh, stealth? I guess that
>             means privacy
>             right? I like privacy." If I try searching for a stealth
>             address on
>             blockchain.info <http://blockchain.info>, when it doesn't
>             work I might think twig on "Oh right!
>             It said stealth addresses are private, so maybe the
>             transactions are
>             hidden?" I might also think "Maybe this is like
>             stealth/incognito mode
>             in my browser? So like, there's no history being kept for
>             others to
>             see?" Regardless, I'm going to be thinking "well I hear
>             scary stuff
>             about Bitcoin privacy, and this stealth thing sounds like
>             it's gonna
>             help, so I should learn more about that"
> 
>             Finally keep in mind that stealth addresses have had a tonne
>             of very
>             fast, and very wide reaching PR. The name is in the public
>             conciousness
>             already, and trying to change it now just because of vague bad
>             associations is going to throw away the momentum of that
>             good PR and
>             slow down adoption. Last night I was at the Toronto Bitcoin
>             Meetup and I
>             based on conversations there with people there, technical and
>             non-technical, almost everyone had heard about them and
>             almost everyone
>             seemed to understand the basic idea of why they were a good
>             thing. That
>             just wouldn't have happened with a name that tried to hide
>             what stealth
>             addresses were for, and by changing the name now we risk
>             people not
>             making the connection when wallet software gets upgraded to
>             support
>             them.
> 
>             --
>             'peter'[:-1]@petertodd.org <http://petertodd.org>
>             0000000000000001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
> 
>             ------------------------------------------------------------------------------
>             CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>             Learn Why More Businesses Are Choosing CenturyLink Cloud For
>             Critical Workloads, Development Environments & Everything In
>             Between.
>             Get a Quote or Start a Free Trial Today.
>             http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>             _______________________________________________
>             Bitcoin-development mailing list
>             Bitcoin-development@lists.sourceforge.net
>             <mailto:Bitcoin-development@lists.sourceforge.net>
>             https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
>         ------------------------------------------------------------------------------
>         CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>         Learn Why More Businesses Are Choosing CenturyLink Cloud For
>         Critical Workloads, Development Environments & Everything In
>         Between.
>         Get a Quote or Start a Free Trial Today.
>         http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>         _______________________________________________
>         Bitcoin-development mailing list
>         Bitcoin-development@lists.sourceforge.net
>         <mailto:Bitcoin-development@lists.sourceforge.net>
>         https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today. 
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREKAAYFAlLZj5cACgkQBJ8cMDO159YxKQEAh8QHHgMaL1IVvfYROU0yKG89
Ap1byTpAvt/+O5chTGQBAK4K+DfUOOkaMvUmssWIVsLQ56xKxsuzZiIJXF2yPI0g
=fcYD
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 3222 bytes --]

On Fri, Jan 17, 2014 at 10:15:40AM +0100, Mike Hearn wrote:
> I must say, this shed is mighty fine looking. It'd be a great place to
> store our bikes. But, what colour should we paint it?

I think we should paint it this colour:

    They had uncovered what seemed to be the side of a large coloured
    globule embedded in the substance. The colour, which resembled some
    of the bands in the meteor's strange spectrum, was almost impossible
    to describe; and it was only by analogy that they called it colour
    at all.  Its texture was glossy, and upon tapping it appeared to
    promise both brittle ness and hollowness. One of the professors gave
    it a smart blow with a hammer, and it burst with a nervous little
    pop. Nothing was emitted, and all trace of the thing vanished with
    the puncturing. It left behind a hollow spherical space about three
    inches across, and all thought it probable that others would be
    discovered as the enclosing substance wasted away.

I think it really gets to the core of my feelings about this naming
discussion.

> How about we split the difference and go with "privacy address"? As Peter
> notes, that's what people actually like and want. The problem with stealth
> is it's got strong connotations with American military hardware and perhaps
> thieves sneaking around in the night:
> 
>    https://www.google.com/search?tbm=isch&q=stealth

WOW! AWESOME KICK-ASS PICS!

Come to think of it, I could have called it "incognito addresses" - a
term nice enough that Google and Firefox use it in their browsers - but
what's done is done and any further discussion about this is just going
to confuse the public. Remember that in the long run all this stuff will
be hidden behind payment protocols anyway, and users *won't even know*
that under the hood a stealth address is being used, making the name
just a technical detail. For now though, lets use the good PR and get
some early adopters on board.

However, the term 'incognito' probably would be a good one to use within
wallet software itself to describe what it's doing when the user clicks
the "I want my transactions to be private" setting - there are after all
fundemental bandwidth-privacy trade-offs in the threat model supposed by
both prefix and bloom filters. In this instance the term isn't going to
go away.


Anyway, back to work: For the actual address format I strongly think we
need to ensure that it can be upgrading in a backwards compatible way.
This means we have to be able to add new fields - for instance if
Gregory's ideas for different ways of doing the SPV-bait came to
fruition. Given that "addresses" aren't something that should stay
user-visible forever, thoughts on just making the actual data a protocol
buffers object?

Second question: Any performance figures yet on how efficient scanning
the blockchain for matching transactions actually is? I'd like to get an
idea soon for both desktop and smartphone wallets so we can figure out
what kind of trade-offs users might be forced into in terms of prefix
length.

-- 
'peter'[:-1]@petertodd.org
0000000000000001c9b372ed519ecc6d41c10b42a7457d1ca5acd560a535596b

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Ben Davenport]

[-- Attachment #1: Type: text/plain, Size: 4027 bytes --]

Well, at least we don't have to worry about cache invalidation.

Ben


On Fri, Jan 17, 2014 at 6:46 AM, Peter Todd <pete@petertodd.org> wrote:

> On Fri, Jan 17, 2014 at 10:15:40AM +0100, Mike Hearn wrote:
> > I must say, this shed is mighty fine looking. It'd be a great place to
> > store our bikes. But, what colour should we paint it?
>
> I think we should paint it this colour:
>
>     They had uncovered what seemed to be the side of a large coloured
>     globule embedded in the substance. The colour, which resembled some
>     of the bands in the meteor's strange spectrum, was almost impossible
>     to describe; and it was only by analogy that they called it colour
>     at all.  Its texture was glossy, and upon tapping it appeared to
>     promise both brittle ness and hollowness. One of the professors gave
>     it a smart blow with a hammer, and it burst with a nervous little
>     pop. Nothing was emitted, and all trace of the thing vanished with
>     the puncturing. It left behind a hollow spherical space about three
>     inches across, and all thought it probable that others would be
>     discovered as the enclosing substance wasted away.
>
> I think it really gets to the core of my feelings about this naming
> discussion.
>
> > How about we split the difference and go with "privacy address"? As Peter
> > notes, that's what people actually like and want. The problem with
> stealth
> > is it's got strong connotations with American military hardware and
> perhaps
> > thieves sneaking around in the night:
> >
> >    https://www.google.com/search?tbm=isch&q=stealth
>
> WOW! AWESOME KICK-ASS PICS!
>
> Come to think of it, I could have called it "incognito addresses" - a
> term nice enough that Google and Firefox use it in their browsers - but
> what's done is done and any further discussion about this is just going
> to confuse the public. Remember that in the long run all this stuff will
> be hidden behind payment protocols anyway, and users *won't even know*
> that under the hood a stealth address is being used, making the name
> just a technical detail. For now though, lets use the good PR and get
> some early adopters on board.
>
> However, the term 'incognito' probably would be a good one to use within
> wallet software itself to describe what it's doing when the user clicks
> the "I want my transactions to be private" setting - there are after all
> fundemental bandwidth-privacy trade-offs in the threat model supposed by
> both prefix and bloom filters. In this instance the term isn't going to
> go away.
>
>
> Anyway, back to work: For the actual address format I strongly think we
> need to ensure that it can be upgrading in a backwards compatible way.
> This means we have to be able to add new fields - for instance if
> Gregory's ideas for different ways of doing the SPV-bait came to
> fruition. Given that "addresses" aren't something that should stay
> user-visible forever, thoughts on just making the actual data a protocol
> buffers object?
>
> Second question: Any performance figures yet on how efficient scanning
> the blockchain for matching transactions actually is? I'd like to get an
> idea soon for both desktop and smartphone wallets so we can figure out
> what kind of trade-offs users might be forced into in terms of prefix
> length.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000001c9b372ed519ecc6d41c10b42a7457d1ca5acd560a535596b
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 5220 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 2625 bytes --]

*Avoiding ECDH calcs on every blockchain transaction (and avoiding the
prefix thing):*

Can we skip the whole ECDSA/ECDH thing, and use the second key pair for
encryption instead?  Then we don't need any ephemeral keys.  We use the
much simpler scheme like I mentioned before (just root keys and
multpliers), but instead of requesting a multiplier from the person
receiving the money, the payer can create their own multiplier and
encrypt it into an OP_RETURN msg (using the secondary public key of the
receiver).  When they do this, they append a deterministic identifier to
it, so that the receiver can immediately identify it upon decryption.

Basically, the receiver simply attempts decryption of every OP_RETURN
message, and if the identifier is there, they immediately know that the
tx is theirs, and that the other bytes of the decrypted message is the
multiplier used.

Of course, using something like ECIES and forcing the receiver to
attempt decryption of every OP_RETURN tx may not be any faster than the
ECDH we've already talked about here.  But with this, we are not tied to
any particular crypto.  Isn't there a much faster asymmetric scheme that
we can use?  I've heard people talk about ed25519, though I'm not sure
it can be used for encryption.  I'd bet money there is an asymmetric
_/encryption/_//algorithm that would be fast enough to not burden the
receiver.

Here's how I envision it:

--Alice gives out her business card that has public key X (BIP32 root),
and public key Y (fastCrypto)
--Bob generates a random 32-byte nonce, and EC-multiplies Alice's public
key by it.   He prepares a transaction sending coins to that address (Z)
--Bob also computes a deterministic identifier, perhaps hash(pubKeyX ||
addrZ)[8:].  Bob appends the those 8 bytes to the multiplier, and
encrypts all of it with Alice's fastCrypto key, Y.   He puts that
message in the OP_RETURN output.
--Alice's wallet will attempt decryption of every OP_RETURN message. 
First she computes hash(pubKeyX, addrZ)[8:], and then decrypts the
message with the fastCrypto private key.  If the tx is actually hers,
the last 8 bytes will match the identifier, and she knows to use the
other 32 bytes as a multiplier.  If it doesn't, it's irrelevant to her
and she moves on.

[**Should probably use 24-byte values for the multipliers (or hashes of
24-byte values), so that adding 8 bytes makes the whole message an even
32 bytes which is better for encryption]

Doesn't this have the exact same properties as the original proposal
(including compatibility with CoinJoin)?  But it all depends on having
fast asymmetric encryption.

-Alan




[-- Attachment #2: Type: text/html, Size: 3210 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Gregory Maxwell]

On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner <etotheipi@gmail.com> wrote:
> Isn't there a much faster asymmetric scheme that we can use?  I've heard people talk about ed25519, though I'm not sure it can be used for encryption.

Doing ECDH with our curve is within a factor of ~2 of the fastest
encryption available at this security level, AFAIK.  And separate
encryption would ~double the amount of data vs using the ephemeral key
for derivation.

Using another cryptosystem would mandate carry around additional code
for a fast implementation of that cryptosystem, which wouldn't be
fantastic.

So I'm not sure much can be improved there.

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

> On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner <etotheipi@gmail.com> wrote:
>> Isn't there a much faster asymmetric scheme that we can use?  I've heard people talk about ed25519, though I'm not sure it can be used for encryption.
> 
> Doing ECDH with our curve is within a factor of ~2 of the fastest
> encryption available at this security level, AFAIK.  And separate
> encryption would ~double the amount of data vs using the ephemeral key
> for derivation.
> 
> Using another cryptosystem would mandate carry around additional code
> for a fast implementation of that cryptosystem, which wouldn't be
> fantastic.
> 
> So I'm not sure much can be improved there.

In the case where payment is being sent only to Q1, and Q2 is for discovery only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20 byte vs 32 bytes in the OP_RETURN, and of course faster multiplication. 

80-bits of security I assume still greatly exceeds the actual level of privacy you get with the overall solution, and since Q2 is never protecting actual funds...

But if it's a "real weakening" of the privacy then definitely not worth it, and even the added complexity of another curve seems possibly not worth it...

Re: [Bitcoin-development] Stealth Addresses

[Gregory Maxwell]

On Sat, Jan 18, 2014 at 3:12 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
> In the case where payment is being sent only to Q1, and Q2 is for discovery only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20 byte vs 32 bytes in the OP_RETURN, and of course faster multiplication.
>
> 80-bits of security I assume still greatly exceeds the actual level of privacy you get with the overall solution, and since Q2 is never protecting actual funds...
>
> But if it's a "real weakening" of the privacy then definitely not worth it, and even the added complexity of another curve seems possibly not worth it...

Well super-fast hand optimized code for (your choice of) 160 bit curve
may not ever exist, making it slower in practice. Plus the extra code
to carry around even if it does exist…

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]

On Sat, Jan 18, 2014 at 05:12:58PM -0600, Jeremy Spilman wrote:
> 
> 
> > On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner <etotheipi@gmail.com> wrote:
> >> Isn't there a much faster asymmetric scheme that we can use?  I've heard people talk about ed25519, though I'm not sure it can be used for encryption.
> > 
> > Doing ECDH with our curve is within a factor of ~2 of the fastest
> > encryption available at this security level, AFAIK.  And separate
> > encryption would ~double the amount of data vs using the ephemeral key
> > for derivation.
> > 
> > Using another cryptosystem would mandate carry around additional code
> > for a fast implementation of that cryptosystem, which wouldn't be
> > fantastic.
> > 
> > So I'm not sure much can be improved there.
> 
> In the case where payment is being sent only to Q1, and Q2 is for discovery only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20 byte vs 32 bytes in the OP_RETURN, and of course faster multiplication. 
> 
> 80-bits of security I assume still greatly exceeds the actual level of privacy you get with the overall solution, and since Q2 is never protecting actual funds...
> 
> But if it's a "real weakening" of the privacy then definitely not worth it, and even the added complexity of another curve seems possibly not worth it...

Keep in mind that Bitmessage uses the same ECDH mechanism as what
stealth addresses will use. They seem to get decent enough performance
from it for a use-case not-unlike that of a Bitcoin wallet.

In any case I'm interested in knowing actual performance numbers for it;
last I talked to Kyle Drake he said he was working on getting ECDH
numbers on Javascript, probably the slowest possible implementation of
the idea. As for send to stealth addresses using prefixes, he's
confirmed that you'll be able to do that will well under a second to
brute-force the prefixes with the proposed OP_RETURN mechanism even with
rather long 8-bit prefixes.

-- 
'peter'[:-1]@petertodd.org
000000000000000190a2900f1a25c507a999fa11116f7bd0126618c1ebc4f5fb

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

> > Likewise, I could attach a payment request to an email and send it to you,
> > and now you can pay me whenever you want forever.
> 
> That certainly sounds like a plausible use case.  You do still have
> the problem that e-mail is an insecure channel, but it's no worse than
> exchanging Bitcoin addreses over e-mail as things stand at the
> moment.

On further reflection, I'm not sure I understand this use case of the
payment protocol.  Since a PaymentRequest currently contains the
Outputs that specify the addresses to send to, reusing a
PaymentRequest like this without using stealth addresses implies
address reuse.

(Granted there are alternative solutions to stealth addresses, such as
a BIP32-style derivation.)

roy

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

>
> On further reflection, I'm not sure I understand this use case of the
> payment protocol.  Since a PaymentRequest currently contains the
> Outputs that specify the addresses to send to, reusing a
> PaymentRequest like this without using stealth addresses implies
> address reuse.


Yes indeed ...... which is why we're talking about extending the protocol
(in a future version! the first version isn't even out yet!).

[-- Attachment #2: Type: text/html, Size: 667 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

rOn Mon, Jan 13, 2014 at 08:57:33PM +0100, Mike Hearn wrote:
> >
> > On further reflection, I'm not sure I understand this use case of the
> > payment protocol.  Since a PaymentRequest currently contains the
> > Outputs that specify the addresses to send to, reusing a
> > PaymentRequest like this without using stealth addresses implies
> > address reuse.
> 
> 
> Yes indeed ...... which is why we're talking about extending the protocol
> (in a future version! the first version isn't even out yet!).

Yes, sorry, I miscontrued the thread here and now see that your
message was exactly talking about using stealth addresses within the
payment protocol.

Sorry for the confusion.

roy

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

On Mon, Jan 13, 2014 at 01:52:25AM -0800, Gregory Maxwell wrote:
> On Sun, Jan 12, 2014 at 1:18 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> > No, please. Make it easy for non-geeks, extend the payment protocol, or
> > we'll spend the next two years writing code that tries to ignore linebreaks
> > and spaces and changing <input> elements in HTML forms to <textarea> ....
> 
> However, if you're able to use the payment protocol then you probably
> don't need stealth addresses to prevent reuse.

I definitely think this is a case that should be addressed better than
at present.

To consider a concrete use case, imagine I wish to be able to give my
friends and acquaintances a paper business card with a QR code on it,
that they can use to make payments to me.  I don't own a domain or any
kind of X.509 certificate and I don't run an HTTP server.  I don't
feel comfortable with a solution that requires me to trust a third
party to complete the payments.

At the moment, I can give them a business card with a Bitcoin address.
Being able to give out a business card with a stealth address would be
a major advance.

roy

Re: [Bitcoin-development] Stealth Addresses

[Drak]

[-- Attachment #1: Type: text/plain, Size: 259 bytes --]

On 13 January 2014 19:40, Roy Badami <roy@gnomon.org.uk> wrote:

> At the moment, I can give them a business card with a Bitcoin address.
> Being able to give out a business card with a stealth address would be
> a major advance.


My thoughts exactly.

Drak

[-- Attachment #2: Type: text/html, Size: 664 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

How is this different from the proposal I have made?

You distribute the root public key (but not chaincode!) of a BIP32
branch.  You can put your root key on a business card if you want.  Then
when someone wants to pay you, you simply give them the multiplier and
root key (they already have the root key, but should verify).  The
multiplier does not reveal the chaincode, thus keeping it private, but
it does allow them to confirm that the final address they are paying is
derived from that root key they know belongs to you ("Please pay address
X; oh btw, X=rootKey*mult").

You can /choose/ to reveal that a given payment address is linked to
your root key without any compromise of privacy.  Or you can choose to
ignore it and just give them a bare address the old way and still
maintain privacy.  What advantages does "stealth addresses" have over
this scheme?  You could extend it using some kind of deterministic
sub-branching and/or ECDH to create multiple payment addresses without
querying the payee. 

I had planned to implement this system and push for people to accept it
because I don't see any downsides to it.  It can easily be integrated
into a WoT (with signed root keys), or CA system piggybacking on SSL.

-Alan


On 01/13/2014 02:44 PM, Drak wrote:
> On 13 January 2014 19:40, Roy Badami <roy@gnomon.org.uk
> <mailto:roy@gnomon.org.uk>> wrote:
>
>     At the moment, I can give them a business card with a Bitcoin address.
>     Being able to give out a business card with a stealth address would be
>     a major advance.
>
>
> My thoughts exactly.
>
> Drak 
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today. 
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #2: Type: text/html, Size: 3941 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Gregory Maxwell]

On Mon, Jan 13, 2014 at 11:59 AM, Alan Reiner <etotheipi@gmail.com> wrote:
> Then when someone
> wants to pay you, you simply give them the multiplier and root key (they
> already have the root key, but should verify).
[...]
> What
> advantages does "stealth addresses" have over this scheme?  You could extend
> it using some kind of deterministic sub-branching and/or ECDH to create
> multiple payment addresses without querying the payee.

The stealth address stuff is the ECDH to create multiple payment
addresses without querying the payee.


Uh while I'm responding again, what I'd discussed with Peter Todd in
IRC used two EC points in the stealth address. One for the payment and
one for the ECDH.  The reason to use two is that it makes delegating
detection possible and so you don't have to have you spending keys
online to even detect these payments.  Why'd that get dropped?

I don't think this is a good idea if you have to constantly keep your
spending key(s) online even to detect payments, even with the limited
use-cases envisioned.

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On Mon, Jan 13, 2014 at 12:10:56PM -0800, Gregory Maxwell wrote:
> Uh while I'm responding again, what I'd discussed with Peter Todd in
> IRC used two EC points in the stealth address. One for the payment and
> one for the ECDH.  The reason to use two is that it makes delegating
> detection possible and so you don't have to have you spending keys
> online to even detect these payments.  Why'd that get dropped?

I mentioned it again in another email; I just forgot to include it in my
final write-up.

-- 
'peter'[:-1]@petertodd.org
00000000000000023d5a8bbe131414328a6c50a2741933ba03775afd3c3db395

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

> Uh while I'm responding again, what I'd discussed with Peter Todd in
> IRC used two EC points in the stealth address. One for the payment and
> one for the ECDH.  The reason to use two is that it makes delegating
> detection possible and so you don't have to have you spending keys
> online to even detect these payments.  Why'd that get dropped?

I think this is exactly what I've implemented.

I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping one of the pubKeys in the OP-RETURN, to prevent a malicious sender from triggering false positives on your online detection key when the funds are actually still fully controlled by the payer.

You can still have a false positive (only 1 of 2 keys actually yours) but the funds would be trapped so it's unlikely anyone would do it. 

Can you take a look at the Gist and TXs on TestNet I sent out, and see if that's in line with what you expected?

I would also greatly appreciate if you could review the discussion around doing two ECDH operations with a single ephemeral key.

Thanks!
--Jeremy

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
> 
> > Uh while I'm responding again, what I'd discussed with Peter Todd in
> > IRC used two EC points in the stealth address. One for the payment and
> > one for the ECDH.  The reason to use two is that it makes delegating
> > detection possible and so you don't have to have you spending keys
> > online to even detect these payments.  Why'd that get dropped?
> 
> I think this is exactly what I've implemented.
> 
> I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping one of the pubKeys in the OP-RETURN, to prevent a malicious sender from triggering false positives on your online detection key when the funds are actually still fully controlled by the payer.
> 
> You can still have a false positive (only 1 of 2 keys actually yours) but the funds would be trapped so it's unlikely anyone would do it. 

How would they trigger false positives? The payee recovers the nonce
with ECDH from the payor's ephemereal pubkey and their online detection
secret key. They use BIP32 public derivation with their offline spending
pubkey(s), if the derived pubkeys match the actual scriptPubKey they
know the output is spendable by them. I don't see how that can go wrong.

-- 
'peter'[:-1]@petertodd.org
000000007dd7a87aec311fb7fb13770f54edf628e6976f8c6091a5b2638878a7

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

On Tue, 14 Jan 2014 06:19:08 -0800, Peter Todd <pete@petertodd.org> wrote:

> On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
>> I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping  
>> one of the pubKeys in the OP-RETURN, to prevent a malicious sender from  
>> triggering false positives on your online detection key when the funds  
>> are actually still fully controlled by the payer.
>>
>> You can still have a false positive (only 1 of 2 keys actually yours)  
>> but the funds would be trapped so it's unlikely anyone would do it.
>
> How would they trigger false positives? The payee recovers the nonce
> with ECDH from the payor's ephemereal pubkey and their online detection
> secret key. They use BIP32 public derivation with their offline spending
> pubkey(s), if the derived pubkeys match the actual scriptPubKey they
> know the output is spendable by them. I don't see how that can go wrong.
>

Right now I have this:

   byte[] e = EC.NewPrivateKey();
   byte[] P = EC.GetPublicKey(e, compressed: true);
   byte[] S1 = EC.DH(e, Q1);
   byte[] S2 = EC.DH(e, Q2);
   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S1));
   byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S2));
   stealthTx.Vout.Add(TxOut.PayToMultiSig(Util.Amount(".995"), 2, 2, q1New,  
q2New));
   stealthTx.Vout.Add(TxOut.OpReturn(P));

In this case, you can scan with d2, calculate S2, and matching payments  
will have the right 'q2New'. But you need to check again offline with d1  
since it's a separate shared secret.

Maybe you are saying:

   byte[] S = EC.DH(e, Q2);
   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
   byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S));

But the payment would have (q2New - q1New) == (Q2 - Q1), so I think not  
entirely stealth? OK, let's fix that by adding a counter to the hash  
function...

   byte[] S = EC.DH(e, Q2);
   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S || 1));
   byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S || 2));
   stealthTx.Vout.Add(TxOut.PayToMultiSig(Util.Amount(".995"), 2, 2, q1New,  
q2New));
   stealthTx.Vout.Add(TxOut.OpReturn(P));

This is assuming we want to put q2New somewhere into the transaction,  
which, is it even required?

   byte[] S = EC.DH(e, Q2);
   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
   stealthTx.Vout.Add(TxOut.PayToPubKeyHash(Util.Amount(".995"), q1New);
   stealthTx.Vout.Add(TxOut.OpReturn(P));

I'll wait for ACK and then update my sample code.

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

On Tue, Jan 14, 2014 at 11:12:40AM -0800, Jeremy Spilman wrote:
> Maybe you are saying:
> 
>   byte[] S = EC.DH(e, Q2);
>   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
>   byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S));
> 
> But the payment would have (q2New - q1New) == (Q2 - Q1), so I think
> not entirely stealth? OK, let's fix that by adding a counter to the
> hash function...

Good catch, yeah, use the master shared secret to derive per-pubkey
secrets.

>   byte[] S = EC.DH(e, Q2);
>   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S || 1));
>   byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S || 2));
>   stealthTx.Vout.Add(TxOut.PayToMultiSig(Util.Amount(".995"), 2, 2,
> q1New, q2New));
>   stealthTx.Vout.Add(TxOut.OpReturn(P));
> 
> This is assuming we want to put q2New somewhere into the
> transaction, which, is it even required?
> 
>   byte[] S = EC.DH(e, Q2);
>   byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
>   stealthTx.Vout.Add(TxOut.PayToPubKeyHash(Util.Amount(".995"), q1New);
>   stealthTx.Vout.Add(TxOut.OpReturn(P));

Well like I said, you shouldn't force the txout to be exactly a 2-of-2
multisig - the recipient might be using a multi-factor wallet for
instance. So, if I understand your code, what you want is the following:

byte[] Q = <payee root pubkeys>;
byte[] Q_Scan = <may or may not be provided in Q>
int m = <# of pubkeys required to redeem>;
byte[] S = EC.DH(e, Q_Scan);

byte[] qDerived[];
for (int = 0; i < len(Q); i++){
    qDerived[i] = EC.PointAdd(Q[i], Util.SingleSHA256(S || i));
}

// Best to have a single canonical order re: anonymity set.
qDerived = sorted(qDerived);

if (len(Q) > 1){
    stealthTx.Vout.Add(TxOut.PayToMultiSig(amount, m, len(Q), qDerived));
} else {
    stealthTx.Vout.Add(TxOut.PayToPubKeyHash(amount, qDerived[0]);
}
stealthTx.Vout.Add(TxOut.OpReturn(P));


Finally, it would probably be better if the multisig output was wrapped
in a P2SH output to better match the behavior of other wallets for the
sake of a bigger anonymity set - seems that stuff that is implementing
multifactor wallets and escrow is using P2SH to do it rather than bare
multisig. Also there's quite a bit of support for making bare multisig
not IsStandard() to discourage data-storage applications.

-- 
'peter'[:-1]@petertodd.org
00000000000000010c474cd4e25913535ec1c166b6d43fbdd9a5f2726711ced7

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Adam Back]

I saw in the math version you had said Q'=Q+H(S) and I presumed it was a
typo, but your code says the same thing.  I presume you meant Q'=Q+H(S)*G
and therefore that Util.SingleSHA256() multiplies by G internally?

Adam

Re: [Bitcoin-development] Stealth Addresses

[Jeremy Spilman]

On Tue, 14 Jan 2014 13:51:06 -0800, Adam Back <adam@cypherspace.org> wrote:
> I saw in the math version you had said Q'=Q+H(S) and I presumed it was a
> typo, but your code says the same thing.  I presume you meant Q'=Q+H(S)*G
> and therefore that Util.SingleSHA256() multiplies by G internally?
>
> Adam
>

Thanks for reviewing this. The relevant line:

    byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S1));

SingleSHA256 is a single application of SHA256 -- named so since 'SHA256'  
functions in many Bitcoin libraries too often actually run DoubleSHA256.  
32 bytes are returned.

The multiplication by 'G' that you mention is part of my EC.PointAdd...

I should probably just publish all my code as MIT and be done with it ;-)

Thanks,
Jeremy


public static byte[] PointAdd(byte[] point, byte[] scalar, bool compressed  
= true)
{
     var point1 = new OpenSSL.Crypto.EC.Point(EcGroup, point);

     var num = OpenSSL.Core.BigNumber.FromArray(scalar);
     var point2 = OpenSSL.Crypto.EC.Point.Multiply(EcGroup, num,  
EcBnContext);

     var result = point1.Add(point2, EcBnContext);

     if (compressed)
         return result.GetBytes(ConversionForm.Compressed);
     else
         return result.GetBytes(ConversionForm.Uncompressed);
}

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]

On Mon, Jan 13, 2014 at 02:59:08PM -0500, Alan Reiner wrote:
> How is this different from the proposal I have made?
> 
> You distribute the root public key (but not chaincode!) of a BIP32
> branch.  You can put your root key on a business card if you want.  Then
> when someone wants to pay you, you simply give them the multiplier and
> root key (they already have the root key, but should verify).  The
> multiplier does not reveal the chaincode, thus keeping it private, but
> it does allow them to confirm that the final address they are paying is
> derived from that root key they know belongs to you ("Please pay address
> X; oh btw, X=rootKey*mult").
> 
> You can /choose/ to reveal that a given payment address is linked to
> your root key without any compromise of privacy.  Or you can choose to
> ignore it and just give them a bare address the old way and still
> maintain privacy.  What advantages does "stealth addresses" have over
> this scheme?  You could extend it using some kind of deterministic
> sub-branching and/or ECDH to create multiple payment addresses without
> querying the payee. 

Basically stealth addresses *are* your scheme, using the blockchain as a
low or even no overhead communication channel for the payor to give the
payee that multiplier without bidirectional communication.

In the business card example I can't easily take your business card and
just send you some money without that transaction being linked to public
information. (your business card)

> I had planned to implement this system and push for people to accept it
> because I don't see any downsides to it.  It can easily be integrated
> into a WoT (with signed root keys), or CA system piggybacking on SSL.

WoT is a perfect example of the problem: if you put BIP32 branch payment
info into my OpenPGP key I can't pay you securely and reliably without
making the transaction public. The best I can do is pick a nonce and pay
X=rootKey*nonce, communicating to you the nonce later - this isn't
reliable because if I or you lose the nonce the funds are lost.

With stealth addresses the user experience can be as simple as you
telling me on the phone "hey! send me that 0.234 BTC you owe me!", me
clicking on "Send to Alan Reiner (verified by PGP)" (perhaps again on my
off-line second factor device for a multi-sig wallet) and tellling you
"OK, sent".

Even if your phone has been wiretapped, the attacker still didn't learn
exactly what transaction was actually used to make the payment - a big
advantage over per-tx nonce stuff.

-- 
'peter'[:-1]@petertodd.org
00000000000000023d5a8bbe131414328a6c50a2741933ba03775afd3c3db395

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 2699 bytes --]


On 01/13/2014 03:14 PM, Peter Todd wrote:
> On Mon, Jan 13, 2014 at 02:59:08PM -0500, Alan Reiner wrote:
>> How is this different from the proposal I have made?
>>
>> You distribute the root public key (but not chaincode!) of a BIP32
>> branch.  You can put your root key on a business card if you want.  Then
>> when someone wants to pay you, you simply give them the multiplier and
>> root key (they already have the root key, but should verify).  The
>> multiplier does not reveal the chaincode, thus keeping it private, but
>> it does allow them to confirm that the final address they are paying is
>> derived from that root key they know belongs to you ("Please pay address
>> X; oh btw, X=rootKey*mult").
>>
>> You can /choose/ to reveal that a given payment address is linked to
>> your root key without any compromise of privacy.  Or you can choose to
>> ignore it and just give them a bare address the old way and still
>> maintain privacy.  What advantages does "stealth addresses" have over
>> this scheme?  You could extend it using some kind of deterministic
>> sub-branching and/or ECDH to create multiple payment addresses without
>> querying the payee.
>
> Basically stealth addresses *are* your scheme, using the blockchain as a
> low or even no overhead communication channel for the payor to give the
> payee that multiplier without bidirectional communication.
>
> In the business card example I can't easily take your business card and
> just send you some money without that transaction being linked to public
> information. (your business card)

It's not public.  When I say "please pay me" I also say "use this
multiplier".  The multiplier isn't published, and it's not publicly
discoverable without my wallet (or access to my email).  The address
remains private between you and me.  As you said, it could be
discoverable if the email is discoverable, but I'm not seeing how how
critical that really is.

There's a lot of complexity around this constraint (possibly involving
new/secondary private keys, extra outputs, relying on change outputs,
and/or using 3rd parties to help look for transactions).  I'm not
convinced that what is being gained is really worth that extra complexity.

By contrast, what I proposed, that does require sending sending the
payer a multiplier once, is easy to implement in any BIP 32 wallet,
doesn't require any special address formats, and achieves 98% of the
same benefits without any special computation.   I guess I'm just not
convinced that it's really necessary for people to be able to send
others payments without contacting them (and/or hiding the evidence a
payment was made even if they communications were discovered).

-Alan




[-- Attachment #2: Type: text/html, Size: 3652 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Gregory Maxwell]

On Mon, Jan 13, 2014 at 12:41 PM, Alan Reiner <etotheipi@gmail.com> wrote:
> It's not public.  When I say "please pay me" I also say "use this
> multiplier".  The multiplier isn't published, and it's not publicly
> discoverable without my wallet (or access to my email).

If you have enough of a communications channel to do that you can just
give the person the finished address (authentication aside).

The idea here is to cover the cases where the communication is one way
or nearly so.  Consider a donation address on a fully static webpage,
in a forum signature or email address, or on a billboard. ... or where
users-being-users mean that the user isn't going to start up their
wallet software to compute a new multiplier every time they give out
an address no matter how much we whine at them.

Re: [Bitcoin-development] Stealth Addresses

[Roy Badami]

> It's not public.  When I say "please pay me" I also say "use this
> multiplier".

Sending a "please pay me" message is really great for business
transactions.

But I think the use case that Peter Todd mentions is actually *the*
most important currently under-addresesd use case:

> With stealth addresses the user experience can be as simple as you
> telling me on the phone "hey! send me that 0.234 BTC you owe me!",
> me clicking on "Send to Alan Reiner (verified by PGP)" (perhaps
> again on my off-line second factor device for a multi-sig wallet)
> and tellling you "OK, sent".

Lots of work is being done on handling consumer-to-merchant
transactions.  BIP 70 does a good job of tackling the online purchase
case, and the work that Andreas Schildbach is doing with Bluetooth and
NFC will improve the options for a payer in a physical PoS transaction
who might not have Internet connectivity on their smartphone.

But relatively little work (that I know of) is being done on
non-transactional personal payments - that is, being able to pay money
to friends and other people that you have a face-to-face relationship
with.

What I want... no need... is to be able to open my wallet, select a
friend from my address book, and transfer the $10 I owe them from the
bar last night.

I don't care - within reason - what process is involved in getting my
friend set up in my address book.  That may well requires two way
communication (e.g. over NFC).  But once it's set up, I should be able
to just select the payee from the address book and send them some
funds.  Anything else is just too complciated.

I don't know if stealth addresses are the best solution to address
this use case, but AFAIK the only current solution to this use case is
to store a long-lived Bitcoin address in the addresss book.

roy

Re: [Bitcoin-development] Stealth Addresses

[Alan Reiner]

On 01/13/2014 04:02 PM, Roy Badami wrote:
>> It's not public.  When I say "please pay me" I also say "use this
>> multiplier".
> Sending a "please pay me" message is really great for business
> transactions.
>
> But I think the use case that Peter Todd mentions is actually *the*
> most important currently under-addresesd use case:
>
>> With stealth addresses the user experience can be as simple as you
>> telling me on the phone "hey! send me that 0.234 BTC you owe me!",
>> me clicking on "Send to Alan Reiner (verified by PGP)" (perhaps
>> again on my off-line second factor device for a multi-sig wallet)
>> and tellling you "OK, sent".
> Lots of work is being done on handling consumer-to-merchant
> transactions.  BIP 70 does a good job of tackling the online purchase
> case, and the work that Andreas Schildbach is doing with Bluetooth and
> NFC will improve the options for a payer in a physical PoS transaction
> who might not have Internet connectivity on their smartphone.
>
> But relatively little work (that I know of) is being done on
> non-transactional personal payments - that is, being able to pay money
> to friends and other people that you have a face-to-face relationship
> with.
>
> What I want... no need... is to be able to open my wallet, select a
> friend from my address book, and transfer the $10 I owe them from the
> bar last night.
>
> I don't care - within reason - what process is involved in getting my
> friend set up in my address book.  That may well requires two way
> communication (e.g. over NFC).  But once it's set up, I should be able
> to just select the payee from the address book and send them some
> funds.  Anything else is just too complciated.
>
> I don't know if stealth addresses are the best solution to address
> this use case, but AFAIK the only current solution to this use case is
> to store a long-lived Bitcoin address in the addresss book.
>
> roy
>

Fair enough.  I haven't spent much time thinking about that use case. 
Though, I question the feasibility of anything that requires O(N) EC
multiply operations/sec, where N is the total volume of transactions
moving over the network.  But I guess if the prefix is big enough, the
scanning operations will remain feasible forever.

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]

On Mon, Jan 13, 2014 at 04:15:01PM -0500, Alan Reiner wrote:
> > I don't know if stealth addresses are the best solution to address
> > this use case, but AFAIK the only current solution to this use case is
> > to store a long-lived Bitcoin address in the addresss book.
> >
> > roy
> >
> 
> Fair enough.  I haven't spent much time thinking about that use case. 
> Though, I question the feasibility of anything that requires O(N) EC
> multiply operations/sec, where N is the total volume of transactions
> moving over the network.  But I guess if the prefix is big enough, the
> scanning operations will remain feasible forever.

Well that's the thing: the cost to find all stealth-address-using
payments to you isn't O(n) transaction volume, it's O(n) anonymity set
size. I think we can make a pretty good argument that the anonymity set
people need is mostly fixed in size and has nothing to do with overall
tx volume, so really we've got O(1) scaling.

There is a catch however: if you need the prefix to be against
H(scriptPubKey) rather than scriptPubKey directly the sender needs to
grind the OP_RETURN output at 2^len(prefix) cost. Fortunately that
grinding can be done with hash operations rather than ECC - even if we
needed 32-bit prefixes eventually computing 32-bit hash collisions is
plausible, and more reasonable 8-bit is quite doable now.

-- 
'peter'[:-1]@petertodd.org
00000000000000013f56c73dbb82447ba01e303648109b2e7ea0adf6ca53a7ff

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 3768 bytes --]

On Mon, Jan 13, 2014 at 03:20:15PM -0800, Jeremy Spilman wrote:
> On Mon, 13 Jan 2014 13:27:52 -0800, Peter Todd <pete@petertodd.org> wrote:
> 
> >There is a catch however: if you need the prefix to be against
> >H(scriptPubKey) rather than scriptPubKey directly the sender needs to
> >grind the OP_RETURN output at 2^len(prefix) cost. Fortunately that
> >grinding can be done with hash operations rather than ECC - even if we
> >needed 32-bit prefixes eventually computing 32-bit hash collisions is
> >plausible, and more reasonable 8-bit is quite doable now.
> 
> I'll be updating my test code to support a prefix on the OP_RETURN
> TxOut, for either where we expect to have an index on scriptPubKey,
> or where we have an index on H(scriptPubKey) and have to grind with
> a nonce.
> 
> Where do we say what prefix we are targeting, or how many bits
> should match with Q? I assume the only place to communicate this,
> dare I say it, is in the address string.

That's exactly where you need to put it.

Incidentally a prefix nonce, either direct or grind-style, is a bit of a
privacy leak by suggestion how long the prefix was in the original
stealth address. Code should be written such that grinding routines
start at a random nonce, and nonces of any length are accepted. The
easiest way to do that is to just stick the grind nonce at the end after
the 33 bytes of pubkey.

I dunno yet what hashing algorithm to target for grinding. I'd assume
SHA256^2 on the basis that it's identical to what the merkle tree uses
and thus will have the same security properties in a committed index,
but I can see people pushing for the shorter 20-byte HASH160 too.

> Also, for symmetric encryption of P in the OP_RETURN TxOut using a
> key H(Q), what cipher did you have in mind? Since P is ephemeral and
> random, I don't follow, why does encrypting it 'gives a slightly
> larger anonymity set'?

The idea was to make the anonymity set include other uses of OP_RETURN
txouts, however Gregory Maxwell pointed out that it'd easily lead to a
much reduced anonymity set because someone could trial decrypt the
encrypted P and check if it was a valid pubkey. If you encrypted the
full 33 bytes that'd be a total disaster - only 1/256 candidate stealth
keys would work. There are ways to do it right, but it's tricky and
there may be other attacks I don't know about, so I'm inclined to just
drop that idea for now unless a professional cryptographer wants to take
it on.

> You made an interesting point in the original post that payer should
> hold onto their ephemeral privKey 'e' corresponding to pubKey P if
> they need to later prove the payment was actually sent to Q.

Yup. You can even use that pubkey to disambiguate/prove payments with
Timo Hanke's pay-to-contract ideas by deriving it from some root and a
contract hash.

Conversely Amir Taaki pointed out on the unsystem list that once a nonce
is agreed on, it can be used directly with BIP32 derivation so that
future payments don't have to use an OP_RETURN txout. Interesting idea,
although I worry that the statelessness advantage of stealth payments
gets lost if you do that. Probably best to look at that one after an
initial implementation happens and we get some experience with them in
the real world - adding that can be done in a backwards compatible
fashion.

> Finally, I hope you can take a look at the Gist and sample Test-Net
> TXs I sent out this morning. I just went back and re-read your
> original post, and compared to what I implemented there are some
> differences, I'd like to make sure you think it's on track.

Will do.

-- 
'peter'[:-1]@petertodd.org
0000000000000001420349f2276e53e5b087faea67c7c40aa12383c416067364

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Stealth Addresses

[Dan Carter]

I think stealth addresses combined with zk-snarks would obviate the need 
for CoinJoin.  zk-snarks could be used to hide the coin's value and 
stealth addresses could be used to hide the recipient for payments and 
even mined coins.  More info on zero-knowledge snarks:

http://cs.tau.ac.il/~tromer/papers/vnsnark-20131230.pdf
http://cs.tau.ac.il/~tromer/papers/csnark-20131007.pdf

Start with a mined coin: generate a coin secret, create a coinbase 
transaction with an output to your stealth address and send 
hash(coin-secret + reward-value) + encrypt(coin-secret + reward-value) 
where only the recipient (you) can decrypt. (The reward value is known 
publicly but just assume it isn't here for generality). You also embed 
the 0.2KB zk-snark proof + 3KB verifying key that the hash result is in 
fact SHA256(coin-secret + reward-value), where your private witnesses 
are (coin-secret, reward-value).

Now you could split a coin into as many pieces as you want in a single 
transaction and send to multiple recipients, some pieces go to yourself 
(change) and others to the payee, every piece would have a different 
recipient address thanks to stealth addresses, and all values hidden 
thanks to zk-snarks.

So lets say you want to split the mined coin into two new ones.  You 
create a transaction where the input redeems the mined coin using mined 
tx out + your stealth address, and there are two new coins as outputs to 
your own stealth address each having: hash(new-coin-secret + 
new-hidden-value) + encrypt(new-coin-secret + new-hidden-value).  You 
also embed the zk-snark proof that the two new hidden values add up to 
the original hidden value, and that the two new hash results are in fact 
SHA256(new-coin-secret + new-hidden-value), where your private witnesses 
are (original-coin-secret, original-hidden-value, new-coin-secrets, 
new-hidden-values).

If you want to merge two coins into one it's just a split backwards, two 
inputs one output, zk-snark proof that two original hidden values add up 
to the new hidden value and that the new hash result is 
SHA256(new-coin-secret + new-hidden-value).

If you want to transfer ownership of a coin then just redeem at input, 
and output same as mined coin except using recipient stealth address 
(which is a public key) to encrypt(coin-secret + hidden-value).

- Dan



On 2014-01-06 4:03 AM, Peter Todd wrote:
> * Abstract
>
> A Stealth Address is a new type of Bitcoin address and related
> scriptPubKey/transaction generation scheme that allowers payees to
> publish a single, fixed, address that payors can send funds efficiently,
> privately, reliably and non-interactively. Payors do not learn what
> other payments have been made to the stealth address, and third-parties
> learn nothing at all. (both subject to an adjustable anonymity set)

Re: [Bitcoin-development] Stealth Addresses

[joseph]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On naming, please allow consideration of "Confidential address".
Less conflation with "private key", connotes confidence, and as the address is known to the transacting parties, it is a precisely accurate name.
 
One of the use cases for these will be in multinational corporate internal international settlement.  For a company to use bitcoin for its internal settlement and maintain confidence that competitors will not be able to suss out its transactions, these confidential addresses will be of great use.
 
 
Stealth connotes stealing, theft, hiding, fear, sneakiness, stealth bombers.  Maybe it is a good name, but not the best name.

[-- Attachment #2: Type: text/html, Size: 750 bytes --]