I think the message would be to educate them on this— that they can have users provide a single public key and then generate unique sequential addresses without any further user interaction where the user will have the private key... and find out what they need to make it a reality.

Wallet support for being able to easily just ask for a xpub address is in the pipeline (at least from armory, electrum, and bitcoin-qt) but not there yet— so the only people who could use it now would be people doing it manual style like I just described, but it would be good to get the pipeline primed. E.g. are there OSS tools that they're using that need the support added to them?

Well, you don't have to wait for wallet software yet.

Here is an example:

Grab pycoin:

https://github.com/richardkiss/pycoin


$ python pycoin/scripts/genwallet.py -u -g > private_key
$ cat private_key
xprv9s21ZrQH143K4SHxWhmMDebDpB85Jo9wgwxnbHwXeGs5nnfCdwohgHv3bMnVGZMtgsVkNp1FsuA jSFu7caFh6qMrQ4ognrs5MUkoQChT1QM


Thats a private key, put it someplace safe. Now:


$ python pycoin/scripts/genwallet.py -f private_key -s 0.pub
xpub69Nh7f4uTEF6N1CdXpEp44AevN31pt1KdS8S4mqoLk2X4CS684gY2enwoJdmeaemB2atbU5gF1s waCwpaP4aAhgsFUzRMyHckSyoi8rbsbi


Thats a public key, it's what you'd give to eligius.

Eligius would generate addresses for you:

$ python pycoin/scripts/genwallet.py -k xpub69Nh7f4uTEF6N1CdXpEp44AevN31pt1KdS8S4mqoLk2X4CS684gY2enwoJdmeaemB2atbU5gF1s waCwpaP4aAhgsFUzRMyHckSyoi8rbsbi -a -s 0
1B7Y1zpPqcNoXDeB9NqRXg97gHCTYuQzNv
$ python pycoin/scripts/genwallet.py -k xpub69Nh7f4uTEF6N1CdXpEp44AevN31pt1KdS8S4mqoLk2X4CS684gY2enwoJdmeaemB2atbU5gF1s waCwpaP4aAhgsFUzRMyHckSyoi8rbsbi -a -s 1
1Q53tMUTzKjxYjnSFC58MtCQs6tEszUu7M
$ python pycoin/scripts/genwallet.py -k xpub69Nh7f4uTEF6N1CdXpEp44AevN31pt1KdS8S4mqoLk2X4CS684gY2enwoJdmeaemB2atbU5gF1s waCwpaP4aAhgsFUzRMyHckSyoi8rbsbi -a -s 2
1LyNrtpHuEjHMTmg9PWRxeP7jCpZuKiBsr
$ python pycoin/scripts/genwallet.py -k xpub69Nh7f4uTEF6N1CdXpEp44AevN31pt1KdS8S4mqoLk2X4CS684gY2enwoJdmeaemB2atbU5gF1s waCwpaP4aAhgsFUzRMyHckSyoi8rbsbi -a -s 3
16QPNHmkac7JurbJLwmBvkPjrFgNR13yvt


and you can generate the matching private keys in WIF format:


$ python pycoin/scripts/genwallet.py -f private_key -s 0/0 -w
L4DobQyRtccLvA3Hna5DDpUSfKdWx7wLMbTA9DXgUfq61vypeckb
$ python pycoin/scripts/genwallet.py -f private_key -s 0/1 -w
L4tytdhG8p6oJXQpFmCrZ4GWRVfHJe8FthxDTGn7HHYc6Yx7ZtuT
$ python pycoin/scripts/genwallet.py -f private_key -s 0/2 -w
L5iwTNQYuwC6VG4SnsFKSULB6mvCjW6om1L9AifAYC2FPGi3ZGwV
$ python pycoin/scripts/genwallet.py -f private_key -s 0/3 -w
L4mAzvyZvRdtLa2u2BhT8dxLFDELgWR5p8wipSrJ6iLXhXzNDFaq


No reason to delay supporting this on eligius, as at least some users could be using it today.

