I'm confused by this thread. You guys understand that the payment protocol already allows the recipient to request an arbitrary number of outputs, right?
With an extended public key there is no need for the sender to request a pre-defined number of outputs at the negotiation phase. When a recipient gives a sender a BIP32 key that sender now has the ability to create as many as they will need, forever, with no need for additional negotiation. 
Topic: HD wallets for increased transaction privacy [split from CoinJoin thread] - page 2. (Read 5779 times)
October 17, 2013, 11:09:18 AM
October 17, 2013, 11:07:02 AM
I'm confused by this thread. You guys understand that the payment protocol already allows the recipient to request an arbitrary number of outputs, right? Whether they are generated from an HD key or not is an implementation detail of the recipient side. The sending side just gets a set of instructions that it must satisfy. It makes sense for the the sender to try and craft multiple independent transactions to satisfy those outputs, if that is what is best for privacy. Again, the payment protocol is already designed with this in mind.
There's no need for new URI or serialization schemes. Just implementing BIP 70 is sufficient.
There's no need for new URI or serialization schemes. Just implementing BIP 70 is sufficient.
This is for cases where the number of future transactions is unknown, and perhaps unbounded.
October 17, 2013, 09:39:47 AM
Why not just generate addresses from HDseed+blockheight/n, where n is some small power of two integer like 8 or 16? Your wallet isn't going to have an issue generating and scanning for a few hundred addresses matching the rolling window, and it still provides the privacy benefit in most cases where payments are being spaced apart.
We don't need this to be perfect - the main usage is donation addresses where a really dedicated attacker could find them anyway.
Other than that I'd suggest creating a standard where the address is included in a small OP_RETURN data packet encrypted to the owner; you'd scan the whole blockchain for payments that you can decrypt.
We don't need this to be perfect - the main usage is donation addresses where a really dedicated attacker could find them anyway.
Other than that I'd suggest creating a standard where the address is included in a small OP_RETURN data packet encrypted to the owner; you'd scan the whole blockchain for payments that you can decrypt.
October 17, 2013, 06:28:47 AM
I'm confused by this thread. You guys understand that the payment protocol already allows the recipient to request an arbitrary number of outputs, right? Whether they are generated from an HD key or not is an implementation detail of the recipient side. The sending side just gets a set of instructions that it must satisfy. It makes sense for the the sender to try and craft multiple independent transactions to satisfy those outputs, if that is what is best for privacy. Again, the payment protocol is already designed with this in mind.
There's no need for new URI or serialization schemes. Just implementing BIP 70 is sufficient.
The idea of sending public chain codes to people to be used into the future hasn't been sitting well with me because if your wallet is lost or compromised, then you'd have to go around to everyone you've given one out to and revoke them. Or build an entire key revocation infrastructure around them.There's no need for new URI or serialization schemes. Just implementing BIP 70 is sufficient.
The payment protocol makes a lot more sense to me too.
October 17, 2013, 05:00:55 AM
I'm confused by this thread. You guys understand that the payment protocol already allows the recipient to request an arbitrary number of outputs, right? Whether they are generated from an HD key or not is an implementation detail of the recipient side. The sending side just gets a set of instructions that it must satisfy. It makes sense for the the sender to try and craft multiple independent transactions to satisfy those outputs, if that is what is best for privacy. Again, the payment protocol is already designed with this in mind.
There's no need for new URI or serialization schemes. Just implementing BIP 70 is sufficient.
There's no need for new URI or serialization schemes. Just implementing BIP 70 is sufficient.
October 16, 2013, 09:01:41 PM
An extended public key only lets you see the transactions in the subchain its on. Not all your transactions!
It's still an inexcusably-high amount of metadata to leak.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.
The alternative is that the forum gives out some token that can be used to find the other person to exchange pubkeys directly, without the forum being able to record the information itself.For example, your HD wallet client can have Torchat functionality built in, and you post the address in your profile such that anyone wanting to get payment information can point their client to that address.
Substitute Bitmessage, or any other eavesdropping-resistant P2P messaging system, for Torchat as desired.
It just takes a bit more thought to architect the negotiation protocol, but it's not all that complicated. For extra credit, you design the extended pubkey request and exchange protocol to be transport-independent and add a plugin feature to the clients such that you can do it over Torchat, Bitmessage, IRC, I2P, Freenet, or any protocol you can write a transport plugin for.
October 16, 2013, 08:53:45 PM
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.
October 16, 2013, 07:34:44 PM
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.
October 16, 2013, 07:29:38 PM
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.
Quote
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
October 16, 2013, 06:42:44 PM
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.
October 16, 2013, 06:27:44 PM
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?
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?
October 16, 2013, 06:16:43 PM
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. October 16, 2013, 06:09:33 PM
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.
October 16, 2013, 04:57:28 PM
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.
October 16, 2013, 04:34:26 PM
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.
October 16, 2013, 04:31:47 PM
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.
October 16, 2013, 04:10:53 PM
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.
October 16, 2013, 03:51:10 PM
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.
October 16, 2013, 03:24:19 PM
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) October 16, 2013, 02:30:58 PM
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?Quote
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)
Jump to: