Bitcoin Forum

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

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.

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

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.

HD wallets?

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?

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.

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.

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.

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

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.

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.

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.

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?

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

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.

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. 



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 :) 

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.

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.

It's still an inexcusably-high amount of metadata to leak.

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.

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.

The payment protocol makes a lot more sense to me too.

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.

This is for cases where the number of future transactions is unknown, and perhaps unbounded.

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.

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

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.

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 (https://bitcointalk.org/index.php?topic=300809.msg3227426#msg3227426), 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.

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.

Off-chain Transactions - Bitcoin 2013 Conference - Peter Todd (https://www.youtube.com/watch?v=4d3LA8KpdMQ) <- 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.

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.

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

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

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.

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!

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.

Under what circumstances would this be a problem?

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?

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

I'm really very confused by your comments.

Being able to delegate address generation to less trusted things, like a VPS— allowing you to have unique addresses where otherwise reuse would be required was a major design goal of BIP32.

Yes, you could have some always online trusted server communicating over some strongly private channel. But that just isn't practical in many cases.  As evidenced by the rampant use of static addresses in these places.  Allowing the less trusted device to generate addresses is a _strict improvement_ in privacy over the alternative of equivalent usability, because it reduces the space of parties who can deanonymize these particular transactions to only those who can compromise the less trusted issuer.  True, it does not replace issuing from a trusted location— thats still preferable— but presumably people would still do that where its actually possible, as they already do.

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?

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

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.

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 (https://bitcointalk.org/index.php?topic=19137.msg239768#msg239768).

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

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.  

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.