Topic: HD wallets for increased transaction privacy [split from CoinJoin thread] (Read 5779 times)

Okay, this still doesn't prevent the issuing of extended public keys being orthogonal with the gap problem.

On this point you now have to weigh the privacy vs reduced unzip attack security. I don't expect people to actually do what you're suggesting, especially since there is also the alternative of just asking for multiple addresses from the webserver (which also works for your application even where there is no public derivation available).  We're also taking a tradeoff of increased ecosystem dependance on the possibility of public derivation when you we do that, which I think is unfortunate as it'll be incompatible with any other cryptosystems bitcoin adds in the future.

As an aside, I note that if you invoke petertodd's take on cut-through payments you get the quadratic gap problem.

The customer might not have a single address contain a sufficiently-large output to make the payment. In that case, the customer might prefer to use multiple payment addresses to send the payment in two or more transactions for improved privacy.

The need for multiple payment addresses is not dependent on recurring payments.  

It doesn't matter if the customer is given an extended public key or a regular address. In fact, in the worst case the additional level of indirection makes the gapping problem quadratically worse, though if you allow no gaping of the leaf chain it's merely no better (because there can be gaps between customers who have successfully paid).  Nor is there a need to give customers in many cases an extended public key such as when there is no reoccurring payment relationship. (and avoiding doing so avoids disclosing a chaining code, thus reducing your exposure to the unzip attack should a private key get disclosed).

Ok, so you delegate an extended public key to your VPS and keep your master seed on an air-gapped cold wallet. You can still give each customer a unique extended public key - you just need to configure the client on your VPS and on your air-gapped wallet to add one extra layer of structure.

So you are just willfully ignoring a use case used by thousands of people, one which likely dwarfs many of the reoccurring payment applications... and instead propose a solution which doesn't need BIP32 at all, which works fine today, and which people _do not use_ because it is too costly relative to the privacy provided.  I don't think anyone would be at danger of not realizing that the forum would know about forum issued addresses, but even if they were— the alternative you propose can already be used and observably isn't in very many cases.

I believe you're allowing your dislike of third party delegation to blind you to all forms of delegation.  I run a website on a not very secure VPS. I would rather it not be the case that someone who compromises the VPS be able to steal all the funds. So I delegate an extended public key to the VPS to allow it to compute new addresses for payments, the spending of which is handled by an entirely air gapped wallet.  Because some people may fail to pay the usage may be sparse, and you can not depend on advancing only to the next unused address or payments will be missed.

If you start to respond that my VPS would be a honey pot and I shouldn't have an extended public key on anything which isn't completely secure, please just don't reply. If you have an issue with one of the design objectives of BIP32 then please feel free to ignore that objective completely.  Other people live in a world where security involves complicated tradeoffs and are going to go ahead happily using it for what it was specifically invented for.

If you're going to encourage people to upload their extended public keys to this forum to hand out to other users on their behalf, then some of them are going to believe they are getting more privacy than they actually are. That is only marginally more secure than posting a static public address and might be worse in practise because of the false sense of security. That's what I mean by a honeypot.

If Alice is expecting a payment from Bob, then she just watches her series of addresses, incrementing her lookahead windows appropriately, until she sees the entire thing.

If Alice is worried about Bob being a jerk and sending payments out of sequence or otherwise inconveniencing her, she just need to arrange the deal such that she waits to deliver whatever product or service is being paid for until she can confirm the payment. That puts the onus on Bob to uphold good behaviour if he wants Alice to follow through on whatever deal is happening in a timely manner.

Alice should also never give the same extended public key to two people, so one person's griefing won't affect her dealing with anyone else.

If we're talking about donations, and some donor wants to send the donation to the address at index 1000000 instead of 1, then Alice will probably not see it for a while. She's no worse off though than if the donor had never sent it at all.

Because I'm an evil nasty person out to do you harm. Because thats totally more likely than us just having an honest misunderstanding and me not being able to figure out how you're not crazy here. 

Under any circumstance where it happens when the receiver is not looking forward at least 1000 addresses.

You've subtly misrepresented what I said, which doesn't particularly surprise me, but whatever.

Are you honestly claiming that creating a honeypot is a way to improve privacy?

Under what circumstances would this be a problem?

Please take a step back and consider how you're responding here.  Some people want to post addresses online so an anonymous party can pay them, even when they aren't online.  They can and do currently do this by throwing up a static address.  You are instead saying they need to be online 24/7 and use bitmessage or torchat or any of a bunch of other things that they aren't already using.

You have failed to improve anyone's privacy. With your response practically anyone, including _myself_ would just continue what they've been doing. Good job.

No. The worst he can do is send nothing to 1000 addresses and then someone else sends 100 bitcoins to the next one. Knowing how many addresses gap there are permitted to be is important information!

If you're talking about an attacker trying to grief the recipient by consuming large numbers of addresses, the worst he could do is send a single satoshi to each address in sequence, and since the number of satoshis is finite there's no "forever" involved.

What if there is no "last transaction"? How else but a lookahead bound to you propose to avoid scanning forever?

Why? As keys are used, just keep moving the lookahead window forward until you find the last transaction.

The recipient still has to have some bound on the key lookahead, so in reality even with an extended key there isn't infinite flexibility about how to send money.

Off-chain Transactions - Bitcoin 2013 Conference - Peter Todd <- it's well understood how to prevent all those things.

Anyway decentralized consensus theory has advanced to the point where we can probably build crypto-coin systems that allow for much better tradeoffs when it comes to scalability, transaction volume, and security. But they'll require thousands of lines of code, and years of testing before any of it gets implemented. They're also all systems that clearly expose the underlying "There Ain't No Such Thing As A Free Lunch" nature of the world; outsourcing your security to miners comes at a cost and I mean it when I say these systems have tradeoffs. But so does Bitcoin - it's just not made obvious yet because Bitcoin is still in its infancy.

Anyway for now we've got the Satoshi Bitcoin v1 system, and we have to live with it's limitations.

You mean, no privacy issues other than that users are forced to hold their funds with a third party service who can monitor their transactions or lose or steal their bitcoins.

Yes it does: spending 100 transactions costs more in fees than spending 1 transaction.

At least, that's what it looks like at first glance; in reality it depends on how you spend your coins. Take the example of Alice, who receives a weekly paycheck from Bob, valued 100BTC: She starts off with a single txout, of 100BTC value, and pays her bills, buys lunch, gives her kids their allowance etc. Each payment she makes results in a wallet with a (100-expenditures) txout, so she's averaging one input and two outputs per transaction. If her payments were all 0.5BTC, she'll would have made ~200 transactions before that txout is finally used up. She could have instead received ten 10BTC txouts instead, and her total transaction fees paid would have increased slightly because a few more of the txouts would have had multiple inputs as the money ran out. But all the same her total tx fees have increased for the sake of maybe privacy.

On the other had Bob, who runs an online store, has to combine the payments of 200 customers to pay Alice. He has to pay transaction fees on the ~142 bytes required per txin, and the last thing he needs is for his customers to start paying him with even more txouts.

Having said that even Bob still has a privacy problem as it's likely that his payments to Alice, and his other employees, are going to end up linked together; Alice certainly has a problem. Overall they both could benefit from cut-thru payments, both to reduce total transaction fees, and improve privacy. I think in most cases it'd be enough to have Alice's wallet software just give Bob a list of addresses and amount ranges she's interested in - I don't think it's really required that for Bob's customers' wallet software support anything beyond single txout payments, although it wouldn't hurt.

Of course all this stuff is really assuming that blockchain space remains cheap enough that most transactions happen on the blockchain, in which case you have to wonder why anyone would care much about fees. On the other hand if blockchain space is expensive, Alice's transaction patterns are going to be mainly receiving large chunks of Bitcoins, and moving them to off-chain tx services periodically. That's easy to do with single-txin, single-txout transactions, has no privacy issues at all, and will naturally be supported by wallet software to save on fees.

That's for the sender to figure out, based on whatever balance of privacy vs speed of transaction vs fees matches their own preferences.

The recipient doesn't need to know or care about that at all. If they are expecting a certain amount of funds to arrive they just keep watching their sequence of addresses for it to show up until it does. It shouldn't matter to them whether it arrives in a single transaction or 100 transactions.

One of the problems with the payment protocol with single addresses (instead of extended pubkeys) is that the recipient can effectively dictate the amount of potential privacy the sender can enjoy. (Refuse to provide more than a single deposit address and the sender might be forced to combine outputs from different addresses to make the payment, thus linking them on the blockchain). If that somehow become a default setting somewhere then we get privacy turned off by default in a large chunk of the ecosystem.

On the other hand, if the recipient provides an extended pubkey they can't restrict the number of payment addresses the sender uses and appropriately-coded clients get privacy on by default.

Sure, I understand that, but then you're back to wondering - how many keys should I use, and what values should I assign to them?

Extending the payment protocol with deterministic pubkeys would be interesting and it was already suggested a long time ago. That's the sort of thing it's for. But you'd probably want to extend it with some kind of subscription related info at the same time. Otherwise it's incomplete ...