Bitcoin Forum
November 13, 2024, 01:46:24 PM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: HD wallets for increased transaction privacy [split from CoinJoin thread]  (Read 5776 times)
justusranvier (OP)
Legendary
*
Offline Offline

Activity: 1400
Merit: 1013



View Profile
October 18, 2013, 08:38:04 PM
 #41

I am struggling to come up with any remotely rational basis for your complaint.  Are you under the impression that a user could only have a single chain, and thus this practice would reduce their privacy for all their addresses rather than just the subset which would have instead used a single static address?
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.

Under any circumstance where it happens when the receiver is not looking forward at least 1000 addresses.
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.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
October 18, 2013, 08:47:59 PM
 #42

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.
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.

Under any circumstance where it happens when the receiver is not looking forward at least 1000 addresses.
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.
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.
justusranvier (OP)
Legendary
*
Offline Offline

Activity: 1400
Merit: 1013



View Profile
October 18, 2013, 08:52:55 PM
 #43

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.
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.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
October 18, 2013, 08:56:27 PM
 #44

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.
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).
justusranvier (OP)
Legendary
*
Offline Offline

Activity: 1400
Merit: 1013



View Profile
October 18, 2013, 09:00:43 PM
 #45

Nor is there a need to give customers in many cases an extended public key such as when there is no reoccurring payment relationship.
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.  
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
October 18, 2013, 09:06:04 PM
 #46

Nor is there a need to give customers in many cases an extended public key such as when there is no reoccurring payment relationship.
The customer might not have a single address contain a sufficiently-large output to make the payment. In that case, the customer would prefer to use multiple payment addresses to send the payment in two or more transactions.

The need for multiple payment addresses is not strictly related to whether or not payments are recurring. 
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.
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!