Miners: Time to deprioritise/filter address reuse! - page 12.

luv2drnkbr

hero member

Activity: 793

Merit: 1026

Quote from: Luke-Jr on November 15, 2013, 05:01:48 PM

Quote from: luv2drnkbr on November 15, 2013, 04:47:21 PM

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.

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

Quote from: luv2drnkbr on November 15, 2013, 04:47:21 PM

People like vanity addresses.

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

Quote from: luv2drnkbr on November 15, 2013, 04:47:21 PM

Donations need single addresses.

No, they don't.

Quote from: luv2drnkbr on November 15, 2013, 04:47:21 PM

Privacy should come at the CHOICE of the user, not the FORCE of the miners.

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.

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

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: BigJohn on November 15, 2013, 06:21:04 PM

Quote from: DeathAndTaxes on November 15, 2013, 04:55:01 PM

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.

I know this is slightly off-topic, but why is it not? 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.

BigJohn

member

Activity: 116

Merit: 10

Quote from: DeathAndTaxes on November 15, 2013, 04:55:01 PM

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.

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?

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: luv2drnkbr on November 15, 2013, 04:47:21 PM

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.

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.

Quote from: luv2drnkbr on November 15, 2013, 04:47:21 PM

People like vanity addresses.

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

Quote from: luv2drnkbr on November 15, 2013, 04:47:21 PM

Donations need single addresses.

No, they don't.

Quote from: luv2drnkbr on November 15, 2013, 04:47:21 PM

Privacy should come at the CHOICE of the user, not the FORCE of the miners.

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.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: btcdrak on November 15, 2013, 04:52:28 PM

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.

btcdrak

legendary

Activity: 1064

Merit: 1000

Quote from: DeathAndTaxes on November 15, 2013, 04:49:32 PM

Quote from: luv2drnkbr on November 15, 2013, 04:47:21 PM

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.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: luv2drnkbr on November 15, 2013, 04:47:21 PM

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.

luv2drnkbr

hero member

Activity: 793

Merit: 1026

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.

Nuprator

newbie

Activity: 3

Merit: 0

https://bitcointalksearch.org/topic/someone-is-sending-out-0001-btcs-to-hundreds-of-random-people-who-and-why-254615

P_Shep

legendary

Activity: 1795

Merit: 1208

This is not OK.

Quote from: Nuprator on November 15, 2013, 03:07:23 PM

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?

Nuprator

newbie

Activity: 3

Merit: 0

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.

P_Shep

legendary

Activity: 1795

Merit: 1208

This is not OK.

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

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Schleicher on November 15, 2013, 11:33:48 AM

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.

Schleicher

hero member

Activity: 675

Merit: 514

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?

soy

legendary

Activity: 1428

Merit: 1013

Quote from: Luke-Jr on November 15, 2013, 12:12:16 AM

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¹ are perhaps² being forced³ to act sooner⁴.

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
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 (15% of total network hashing) is now the first to deploy this change on an experimental basis.

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.

BurtW

legendary

Activity: 2646

Merit: 1137

All paid signature campaigns should be banned.

Quote from: Come-from-Beyond on November 15, 2013, 06:58:08 AM

Quote from: servowire on November 15, 2013, 06:56:45 AM

Quote from: Come-from-Beyond on November 15, 2013, 05:45:50 AM

"New address for each payment" is a logic bomb

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

Obviously u didn't read it.

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.

n8rwJeTt8TrrLKPa55eU

hero member

Activity: 588

Merit: 500

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.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie