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.
Topic: Miners: Time to deprioritise/filter address reuse! - page 9. (Read 51830 times)
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?
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.
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.
Yes. This is a crucial difference between reuse for inputs only (for example a donation address) and reuse after an output.
The point is that people need to stop this bad behaviour and start using Bitcoin correctly.
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?
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
Quote
Why does my Bitcoin address keep changing?
Whenever the address listed in "Your address" receives a transaction, Bitcoin replaces it with a new address. This is meant to encourage you to use a new address for every transaction, which enhances anonymity. All of your old addresses are still usable: you can see them in Settings -> Your Receiving Addresses.
from 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. Whenever the address listed in "Your address" receives a transaction, Bitcoin replaces it with a new address. This is meant to encourage you to use a new address for every transaction, which enhances anonymity. All of your old addresses are still usable: you can see them in Settings -> Your Receiving Addresses.
What about donation addresses?
Address Chains, forthcoming in the new version of Bitcoin Qt.
Is it actually being implemented or one of those things that has been sidelined?
What about donation addresses?
Address Chains, forthcoming in the new version of Bitcoin Qt.
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?
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.
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.
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?
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.
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).
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?
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.
What's the risk?
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 about donation addresses?
The point is that people need to stop this bad behaviour and start using Bitcoin correctly.
Meanwhile, outside the bubble of authoritarian-minded mining pool operators:
(via http://www.reddit.com/r/Bitcoin/comments/1qrp1h/subway_accepting_bitcoins_in_slovakia_bratislava/ )
The point is that people need to stop this bad behaviour and start using Bitcoin correctly.
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?
I assume this cannot affect the prioritisation of the Coinbase transaction that constitutes p2pool miner's reward payments? Can you clarify this?
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.
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.
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(269999) that there is causing atleast 1 hour 40 minute delay for that 10th transaction. and what about other transactions sent 10 minutes after(269989). they have no spaces in block(269990) through to (269999)
so lets say there were 10 used addressed transactions per block
in block(269990). after waiting 1 hour 40 minutes, each of those 10 transactions have to wait a further 10 minutes filling up blocks (270000-270009) . making the 10th transaction sent at the timestamp of 269990 finally enter a block over 3 hours 20 minutes later
now imagine the transactions timestamped at the times of blocks 269991-270009.. 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. 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(269999) that there is causing atleast 1 hour 40 minute delay for that 10th transaction. and what about other transactions sent 10 minutes after(269989). they have no spaces in block(269990) through to (269999)
so lets say there were 10 used addressed transactions per block
in block(269990). after waiting 1 hour 40 minutes, each of those 10 transactions have to wait a further 10 minutes filling up blocks (270000-270009) . making the 10th transaction sent at the timestamp of 269990 finally enter a block over 3 hours 20 minutes later
now imagine the transactions timestamped at the times of blocks 269991-270009.. 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..
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..
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..
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?
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.
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.
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.
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 ?
This first patch just rejects from your memorypool any transaction which: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 ?
- 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.
And then there's Blockchain.info. Did you know Blockchain.info wallets reuse addresses by default unless you create new ones?
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.
I assume this cannot affect the prioritisation of the Coinbase transaction that constitutes p2pool miner's reward payments? Can you clarify this?
This will not affect any generation transactions, nor any miners who choose not to use it. 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).
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.
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.
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.
Jump to: