Bitcoin Forum

Addresses have always been considered single-time-use since Satoshi released the whitepaper.
While the community has tolerated reuse for things like donation addresses due to lack of convenient alternatives, it looks like the time is here early that this needs to stop.
I had hoped to defer anything in this area until wide deployment of the payment protocol (which should make such things unnecessary), but our hands¹ (https://bitcointalk.org/?topic=333211) are perhaps² (https://bitcointalk.org/?topic=333824) being forced³ (https://bitcointalk.org/?topic=333586) to act sooner⁴ (https://bitcointalk.org/?topic=334265).

I am hereby announcing the first release of a the first patch for miners to filter address reuse:
unique_spk_mempool for bitcoind 0.8.5 (https://gitorious.org/bitcoin/luke-jr-bitcoin/commits/f6ceb1d6434ea00c3f632fa90e4237d9b9baba6f)
For now, since this is still somewhat common, this just deprioritises it to one reuse per block.
If I have time, I plan to write patches to be more and less aggressive that miners can choose between (or maybe others will beat me to it!).

If you want to support this move, encourage your favourite mining pool to adopt this or a similar policy change, or use a decentralised pool that lets you apply it yourself.

In collaboration with wizkid057, the Eligius mining pool (http://eligius.st/) (15% of total network hashing) is now the first to deploy this change on an experimental basis.

Reserved (for pool position list/summary, etc).

Pool	Patch/Position
BTCGuild	Waiting until threat materialises more. (https://bitcointalk.org/?topic=334316.msg3588095#msg3588095)
Eligius	unique_spk_mempool

good on you man. This was the best approach to stick it up yifu's ass.

I'd previously run something similar on my miners.

Beyond encouraging behavior that improves privacy for everyone and making censorship more of a non-starter, this has a benefit of giving naturally more equitable access to the shared resource of the blockchain:  If someone is self-identifying as a single user by using an address over and over again, why not use that information to give other transactions (which may all be from independent users) more equal access?

The specific details of what form the deprioritization takes are less clear. Right now this patch implements a hard prohibition on reuse that has a one block scope. E.g. if there are 10 transactions with 1APPLE and if all miners ran this patch it would take 10 blocks for them all to make it in.   I'd probably prefer something softer (e.g. treat reuse as having half or quarter the fee/priority), but with longer memory... but the important thing is to get it out there and explore the ideas and effects, and also clean up some of the Bitcoin ecosystem which was lazily reusing addresses constantly for no reason except nothing was incentivizing them to fix it.

We need to get some things (like BIP32) deployed to eliminate some of the sources of reuse, but it does no good if only the paranoids use it,  faster confirmations will be an added incentive for the changes than the amorphous and indirect benefits of inoculating our economy against censorship and loss of privacy.

How would this effect things that require a static address? (Donations, etc.)

I personally would prefer to see those HD addresses, or address scopes.

So you're going to make it harder for people to spend coins they legitimately earned.  I have no intention on slowing down transactions on the network by forcing people to implement changes to how they receiving mining payments/accept donations due to overreaction to some Coin Validation scheme that I doubt will ever actually come into existence.  I'll react if it shows the slightest sign of ever actually being implemented, but I highly doubt it ever will be in the first place.

I particularly think this is a good "selling point" to this.

Yeah lets make things more complicated!! Who wants user-friendly bitcoins anyways...  ::)

Btw what's the reason for such a change? Are we after vanity addresses or something  :P :P

Those things don't require a static address; it is simply much more convenient to use one. Ostensibly, deprioritised transactions may still go though, but it may take hours of days. If you are only emptying such addresses monthly, should not be much of a problem. Fees can likely be used to bump the priority back up.


Check the links in OP. White/green/red/black-lists are coming. If implemented by a large number of merchants or exchanges, they will hurt the fungibility of Bitcoin. Without fungibility, you don't have money: you have collectibles.

Except if you are expecting more than a single transaction every 8mins. Are you saying we should make it harder to use bitcoins? I am all for the change, but there does not appear to be the infrastructure in place to support this change. Implement HD addresses and we would be ready to go.

Knee Jerk Reaction.

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

There are things in the works to make things easier, like the payment protocol and BIP32.
As I said, it would have been nice if these matured before we phased out address reuse, but it seems we don't have that kind of convenience.

Would this effect both inputs and outputs to the address?  And I am correct in understanding this simply would make confirmations longer but not somehow land them in forever limbo?

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.

Luke-Jr, even this one?

Donate: 134dV6U7gQ6wCFbfHUz2CMh6Dth72oGpgH

So someone might do something, maybe, and this something might catch on and might cause something we don't like so let's do X right now.

Fine line between "knee jerk reaction" and "being proactive".

OK, having said that the proposal does not sound that bad, might do some good, no one can stop you, does not appear to affect me one way or the other (as proposed).  Go for it!

I applaud the effort.  Thanks Luke.

Question: if one were to apply this patch to bitcoind that is being used by a local p2pool instance, what happens?

I guess it should work.... thinking it through.  Unpatched machines would be submitting shares including the re-used addresses, but patched machines would be submitting shares with unique output addresses only.  A block may be found by a patched or unpatched bitcoind, so the uniqueness would be enforced (or not) depending on the bitcoind instance of the miner that finds it.  So everyone just gets along.

Does that sound correct?

My question was sarcastic. People are acting like they discovered that a public ledger exists only after that blacklists thing.
Yeah that ledger exists.It is called the blockchain. Like someone else said before: stop overreacting...

The current design for p2pool pays out as a trickle of multiple payouts across a 72 hour period to the same address...

This patch really seems to punish / rate limit anyone using p2pool since they will only be able to spend once every ten minutes for any transactions which had to tap into the freshly mined bitcoins (120+ confirm-blocks deep in bitcoin's blockchain)

Is it really THAT urgent? I figured the payment protocol was coming out within 6-12 months... and I doubt any coinvalidation thing is going to gain significant ground before then. What are your projections for how things would evolve in time?

Soooo...I use the same receive addy for mining on Eligius & other pools,do I have to change that addy every say 2 hours or 2 days on every pool ??? 

Or am I missing the point  ::)

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.

Yes, p2pool users can immediately make use of the patch like this.

Shouldn't this go first or at least be done somewhat concurrently with the proposal?

More importantly shouldn't the input selection algorithm on the wallets be changed to take this new mining behaviour into account and attempt to group inputs and select them in a way that minimizes the number of times a spend is delayed due to this change?

One very common scenario is to use a bitcoin address as the identification. This may be used in faucets, mining pool, gambling sites, and maybe future block-chain based exchanges. If address reusing is discouraged, any alternative is suggested? To introduce another identity-> bitcoin address translation layer?

Maybe you mean outgoing only? An bitcoin can accept many incoming transactions, but it can send out coins only once? That's a little bit better, but still in many scenarios people are expecting coins are sent from the same address. Mastercoin is an example.

If people want to hide their trace, they can choose not to reuse addresses. If people don't care, why have to increase the difficulty for them? Why not just let the users to make the decision?
 

Address-as-identity does not use the blockchain at all.

Reusing addresses doesn't merely hurt your own privacy. It hurts everyone's.
There are also security ramifications. And now adoption issues too.

Hmm.   I'm not sure it is rate limiting p2pool payments.   Can someone clarify?

I interpreted Luke's announcement to mean that the patch only enforces uniqueness (per block) for addresses that are being paid to.   afaik, p2pool only makes one payment to a given address per block, so should be unaffected.

Now I do sometimes consolidate p2pool generated transactions into larger ones by sending larger and larger amounts back to myself.  I have re-used the same address for this purpose so that usage would be affected, but that is already somewhat rate limited by the coin-freshness checks anyway, and also I could just use a unique address for each payment.

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.

The software ecosystem is missing a useful piece:

When you are receiving regular payouts, from a job salary or mining pool for example, there needs to be address rotation.

Right now, the only way to do that is manually logging into the payer's website, and replacing the current payout address with a new one.

Software should communicate with the payer, or give the payer a list of addresses, or an HD seed that may generate additional public keys, etc.

Address reuse in these circumstances is annoying, hurting privacy, but inevitable until software improves.

So you mean BTC is mainly adopted by people wants 100% privacy?  On the contrary, it's possible that the majority haven't adopt BTC just because of the anonymity. Most of people heard of BTC but haven't convinced to use them because they think the government will not allow such things to exist. The main objective of BTC foundation is not to increase its anonymity, but to explain to the authority that it's not as anonymous as they think. What you are doing, IMHO, is not helping the BTC but killing it.

For those who wants complete anonymity, they can go for some altcoins supporting it. In my opinion, BTC is supposed to be used by everyone and everywhere as mainstream currency. So please stop doing things like this to push the majority away just for the sake of niche market.

To clarify the part which I just bolded:

I meant that this will act as rate limiting on the ///SPENDING/// of any new p2pool-generated funds as they come in

Not sure why you got the idea that I meant payouts.

Hence my question/comment above:


But even these changes to the input selection algorithm will not help you if all of your income is from one source (one pool to your one payout address) and you go on a spending spree and try to make a lot of payments in a short period of time, all your inputs will have to come from your one income address - delaying your payments.

Not sure how big/widespread of a problem this would be.

This is (basically) my argument at the moment against this.  In the case of BTC Guild, the *highest* level of security an account can have is locking the wallet address.  With this, you can not change it unless you digitally sign a message using the private key, confirming ownership.  Removing the lock is a manual process, nothing on the site is capable of removing the wallet lock once it's in place (even an SQL injection would not be able to do it due to lack of permissions).

Similarly, it discourages automatic payouts, since those would use the same address every time unless changed.  The last thing I want is automatic payouts adding hassle, considering they're the best way to encourage users to not use the pool as a bank.

The only fix on this I can see would be on my end adding some kind of "wallet queue" to accounts where they can pre-make a batch of wallets to use (maybe even using the BIP32 suggestions), but my limited knowledge of BIP32 leads me to believe this would still require manual entry on the user part.  If somebody else could generate the chain of public addresses to use, it seems like it wouldn't be very anonymous (they'd actually be able to follow all your transactions forever on that wallet-chain?).

BIP32 supports a hierarchy of pubkey seeds.   So a user can generate a pubkey seed ONLY FOR YOUR SITE and upload it.  Using that seed you can deterministically compute an infinite number of unique addresses in a sequence the user will expect.  

Wallet support isn't there yet which is the only negative of moving forward at this time but in theory that is how it would work in the future.  Your site would simply have user upload a seed for all their future pool payments.  You will be unable to deterimine any of the addresses in the user's wallet. You will always be able to generate a new address.  The same address never needs to be used twice.   For added security you could lock the pubkey seed the same way you now lock a single address.

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.

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

Awesome post! I truly hope the majority takes this view. I think I'll get too depressed about humanity if they don't.

No one asks you to make your btc addresses public. You can keep it as secret as you will. You can always choose to generate one-time receiving address if you want. But is there any reason to stop others to use one address as their public address if they think they don't mind?

Bank records are actually open to banks and authorities. So if there's some need, allowed by the law, they can do the investigation. But it does not mean I have to make it open to you. It is a controlled anonymity. My information is a secret to the public, but can be investigated by the authority based on the law.

Complete anonymity, however, makes laundering money unable to be detected. Then the authority has no other choices but to suppress it. BTC will not dead, I believe, even under suppression, but it will stay where it is and never becomes mainstream in that situation.

yeah, I think we should all put gmaxwell's post in our sigs for all to see.   ;-)

This isn't about anonymity.
If the government wants to know who you are, they'll subpoena your landlord to tell them.
Are you saying the majority of people want the unknown to-be-rapist down the street to know their every purchase, telling him where you've been and what you buy?
They want the pedophile-to-be to know when and where they drop their children off at childcare?

Why will they know my every purchase, and where I've been?  I don't understand. Just because I put a fixed receiving address on the mining pool?  Many people on this forum put their btc address in their signature for tips, what kind of privacy they lose?

It only happens when they are using that address to buy something requiring name and shipping address, right? I believe no one will use public address to pay for something they don't want others know anyway.

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.

Somebody please explain to me the following situation..
I have a business like a gas station or a fast food, in order to actually serve all my customers and have the bitcoins in my account (transaction confirmed) with this limit of 1/block or 250/day I would have to use multiple addresses. Won't this just put more pressure on the blockchain when people we'll try to cash out?

What will happen if you have 1000 customers a day ?

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.

Thanks for the info

Why do you need that? Do you accept credit cards? Do you wait for them to confirm as well (6 months)?
You have to use multiple addresses anyway.
"Addresses" are badly named: "invoice id" would be more accurate.
If you use the same address all the time, it'll be impossible to know which of the 10 or so paying-right-now customers failed to pay their bill.

Thanks for the response.
So the only inconvenience will be if you use the same address to pay for something you'll have to wait two block.
This is not as bad as it seems for the average user.

But , what will happen if the next pool decides to raise this for 1 to 100?
I'm more concern about what this could lead to that what it actually does , to be sincere.

Could you provide a concrete example to explain why reusing addresses by A will affect B if B always carefully choosing address. and how both A and B never reusing addresses prevent it? I'm still not so clear about it.

Since the drawbacks are very apparent, IMHO you need a very clear explanation about the benefit and why the benefit is far more important than the drawbacks.

 

I think client can help in this case. Whenever you are sending out BTC from an address, all unspent BTC are spent and send to a newly generated change address. In this case, no one will send out BTC with the same address more than once.

I just don't agree on forbidding one address to accept BTC for multiple times. That makes many things complicated and brings no apparent advantage. It will be enough to restrict an address to be used again once its balance is spent.

This could significantly reduce the frequency people have to change their donation address, tip address, and mining income address. But still it invalidates some useful applications, such as MasterCoin and maybe ColorCoin.

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?

http://blockexplorer.com/address/1Lukejrwhew7sj4TvWCKksaVo7aLpedHDt

Follow the coins back ~12 hops to where they were generated, then follow forward where they were sent to "A". Easy to identify the recipient and owner. Backwards, not so much.

Now if B's next payment with the change from that transaction is to "free Tibet", buy "recreational substances", or pay a hitman to whack a business partner, association with the transaction A may reveal identity. When A is shared and reused, as in "this is the donation address for Eligius", any separate-channel information about someone making a donation to Eligius can be used with this known address to reveal a path to their money.

https://bitcointalk.org/index.php?topic=334399.msg3589360#msg3589360
I've create a new topic and put my question there.

A question of mine is posted in https://bitcointalk.org/index.php?topic=334399.msg3589360#msg3589360.

The patch should be submitted to the main bitcoin project imo so it makes it into the next release.

"New address for each payment" is a logic bomb (https://bitcointalk.org/index.php?topic=334348.0)

So TLDR; you think that a collision could occur? Yes it could, but it won't.

Obviously u didn't read it.

Thank you Luke and Greg and everyone else who is going to deploy this modification.

It's unfortunate that Satoshi did not have time to plug the privacy leaks in his design, and those leaks are now starting to be exploited by seedy individuals.  But this kind of countermeasure (and the CoinJoin pull request) makes me hopeful that the Bitcoin community can (and will) respond rapidly to mitigate major threats.  Or, worst case, that the developers and miners are quite capable of coming up with a less leaky architecture + hardcoded best practices that could be built-in to a new cryptocurrency from the get-go.

I did.  So tl;dr:  People will try to discredit Bitcoin.

But they already do that so this is not new.

I started out not liking the proposal, got up on the fence, now fully support it.  In fact I now see it as only a first step in the right direction.

I now believe that we must do everything we can think of to protect the fungibility of Bitcoin.  Any attack on the fungibility of Bitcoin is a direct attack on Bitcoin itself.  In fact, I now believe that attacking the fungibility of Bitcoin may be the most expedient, cost effective and preferred method of attack by anyone who wishes to destroy it.

Thanks to everyone who is on top of this.  We should be behind this proposal and considering additional proposals.

This would seem to be an objection to whitelisting addresses.  Read of that recently.  Mellon, of the banking industry I think it was.  Wants to whitelist addresses that don't want silkroad besmerchment.  Except for making oneself banking industry targetable by them having one's identity it seems like a good idea.  I'd ignore it rather than work against it.

Ok, let's assume that BIP0032 will be used.
Is it possible to create new addresses with PHP or Javascript, without access to a bitcoin client?

Yes. 

So a Q... As a miner with a static address on my pools... how do we deal with that?

Ok question from relative noob... What if someone ,,inseminate'' my holding adress with 0.001 BTC? Do it mean I ll have problems to use this adress in future ? Sorry if the problem was answered earlier and I didn't noiticed.

How would anyone know your address before you use it?

https://bitcointalk.org/index.php?topic=254615.0

I voted for "don't do this".  While we should definitely encourage people to use bitcoin in privacy-friendlier ways, we should not force it upon them.  We should simply make it a default, but still an option.  People like vanity addresses.  Donations need single addresses.  If people want to give their privacy away by re=using addresses, we should let them and not de-prioritize them.  Privacy should come at the CHOICE of the user, not the FORCE of the miners.

It is still a choice just a choice with consequences.

Donation addresses don't need to be static.  It is easier if static but easier isn't an absolute.  Any address can be made dynamic.  It will require support of sites and services providers but with no incentive no such system will ever take place.

For example Bitcointalk could have a field where user inputs their pubkey seed.  It would then generate the first address from that seed and as you receive a donation it would detect it and rotate the address to the next available one.   Sound like a lot of work, maybe but once implemented it would be copy and paste easy for all users to have a dynamic donation address.  Will it happen without some incentive?  Probably not.

To imply it is forced would imply that the patch makes address resuse impossible, that coins sent to a used address are permanently lost and that isn't the case.

It doesnt stop reuse, it just means they wont clear as fast. So what.

Not sure what you point was.  The title is "DEPRIORITIZE" and that is exactly what it would do.  It creates a method for privacy and security minded individuals to create an incentive for like minded individuals.  Nothing more.  Nothing is being forced.  Nothing is being prevented.

We've been doing this since Satoshi first released Bitcoin...
The problem now is that unless we force strengthen this good behaviour, other interests will start forcing the bad behaviour.

Great, vanitygen has a -k option just for this!

No, they don't.

Address reuse forces non-privacy on other users.
If everyone is using Bitcoin correctly (ie, no address reuse), people can still choose to publish their transaction log.
That is, address reuse takes away the choice; forbidding it does not.

I know this is slightly off-topic, but why is it not being forced? Why not have that stuff as a fundamental part of the protocol? It seems that address reuse is causing nothing but harm, and after reading this thread, I don't see any legitimate reason why it's absolutely needed. So why not just eliminate address reuse altogether?

Protocol change would mean a hard fork and getting consensus on even mundane changes (google threads about P2SH) is very tough.  Getting consensus (or super super majority) on a contraversial change to make a hard fork go smoothly is essentially DOA.

You know, you make it really hard for me to argue my side when you do nothing but make well-reasoned completely fair points.

I see. That's good I suppose. Otherwise Bitcoin could be changed too easily.

But this sounds like a worthy cause. Maybe this is something that should be tried in the future.

It could be forced, but existing clients couldn't cope with such a change very well.
Furthermore, in the meantime address reuse has gotten way too common for donations, so will need some gradual change.
Finally, it's uncertain and unlikely that 51+% of miners are willing to shutdown this tolerance entirely right away.
If there was a clear agreement from maybe 75% of miners that this needed to be done, though, it could be...

Seeing as how it's common practice to re-use addresses I'd say the users have already decided. Why should you, the 15% mining pool host say otherwise?
 
Satoshi wrote it into the white paper as an additional privacy measure not as a mandate!!

""As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. ""

Who are you to penalize me based on your personal opinion?

Because miners can choose which tx to include in a block based on whatever criteria they decide?  If no other pool ever adopts a similar set of rules then at most the impact is 15% slower confirmation times.

What about non-standard transactions? Isn't eligius the only game in town for that?

If it's this important shouldn't Eligius start forcing new addresses for every withdrawal? Think the miners would go along with that?

It's easy to force your changes when the users of the pool can just passively go along with it. It's a lot tougher when you force them to actively make a decision on the issue.

Yes, migrating to HD/recurring invoice ids has been on the todo list for Eligius for a long time.
Unfortunately, wallet software has not matured enough for that yet.

This is a good start.  I think you've hit a real sweet spot with this and I hope all the miners take it up.

Without shutting anyone down, It puts just a bit of pressure on everyone to find ways to make it easier and simpler to use new addresses every time. 

And the pressure is adjustable; as it gets easier to do the right thing, it's easy to "dial up" the number of blocks between reuses making the wrong thing ever just a little bit less tenable. 

One problem though is 'perverse incentives' for miners in the form of transaction fees.  In est, the more miners deploy this patch, the greater the additional revenue enjoyed by the miner who does *not* deploy this patch.  This is because the miner who does not deploy the patch will be picking up tx fees from tx left "on the ground" by miners who have deployed it. 

As yet, I have never reused an address.  I intend not to.  I wish my client made it easier to be sure.

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

Cool.  I can talk to some other pool owners I know.

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?

I don't agree at all that this solves anything and thus was forced to opt for one of the personal assault options (why not word it less personal? yeah, tonal bitcoins edit war haha).

blacklisting would not work on an address basis but on an output basis and all of this output's descendants would be flagged, so it makes no change to incentivize using more addresses.

At first I was afraid your patch was about some security issue from private keys being revealed but now I feel like this move is simply bad for mobile clients that typically use just one address, for vanity addresses, for charities, satoshi dice (your biggest friend?), etc.

Is at least only the transaction from that address throttled or is it also the transaction to known addresses?

I can very well understand Luke's motivation for publishing and implementing this patch as a counterweight to CoinInvalidation and similar awfulness. Admittedly, my poor brain hasn't had time to sort through all the pros and cons here. But:


Er, not so. If you're arguing from the standpoint of a profit-driven business in a competitive landscape or from the standpoint of an individual burdened by increasingly pervasive financial surveillance, you're right, but those are not the only use cases for a currency.

There are lots of people around the world continuously pushing for more and more transparency in government finance, the logical endpoint of which is real-time, globally-visible transactions records for state treasury accounts. Most inputs (taxes, fines, fees, etc.) blinded for privacy reasons, and most outputs (salaries, goods, services, etc., but not, for example, welfare payments) required to be explicitly linked to an identity, for transparency and accountability purposes. Want to work for the state or one of its corporate appendages/owners? Be transparent and accountable.

The non-profit sector, and donors to it, would also benefit from such radical transparency. Charities that can prove that they're not blowing donor funds on exorbitant executive pay, corporate jets, fancy hotels and catering, for example, and are actually delivering real benefits to people in need (or at least working diligently toward what they've promised to donors), globally visible (at least up to the fiat interface or the real-world-goods/services interface), supplant and, er, out-compete, those which waste so much on overheads. For them and for donors, globally visible public records are a desirable feature, at least for the ones that survive the transition to a cryptocoin economy.

As another example, I operate a Bitcoin legal defense fund for the accused Dread Pirate Roberts (link in my sig). The transaction record to the fund's sole address shows that I've disbursed nothing of what's been given, and it needs to stay that way until I can properly justify an expenditure.

All of these models, and others, can benefit from reusing addresses tied to individual and/or institutional identity, and address re-use carries a massive benefit in simplicity ("donate here" QR codes on paper flyers? yes we can!), despite the known drawbacks. Deprioritizing or (especially!) filtering transactions seems to raise the costs for implementing such models, significantly.

(At another level, all of this sums down to mining pool centralization as systemic risk, but that's another discussion entirely.)

https://en.bitcoin.it/wiki/Identity_protocol_v1 ?

I what's important to remember is what Luke is doing with Eligius is a: just a one block delay, and b: can be easily changed later. Right now we have a serious problem with address re-use - doing what we can to stop it makes a lot of sense even if what we do isn't necessarily the perfect solution.

Even if reusing addresses was 100% banned and it was impossible to re-use an address ever, with appropriate tools all those examples of transparency that you cite would still be possible using BIP32: rather than achieve transparency by publishing the address, publish a BIP32 pubkey seed and derive all the addresses where funds are stored from it. In many cases this is an even better solution, because you now have the option to be selective about who you are transparent too.

On the other hand if you truly are trying to be globally transparent re-using a single fixed address has an advantage over the BIP32 option: it lets other people know that your transactions are not anonymous. If I receive funds in a transaction where the change address is the same as the address the funds were originally at, I know the funds I've received are not as anonymous as they could be, and I might want to take steps in response. But again, in this case a minor one-block delay does no real harm.

tl;dr: I fully support what Luke is doing in the here and now, and we can and should monitor the situation to determine if the strategy needs to be changed in the future.

Luke, can you describe more clearly what the patch does?
in particular:
- one reuse of any given address per block, or one address reuse per block?
- does it concern only  inputs, outputs, or both?  for example, an address
that has several inputs and tries to spend them all is deprioritized or not ?

right now the  [rationale/code] and  [reasoning/action] ratios are really too low.

The right way for an organization that desires this level of transparency is to use BIP32 and publish their extended public key.

The single address model for simplicity is like trying to use a screwdriver as a hammer.

My overall point is that this kind of solution tends to raise costs for certain use cases.

BIP32 is all well and good, but requires significant tooling for a donation-accepting entity to implement, requires much broader dissemination among wallet clients, and is largely incompatible with the widely-deployed single-address model already in use by many entities.

I'm not here to scream bloody murder about Luke's initiative, but rather to encourage looking at this from as many sides as possible. CoInvalidation etc. present real threats to Bitcoin as a privacy-enhancing system, but, as I think I demonstrated above, privacy is not the sole or even primary concern for every use case.

This would be all well and good if every wallet client (or even most of them) actually, you know, implemented BIP32! As it is, the best you can do is point me to a python tool? I'm capable of using it, but that just seems like a massive pain in the ass to go to. (Oh look, someone used another one of my addresses! Better boot to linux, generate the private key, and import it into my wallet!) And that's for me, a software engineer. What about the less tech-savvy users?

Moreover, most Bitcoin-related websites don't have BIP32 support either! They take one address for withdrawals. Some allow you to give multiple addresses, if they're a bit fancier, but even then, I'm supposed to post 50 addresses and log in to switch the address every time I get a payout?

And then there's Blockchain.info. Did you know Blockchain.info wallets reuse addresses by default unless you create new ones?

I appreciate the intent behind this proposal, but I don't think we're ready for this change yet. I do agree that we need to do this at some point in the future, but shouldn't we, you know, roll out the infrastructure necessary to make it actually workable first?

Hmm, I only scan read this thread, but as bitcoinj based wallets are one of the primary guilty parties in address re-use I'll just pop in to give my view:

People already have the right incentives to not re-use coins (privacy). SPV wallets suck at it today because I chose backup safety over privacy, but BIP32 let's us have our cake and eat it in that regard and it's now being implemented. So at some point SPV wallets will update and addresses will start automatically changing, users won't have to do anything. I'm figuring out ways existing wallets can be upgraded in place.

Punishing address re-use NOW, when many users who are doing it don't have any good way to stop, is just attempting to pressure volunteer wallet developers through their userbase. That's not cool. I already spend a lot of my spare time at evenings and weekends fixing bugs and keeping up with the Bitcoin protocol (20% only gets you so far and can't always be taken). Being "forced" to do it by punishing my users would be quite upsetting, especially as it's coming anyway and Bitcoin-Qt itself doesn't even implement BIP32 properly yet (AFAIK only Electrum has done this?).

I was not commenting on the advisability of the patch in the OP, just pointing out that just because people are using single address wallets does not mean that it's the right thing to keep doing.

That behaviour was known broken ever since the beginning, but since Satoshi didn't worry about the ability of users to backup their keys when he wrote the client (otherwise he would have gone with deterministic key generation), client developers responded by making wallets with a single key. Now a bunch of new users have been trained with bad practises and it will take some now to reverse.

"Guilty" is rather too strong a word, especially given that a library like bitcoinj sits fairly distant from the wallet UIs, which is where the flags and cautions need to be shown to the user.

What would be very nice to see as at least a minor mitigation here would be wallet clients presenting users with an additional challenge when attempting to send to an address the client has already spent to. That only takes a chink out of the systemic problem under discussion, but has a nice side effect in reducing the risk of a mis-click someplace leading to an unintended irrevocable spend to an incorrect address (which, er, I've done more than once).


Cool. I'd be thrilled if wallet clients used the BIP32 scheme as the default. It's a win for the whole ecosystem -- provided that, in light of the use cases above and others -- the choice to re-use addresses is not phased out.


Another very good perspective on this.

This is not the case.  My privacy is not an incentive for someone who wants to pay me coin, nor for someone whom I want to pay coin to.  It is only an incentive for me, and I need the cooperation of these other parties to make it work.  In the absence of some further incentive that works for all the parties involved, privacy simply has not happened and evidently will not happen.

It's nice to think it's "coming" in these newer clients, but my privacy is more secure, AFAICT, if when it does so people have some substantial reason to *USE* and *PREFER* these features of the newer clients. Otherwise I wind up out on the short end of the stick dealing with people who don't want the new client for some reason and who aren't sufficiently inconvenienced by my lack of privacy to care.

Really as a tech savy person you can't think of a better workaround?  How about generate and import 1,000 private keys.  Then when you need to change the address simply use the python tool to find the next one in the sequence.


Well they won't until there is a reason to do so and the patch gives them a reason.  In the interim if a site allows posting 50 addresses why would you need to manually change them.  It would be a trivial amount of coding for a site to use the next one automatically and notify you when the queue is low or out.  Still BIP32 is a better longer term solution.  However if sites don't implement them you can still use funds with a small disincentive.  That would encourage people to use sites which do promote single use addresses.


Then encourage blockchain.info to change their default behavior.  The issue of reuse has been known since a YEAR PRIOR to the genesis block.  It is unlikely without an incentive anything will change.  Lastly remember this doesn't prohibit reuse, it doesn't make coins sent to a used address lost, it doesn't even mean higher mandatory fees.  It is merely delaying secondary spends from the same address.


Chicken or the egg.  Without the incentive will the infrastructure ever exist.  Blockchain.info could easily (within minutes) change their code.  Will they?  Probably not.  Not until users complain.  Will users complain unless their is an incentive?  Once again probably not.  It isn't like Bitcoin just launched.  There has been years to do things right and the lazy, easy approach has been used in most cases.

This.  Privacy doesn't end at a single persons addresses.  It involves everyone one you interact with and everyone they interact with.  One can be perfectly anonymous and if the people they interact with are not well that can provide an indirect method of identifying transactions.

this is a real good idea with some small road bumps which can be solved.

I see:

Mining pools with a auto payout, slight problem here. I dont want to change my payout adress every 2 days... But maybe you can import a batch of addresses or maybe there is some way to link your wallet api with your pool to auto generate an adress. Not really sure about that since im not really a professional programmer.

Bitcoin wallet software should Automaticaly generate an adress whenever you send BTC.

Bet there is more bumps but these came to my mind now

I'm not a miner but I just discovered this important thread.  Excuse me if this has already been covered (thread now too long to read in full) but let me share my 2 satoshis:

I setup all my "converts" with the blockchain.info wallet on a smart phone.  People just send and receive to the same address over and over and I can see all the money flows into and out of their account.  You can't tell them to do anything different--they *think* they don't care, and besides it can't really be done on blockchain.info for mobile anyways. Most new users don't realize the potential for future privacy/security problems with address re-use.

I like Luke's idea because it would incentivize people like piuk to implement BIP32 for the main web wallet on blockchain.info.  Users would just see a balance in their "spend" account and the fact that a new address is being created for each transaction would be invisible to them.  This adds no complexity that I can see, but lots of privacy and security.  It seems only a good thing.  

BIP32 means you can give the pool your public key and it can generate a new pubic address for you.

First off, thank you for taking initiative and time to explain.

Another reason not to reuse addresses for sending is a compromised RNG. You may recall the issue with Android just recently. Only worked because private keys were reused for signatures.

http://crypto.stackexchange.com/questions/9694/technical-details-of-attack-on-android-bitcoin-usage-of-securerandom

I like what's being done here. At first glance, it seems rather rushed to throw this into miners straight away; but I guess it could be looked at as a shot across the bow, since it doesn't break any kind of transaction right now, just makes a certain subset slightly slower.

Also, I stumbled across this by accident. Shouldn't something like this be disseminated to the broad community? Maybe I missed it, if so apologies.

A third thought cropped up: put yourself in place of the regulator determined to implement rainbow-lists or whatever they're called nowadays. The first thing you're going to see is miners deliberately blocking your ability to trace "illicit payments". So you go after the miners ... wouldn't it be ironic if, by attacking large mining pools, the regulators pushed Bitcoin back into a totally decentralised mining model (maybe with less hashing power to start with, but not for long)? (yeah I know it's mostly nonsense what with the international nature of mining, but a fun thought).

I agree.  I just discovered this thread this morning by accident and then learn about this effective yet non-invasive way to incentive privacy.  We've been discussing black/white/red listing in the main discussion area and this idea has not been given its due share of attention.   

Perhaps someone with more activity points than me should post this topic in the main discussion area....

I'll link it to reddit. Perhaps the peanut gallery redditors will appreciate it :)

Edit: scratch that, it's already up: http://www.reddit.com/r/Bitcoin/comments/1qpay8/eligius_pools_response_to_coinvalidation_nonesense/

All yes.


No.


BIP32


No. More than one chain. BIP32.

I will most definitely be using this patched client with my p2pool node.


But I also agree that we should not be enforcing any absolutely transaction exclusion policy on an address basis. HD wallets are not implemented yet, I'm not sure that the standard has even been totally finalised. De-prioritisation sets the right balance until the landscape of listing develops further, we must in the meantime educate users across the whole community of users about the issues surrounding all of this.


Edit: Question to Luke Jr.

I assume this cannot affect the prioritisation of the Coinbase transaction that constitutes p2pool miner's reward payments? Can you clarify this?

Well so far only one major pool (plus maybe a few solo miners) is using it.  That is the nice thing about decentralized network.  Some parts can try out new code (outside of core protocol) at different times.   Right now 15% of hashpower is using this.   Maybe by the time BIP32 is more ubiquitous 80% of the hashpower will be using it.

As I understand it, P2Pool needs to implement BIP32 as well.

I think we all need to lobbying pools and wallets to pull their act together and implement this asap.

The coinbase tx itself?  No (it would be in the block you solve, nothing can change that).
Spending the outputs of the coinbase tx?  Yes.

p2pool could implement BIP32 or in the interim given that p2pool nodes also run bitcoind could just implement a direct getnewaddress() RPC call after any successful block to ensure future blocks use a unique address.

Yup. That is the important part.  Luke's patch can't FORCE anyone to use unique addresses however it can provide an incentive and if/when more of the hashpower implements it the incentive grows.  Without any incentive we likely will be in the exact same situation a year from now.  The current "lazy" static address use scenario is the easiest to implement.  Privacy minded miners can push for this patch which provides an incentive to make the Bitcoin network more what they want it to be.   Voting for change with hashpower.

I'm not sure which I prefer, an RPC call to generate a new random address, or supplying a keychain of addresses that are predetermined... I guess it depends on whether the keychain appears on the blockchain or is made public through the p2pool network. I can't think of a reason for the latter to happen, I don't see how other p2pool nodes need the keychain itself, they should only need the latest iteration of address from within the keychain sequence. But this all depends on how p2pool and BIP32 neccesarily operate (and how the pair of them operate together).

forrestv, LukeJr, anyone else who can shine a light: we welcome your comments

A key point, and a reminder of the sway that miners may ultimately hold over the future of bitcoin.  Miners can switch to Eligius if they support this policy, and increase its network hash percentage, or switch away if they don't.  Is this a harbinger of things to come...will we see more examples of political "policy" differences between how pools process transactions in the future?

I'm mining strictly on p2pool, so I'll be switching my own personal mining client instead. But Eligius just became my 1st preference failover pool (not that I've had any downtime so far using p2pool, but the machine my p2pool node runs on could drop dead one time when I'm not there to deal with it).

This first patch just rejects from your memorypool any transaction which:

• Sends to a scriptPubKey which is already sent to (output) by another transaction in the memorypool.
• Sends to a scriptPubKey which is already being used to redeem a coin (input) by another transaction in the memorypool.
• Sends to the same scriptPubKey in two different outputs, within the same transaction.
• Uses a scriptPubKey to redeem a coin (input) which has already been used to redeem a coin (input) by another transaction in the memorypool.

Any software which reuses addresses by default is broken.
I am okay with forcing incompetent* software developers to fix their software.

* Sorry, they should really know better.

This will not affect any generation transactions, nor any miners who choose not to use it.

A question for the OP: Are you proposing this just for addresses that are reused after a output, (where the privacy risk is highest), or also for addresses that have multiple inputs but only 0 outputs before the transaction in question?

To give an example.

In the first example a donation address is set up that receives multiple inputs. Then a spend is made that triggers an output from the address. Then after the spend the same address in used again for inputs. In the second example a donation address is set up that receives multiple inputs. Then a spend is made that triggers an output from the address. After the spend a new address is generated for subsequent donations.

The risks (which are not limited to mere privacy, I might note) are the same for both of these cases.

In any case, while I did only provide a single patch upfront, my proposal is to discuss and implement a variety of possible solutions, not any single solution, in the short-term.

i just grabbed a random block
http://blockchain.info/block-index/440384/0000000000000000a1bf1c65136cbd618e356179fec857d583e7a9373ca8386d (269989)

and looked at the transactions in it..

within the first 20 transactions there were around 10 where the destination was at that time used address.

so is Luke JR telling us that the first transaction goes into this block(269989) the next transaction has to wait for the next block(269990)

and so on for the 10 addresses i looked at(269998) that there is causing atleast 1 hour 40 minute delay for that 10th transaction.

so lets say there were 10 used addressed transactions per block, what about other transactions time stamped at (269990). they have no spaces in block(269990) through to (269998)

each of those 10 transactions have to wait even further before filling up blocks  (269999-270008) . making the 10th transaction sent at the timestamp of 269990 finally enter a block over 3 hours 20 minutes later(270008)

now imagine the transactions timestamped at the times of blocks 269991-270008.. imagine how long they have to wait. (300 transactions of used addresses waiting......)

Luke JR i guess you never watched the butterfly effect, or what happens when you throw a pebble into the water..

The point is that people need to stop this bad behaviour and start using Bitcoin correctly.

I'm not sure that the bolded part is correct. It depends on Luke's patch implementation, as well as the protocol rules.

Do multiple inputs to the same address constitute address re-use in the same way that multiple outputs from a single address do? LukeJr does indicate that this initial version of his patched client isn't the most aggressive. If inputs are being relegated, would it be possible to make this more subtle, and exclude inputs from CoinBase tx's? I'm deferring to Luke again.

then teach them how to transact properly through a youtube tutorial. instead of putting in protocol bureaucracy that will cause transaction delays..

this to me is not about teaching people the right way, but to hit people with a delay stick as many times as it takes until they get it right.

have you atleast made a massive announcement that there will be expected transaction delays if people do not transact properly, on bitcointalks main thread, or the foundations website.

no? well start tutoring people before knocking their financial kneecaps with block change protocols

i must also highlight the voting (stats taken at time stamp of this post

You're an idiot, don't do this!   - 59 (36.6%)
I don't like this, but I agree we need to move forward with it.   - 14 (8.7%)
We should have waited longer, but I guess it needs to move forward now.   - 19 (11.8%)
Great, it's about time!   - 23 (14.3%)
You're a hero, let's get this deployed everywhere ASAP!   - 35 (21.7%)
If it's from Luke, it can't be any good.   - 11 (6.8%)

which simplified down is
103 say no to implementation 64%
58 say yes implement the change to miner protocol 36%

so why luke have you decided to go against consensus and implement it with elegius?

Meanwhile, outside the bubble of authoritarian-minded mining pool operators:

https://i.imgur.com/UH6Pqp5.jpg

(via http://www.reddit.com/r/Bitcoin/comments/1qrp1h/subway_accepting_bitcoins_in_slovakia_bratislava/ )

What about donation addresses?

An address is an address.  The protocol/network cares not the purpose.  It is possible to use a dynamic address for donations.

What?

What's the risk?

It leaks cryptographic information - that's how that recent 55BTC hack occurred (in combination with the PRNG issues in Java SecureRandom lib).

Also in the event that ECDSA is degraded the pubkey being unknown (payments are to pubkeyhash) provides an added layer of security.   Commonly people assumes algorithms are either "safe" or "broken" where broken means someone can instantly find a private key from the public key.  The reality is often algorithms are merely degraded.  As an an example a flaw could be found in ECDSA such that it takes on average 2^60 operations to perform a preimage attack (normally 2^128 by brute force.  Now 2^60 is a relatively large number but a dedicated attacker with sufficient resources could attack (over the course of months) a known PubKey.  If the PubKey is unknown no attack is possible. 

Address Chains, forthcoming in the new version of Bitcoin Qt.

Is it actually being implemented or one of those things that has been sidelined?

You're an idiot, don't do this!   - 59 (36.6%)
I don't like this, but I agree we need to move forward with it.   - 14 (8.7%)
We should have waited longer, but I guess it needs to move forward now.   - 19 (11.8%)
Great, it's about time!   - 23 (14.3%)
You're a hero, let's get this deployed everywhere ASAP!   - 35 (21.7%)
If it's from Luke, it can't be any good.   - 11 (6.8%)

I read the poll more along these lines. Opposed: 43.2% In favour with varying degrees of support: 56.5% Rounding 0.3%. There is a fair degree of support for this. We must also keep in mind the following

from https://en.bitcoin.it/wiki/FAQ#Why_does_my_Bitcoin_address_keep_changing.3F (https://en.bitcoin.it/wiki/FAQ#Why_does_my_Bitcoin_address_keep_changing.3F) The original design of Bitcoin was that address reuse is to be the exception rather than the norm and what is been done here follows this intent. I get the distinct impression here that Coin Validation has fired a shot across the bow of Bitcoin and someone has just shot back.

Yes. This is a crucial difference between reuse for inputs only (for example a donation address) and reuse after an output.

I have used bitcoin the following ways with address re-use.  I thought it was a strength of bitcoin.

I.  Auction bidding.

I sold shares in my Avalon to different people.  They were careful to pay my auction address from an address that they controlled.  This auction address received many payments, often times payments from the same source.

This let me and all the people interested in bidding be confident that we were not victims of joy-bidding.  I think this was a good way to run an auction, it was transparent.

I refunded non-winning bids to their payment address.  Again, everyone was able to see that I refunded those bids.  I think this was a good use of bitcoin.


II.  Payouts of mining pool

I receive my mining proceeds into an address that is only used to receive and disburse these proceeds.  Each Tuesday I take the proceeds of this week's mining earnings and issue a bitcoin sendmany to the successful addresses.

At this time, I do not know the identity of many of my shareholders.  I only have their address.

I don't see the increased danger in making many disbursement payments to the same set of addresses instead of 1.  I also don't see how to communicate with my shareholders to ask them for new payment addresses, as I don't know their identity.

This can be accomplished with a BIP32 address chain


Worst case scenario if you stop sending regular payments I am sure they will contact you. :)
In the future you could have them generate a BIP32 public key, put that PubKey in a message and sign the message with the existing address as a cryptographically secure way to transition.

Is this supported with blockchain.info or bitcoin-qt at this time?

No however I would strongly encourage you to advocate for them to update.

the other thing to note is:

Gavin A proposes adding API callbacks into the bitcoin URI so that retailers do not have to use unique addresses per customer, but using one address and be able to track which TXID belongs to which customer by use of the API callback.

so we have Gavin A trying to reduce the need for unique addresses. and we have Luke Jr trying to increase the need for unique addresses.

can we find a room for the main dev's to go in and slug it out for a few matches as to something that can be agreed on that is best for the community..

i coloured it because for instance
saying "i dont like this" 14 (8.7%) means literally i dont like this.. in other words NO
saying "we should have waited longer" 19 (11.8%) means literally i dont want this to be done yet.. in other words NOT YET

but both questions are worded to then subtly suggest they agree to implement it. these type of questions are called trick questions.

EG if i said "do you hate termites" and you chose
1) i dont like them, but i agree we to live along side them as they are living creatures

great using that answer, you have agreed to allow me to deliver 500,000 termite larvae to your house as you seem to be ok with it.

BIP list (https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposal)

No. 32

Status is "Accepted", Peter Wuille is the author, it constantly gets talked about as if it is happening, and the (likely) first hardware wallet to market is going to be implementing it. It might actually be the first wallet to implement it period, seeing as the new version of Qt client is currently incubating, no Release Candidates as of yet.

Apparently no restriction should be done before the clients supporting convenient solutions to avoid address reusing. Otherwise you are trying to kill BTC rather than helping. Please spend more efforts on clients instead of mining softwares. No project will succeed in going to mainstream try to piss off users just for pleasing some genious developers who think they have better vision of the future.

BTC now is no longer the toy of developers as the early days. You are dealing with billions of people's money now. Remember even your decision is correct in the long term, it's side effect will do great harm if not being careful enough. Now it's too dangerous to do something like: just do it and let's see what will happen.

Could you provide a link, please.

This patch isn't designed to restrict, it is designed to discourage.

Thin wallets like Electrum and blockchain.info retrieve UTXOs from server, and cost for server is roughly proportional to number of addresses used, so address re-use improves efficiency. Are you against that?

 So let me get this right: A mining pool operator implemented a change that, with (wider) acceptance, would delay payments to his own miners? Should his miners change their payout addresses every single mined block?

BIP_32 is not in effect, so that argument is currently moot.

Are you saying that address reuse makes the UTXO set smaller?

This isn't correct.
If a mining pool paid people more than once per block, there's something more subtle wrong...

They should use Bitcoin recurring invoices (BIP32), not addresses.

Bitcoin is still beta and incomplete.

I think he's saying that these clients are missing bloom filter support, which has been standard for a while.

I've argued with Luke before on this obsession of his, your never going to go mainstream with something that dose not give people DURABLE identities.  Disposable identities are never going to fly in mainstream commerce where law enforcement must be conducted.  Also you have the grandmother factor at work here, a users needs a durable identity to give to other people and they can barely handle the technical hurdles of BTC as it is now.  This kind of secrecy and techno-elitist obsession will always fail.

No. They ask server about each address they use. If client uses N addresses, there are N queries against server's database.

Bitcoin does not provide identities of any sort.
If you need identities, use PGP.

Payment protocol should make things easier.

Address isn't supposed to be an identity. It is more like an invoice number.  Invoice numbers are not supposed to be durable, are they?

Maybe you can use grandma as a hostage against privacy preservation today, but there are projects in the works to make anonymous commerce just as safe (or safer) as non-anonymous commerce, in a grandmother-friendly way.

After that's done, law enforcement can shove their desire to spy on everyone and everything up their ass.

Can a miner use a BIP32 recurring invoice as an Eligius login right now?

If not, perhaps your patch rollout timing was ill-informed.

Are you sure Bloom filter is the right solution? It creates more load on Bitcoin nodes than UTXOs-for-address queries would.

I have no flipping idea what anyone is talking about. Am I going to need to create new address everytime I get paid from my pool? Because that would be plain stupid. Please correct me in simple English because this is how I'm seeing it.

I recently lost all my coins because I created a new receiving address and didn't back it up. Wouldn't this create more similar problems?

I may be barking up the wrong tree here... but what gives? Bitcoin is fine the way it is.

Link please.  Nothing I have read about the payment protocol implies static addresses.

Bitcoin is never anonymous, no matter how you use it.

Law enforcement can do forensics the same way they do with cash (actually, they can do better with Bitcoin).
This only buys you privacy - without it, everyone would be able to see everything you do.

"Lookup by address" is only less load than "lookup by bloom filter" if every node carries an address index (which adds to disk and memory requirements).
In any case, Bitcoin was designed with addresses being single-use, and it becomes unusable with too much reuse, so this side-topic is irrelevant.

Not yet, relax for the moment. None of this will matter for a while yet, till then, get clued up. I've explained it all below.


Nope, instead it solves them.

There's a new wallet feature, Armory has used this idea since very early on. The idea is to have the addresses worked out in advance, but not just in a list. Instead, and you should be able to guess this, you use cryptography to define the list. You get the ability to create Master Addresses, and each Master Address basically gives you an infinite list of addresses for receiving funds at your wallet. You create yourself a Master Address for mining with, and give that to the pool. Then you only have to BACK UP ONCE. It's pretty neat, I've used Armory's version of this already. Create as many Master Keys as you like, just like normal addresses. So that whoever you give a Master Address can't see your whole wallet and every address in it, they can only see the ones you gave it to them for in the first place.


Problem is the idea for colour lists that track our coins. It comes down to the old theory of money stuff. Someone can look at one of these tracking lists, look at my BTC address, then look at your BTC address, and decide they'd prefer your coins to mine. Because mine are on a list that says they were ransomed from a grandma. This makes Bitcoin less money-like, and if yours or my government want to kill Bitcoin, they can start by creating laws that say "everyone must use addresses that are on the list, otherwise they can't pay". It doesn't have to be in the BItcoin software, it can just be a list you can search on some website. If you get given listed coins, you say to the person paying you "Sorry, can't give you what you paid for, because you paid with dirty money. I can't spend this, because it's on the list. If you still want [whatever it is], you can pay with clean, listed BTC. I'm sending the dirty money to the dirty money collection & cleaning guys". Big problem. People don't want to use a system like that, BTC price goes down. People stop using it. Bye bye Bitcoin.

The lists are no good if we take steps. This is one out of many steps. If we concentrate on getting these things in place, and make them understood by everyone, the lists won't work. Hello Bitcoin.

To quote the termite example. It is more like I am not ok with allowing you to deliver 500,000 termite larvae to my house; however if you do I will not call the exterminator even though the termites will demolish the house. The trouble with saying "no but" is that more often than not it means "yes".

It's not just discourage as you think, it's forbidding in some scenario. If a merchant use a fix address to receive payment , it can only receive 6 payments per hour. Basically makes the service useless. It's customers have to wait forever if there're more than 6 payments per hour.

Eligius are only testing this out. It's only one pool. It's not absolute, just preferential. Mining Dynamics 101. Find. Read. Learn. Understand. Shush.

No...

Options 2 and 3 are more like "I don't really want to pay for a security system, but if people are going to start burgling my house, I want one."

FWIW, I personally am in the "We should have waited longer, but I guess it needs to move forward now." boat.

Which is why I do not like options 2 and 3. Why? Because there may not be enough time to install the security system before the house is burgled. Option 4 is more to my liking by the way. One thing to note is that the proposed payment protocol will address the many of arguments against what is being proposed here.

But isn't that the exact point? That it would start to be a hindrance to merchants so they'd stop reusing addresses?

What merchant uses a static address for all customers?   Horribly insecure and prone to problems.  Anyone that foolish should just use a service like bitpay and have it done right by someone competent.

Yup.

Just thought of something... how does the BIP32 protocol addendum limit the usable address space based on whatever seed is generating the string of future keys? Reading the wiki pages now, will edit this post if i find an answer. I understand this might be nonsensical.

What do you mean limit the usable address space?  There is no change in the number of possible addresses.

See, e.g., the Subway shop in Bratislava, Slovakia mentioned above, and at http://www.reddit.com/r/Bitcoin/comments/1qrp1h/subway_accepting_bitcoins_in_slovakia_bratislava/ and also the discussion above around non-profits and other entities wishing to conduct transparent finance on the blockchain.

For some reason I was thinking that using a seed->prng, and sequential nonce would end up with a subset of the 2^160 (#?) key pairs.

If the entire world economy used a new key pair for every digital transaction (the rate of which is increasing exponentially) for the next 50 years... where would we end up in terms of collision probability? I dunno, i think i'm way off topic here. We can let this sidebar fall away now...

Just about every in person retail merchant I've ever seen.

Quote from such a merchant "I like taking payments directly versus using a third-party processor like BitPay or Coinbase because it is more in the spirit of bitcoin. Why fill out an application and give up all your personal info when you don't have to? Bitcoin is your money." Is bitcoin our money or is it the miners money?

What makes it "horribly insecure" other than having the transactions visible?

Quote from: AtlasONo

: What makes it "horribly insecure" ?

A permanent  list of addresses and times is created for that physical location.

Imagine a customer is careless and visits daily , using a address with other large transactions. That high value wallet can be ambushed.

This is a very good explaination, I understand much more about the issue now.  Everyone that wants to express their opinion about this debate should read this kind of writing before writing about the subject.

Thanks gmaxwell !

As I said, you cannot do some changes to a billion dollar related project just because you think it's correct. The side effect may kill a project before you see any positive effect. That's why backward compatibility is so important in software industry.

No, and that's the point. Unless some pressure is exerted, adoption of BIP0032 will always be on the back burner. This is an example of how miners can exert pressure on the entire ecosystem.

And thus create incentive for wallet operators to implement BIP32 now. In doing so they will also attract more users to their brand of wallet since they will be the frist to adopt. This doesnt harm bitcoin in the slightest.

On the contrary, now I think the over centralized miners become the biggest danger of BTC. Just two or three big pools can ruin the who ecosystem with just one bold action.

With current difficulty, there's almost no chance for a new pool to survive and hence no democracy at all in BTC now. We are now all controlled by the operators of BTCGuild and other couple of pools.

Utter nonsense.   This isn't a change to the core protocol.  All miners have ALWAYS had the ability to prioritize tx as they see fit.  Currently ~15% on the network is implementing this so the effect on multi-use addresses is minimal at best.

Bitcoin was DESIGNED for this type of decentralized tx processing.   There is a reason tx selection is loosely coupled.  There is a reason that miners are free to include any valid tx in a block.  There is a reason that other miners can't override or veto that decision.

Once BTCGuild joins, it's done. BTC now is not decentralized at all.

As a simple example, yesterday I suggested to create a pool to save master coin, which will be killed immediately with Luke's patch. Then we realized we need 500TH and double it every month to mine a block each hour. even we can get several TH to start it, no miner will join us since it may takes weeks to find a block.

Now you can clearly see the danger of centralized mining.

Disclaimer I hold 0 share of mastercoin.

The moment a business realises someone can look up their address and see their takings... they will want to use unique-addresses at checkout afterall...

Miners vote with their hashing power.  If miners agree then it is no different than a million solo miners implementing it directly.  If miners disagree then they can move to another pool more inline with their views.  Miners have always had the power to choose the tx they want to include in a block.  The availability of the patch merely gives miners an effective tool to implement this type of prioritization. The patch isn't doing anything the protocol doesn't already allow.

Still this is still a relatively soft change.  Even for affected tx having 50% of hashing power implementing the patch doesn't kill those tx.  Affected tx will simply take twice as long for first confirmation and the following 5 will be at the same rate.  Essentially a 6 confirm goes from 60 minutes to 70 minutes.  If you honestly believe that will "kill" Bitcoin then honestly Bitcoin never had a chance of surviving and was a pretty crappy experiment to begin with.

Bitcoin will survive just fine.   

Miners will not join a new pool which find a block every one week. To create a new pool you have to spend huge amount of fund beforehand. It is not so different as 'everyone can be a president candidate in US'.

You are talking about just one transaction. As long as some addresses have more than  a couple of transactions every 10 minutes, the waiting time goes to infinity.

Who said anything about a "new pool"  If BTC Guild supports this patch (which they don't yet) and miners disaprove they can simply go to the #2 pool which doesn't support the patch.  Still 50% of miners supporting the patch still doesn't have a catastrophic effect on multi-use addresses.   1st confirm time doubles to 20 minutes.  6 confirm time goes from 60 minutes to 70 minutes.

Why miners care so much to leave the pool they are used to? They are not the ones suffering from this patch. I am saying those who disagrees has no chance to create a new pool to protect themselves.

Miners aren't Bitcoin users?  Not a single miner will be affected by this patch in any way shape or form?  Not a single miner will be convinced by your FUD and doom and gloom and switch in order to save Bitcoin from Luke-Jr?

Is your worlds so black and white that miners are a group outside of the group of users?

We went through the same kind fud with P2SH, we went through the same kind of fud with dust threshold.  Bitcoin survives.  The protocol is robust, clients and service providers will make improvements.  If they don't they lose marketshare to those who do.   

Please calm down and think about it more. A small part of miners may care about this patch does not change the fact that now everyone's fate are in the hands of a few operators of big pools.

Some day you may disagree some actions they will take. But you can do nothing, just like me now.

No everyone's fate is in the hands of miners.   However it HAS ALWAYS BEEN in the hands of miners (since the genesis block).  Don't like that concept?  Then become a miner. 

So you don't support using new addresses, but think everyone else who doesn't support it should be punished?
Isn't that a bit hypocritical?

I think this move should have waited a few more months at least, but we're out of time it seems.
In other words, I would vote "We should have waited longer, but I guess it needs to move forward now."

I don't think it would even make a dent. The number is (I believe) 2^160 possible addresses. That's just gigantic beyond my reckoning. Maybe if every person on earth did like a trillion transactions a day for god knows how many years you'd get there.

FWIW, Luke-Jr - I think you've done a good thing here and I am glad you can take the heat. The science and the maths all add up here.

Not in the hands of miners, but in the hands of the operators of big mining pools. That's a big difference. A small miner is as powerless as non-miner.

I'm looking at total amount of computational work which needs to be done. Suppose we have 1 million thin clients which launch recover from seed. We need to scan the whole blockchain 1 million times.

On the other hand, suppose one client need to look up M addresses on average.

We can compare this two cases if we assume that one address lookup is computationally equivalent to scanning K bytes. If blockchain is N bytes long, lookups are M*K/N less expensive.

For example, if M = 1000 (addresses per client, on average), K=100 (100 bytes scanned per address), N=10^10 (blockchain is 10 GB large), it turns out that lookups are 10000 times less expensive.

This means, for example, that the work which requires 10000 Bitcoin nodes can be done by just one server.

This is true even if there is no address reuse (1000 addresses per client).

Please do the math before coming to conclusions. It looks like Bloom filter doesn't scale, so you should recommend it as a solution.


Are you talking about ECDSA vulnerability? How much is too much?

Can't we allow limited reuse?

Take for example way back when when deepbit Was nearing 50% for weeks everyone was told don't mine there! switch pools! For weeks they remained a threat and were eventually hit with a DDoS attack to force people away. If miners couldn't be bothered to stop a 50% attack what makes anyone think they would care about smaller matters?

Additionally with the surge of ASICs mining power has become further centralized, no longer is control in the hands of anyone with a gaming GPU. 

Just do it. And keep it coming.

If you create a pool with a clear mission, miners will join it no matter if you have less than one block per week. Spread enough fud about the big pools and yours will grow. Even though I don't agree on that subject, more pools and more solo miners that care about these behind the scenes politics are a good thing.

Mining reminds me a lot of liquid democracy. This is great :)

+1 

There are many benefits to public addresses and address reuse.  In banking it would NOT BE SAFE to give out your bank account numbers, but with Bitcoin since the transactions are one way, it is not as problematic.  The whole idea is Bitcoin gives the user CHOICE.  Why would we start to take that benefit away from users as a reaction to something that probably will not happen?

Can't tell if trolling or stupid.... at least try to stick to one mumbling complaint at a time


Your complaint was true yesterday, the day before, the previous week, the previous month, and the entire history of pooled mining. Give yourself a round of applause for finally working out that pools represent multiple miners working for a single node. BITCIONS IS DIEEEING

Just a note, but.... 

All those in favor of "open transactions" and "transparency" can achieve it in the post BIP32 world by making their master addresses public. 

IOW, if a charity wants everybody to be able to see all the payments it's recieved and made on a particular issue, wants anybody to be able to donate on a particular issue, etc, they just publish the master address that all those bitcoin addresses are to be derived from, the same way they'd publish the bitcoin address itself now.  You can use the master address to identify payment addresses derived from it. In the "normal" case the master address is a secret between the payer and the payee, but if it's not secret, it doesn't create secrecy.

And if a sandwich shop in bratislavia wants to put a public QR code for making sandwich payments on the menu, it just needs to put the QR code of a master address on the menu; customers can scan it, create a payment address, and pay for their sandwiches.  Now, those customers could also see how much money other customers are spending to that master address so they could tell how much sales in bitcoin are being made at the shop, but if the shop doesn't mind, then they don't mind.   

It isn't a problem as long as the software isn't so braindead that everyone with the same "master" address creates the same payment address.  Right? 

Another note, to those who've been claiming that the current patch creates infinite delays in payment processing on addresses that take more than one payment per ten minutes;

With 100% adoption of this patch that would be true, but nobody is now looking at 100% deployment even as a remote possibility.

With 90% adoption of this patch, you'd get one transaction per block on 9/10 of blocks, and then all the transactions that had been delayed, all going through at once, on 10% of the blocks.  So, if for silly reasons you're taking one payment per ten seconds on a given bitcoin address, your expected time to first confirmation for a given transaction would be slightly less than 90 minutes instead of 10 minutes, but without 100% adoption, would not be spiraling to infinity.

Even if every pool adopted this patch you'd still get all your transactions through any time a solo miner who had not adopted the patch solved a single block.

If I'd been writing the patch I'd have hit it in transaction fees instead of delay;  ie, I'd have written a bitcoind/bitcoin-qt patch that made repeat-using a bitcoin address be a nonstandard transaction unless accompanied by an additional transaction fee.  But that would be a much less 'measured and predictable' effect than the patch we're looking at now; it would be more likely to cause chaotic unpredictable failure of such tx that depend on things far more random than this one.  This is more elegant and gentle than what I'd have written, because it is more subtle.

I think this is what gmaxwell was suggesting: https://bitcointalk.org/index.php?topic=334316.msg3588058#msg3588058

I think we should look at Luke-Jr's patch as just that: a patch.  It is doing the important job of getting the discussion going, but I expect something more along the lines of what gmaxwell proposed (scaling tx priority) is a better long-term solution.  

I don't think anyone wants to "ban" address re-use or make things like Mastercoin unusable.  We just want a reasonable and effective way to incentivize *not* re-using addresses.  If you want to re-use your address then you should be able to: I personally think it should just cost you more in fees to get your TX priority up to what it would have been had you not re-used addresses, but perhaps I am missing something.  

Here's what I want: when a new bitcoin user picks a wallet and begins to use it, the wallet should *by default* not re-use addresses and the user should be none the wiser.  Let's put the right incentives in place to make this happen.  

Even this isn't right, but you're along the right lines. With this type of patch, confirmation time "spiralling to infinite" doesn't happen for re-used addresses. All this is doing is putting transactions using un-used addresses to the front of the queue. If un-used addresses make up the whole block, then no re-used addresses will make it into that block. But if the block has space in it before it hits 1Mb limit, the re-used addresses will still have their transactions processed.

If Luke had made a patch that stopped re-used addresses in transactions from ever being processed by the software, never to be included in the block under any circumstances, I would not support it. Good thing that this is not what he's come up with.

I will go reread the patch; If you're right, then I misunderstood it.

I thought its effect was that a block could hold only one transaction per address.  If an address were reused then additional uses would have to be in separate blocks rather than the same block. And I'd consider that to be a 'reasonable' restriction given less than 90% adoption. (so that *all* reuses could clear occasionally, just after a somewhat unpredictable delay...  )

If you're right, then its effect is much much milder than that.   If it only rejects reuses of addresses until it has as many non-reused addresses as it can find, and then fills them in on a space-available basis, then it's actually nothing but a prioritization mechanism;  Since block space is rarely an issue, this has almost no effect at all on reused addresses; the effect of prioritizing tx with only non-reused addresses, even with 100% adoption is a very small change in the reliability and timeliness of transactions, hardly noticeable in the larger scheme, and has as many winners (people getting tx confirmed earlier) as losers (people having to wait an extra block time for a confirmation).

In that case, this is probably the mildest incentive I can imagine going up and I'm amazed that anyone is having a problem with it.  It's not so much the effect that people are debating here as the intent, I guess.  It shows an *intent* to deprecate reuse of addresses that people want to discuss.  But it doesn't present any noticeable obstacle to it; reusing addresses will see either zero or one additional block-time before confirmation.  And more likely zero than one.  Meanwhile, non-reuse will become slightly more reliable and timely, making the average wait exactly the same. 

This also means the miners aren't in the position of foregoing any tx fees.  If they can still fill up their blocks, they can still collect a whole block's worth of fees.  So there's no disincentive for the miners to deploy the patch, as I was afraid there might be given my earlier understanding of it.

So, yes, this is a very subtle effect.  I'd have even guessed possibly too subtle to be effective, except that people do seem to be paying attention to it here.

Well, it's actually a little ambiguous to me now that I scrutinize it closely. Luke refers to it as re-use de-prioritisation, and that is an appropriate description of what you understand the patch to be. It would introduce perhaps significant latency to getting a block solution propagated on the network if a mining client were to search the list of re-used addresses for matches in the current transaction pool. Perhaps Luke can enlighten us.

Why would block propogation be slowed?  The patch modifies how tx are "ordered" for inclusion into a block. Once a block solution has been found the block is simply broadcast.  Nodes just validate and relay like they would any other block.

Do you mean it may introduce a delay in the creation of the tx set (which is used to construct merkle tree, which is used for merkle root, which is part of block header) BEFORE workers attempt to find a solution for the block?  I can't see it being more than a minimal additional processing and pools already use "tricks" to rapidly generate work for all workers after a block change.

That is what I mean, yes. I wasn't aware that the transaction set is developed before the solution is attempted, that is an interesting and crucial fact when considering the applying of novel tx prioritising logic. It then appears there would be only a small additional system memory cost to maintaining a list of re-used addresses for demotion in priority for block inclusion.

Admittedly, the deprioritisation could be done much better.
The problem is, the code that creates the blocks is a total mess, and rewriting it is a sensitive area that would be a real pain to get merged, even with no behavioural changes.
So, it's easier for a miner to see that this patch won't make invalid blocks, than it would be if I started touching that code.

Wouldnt doing this provide further economic justification for selfish mining,  as the researchers call it, because people whose tx are deprioritized will have further economic incentive to alter the blockchain?

I think you guys should really think things through a few steps ahead, the 2nd and 3rd order effects. Even if it was the original intention to not reuse addys, it was never enforced, and changing the rules now, changes the dynamics of the system possibly in unpredictable ways.

The rules aren't being changed.  The rules are encoded in the protocol.  Changing them requires a hard fork.  The rules have ALWAYS allowed miners to choose which tx to include in a block (including none) and under what criteria they will be ranked/sorted/selected.

The patch simply gives miners an effective way to use the power they are already granted by the "rules" of the game.

Minor correction: changing the rules in this case only requires a softfork.

Okay the dynamics are being changed.  Whatever.......

I worked with guys who were running the first virtual economies in the late 80s and one of the big lessons they learned was when you start tweaking the dynamics shit happens that you never expected. 

You have been warned...  think it through...

Another more fun option imho is to encourage altruistic behavior by criminals to use stolen btc to send dust to all known active addresses and then all those wallets become dirty.  Not sure anyone would actually do that but it would be fun.

You would need to turn off the dust rule and tx fee temporarily for that. Sort of like a jubilee.

It wouldn't work the way you think it does.

Sending someone a dust output in no way interferes with any future spending they might choose to do. That's like saying that if somebody throws a penny at you and it lands in your pocket all of a sudden you'll have problem spending your $100 bill.

Good analogy however if user is unaware they have received this "bad" input it is possible they will create a tx and combine it with a larger "good" input.  Note: good & bad is simply in reflection of CoinValidator's asinine system IMHO coins are simply coins.

On a related note, that's what I tried to express here: http://bitcoinism.blogspot.com/2013/11/eli5-bitcoin.html

What exactly is this? I newish, sorry.

It's not as true when the difficulty was not as high as now and increased as quickly as now. In the early days, it was much easier to create a new pool and get enough miners to join to survive. Now may I ask a simple question to you? How many hash rate do you have to get before anyone will be interested in joining the new pool you created? This situation becomes worse and worse every time the difficulty increases.

Why should I troll when my benefit lies on the appreciation of the BTC? I am just worrying. One of the main reasons why people love BTC is  that they think BTC is democratic and nobody can damage it since it is protected by millions of users. Call me stupid if you want cause I feel quite unconformable now when I realized just 3 to 5 persons (the operators of BTCGuild, GHash, Eligius, BitMinter, and Slush) can effectively damage the who ecosystem.

Yes, this time this patch may be not so harmful and you happen to side with the OP. But eventually you may disagree on other more serious issues. Considering it more before calling others FUD or stupid. Problems have to be warned by some FUDers before they can be fixed, because the Lovers are often too blind to find them.

Finally maybe off topic, a proposal to OP, as I believe he really cares about the future of BTC. Could you please also considering a patch that restricts the market share of one pool. I think that is at least as important as your current patch. Maybe we could open a new topic on that?

EDIT: create a new topic here: https://bitcointalk.org/index.php?topic=337260.msg3618577#msg3618577

Do the wallets support this (when will they)?

Of course coins are coins, but when the men in black show up at your door and start asking you about tx between you and other addresses as they try to id people, then you shall realize why not all coins are equal :p

That is why the real solution to fungibility is making all coins dirty.  They do not have time to question millions of people.

That is how assymetric warfare works boys :p

Use mix service for that purpose. Rely on everyone changing address every time is always risky and will only give you false sense of safety.

If you want to lead from the front, wouldn't a better approach be to develop the website frontend for supporting multiple addresses, and offer that up to other sites to reuse, at the same time as putting in the 'de-prioritisation'? At the moment you've introduced a problem, but not the solution.

From what I can tell the code needed to do this is available.  See here:

https://bitcointalk.org/index.php?topic=334316.msg3598018#msg3598018

If you mean this mining patch, they support this already, even though the client running the patch is different to the standard wallets available today (so this is not even a soft fork, to put it another way)

If you're talking about the key-chains/BIP32, I think the plan is to include that feature in the forthcoming 0.9 Qt/bitcoind client.

This patch only seems to affect donations and webmerchants that re-use addresses right now, and the former could route around it right now by adding a bit of Bitcoin RPC code into their webshop coding. I don't think the days of using this method are over, and it's actually a better method for privacy. Anyone with a copy of a BIP32 keychain can see how much money has been paid to that keychain (but you can create as many keychains as you like, just like with regular public keys now). So if you've got a an always-on server on the web, and are using a webpage (i.e. that you run or have permission to insert the appropriate code into) to request bitcoin for whatever reason, you can use the tried and trusted (and private on a per-payee basis) way to take payments or donations.

i have a number of addresses but i have it organised so that each address is a ledger for a particular project

i do not want to have to set up a new address with a regular customer everytime they pay me.
EG. BTC-E or BITSTAMP customers do not want to forced into keep looking for a new deposit address everytime they want to deposit into their account. they prefer the option to refresh address or continue using original address linked to their username.

i do not then want to have balances split over hundreds of addresses which would add KBytes of data to the next tx i send, meaning higher fee's for pool owners to take .. hmmm i might have hit a spot here where a pool owner would love this as a selfish reason to make them more money at the expense of user convenience.

i do not want delays when topping up my cold store address (paper wallet)


i do not want to wait 10 hours because in the last 30 seconds only 60 people out of millions are also re-using addresses
i do not want to wait 3 hours because in the last 30 seconds only 18 people out of millions are also re-using addresses

i want to wait just 10 minutes because millions of people are able to do with their own funds the way they want.

Please learn how Bitcoin works.  The number of addresses used as inputs in a tx is irrelevant to the tx size.   Each INPUT (same address or different) uses ~150 bytes.  10 inputs from the same address = ~1.5KB.  10 inputs from 10 addresses = ~1.5KB.


Ok you don't want it.  Then mine blocks and don't apply the patch.  Problem solved.   You didn't ever think you were able to force miners to include your tx in a block did you?  The patch doesn't give miners some brand new novel power/authority.


And miners are free to prioritize transactions how they see fit.  Isn't freedom great.

here he goes meandering the subject offtopic.
learn "sweeping"

instead of me just receiving 100 TX's where customers pay no fee individually. i have to make a transaction that groups all of those together to bring them into an address i want. EG a project address, or a cold store paper wallet public key.

and im not going to send each transaction individually to avoid fee's especially knowing the second TX will have to wait for the next block and the 3rd will wait for the block after that. and so on for 100 blocks thanks to luke JR protocol causing a 16 hour delay atleast.

and if you look on the main bitcointalk thread you will see many people complain about lengthy delays just to get their coin accepted into a block.

this is much like banks.. ruining a good financial system for personal gain. the financial system protocol should not be used to cause miners to gain more profit or be in favour of them. it should be a unbiased system.

a comparitive would be banks only wanting to deal with people with 20 credit cards and willing to accept high interest on those cards.

security of the network and making peoples financial freedoms easier to manage should be top priority. not mining pool owners 'cut' of the pie bigger by forcing people to transact differently or pay the consequence

There is no "personal gain".  A tx with 10 inputs from the same address is no larger or smaller than a tx with 10 inputs from 10 unique addresses.  So please (I honestly mean it) spend some time learning about how Bitcoin works before you start throwing around FUD.

Miners have ALWAYS had the power to prioritize tx as they see fit.  Always, back to the genesis block.  If you are realizing this for the first time well that is kinda sad.  If Luke never published the patch his pool would still be able to internally prioritize tx as they see fit.  Why are you so afraid of freedom?

You can do this in one transaction, one block, one fee.

Why are you (those proposing this) so afraid of my freedom to reuse an address?

They aren't. You are free to continue to reuse addresses.   Freedom of choice means a CHOICE.   It doesn't mean other people have to support your choice if they disagree with it.   Nobody is forcing you to change how you operate.  Miners have always had the right to prioritize tx.  After every block SOME tx are not included.  The patch simply changes which tx have priority, nothing more.

People wanting anonymity can reuse addresses. No need to force anything down people's throats.

The clear purpose of this is to dissuade people from reusing addresses, you wouldn't disagree with that?
While I still have the option, you are making it a poorer option than it was before, for political reasons.

That is called freedom.  Freedom doesn't mean people always doing what you WANT them to do, thats easy. In fact it often means people doing something you disagree with, freedom of speech means someone having the freedom to say things you might find hurtful or offensive.

Yes freedom can be scary.  Freedom can mean you are inconvenienced.  Freedom can make you question if your choice is worth it.

So once again why are you so afraid of freedom?

Also "I" am not doing anything. At the time of the writing I am not mining (although may in the future) and I didn't right the patch.  I just happen to agree with it.

It stinks of social engineering. If not reusing addresses is the only way bitcoin will survive there will be no need to pressure people into doing that.

That is short sighted thinking:
https://en.wikipedia.org/wiki/Cost_externalizing

Umm. Who is externalizing what cost by leaving things alone.


So forcing busy charities/businesses to have sophisticated systems to accept payment as opposed to a QR code printed on paper is healthy how? I really don't follow your line of thinking.

And I could turn every single one of those questions back at those favouring this patch.
The difference is that you are actively trying to stop me doing the things that you don't want me to do, that might inconvenience you. I'm not trying to stop you reusing addresses whenever you want. So which of us is trying to restrict freedom again?

Miners have ALWAYS had the freedom to pick which txs they want to include in blocks.  If you feel miners shouldn't have that freedom then you probably should have done more research before getting involved in Bitcoin.

Tx selection will only grow more complex in the future.  Some miners may simply sign deals with large merchants to provide a quality of service for their tx.  VIP clients will have all tx to their addresses jump to the front of the line.    I think that type of arrangement is only a matter of time.   

Miners have the freedom to choose tx selection.   Miners aren't obligated to give your tx priority.  That has been the "rules of the game" since the genesis block.  If you have done so little research that this didn't occur to you, well I would recommend some critical thinking.

Well the solution to this problem for now is clearly for the 50% of us who aren't blinded by ideology to keep our hashing power as far away from Eligius as possible. Don't get me wrong, I'm convinced not reusing addresses is the way to go, I just don't need Luke-Jr trying to force the extra cost on everyone.

What does 50% have to do with anything?   This isn't a hard fork or change in core protocol, it doesn't need your or anyone's approval.  Each INDIVIDUAL miner (or indirectly through the pool they choose) have the freedom to prioritize tx as they see fit.  They always have and they always will.  That isn't going to change with or without 50% support.

However I agree as a miner you should select a pool who's views are aligned with your own.  Either you construct your own header and are in direct control of transaction selection, or you "vote" with your hashing power however this patch can be used by anyone at anytime and requires no consensus.

50% has to do with the current poll result... The sum of the 'this is unequivocally a bad idea' responses.

I know that, I'm not sure why you feel the need to be condescending in every reply.
Does that also mean that people shouldn't debate the rules that miners use, for example in an attempt to persuade or dissuade other miners from adopting the same policies? Isn't that what this thread is for?

Also, as much as black addresses are entirely unworkable, green addresses do actually provide a nice benefit.

Anyone who insists on being paid from a "green" address can start digging around the blockchain to try to find out how much BTC you're holding. Not such a benefit.

There's a blockchain based solution to providing a credible ID when making purchases in the works, designed by the Bitcoin main dev team. It's a far superior scheme to this green addresses nonsense.

I pay you, the money comes from the known mtgox green address and is deducted from my balance. How much bitcoin do I have? It's not how much bitcoin mtgox has.

You know that mtgox won't double-spend so you can immediately trust the payment. That's a green address.

I understand the argument you make here and agree with it. I also understand you have good intentions trying to force developers to respond. I disagree with removing choice from the user. Not every user desires or requires privacy. If it's a government address such as the FBI or a non-profit then they'll be able to have privacy too. In the case of the FBI they might want that privacy, in the case of the non-profit they likely don't want it, and people want and expect complete transparency from a non-profit.

So certain addresses in my opinion should be persistent addresses. If you want to discourage the use of persistent addresses then attach a fee to miners to allow specific addresses to be persistent if that fee is paid.

Appears to be an unnecessary knee-jerk reaction for something that is not a genuine problem.

Luke, I know we don't see eye-to-eye on things, but respectfully, I don't see any benefit to this proposal.

EDIT: BurtW, and so you did, post #12. Guess that's why the term was on muh brain. Cheers.

I thought exactly the same thing when I first heard about it, in fact I also called it a "knee jerk reaction", but after carefully reading the posts, especially those from gmaxwell, I have come to the conclusion in my signature.  If coins of different ancestry become different in value then Bitcoin is reduced from "money" to "collectible" just like coins of different grades have different values in the marketplace.

I, for one, would like Bitcion to develop as money, not collectibles.

Not those green addresses. We have a new definition, courtesy of our new friends at the CoinValidation organisation, and it involves linking real world identities to Bitcoin users and put in a public database. The idea is to create regulatory legislation (in the US) that demands for businesses to only accept money from ID validated green addresses.

I'd say about the same thing, except I'd conclude by replacing "benefit" with "harm."  

This isn't going to cause any harm to anyone, and it might cause some benefit.

For all the heat generated, where's the innocent victim its opponents can point at and cry "this person was harmed!"  There is no such person.

It may or may not be a good idea.  

However, what Luke has done seems to be the least intrusive measure possible to find out.  Whether or not he has strong opinions against what he is trying to discourage, what he has actually done is to discourage it. . .slightly.  By expressing mild disapproval of it.  And suggesting that he might express slightly less mild disapproval of it in the future.  In other words, a future intention to deprecate. . .maybe!

I can live with this.

ETA:  Also that poll sucks.  Sorry.  Really, it needs an answer that amounts to "let's collect some data and see how it works."  Because that's what I would have clicked, and it seems to be what you're actually doing.  Good idea!  But there should have been a way to approve of that.

But this change does break those green addresses. Interesting attempt to deflect the issue though. And those green addresses not maintained by a central authority allow people to not have to wait anywhere from 2-60 minutes for confirmations.

If there's something better in the pipeline, that's fine but it really does break behaviors people are relying on.

It affects anyone who wants to use a single address - if they do, then the transactions to that address will be slowed down by it.

i.e. it slows down committing for anyone that use a single address for payment, if they receive more than one payment per block - yes that includes Satoshi Dice - but any site that uses that design.

Now, what is gained by it?
Enforced privacy coz people MUST have it?

Yet when you commit a payment with an amount greater than any incoming transaction you use to pay out, you immediately invalidate this argument. Completely.

I really don't understand why people must be FORCED to use this - i.e. get pools to enforce this rule.

Can someone answer why it MUST be done - and why the current system CAN'T be allowed to continue.

Why can't people have choice?

You CAN implement the option of accepting payments to choose to use a new address every time - so people who want that can have it.

But why are people trying to FORCE this as mandatory?

Seems like: "We know better, we will tell you what you should do and we want to force you to do it"
Sounds very religious to me ...

You're an idiot, don't do this!   - 109 (43.6%)

My thoughts, exactly. I've been trying to find real arguments for doing it now in this thread, but it looks like it is all FUD.

For what it is worth, I was totally against this proposal as well.  This is one of the posts that convinced me this (fungibility) is  a critical issue:

https://bitcointalk.org/index.php?topic=334316.msg3588908#msg3588908

Now I consider the proposal just a "baby step" in the right direction.  We actually need to implement BIP32 system wide and come up with even more ideas to make it as hard as possible to implement those ideas that are floating around that will destroy the fungible property of Bitcoin.

The battle over the fungibility of Bitcoin is the battle for Bitcoin itself.  If fungibility is destroyed then Bitcoin will eventually become just a footnote in history.

As I have said, if you remove the fungible nature of Bitcoin - as is being proposed - then Bitcoin becomes a collectible and is no longer money.

If you have any other/better ideas to help preserve fungibility then we need to hear them now! Please!

How is ZeroCoin doing? I read they are going to start an alt coin and have the transaction size down to very reasonable 500B but they didn't answer my question if cpu use made similar progress.

what's so bad about address reuse anyway?

It is not about address reuse.  The issue is fungibility.

There are many posts above that explain the issue.  Just read them.

Try this one:

https://bitcointalk.org/index.php?topic=334316.msg3588908#msg3588908

Then this one:

https://bitcointalk.org/index.php?topic=334316.msg3589252#msg3589252

and the one after it for starters.

This entire thread is a gold mine for the issue at hand with good posts on all sides of the issue.

But they aren't forced to use this.  Without nearly universal adoption by pools, it appears to be more a mild suggestion than a use of force.

No-one said "lets force everyone to accept this new culture against address re-use"

What happens when your friendly neighbourhood tax barons decide they must FORCE you to use ID VERIFIED PUBLIC KEYS. Then what, Mr. Anti-Coercion?

FUD

Interesting, you clearly misunderstand the point of the thread and then it seems that you are arguing that if govt powers FORCE people to do things then we as bitcoiners should do that also?

The FUD at the start of the first post ... since you seem to have not read it:

Or would you care to explain exactly what your argument there is?

Certainly makes no sense as it is.

indubitably

So , do you know where this is going to lead?
Pools forcing people to  "x" because government is planning "y".
You open the door to pools abuse combined with government abuse , both having some stupid "reasons" to do so.

I notice this change isn't mentioned in the news on the Eligius site...

I want to reuse the addresses. A lot. Actually, I do not want to generate new addresses at all if possible. This way the backup of my wallet does not need updating.
So, my mining goes to one address, some other received coins go to another. That's it. I may even generate a vanity address in the future. I am also running Bitcoin-qt without TOR.

Why do you want to force me to use different addresses?

Using multiple addresses won't make it impossible to track me, maybe not even harder. The mining pool knows my IP and my address, so if my government manages to extract that information from them, they got me. It won't change anything if I change the address - the new one will be linked to the old one via the same pool and because some transactions will have both addresses as the source (if I send more coins than there are in one address). So, those all addresses can be linked to me with some work.

I have two ways of receiving coins - mining (address->IP link in the pool) and buying (address->name, IP, bank account link in the exchange). If I sell the coins, there is another link. So, if the government wants to track me they sure can.

Using bitcoin correctly won't stop your government from tracking you, and isn't intended to.
What it can do, is stop everyone else from tracking you.

Does not look like the official client supports that. I mean there is no automatic way of doing it. I am not running some additional software. You give me and address to send the coins to, I send them to that address. If I want to receive coins from you, I will give you my address (the same one). If you somehow manage to turn it into some other address while making sure the coins reach me - great.

OTOH, I guess this patch could be circumvented by pre-generating as many addresses as I need (transactions per block) and giving them on a round-robin basis. Which still requires giving possible a different address each time someone wants to send coins to me. OTOH, I could just give a list of them and ask to choose one at random. That is static, but still inconvenient (and most would choose the first one in the list anyway).

It is inconvenient, no matter how you look at it.

However, I believe that everyone should decide that for themselves instead of having it basically forced on them (yea, yea, "miners can choose with transactions to include in the block, so there will be at least one miner who run an unaltered client, so your transaction will be included some time before the end of the universe" but it is effectively forcing me to do this).
Just like millions of people use Facebook and share everything about themselves (I am not one of them).

However, this affects not only the destination but also source addresses as I understand it. So, if I have mined a lot of coins (and on Eligius, all coins go to a single address, can't really change it, can I?) I have to wait longer if I want to make a few smaller purchases? Actually, same applies to coins bought in an exchange - unless I want to spend time manually withdrawing to different addresses.

I like the current system where I can keep coins received by mining in one address (so if I see the notification that 1P5p... received coins I know it is from mining, 175... means LabRat paid dividends etc).

There is no official client, or official anything. Official implies centralisation.

Address reuse takes away that choice from other users.
Using a unique address per transaction, as Bitcoin was always intended to be used, allows each user to choose for themselves whether they want their transaction record public or not.

There are no source addresses.
Addresses are only ever used to receive.

Yes, if you use Bitcoin wrong, this will make your transactions take slightly longer to confirm.
That's intentional.
I will continue to work closely with wizkid057 to ensure Eligius gets support for BIP32 as soon as possible.

Future software versions implementing BIP32 should be able to notify you based on the recurring invoice id used.

OK, maybe I chose a bad term. I meant Bitcoin-qt - the original client. The one that comes closest to being "official" and keeps the full blockchain.
After all, bitcoin.org is the first link that Google shows when searching for Bitcoin. That is a de-facto "official" website and a website I send people to to learn about Bitcoin. Bitcoin-qt is the client I first started using (there were no others back in CPU-mining days) and other clients are not compatible with its wallet format, so I can't really change it now.
Hopefully it won't be forced until Bitcoin-qt supports it.

I don't expect it to ever be forced at the blockchain level.

I mean by Eligius I hope I can contiue to use Bitcoin-qt without having to somehow also accommodate BIP32 until it is included in that client.

Thank Satoshi for bad planning when it came to wallets, and switch to Armory instead.

I don't see the problem with mining.  You don't need to give the pool a payment address until it's time for you to take your balance.  You can put *MONTHS* or even *YEARS* of mining output in a single tx, in a single address -- furthermore, doing so will cause you way less expense in the long run, because otherwise you'll have "dust" in that address that will cost you in transaction fees a significant fraction of whatever you spend.

Honestly, the whole interface would work better IMO if people's balance showed the expected amount that they can actually spend, *AFTER* transaction fees are deducted.  That would dispel illusions like getting "just as much Bitcoin" by getting mining paid daily as by getting it paid annually.  It would also go a long way toward making transaction fees easier to deal with; showing people their actual buying power as opposed to a number 30% or more of which may be illusory if their wallet is mostly "dust".

There's a huge distinction in fees between many tiny txouts and one big txout, regardless of the number of addresses they are sent to.  The argument about wanting to get many teeny-tiny mining payments at a single address shows that at least some users just aren't getting that distinction. Because it looks exactly the same in your wallet until you get REAMED on transaction fees when you try to spend it, it's too easy to miss. 

Not really, I have set 0.2BTC as the automatic payout and I think it is normal for me - I get it about every 4 days. Also, 0.2BTC is about $150 at current rate, so it's not "dust".
Sure, if I mined with USB Block erupter and wanted to be paid every day then yes, there would be too many transactions.

With 60GH/s I get 0.2BTC every ~four days. Also, I am risking at most 0.2BTC (let's say the pool server crashes and there are no backups) I am sure people with 1TH or higher hashrate would not want to wait very long for their coin.

Does it support the wallet.dat from the original client?
Does it support the block database from the original client (I do not want to wait another two weeks for the new client to download the blockchain).

Does not directly support wallet.dat, but if you've only got a couple addresses it's easy to import them.

Armory relies on either bitcoind or Bitcoin-Qt to connect to the network and download the blockchain for it, so you can just install Armory alongside your existing Bitcoin-Qt installation and it will just use that.

Even better you can set up bitcoind to constantly run in the background as a service and just use Armory when you need to make a transaction.

But it can't use the bitcoind wallet trough RPC?
I have a VM dedicated to various coins with their services running constantly (takes very long to download the missing blocks in the chain and to verify the block index, but the PC can keep up with the network quite well).

Hmm... Armory is available in two versions -  0.88.1-beta (64bit only, uses lots of RAM) and 0.89.99.16-testing (Vista, 7, 8 only, uses less RAM).
No version that would work on Windows 2003 32bit...

Not yet.

Right now it needs direct access to the downloaded blockchain files. Being able to connect to a remote bitcoind is a feature that he'll add "soon".

Slowing down transactions is not the right way of accomplishing the intented purpose. The right way is to make unique addresses easier to use.

Ok, who is this person:

https://blockchain.info/address/1Dc7NUeohUaujaqzcUg9XQ7YLzSGjn1FRG

Doesn't matter, there's a pseudonym visible.
Anonymity means you cannot name them at all.
Bitcoin is at best pseudonymous.

Practical difference: a pseudonym can be named/identified and theoretically be found, whereas someone anonymous cannot be identified at all distinct from any other actor.

S/he has not used their btc yet :)

First, this doesn't slow down transactions unless blocks are full (at the 1Mb limit) in which case *some* transactions would be slowed down anyway.  This just gives the *FIRST* transactions to all addresses higher priority than the *SECOND* or later transactions to all addresses.

Not sure if this was answered but how would this affect things like Asicminer dividends or are large transaction prioritized anyways?

Which is a really bad idea, and one that I imagine most pool operators would strongly advise you not to do.
Bitcoins in your account with a pool are not really yours, not yet. They are just a ledger entry saying that the pool owes you money.
If the pool is hacked, or just vanishes, those Bitcoin are gone.
And it isn't as though that hasn't happened, more than once.

Agreed.  The trust free (or reduced trust) alternative is to provide the pool a BIP32 address chain and the pool simply sends periodic payments to a new address each time.

Actually, I was thinking we should use hash(recurring invoice id) for the stats page, and not publish a list of those at all.
wizkid057 disagrees at the moment, though, so I'm not sure how it will turn out.

I assume you have already implemented this , can you give some feedback on its' effects?
I know that there are lost of variables , (time between blocks which leads to more or less transactions) but do you have any average on how the number transaction/blocked mined has evolved?

Luke-Jr: how is the patch working out in practice? All ok?

No, it really needs to be rewritten differently (as expected).
Unfortunately, that's very involved.

Juke-Jr,

I am sorry if this has been covered elsewhere, but I was thinking about the issues of address non(reuse) and how that affects paper wallets. Is there a way to have HD paper wallets? Something like you can scan the paper wallet to get an address to send funds to?

Unless there is a technical solution, this seems be an instance where it's not very practical when saving funds to cold storage.

The structure of HD Wallets is presented here (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki).

If your are storing leafs, they have 512 bits of data. This is about twice as much data as traditional keys.

In the "serialization format" section, it says that the keys are up to 112 Characters in base-58 format, which is longer than traditional addresses, IIRC. However, in theory, you only have to back these up once.

I think a more interesting question is if this can be made to work with Pay to Script Hash (https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki) and M-of-N Multisignature Transactions.

this topic is still relevant with all the newbies thinking an address is a wallet