Pages:
Author

Topic: Miners: Time to deprioritise/filter address reuse! - page 14. (Read 51793 times)

donator
Activity: 1218
Merit: 1079
Gerald Davis
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.
legendary
Activity: 1750
Merit: 1007
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.



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?).
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
Hence my question/comment above:

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?

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.

sr. member
Activity: 369
Merit: 250
Hmm.   I'm not sure it is rate limiting p2pool payments.   Can someone clarify?

---snip---

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)

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.
legendary
Activity: 882
Merit: 1000
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?
Address-as-identity does not use the blockchain at all.

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?
Reusing addresses doesn't merely hurt your own privacy. It hurts everyone's.
There are also security ramifications. And now adoption issues too.

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.
legendary
Activity: 1596
Merit: 1091
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.

staff
Activity: 4200
Merit: 8441
Shouldn't this go first or at least be done somewhat concurrently with the proposal?
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.
sr. member
Activity: 321
Merit: 250
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.

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)
legendary
Activity: 2576
Merit: 1186
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?
Address-as-identity does not use the blockchain at all.

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?
Reusing addresses doesn't merely hurt your own privacy. It hurts everyone's.
There are also security ramifications. And now adoption issues too.
legendary
Activity: 882
Merit: 1000
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?
 
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
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.  
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?
legendary
Activity: 2576
Merit: 1186
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?
Yes, p2pool users can immediately make use of the patch like this.
staff
Activity: 4200
Merit: 8441
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)
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.
legendary
Activity: 2212
Merit: 1001
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 Huh 

Or am I missing the point  Roll Eyes
legendary
Activity: 1008
Merit: 1000
Yeah lets make things more complicated!! Who wants user-friendly bitcoins anyways...  Roll Eyes
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.

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?
sr. member
Activity: 369
Merit: 250
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)
sr. member
Activity: 476
Merit: 250
Btw what's the reason for such a change? Are we after vanity addresses or something  Tongue Tongue

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...
sr. member
Activity: 321
Merit: 250
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?
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
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
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!
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
Luke-Jr, even this one?

Donate: 134dV6U7gQ6wCFbfHUz2CMh6Dth72oGpgH
Pages:
Jump to: