HD wallets for increased transaction privacy [split from CoinJoin thread]

[justusranvier]

The only reliable solution is to source your coins in small values, so you don't need to split value. Yet this is not possible if the payer is splitting and paying you numerous times, e.g. an employer.

http://bitcoinism.blogspot.com/2013/07/reclaiming-financial-privacy-with-hd.html

[1713574202]

1713574202

[1713574202]

1713574202

[1713574202]

1713574202

[1713574202]

1713574202

[1713574202]

1713574202

[1713574202]

1713574202

[AnonyMint]

The only reliable solution is to source your coins in small values, so you don't need to split value. Yet this is not possible if the payer is splitting and paying you numerous times, e.g. an employer.

http://bitcoinism.blogspot.com/2013/07/reclaiming-financial-privacy-with-hd.html

Controversial thought. Should the block chain protocol prevent coins greater than say 10 BTC.  

P.S. I've already thought of not allowing coins (note I didn't say transactions) less than 0.01 BTC to eliminate the dust.

[Peter Todd]

The only reliable solution is to source your coins in small values, so you don't need to split value. Yet this is not possible if the payer is splitting and paying you numerous times, e.g. an employer.

http://bitcoinism.blogspot.com/2013/07/reclaiming-financial-privacy-with-hd.html

It gets even better than that with the payment protocol: https://bitcointalk.org/index.php?topic=300809.msg3227426#msg3227426

[jgarzik]

The only reliable solution is to source your coins in small values, so you don't need to split value. Yet this is not possible if the payer is splitting and paying you numerous times, e.g. an employer.

This is actually an interesting problem, that is difficult to solve with current bitcoin.

Entities that issue regular payouts -- in my case, ASICMINER, Eligius and my employer BitPay -- inevitably set up a single payout address, and then send multiple payments to that address.

This is certainly sub-optimal, and reduces privacy.  No amount of CoinJoin'ing by itself will fix this multiple-payout/single-address problem.  We'll call it "recurring incoming payments."

Recurring incoming payments -- and recurring outgoing payments (subscriptions) -- are problems that bitcoin is quite unsuited to address right now.

To increase privacy, those who pay out need some standardized way to request multiple addresses from their payees.

[maaku]

HD wallets?

[gmaxwell]

HD wallets?

Sure, but we need an address type that encodes an extended public key that can be handed over.

[justusranvier]

Sure, but we need an address type that encodes an extended public key that can be handed over.

Is the serialization format mentioned in BIP32 not sufficient for this?

Extended public and private keys are serialized as follows:

• 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)
• 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, ....
• 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)
• 4 bytes: child number. This is the number i in xi = xpar/i, with xi the key being serialized. This is encoded in MSB order. (0x00000000 if master key)
• 32 bytes: the chain code
• 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)

This 78 byte structure can be encoded like other Bitcoin data in Base58, by first adding 32 checksum bits (derived from the double SHA-256 checksum), and then converting to the Base58 representation. This results in a Base58-encoded string of up to 112 characters. Because of the choice of the version bytes, the Base58 representation will start with "xprv" or "xpub" on mainnet, "tprv" or "tpub" on testnet.

[gmaxwell]

Is the serialization format mentioned in BIP32 not sufficient for this?

I'm unsure. It doesn't communicate anything about the permitted range of the index, just a single index. It doesn't communicate anything about further structure being permitted. (E.g. I might want to allow the forum to generate not just addresses for me, but more extended public keys)

[justusranvier]

I'm unsure. It doesn't communicate anything about the permitted range of the index, just a single index. It doesn't communicate anything about further structure being permitted. (E.g. I might want to allow the forum to generate not just addresses for me, but more extended public keys)

Why not just use different address types for the pathological cases?

If you assume that the sender is never permitted to generate new structure and is expected to send payments by strictly incrementing the index that would make it simple to implement now and open up a large number of use cases.

Allowing the sender to create new structure is something that anyone wanting to do could be expected to write custom software for now.

[casascius]

If you assume that the sender is never permitted to generate new structure and is expected to send payments by strictly incrementing the index that would make it simple to implement now and open up a large number of use cases.

My guess is it would create an unbound burden on clients to calculate limitless addresses to look for payments.  If it's feasible that someone might use such a code to generate 10000 payment addresses and then use them in (e.g.) alphabetical or reverse order such that #9999 might get used first, either the rules must be "Sorry you can't do that, you must fund the addresses in numerical order the payment will disappear into never never land", or clients must increment that index to infinity to be certain no payments are missed.

[justusranvier]

My guess is it would create an unbound burden on clients to calculate limitless addresses to look for payments.  If it's feasible that someone might use such a code to generate 10000 payment addresses and then use them in (e.g.) alphabetical or reverse order such that #9999 might get used first, either the rules must be "Sorry you can't do that, you must fund the addresses in numerical order the payment will disappear into never never land", or clients must increment that index to infinity to be certain no payments are missed.

It's not really any different than how existing deterministic wallets work now. They all implement some kind of look ahead window that moves as payments are received.

With extended public keys there's no reason to ever reuse addresses, so software that implements them should not do that. For general cases there's also no reason for a payor's client to do anything other than start at index 1 (0?) and send each transaction to the next address in sequence.

There's always the possibility that broken software won't do this, so the payee's client should have a way to manually locate a payment that was sent to an unexpected address.

[gmaxwell]

It's not really any different than how existing deterministic wallets work now. They all implement some kind of look ahead window that moves as payments are received.

Right, but at a minimum we need well defined conventions.

I do wonder about things like griefing a forum donation forum. E.g. I give the forum an extended public key so it can give each donor a fresh address, and then some clown asks for 10000 addresses and never pays.  Writing advice to address this is part of having a good spec for the usage of extended public keys.

[justusranvier]

Right, but at a minimum we need well defined conventions.

The convention I would use is, "Here's an extended public key. I am going to watch the first address defined in this sequence for an incoming payment. After I see it, I'm going to start watching the second address. After I see a payment there I'm going to start watching the third address, etc."

I do wonder about things like griefing a forum donation forum. E.g. I give the forum an extended public key so it can give each donor a fresh address, and then some clown asks for 10000 addresses and never pays.  Writing advice to address this is part of having a good spec for the usage of extended public keys.

A client can do several things to limit the amount of addresses they need to scan.

First of all there's no reason for a forum to let a single person request 10000 extended public keys.

The forum has it's BIP32 seed and generates a subnode for each registered member.

Each member can go to their account and find the extended public key for them to donate with. They don't ever get a new one because the one they are assigned lets them generate all the deposit addresses they will ever need.

The forum's client has a small lookahead window, like 5 or 10. Whenever a new incoming payments are received the window increments accordingly.

Old addresses are checked for new balances at exponentially-increasing intervals until some cutoff time after which they are only checked manually.

[gmaxwell]

The forum has it's BIP32 seed and generates a subnode for each registered member.

So now you need a 100,000 address lookahead?

I think you're not following what I'm saying here.

I am saying that FORUM USERS. Like you and I. Can provide the forum with an extended public key so that other forum users can requests addresses for us without making all of those addresses public.

Pre-reserving addresses for every user would require huge lookahead.

[justusranvier]

I am saying that FORUM USERS. Like you and I. Can provide the forum with an extended public key so that other forum users can requests addresses for us without making all of those addresses public.

Why would anyone want to give the forum operators the ability to track all their transactions? That's terrible for privacy. I'm never going to give someone an extended public key except for an entity I want to receive payments from.

[maaku]

In the forum case, you'd probably need a special protocol, appending the username or database UID of the forum user to the path to get an address sequence for that particular user, which could then operate as a sequence with a small lookahead.

I had assumed what @justusranvier described was/will be the convention for HD wallet applications. Senders use the first address not in the block chain, and receivers look ahead a small number of addresses (if nothing else to guard against reorgs and race conditions). Of course there are other subtle issues, such as if the UTXO set only is used by the sender to see which nonce is used, then spent addresses will be reused. But as a convention, and until the payment protocol is augmented to support HD sequences, it's a good start. Should this be part of BIP 32?

[justusranvier]

I had assumed what @justusranvier described was/will be the convention for HD wallet applications.

Specifically, for cases such as an employer paying employees. BIP32 solves this problem nicely.

The only reliable solution is to source your coins in small values, so you don't need to split value. Yet this is not possible if the payer is splitting and paying you numerous times, e.g. an employer.

This is actually an interesting problem, that is difficult to solve with current bitcoin.

Entities that issue regular payouts -- in my case, ASICMINER, Eligius and my employer BitPay -- inevitably set up a single payout address, and then send multiple payments to that address.

This is certainly sub-optimal, and reduces privacy.  No amount of CoinJoin'ing by itself will fix this multiple-payout/single-address problem.  We'll call it "recurring incoming payments."

Recurring incoming payments -- and recurring outgoing payments (subscriptions) -- are problems that bitcoin is quite unsuited to address right now.

To increase privacy, those who pay out need some standardized way to request multiple addresses from their payees.

Also, I think AnonyMint had it backwards. Splitting outputs is fine; there are plenty of ways do it safely. Recombining small balances into large balances without sacrificing privacy is the hard part, and that's where CoinJoin can help.

[hashman]

1) Coinjoin as I see it adds some plausible deniability but the taint is still there.  Anonymity is probably not the right word.  If one of the input addresses is considered a red flag,

This is really a question for how _much_ these tools are used. What you're pointing to is that there is an information leak whenever the anonymity set is less than all users of the system.

I guess I wasn't going that deep.. just pointing out that coinjoin still leaves blockchain taint.  Whereas something like me and you swapping private keys or another off chain solution like a third party tumbler does not leave block chain taint.  Of course nothing is perfect as you point out so I do support any improvement in privacy. 

If, after you've exhausted the funds sent to a particular scriptPubKey, someone sends you a tiny amount of coin to that scriptPubKey and you spend it in a new transaction then whatever linkage they knew carries forward and your deanonymization grows as a sufficiently small payment will only be useful when spent in combination with other coins.

Thanks, I get it now.  I didn't really understand the dust was going to empty addresses, to see if they later get used.  Still seems odd but now I know what you folks were talking about  

[maaku]

I guess I wasn't going that deep.. just pointing out that coinjoin still leaves blockchain taint.  Whereas something like me and you swapping private keys or another off chain solution like a third party tumbler does not leave block chain taint.  Of course nothing is perfect as you point out so I do support any improvement in privacy.

I think you're confused. An “off-line” tumbler would still have taint from all the people who use it. As for swapping private keys.. I see no way to do that safely without hitting the block chain.

[gmaxwell]

Why would anyone want to give the forum operators the ability to track all their transactions? That's terrible for privacy. I'm never going to give someone an extended public key except for an entity I want to receive payments from.

An extended public key only lets you see the transactions in the subchain its on. Not all your transactions!

It's not terrible for privacy, its essential for privacy because the alternative is the addresses people put in their signatures/profiles which get automatically scraped and listed on the web.

Instead you give the forum a public chain code for a little stub chain which is used only by the forum, and it replaces those static address.  It's less private than individually giving out addresses, but thats not what its an alternative to.