Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/exclamation.gif) |
November 15, 2013, 05: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 hands1 are perhaps2 being forced3 to act sooner4. 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.5For 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.
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:12:26 AM Last edit: November 15, 2013, 05:46:05 AM by Luke-Jr |
|
Reserved (for pool position list/summary, etc).
|
|
|
|
Lollaskates
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:16:27 AM |
|
good on you man. This was the best approach to stick it up yifu's ass.
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8647
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:18:23 AM |
|
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.
|
|
|
|
jimmydorry
Newbie
Offline
Activity: 58
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:21:05 AM |
|
How would this effect things that require a static address? (Donations, etc.)
I personally would prefer to see those HD addresses, or address scopes.
|
|
|
|
eleuthria
Legendary
Offline
Activity: 1750
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:23:10 AM |
|
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.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
wizkid057
Legendary
Offline
Activity: 1223
Merit: 1006
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:23:48 AM |
|
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?
I particularly think this is a good "selling point" to this.
|
|
|
|
phillipsjk
Legendary
Offline
Activity: 1008
Merit: 1001
Let the chips fall where they may.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:24:24 AM |
|
I like this idea. Would require a lot of user education so they can understand why their transactions are not confirming. Would make asking for donations harder, but maybe that is a good thing.
Edit: "Why is funding my brain-wallet taking so long?" "Because your passphrase is not as unique as you think it is."
|
James' OpenPGP public key fingerprint: EB14 9E5B F80C 1F2D 3EBE 0A2F B3DE 81FF 7B9D 5160
|
|
|
pand70
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:26:20 AM |
|
Yeah lets make things more complicated!! Who wants user-friendly bitcoins anyways... ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) Btw what's the reason for such a change? Are we after vanity addresses or something ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif)
|
|
|
|
phillipsjk
Legendary
Offline
Activity: 1008
Merit: 1001
Let the chips fall where they may.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:28:16 AM |
|
How would this effect things that require a static address? (Donations, etc.)
I personally would prefer to see those HD addresses, or address scopes.
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. Btw what's the reason for such a change? Are we after vanity addresses or something ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) 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.
|
James' OpenPGP public key fingerprint: EB14 9E5B F80C 1F2D 3EBE 0A2F B3DE 81FF 7B9D 5160
|
|
|
jimmydorry
Newbie
Offline
Activity: 58
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:35:46 AM |
|
How would this effect things that require a static address? (Donations, etc.)
I personally would prefer to see those HD addresses, or address scopes.
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. 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.
|
|
|
|
BurtW
Legendary
Offline
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:36:14 AM |
|
Knee Jerk Reaction.
|
Our family was terrorized by Homeland Security. Read all about it here: http://www.jmwagner.com/ and http://www.burtw.com/ Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8647
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:39:03 AM |
|
Except if you are expecting more than a single transaction every 8mins.
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? Knee Jerk Reaction.
Was it an anti-casuaul knee jerk reaction that had me running a similar patch on my mining farm years ago? ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:43:29 AM |
|
Yeah lets make things more complicated!! Who wants user-friendly bitcoins anyways... ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) 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.
|
|
|
|
User705
Legendary
Offline
Activity: 896
Merit: 1006
First 100% Liquid Stablecoin Backed by Gold
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:47:47 AM |
|
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?
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8647
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:50:17 AM |
|
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.
|
|
|
|
BurtW
Legendary
Offline
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 05:51:16 AM Last edit: November 15, 2013, 06:09:31 AM by BurtW |
|
Luke-Jr, even this one?
Donate: 134dV6U7gQ6wCFbfHUz2CMh6Dth72oGpgH
|
Our family was terrorized by Homeland Security. Read all about it here: http://www.jmwagner.com/ and http://www.burtw.com/ Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
|
|
|
BurtW
Legendary
Offline
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 06:01:58 AM |
|
Knee Jerk Reaction.
Was it an anti-casuaul knee jerk reaction that had me running a similar patch on my mining farm years ago? ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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!
|
Our family was terrorized by Homeland Security. Read all about it here: http://www.jmwagner.com/ and http://www.burtw.com/ Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
|
|
|
btc4ever
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 06:06:34 AM |
|
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?
|
Psst!! Wanna make bitcoin unstoppable? Why the Only Real Way to Buy Bitcoins Is on the Streets. Avoid banks and centralized exchanges. Buy/Sell coins locally. Meet other bitcoiners and develop your network. Try localbitcoins.com or find or start a buttonwood / satoshi square in your area. Pass it on!
|
|
|
pand70
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 15, 2013, 06:06:51 AM |
|
Btw what's the reason for such a change? Are we after vanity addresses or something ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) 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. 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...
|
|
|
|
|