Stealth Addresses
88 messages, 6 Jan to 6 Mar 2014. Started by Peter Todd.
Peter Todd (15), Jeremy Spilman (12), Roy Badami (10), Mike Hearn (8), Greg Maxwell (8), Drak (6), Alan Reiner (4), Adam Back (4), +15 more
* 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
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:
Quoted text (12 lines)
> 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>
On Wed, Jan 08, 2014 at 02:20:57AM -0800, Jeremy Spilman wrote:
Quoted text (21 lines)
> 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.
Quoted text (4 lines)
> 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!)
Quoted text (5 lines)
> 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.
On 10 January 2014 10:20, Peter Todd <pete@petertodd•org> wrote:
Quoted text (6 lines)
> 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
On Fri, Jan 10, 2014 at 11:28:33AM +0000, Drak wrote:
Quoted text (11 lines)
> 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. :)
Quoted text (6 lines)
> 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.pdfYou 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:
Quoted text (115 lines)
> > 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 >
Quoted text (2 lines)
> 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?
On Sun, Jan 12, 2014 at 7:20 PM, Jeremy Spilman <jeremy@taplink•co> wrote:
Quoted text (3 lines)
> 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.
On Sun, Jan 12, 2014 at 5:33 AM, Jeremy Spilman <jeremy@taplink•co> wrote:
Quoted text (10 lines)
> ... > 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> ....
On Sun, Jan 12, 2014 at 7:20 PM, Jeremy Spilman <jeremy@taplink•co> wrote:
Quoted text (3 lines)
> > 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:
Quoted text (9 lines)
> 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:
Quoted text (5 lines)
> 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!
On Sun, Jan 12, 2014 at 1:18 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:
Quoted text (3 lines)
> 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.
Quoted text (4 lines)
> > 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 ...
Quoted text (4 lines)
> 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.)
Quoted text (2 lines)
> 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
On Mon, Jan 13, 2014 at 2:37 PM, Roy Badami <roy@gnomon•org•uk> wrote:
Quoted text (2 lines)
> 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.
On Mon, Jan 13, 2014 at 01:52:25AM -0800, Gregory Maxwell wrote:
Quoted text (7 lines)
> 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
On 13 January 2014 19:40, Roy Badami <roy@gnomon•org•uk> wrote:
Quoted text (3 lines)
> 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
Quoted text (7 lines)
> > 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
Quoted text (6 lines)
> > 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!).
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:
Quoted text (25 lines)
> 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
rOn Mon, Jan 13, 2014 at 08:57:33PM +0100, Mike Hearn wrote:
Quoted text (10 lines)
> > > > 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
On Mon, Jan 13, 2014 at 11:59 AM, Alan Reiner <etotheipi@gmail•com> wrote:
Quoted text (3 lines)
> 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).
[...]
Quoted text (4 lines)
> 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.
On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
Quoted text (6 lines)
> 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
On Mon, Jan 13, 2014 at 02:59:08PM -0500, Alan Reiner wrote:
Quoted text (18 lines)
> 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)
Quoted text (3 lines)
> 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.
On Mon, Jan 13, 2014 at 12:10:56PM -0800, Gregory Maxwell wrote:
Quoted text (5 lines)
> 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.
On 01/13/2014 03:14 PM, Peter Todd wrote:
Quoted text (27 lines)
> 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
On Mon, Jan 13, 2014 at 12:41 PM, Alan Reiner <etotheipi@gmail•com> wrote:
Quoted text (3 lines)
> 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.
Quoted text (2 lines)
> 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:
Quoted text (5 lines)
> 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
On 01/13/2014 04:02 PM, Roy Badami wrote:
Quoted text (40 lines)
>> 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.
On Mon, Jan 13, 2014 at 04:15:01PM -0500, Alan Reiner wrote:
Quoted text (12 lines)
> > 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.
Quoted text (5 lines)
> 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
On Mon, Jan 13, 2014 at 03:20:15PM -0800, Jeremy Spilman wrote:
Quoted text (17 lines)
> 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.
Quoted text (4 lines)
> 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.
Quoted text (3 lines)
> 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.
Quoted text (4 lines)
> 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.
On Mon, Jan 13, 2014 at 01:13:08AM -0800, Jeremy Spilman wrote:
Quoted text (2 lines)
> 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.
Quoted text (6 lines)
> 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.
Quoted text (7 lines)
> 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?
Quoted text (14 lines)
> * 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.
Quoted text (3 lines)
> 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.
On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
Quoted text (12 lines)
> > > 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.
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
Quoted text (114 lines)
> 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 >
On Tue, 14 Jan 2014 06:19:08 -0800, Peter Todd <pete@petertodd•org> wrote:
Quoted text (15 lines)
> 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.
On Tue, Jan 14, 2014 at 11:12:40AM -0800, Jeremy Spilman wrote:
Quoted text (9 lines)
> 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.
Quoted text (14 lines)
> 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.
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
On Tue, 14 Jan 2014 13:51:06 -0800, Adam Back <adam@cypherspace•org> wrote:
Quoted text (6 lines)
> 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);
}On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
Quoted text (6 lines)
> > 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
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
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:
Quoted text (20 lines)
> 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 > >
On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport <bendavenport@gmail•com> wrote:
Quoted text (2 lines)
> 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)
"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:
Quoted text (26 lines)
> 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 >
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:
Quoted text (20 lines)
> "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) > >
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:
Quoted text (55 lines)
> "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 > >
On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
Quoted text (2 lines)
> "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
"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:
Quoted text (11 lines)
> 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
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:
Quoted text (55 lines)
> "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
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:
Quoted text (25 lines)
> "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/ >
On Wed, Jan 15, 2014 at 11:17:33PM +0000, I wrote:
Quoted text (1 line)
> 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.)
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:
Quoted text (17 lines)
> "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)
On Wed, Jan 15, 2014 at 4:05 PM, Jeremy Spilman <jeremy@taplink•co> wrote:
Quoted text (1 line)
> Might I propose "reusable address".
I like this too.
On 01/15/2014 04:05 PM, Jeremy Spilman wrote:
Quoted text (1 line)
> 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
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:
Quoted text (58 lines)
> 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 > >
On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back <adam@cypherspace•org> wrote:
Quoted text (11 lines)
> 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.
Quoted text (5 lines)
> 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.
Quoted text (5 lines)
> > 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.
Quoted text (2 lines)
> (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.
Quoted text (6 lines)
> > 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.
Yes. Good idea(s).
Quoted text (52 lines)
> 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 >
On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman <jeremy@taplink•co> wrote:
Quoted text (4 lines)
> 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.
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:
Quoted text (87 lines)
> 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 > >
On Thu, Jan 16, 2014 at 7:26 AM, Gary Rowe <g.rowe@froot•co•uk> wrote:
Quoted text (2 lines)
> 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
On 16 January 2014 00:05, Jeremy Spilman <jeremy@taplink•co> wrote:
Quoted text (5 lines)
> 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
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:
Quoted text (30 lines)
> 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 > >
On Thu, Jan 16, 2014 at 10:14:24AM +0000, Drak wrote:
Quoted text (7 lines)
> 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
On Wed, Jan 15, 2014 at 05:02:10PM -0800, Jeremy Spilman wrote:
Quoted text (3 lines)
>The second pubKey is useful [...] even just being able to scan for >transactions yourself without keeping bitcoin-encumbered private keys >decrypted in memory.
Agreed.
Quoted text (11 lines)
>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.
Quoted text (3 lines)
>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).
Quoted text (7 lines)
>>(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
Quoted text (14 lines)
> >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?
On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
Quoted text (8 lines)
> 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.
On 01/16/2014 01:28 PM, Peter Todd wrote:
Quoted text (2 lines)
> 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."
I hear you, and I really don't care that much what it's called, as much as, does it work and how!
Quoted text (3 lines)
> 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? :-)
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:
Quoted text (71 lines)
> 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 > >
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:
Quoted text (94 lines)
> 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 > >
On 01/17/2014 01:15 AM, Mike Hearn wrote:
Quoted text (5 lines)
> 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.
Quoted text (3 lines)
> 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.
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>:
Quoted text (124 lines)
> 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 > >
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:
Quoted text (110 lines)
> 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 >> >> >
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.
On Fri, Jan 17, 2014 at 10:15:40AM +0100, Mike Hearn wrote:
Quoted text (2 lines)
> 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.
Quoted text (6 lines)
> 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.
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:
Quoted text (81 lines)
> 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 > >
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:
Quoted text (163 lines)
> 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 >
*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
On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner <etotheipi@gmail•com> wrote:
Quoted text (1 line)
> 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.
On Wed, Jan 15, 2014 at 05:32:31PM -0800, Gregory Maxwell wrote:
Quoted text (11 lines)
> 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.
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:
Quoted text (45 lines)
> 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
Quoted text (13 lines)
> 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...
On Sat, Jan 18, 2014 at 3:12 PM, Jeremy Spilman <jeremy@taplink•co> wrote:
Quoted text (5 lines)
> 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…
On Sat, Jan 18, 2014 at 05:12:58PM -0600, Jeremy Spilman wrote:
Quoted text (21 lines)
> > > > 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.
On Sat, Jan 18, 2014 at 11:44:52AM -0600, Troy Benjegerdes wrote:
Quoted text (11 lines)
> > 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.
On Wed, 15 Jan 2014 17:32:31 -0800, Gregory Maxwell <gmaxwell@gmail•com> wrote:
Quoted text (3 lines)
> 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.
Quoted text (4 lines)
> 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.
On Mon, Jan 20, 2014 at 08:00:05PM -0800, Jeremy Spilman wrote:
Quoted text (26 lines)
> 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.
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:
Quoted text (8 lines)
> * 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)