Miners: Time to deprioritise/filter address reuse!

[BurtW]

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.

[1714030974]

1714030974

[1714030974]

1714030974

[1714030974]

1714030974

[1714030974]

1714030974

[1714030974]

1714030974

[darkmule]

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

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.

[Carlton Banks]

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

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?

[killerstorm]

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

[kano]

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

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?

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:

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.

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

Certainly makes no sense as it is.

[kkurtmann]

indubitably

[niothor]

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

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?

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.

[AtlasONo]

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

[Pentium100]

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.

[Luke-Jr]

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.

[Pentium100]

This way the backup of my wallet does not need updating.

BIP32 fixes that, please read the thread.

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.

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.

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

[Luke-Jr]

Does not look like the official client supports that.

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

However, I believe that everyone should decide that for themselves

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.

However, this affects not only the destination but also source addresses as I understand it.

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

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.

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.

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

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

[Pentium100]

Does not look like the official client supports that.

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

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.

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.

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.

Hopefully it won't be forced until Bitcoin-qt supports it.

[Luke-Jr]

Hopefully it won't be forced until Bitcoin-qt supports it.

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

[Pentium100]

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.

[justusranvier]

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.

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

[Cryddit]

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. 

[Pentium100]

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.

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.

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. 

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.

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.

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

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

[justusranvier]

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.

[Pentium100]

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.

But it can't use the bitcoind wallet trough RPC?

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.

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