Because the whole concept of "red" to begin with is a human imposed concept which is senseless in a world where people are widely and casually using coinjoin. This is why its important that it be made as easy and as cheap as possible, because its not really useful to anyone unless its usable by everyone.

0.7.1 will not work reliably anymore, there are workarounds but you really should upgrade due to other vulnerabilities.

There is an address in my BCT profile, or you can contact me in PM for a unique address.

A couple points of comparison come to mind:

The paper proposal has a probability of cheating related to a security parameter, and requires communications in the setup phase linear in that security parameter (though I'd previously described a cut-and-choose communications optimization that could help).

The paper's proposal has an anonymity set of only all such transactions, as the hash commitments will be made public. In the case where a CoinSwap is successful the transactions just look like 2-of-2 escrows which likely results in a larger anonymity set.

CoinSwap doesn't require a third party, Bob can be alice and I noted this in the post. I just thought it was easier to describe using three (or four) parties then trying to make distinct one party operating in multiple roles... an effort to try to simplify some of that complexity you mention.

Generally I prefer protocols that have complexity moved into the initial setup, but the widened anonymity set achieved here by using all escrow transactions is probably worth losing the ability to front-load the complexity.

Whatever made {B} interesting to them in the first place. Perhaps he was involved in an unusually high value transaction.  Perhaps {B} paid to a "Free tibet" honeypot or well known (reused) donation address and the attacker is the chinese government and now they want to identify B to send him to a reeducation camp.

People never worry about a lot of things, including some things they really should and some things they'll later greatly regret not worrying about.

Anyone can start a foundation, feel free to start your own. The more, the merrier.

Every place the rules are made tighter the system becomes harder to implement correctly and harder to improve in a backwards compatible way. One more thing which someone can be invisibly and nearly undetectably too lax on and cause a terribly hardfork if their implementation is ever widely used.

For example, I suggestion I'd made in the past is that someday transactions could contain small (32 bit) checkpoints against random blocks in the recent chain such that the transaction's fees can only be collected in blocks descending from that checkpoint.  This would allow users to make sure their fees are not funding a malicious miner who is mining a fork which is against their interest. Such a thing would require that the coinbase outputs be less than the allowed value in those cases.

Regardless, your invariant would also be violated by the duplicate coinbases or by unspendable OP_RETURN coins which should not be tracked in the UTXO.

This is by far not the most finicky or subtle implementation rule in the Bitcoin system.

Every time I see someone trying to reimplementing Bitcoin themselves my heart is crushed a little bit. There are so many things that need to be created in our ecosystem beyond yet another reimplementation, most of which are never completed, never made correct, and never widely used.

A always reuses addresses. Blockchain.info uses this to display their name and IP address along with their transactions, everyone else they've ever transacted with knows who they are, anyone can identify who they are with a simple google search, etc. Because A reuses so often even if A sometimes doesn't reuse, the coins they receive inevitably get mixed up with the non-reused one. A is entirely public.

Now B is super careful and paranoid... and we're not even in a world where blacklisting or whitelisting prevents B from comfortably using his paranoid practices. He never reuses.  Someone is trying to figure out who B is because they want to defraud him.  Initially they are thwarted by B's pratices but then they see that B initially received his coins from A. Everyone knows who A is. Moreover, they see when they did so. From that alone they've learned a ton of information about B, beyond that they can now go ask A to tell them— they could coerce A, or just trick him, as we've already established that A is pretty happy go lucky and not very cautious.   Beyond that it isn't just A,  B also transacts with other people who are not hygienic and those all potentially leak information too.

This actually works in practice, too... A nice whitehat hacker on IRC was playing around with brainwallet cracking and hit a phrase with ~250 BTC in it.  We were able to identify the owner from just the address alone, because they'd been paid by a Bitcoin service that reused addresses and he was able to talk them into giving up the users contact information. He actually got the user on the phone, they were shocked and confused— but grateful to not be out their coin.  A happy ending there. (This isn't the only example of it, by far ... but its one of the more fun ones).

Uh. We've gone pretty far offtopic here, perhaps these posts should be split from this thread?

You already have to use one address per purchase (/customer) or you cannot tell who paid you. This is already the universal practice in Bitcoin payment processing.

No, a payment is a payement is a payment. There are no accounts or balances in the blockchain itself— it's completely blind to things like addresses.

Because reusing addresses makes it open to everyone, not just the relevant parties you'd like (or have been ordered to) disclose them to. Worse, your lack of privacy make everyone you transact with and everyone they transact with less private.  Your comments about "always choose" are empty promises in the face of proposals to have black and white lists which will limit your ability to transact, and empty in the face of privacy losses created by people who you've transacted with.

I can turn everything you've said right around— there is nothing preventing you from privately identifying yourself and registering your addresses. You can always do this and the parties you transact with can to. Nothing about requiring privacy preserving behavior in the public network prevents you from separately having information disclosed about you, nothing can prevent investigations from happening. But the converse is not true, the lack of privacy in the public network very easily prevents people from choosing to be private at all, and it very easily can make Bitcoin worthless as a money like good.

Sure they will, the first transaction will take all your coins from that source and they'll end up at a new, never used before, change address.

D&T answered Eleuthria exactly, the miner payout case was a major design consideration for me for BIP32. It can still be happily locked, and the users non-mining addresses can be unknown to the pool.. and yet every payment can be to a new address known only to the user and the pool. Basically everything you could want there except not being widely deployed. Yet. Isn't it good we've had this conversation now?

I can't seem to find the link to your bank account records, mind posting them for us?

Luke is pretty much the last person you'd expect to give a crap about underground uses. But privacy is _not_ only a consideration for them, or even primarily for them: dope dealers—or whatever you want your bogeyman to be—can buy their way to privacy even in a system which is very non-private.

Financial privacy is an essential element to fungibility in Bitcoin: if you can meaningfully distinguish one coin from another, then their fungibility is weak. If our fungibility is too weak in practice, then we cannot be decentralized: if someone important announces a list of stolen coins they won't accept coins derived from, you must carefully check coins you accept against that list and return the ones that fail.  Everyone gets stuck checking blacklists issued by various authorities because in that world we'd all not like to get stuck with bad coins. This adds friction and transactional costs and makes Bitcoin less valuable as a money.

Financial privacy is an essential criteria for the efficient operation of a free market: if you run a business, you cannot effectively set prices if your suppliers and customers can see all your transactions against your will. You cannot compete effectively if your competition is tracking your sales.  Individually your informational leverage is lost in your private dealings if you don't have privacy over your accounts: if you pay your landlord in Bitcoin without enough privacy in place, your landlord will see when you've received a pay raise and can hit you up for more rent.

Financial privacy is essential for personal safety: if thieves can see your spending, income, and holdings, they can use that information to target and exploit you. Without privacy malicious parties have more ability to steal your identity, snatch your large purchases off your doorstep, or impersonate businesses you transact with towards you... they can tell exactly how much to try to scam you for.

Financial privacy is essential for human dignity: no one wants the snotty barista at the coffee shop or their nosy neighbors commenting on their income or spending habits. No one wants their baby-crazy in-laws asking why they're buying contraception (or sex toys). Your employer has no business knowing what church you donate to. Only in a perfectly enlightened discrimination free world where no one has undue authority over anyone else could we retain our dignity and make our lawful transactions freely without self-censorship if we don't have privacy.

Most importantly, financial privacy isn't incompatible with things like law enforcement or transparency. You can always keep records, be ordered (or volunteer) to provide them to whomever, have judges hold against your interest when you can't produce records (as is the case today).  None of this requires _globally_ visible public records.

Globally visible public records in finance are completely unheard-of. They are undesirable and arguably intolerable. The Bitcoin whitepaper made a promise of how we could get around the visibility of the ledger with pseudonymous addresses, but the ecosystem has broken that promise in a bunch of places and we ought to fix it. Bitcoin could have coded your name or IP address into every transaction. It didn't. The whitepaper even has a section on privacy. It's incorrect to say that Bitcoin isn't focused on privacy. Sufficient privacy is an essential prerequisite for a viable digital currency.

So, again, I ask—let's see your bank records; I'm sure there is an export to CSV.  Mtgox transaction dumps? Stock trading accounts. Let's see you—even just you—post all this before you presume to say that you think that's what the public wants forced on everyone.

Certainly before _all_ the hashrate does something like this. But so long as there is a substantial portion of hashrate not doing it the other behaviors will still continue.

Basically concurrently is the only option, because people who are _pro_ things like blacklists (and, yes, they do exist) are going to argue against privacy enhancing features,  and so with miners running this there is now a pragmatic non-privacy and non-anti-blacklisting reason to change behavior: Faster confirmations. There also needs to be some co-evolution, e.g. what reuse depriorizing schemes are easy to implement and what reuse avoidance schemes are easy to deploy.

What the wallet software should be doing is taking as many payments as possible to the same address and spending them at once, fixing that has been on my radar for some time.  Personally what I (as a p2pool miner) do these days is group up my p2pool inputs via manual coin control whenever I spend them.

In the future the p2pool share chain could include BIP32 extended public key in the shares and ~every block could be paid to a new address, though they'd be linked to any party that captured the sharechain.  But in general better coin selection in the wallet should handle it nicely.

The strongest defense is complete immunity.

Within the design of Bitcoin today we cannot (yet) have the kind true anonymity which would make Bitcoin completely immune to censorship. Instead, Satoshi envisioned a system of pseudonymous addresses (Bitcoin.pdf (section 10: Privacy)) where your non-anonymity was inconsequential because the addresses were meaningless.

Unfortunately, to enact that vision original Bitcoin wallet software needed to use pay-to-ip-address to fetch a new address for every transaction. Pay to IP had issues and so it was largely replaced with addresses. Convenience and ignorance, distractions like vanity addresses caused people to begin constantly reusing addresses. Wallet software was release that made avoiding reuse hard or nearly impossible.  The vision of privacy through pseudonymous addresses has been broken, Bitcoin has lost its privacy. The result is that white/green/black/red/etc listing addresses is not technologically impossible in our ecosystem today.

But, no biggie, we can fix that. Tools like BIP32 let third parties generate fresh, never before used addresses for you without your help, etc.  Of course, this has been possible before, but there was no immediate benefit to fixing your privacy for the bulk of the users— who aren't paranoid enough to worry about their privacy. But to stop the colored lists we need the _default_ behavior of nearly everyone to be behavior that will make those lists ineffective. Only by changing what most users do can we gain immunity.

Thats why I think it's a good step forward that we now have a large mining pool (Eligius) experimentally giving priority to transactions which use never-before-used addresses. Now people who were squishy on the benefits of privacy and immunity to censorship (and the resulting loss of fungiblity) can get a concrete benefit from switching their software or practices to ones which improve everyone's privacy.

What the patch Luke posted does impacts both inputs and outputs, but doesn't hurt the case where you do an unconfirmed spend of a fresh payment in the same block.  And yes, they'll still go through, just deprioritized (currently in the form of only allowing one use per block) so they'll take longer.

How about more meta than that:  Whitelisting schemes require you to constantly use whitelisted addresses.  Blacklisting schemes are more powerful when the blacklisted parties use constant addresses.

So there is a behavioral difference in transactions which are compatible with a white/black listing broken fungiblity universe: They constantly reuse addresses.  Reuse is already a long term known-bad for privacy thing— so why not depriortize transactions which reuse addresses?

You want the fastest confirmations? Transact in a way which is not compatible with white/black listing.

And its already a reality: Eligius (15% network hashpower) is now experimentally limiting reuse to once per block.

In most normal business use you already must use a new address for each transaction you receive in order to distinguish which user is paying you.

Note that reuse has always been problematic and this isn't news. How long do we have to wait for uses to improve their transaction hygiene while there is no direct incentive to do so?
Was it an anti-casuaul knee jerk reaction that had me running a similar patch on my mining farm years ago?