Miners: Time to deprioritise/filter address reuse!

[BitThink]

As I said, you cannot do some changes to a billion dollar related project just because you think it's correct. The side effect may kill a project before you see any positive effect. That's why backward compatibility is so important in software industry.

Utter nonsense.   This isn't a change to the core protocol.  All miners have ALWAYS had the ability to prioritize tx as they see fit.  Currently ~15% on the network is implementing this so the effect on multi-use addresses is minimal at best.

Bitcoin was DESIGNED for this type of decentralized tx processing.   There is a reason tx selection is loosely coupled.  There is a reason that miners are free to include any valid tx in a block.  There is a reason that other miners can't override or veto that decision.

Once BTCGuild joins, it's done. BTC now is not decentralized at all.

As a simple example, yesterday I suggested to create a pool to save master coin, which will be killed immediately with Luke's patch. Then we realized we need 500TH and double it every month to mine a block each hour. even we can get several TH to start it, no miner will join us since it may takes weeks to find a block.

Now you can clearly see the danger of centralized mining.

Disclaimer I hold 0 share of mastercoin.

[1715037568]

1715037568

[1715037568]

1715037568

[1715037568]

1715037568

[1715037568]

1715037568

[btcdrak]

It's not just discourage as you think, it's forbidding in some scenario. If a merchant use a fix address to receive payment , it can only receive 6 payments per hour. Basically makes the service useless. It's customers have to wait forever if there're more than 6 payments per hour.

What merchant uses a static address for all customers?   Horribly insecure and prone to problems.  Anyone that foolish should just use a service like bitpay and have it done right by someone competent.

The moment a business realises someone can look up their address and see their takings... they will want to use unique-addresses at checkout afterall...

[DeathAndTaxes]

As I said, you cannot do some changes to a billion dollar related project just because you think it's correct. The side effect may kill a project before you see any positive effect. That's why backward compatibility is so important in software industry.

Utter nonsense.   This isn't a change to the core protocol.  All miners have ALWAYS had the ability to prioritize tx as they see fit.  Currently ~15% on the network is implementing this so the effect on multi-use addresses is minimal at best.

Bitcoin was DESIGNED for this type of decentralized tx processing.   There is a reason tx selection is loosely coupled.  There is a reason that miners are free to include any valid tx in a block.  There is a reason that other miners can't override or veto that decision.

Once BTCGuild joins, it's done. BTC now is not decentralized at all.

Miners vote with their hashing power.  If miners agree then it is no different than a million solo miners implementing it directly.  If miners disagree then they can move to another pool more inline with their views.  Miners have always had the power to choose the tx they want to include in a block.  The availability of the patch merely gives miners an effective tool to implement this type of prioritization. The patch isn't doing anything the protocol doesn't already allow.

Still this is still a relatively soft change.  Even for affected tx having 50% of hashing power implementing the patch doesn't kill those tx.  Affected tx will simply take twice as long for first confirmation and the following 5 will be at the same rate.  Essentially a 6 confirm goes from 60 minutes to 70 minutes.  If you honestly believe that will "kill" Bitcoin then honestly Bitcoin never had a chance of surviving and was a pretty crappy experiment to begin with.

Bitcoin will survive just fine.   

[BitThink]

As I said, you cannot do some changes to a billion dollar related project just because you think it's correct. The side effect may kill a project before you see any positive effect. That's why backward compatibility is so important in software industry.

Utter nonsense.   This isn't a change to the core protocol.  All miners have ALWAYS had the ability to prioritize tx as they see fit.  Currently ~15% on the network is implementing this so the effect on multi-use addresses is minimal at best.

Bitcoin was DESIGNED for this type of decentralized tx processing.   There is a reason tx selection is loosely coupled.  There is a reason that miners are free to include any valid tx in a block.  There is a reason that other miners can't override or veto that decision.

Once BTCGuild joins, it's done. BTC now is not decentralized at all.

Miners vote with their hashing power.  If miners agree then it is no different than a million solo miners implementing it directly.  If miners disagree then they can move to another pool more inline with their views.  Miners have always had the power to choose the tx they want to include in a block.  The availability of the patch merely gives miners an effective tool to implement this type of prioritization. The patch isn't doing anything the protocol doesn't already allow.

Still this is still a relatively soft change.  Even for affected tx having 50% of hashing power implementing the patch doesn't kill those tx.  Affected tx will simply take twice as long for first confirmation and the following 5 will be at the same rate.  Essentially a 6 confirm goes from 60 minutes to 70 minutes.  If you honestly believe that will "kill" Bitcoin then honestly Bitcoin never had a chance of surviving and was a pretty crappy experiment to begin with.

Bitcoin will survive just fine.  

Miners will not join a new pool which find a block every one week. To create a new pool you have to spend huge amount of fund beforehand. It is not so different as 'everyone can be a president candidate in US'.

You are talking about just one transaction. As long as some addresses have more than  a couple of transactions every 10 minutes, the waiting time goes to infinity.

[DeathAndTaxes]

Miners will not join a new pool which find a block every one week. To create a new pool you have to spend huge amount of fund beforehand. It is not so different as 'everyone can be a president candidate in US'.

Who said anything about a "new pool"  If BTC Guild supports this patch (which they don't yet) and miners disaprove they can simply go to the #2 pool which doesn't support the patch.  Still 50% of miners supporting the patch still doesn't have a catastrophic effect on multi-use addresses.   1st confirm time doubles to 20 minutes.  6 confirm time goes from 60 minutes to 70 minutes.

[BitThink]

Miners will not join a new pool which find a block every one week. To create a new pool you have to spend huge amount of fund beforehand. It is not so different as 'everyone can be a president candidate in US'.

Who said anything about a "new pool"  If BTC Guild supports this patch (which they don't yet) and miners disaprove they can simply go to the #2 pool which doesn't support the patch.  Still 50% of miners supporting the patch still doesn't have a catastrophic effect on multi-use addresses.   1st confirm time doubles to 20 minutes.  6 confirm time goes from 60 minutes to 70 minutes.

Why miners care so much to leave the pool they are used to? They are not the ones suffering from this patch. I am saying those who disagrees has no chance to create a new pool to protect themselves.

[DeathAndTaxes]

Why miners care so much to leave the pool they are used to? They are not the ones suffering from this patch. I am saying those who disagrees has no chance to create a new pool to protect themselves.

Miners aren't Bitcoin users?  Not a single miner will be affected by this patch in any way shape or form?  Not a single miner will be convinced by your FUD and doom and gloom and switch in order to save Bitcoin from Luke-Jr?

Is your worlds so black and white that miners are a group outside of the group of users?

We went through the same kind fud with P2SH, we went through the same kind of fud with dust threshold.  Bitcoin survives.  The protocol is robust, clients and service providers will make improvements.  If they don't they lose marketshare to those who do.   

[BitThink]

Why miners care so much to leave the pool they are used to? They are not the ones suffering from this patch. I am saying those who disagrees has no chance to create a new pool to protect themselves.

Miners aren't Bitcoin users?  Not a single miner will be affected by this patch in any way shape or form?  Not a single miner will be convinced by your FUD and doom and gloom and switch in order to save Bitcoin from Luke-Jr?

Is your worlds so black and white that miners are a group outside of the group of users?

We went through the same kind fud with P2SH, we went through the same kind of fud with dust threshold.  Bitcoin survives.  The protocol is robust, clients and service providers will make improvements.  If they don't they lose marketshare to those who do.   

Please calm down and think about it more. A small part of miners may care about this patch does not change the fact that now everyone's fate are in the hands of a few operators of big pools.

Some day you may disagree some actions they will take. But you can do nothing, just like me now.

[DeathAndTaxes]

Please calm down and think about it more. A small part of miners may care about this patch does not change the fact that now everyone's fate are in the hands of a few operators of big pools.

No everyone's fate is in the hands of miners.   However it HAS ALWAYS BEEN in the hands of miners (since the genesis block).  Don't like that concept?  Then become a miner. 

[murraypaul]

If it's this important shouldn't Eligius start forcing new addresses for every withdrawal?

Yes, migrating to HD/recurring invoice ids has been on the todo list for Eligius for a long time.
Unfortunately, wallet software has not matured enough for that yet.

So you don't support using new addresses, but think everyone else who doesn't support it should be punished?
Isn't that a bit hypocritical?

[Luke-Jr]

If it's this important shouldn't Eligius start forcing new addresses for every withdrawal?

Yes, migrating to HD/recurring invoice ids has been on the todo list for Eligius for a long time.
Unfortunately, wallet software has not matured enough for that yet.

So you don't support using new addresses, but think everyone else who doesn't support it should be punished?
Isn't that a bit hypocritical?

I think this move should have waited a few more months at least, but we're out of time it seems.
In other words, I would vote "We should have waited longer, but I guess it needs to move forward now."

[BigJohn]

But isn't that the exact point? That it would start to be a hindrance to merchants so they'd stop reusing addresses?

Just thought of something... how does the BIP32 protocol addendum limit the usable address space based on whatever seed is generating the string of future keys? Reading the wiki pages now, will edit this post if i find an answer.

What do you mean limit the usable address space?  There is no change in the number of possible addresses.

For some reason I was thinking that using a seed->prng, and sequential nonce would end up with a subset of the 2^160 (#?) key pairs.

If the entire world economy used a new key pair for every digital transaction (the rate of which is increasing exponentially) for the next 50 years... where would we end up in terms of collision probability? I dunno, i think i'm way off topic here. We can let this sidebar fall away now...

I don't think it would even make a dent. The number is (I believe) 2^160 possible addresses. That's just gigantic beyond my reckoning. Maybe if every person on earth did like a trillion transactions a day for god knows how many years you'd get there.

[btcdrak]

If it's this important shouldn't Eligius start forcing new addresses for every withdrawal?

Yes, migrating to HD/recurring invoice ids has been on the todo list for Eligius for a long time.
Unfortunately, wallet software has not matured enough for that yet.

So you don't support using new addresses, but think everyone else who doesn't support it should be punished?
Isn't that a bit hypocritical?

I think this move should have waited a few more months at least, but we're out of time it seems.
In other words, I would vote "We should have waited longer, but I guess it needs to move forward now."

FWIW, Luke-Jr - I think you've done a good thing here and I am glad you can take the heat. The science and the maths all add up here.

[BitThink]

Please calm down and think about it more. A small part of miners may care about this patch does not change the fact that now everyone's fate are in the hands of a few operators of big pools.

No everyone's fate is in the hands of miners.   However it HAS ALWAYS BEEN in the hands of miners (since the genesis block).  Don't like that concept?  Then become a miner. 

Not in the hands of miners, but in the hands of the operators of big mining pools. That's a big difference. A small miner is as powerless as non-miner.

[killerstorm]

"Lookup by address" is only less load than "lookup by bloom filter" if every node carries an address index (which adds to disk and memory requirements).

I'm looking at total amount of computational work which needs to be done. Suppose we have 1 million thin clients which launch recover from seed. We need to scan the whole blockchain 1 million times.

On the other hand, suppose one client need to look up M addresses on average.

We can compare this two cases if we assume that one address lookup is computationally equivalent to scanning K bytes. If blockchain is N bytes long, lookups are M*K/N less expensive.

For example, if M = 1000 (addresses per client, on average), K=100 (100 bytes scanned per address), N=10^10 (blockchain is 10 GB large), it turns out that lookups are 10000 times less expensive.

This means, for example, that the work which requires 10000 Bitcoin nodes can be done by just one server.

This is true even if there is no address reuse (1000 addresses per client).

Please do the math before coming to conclusions. It looks like Bloom filter doesn't scale, so you should recommend it as a solution.

In any case, Bitcoin was designed with addresses being single-use, and it becomes unusable with too much reuse, so this side-topic is irrelevant.

Are you talking about ECDSA vulnerability? How much is too much?

Can't we allow limited reuse?

[AtlasONo]

Take for example way back when when deepbit Was nearing 50% for weeks everyone was told don't mine there! switch pools! For weeks they remained a threat and were eventually hit with a DDoS attack to force people away. If miners couldn't be bothered to stop a 50% attack what makes anyone think they would care about smaller matters?

Additionally with the surge of ASICs mining power has become further centralized, no longer is control in the hands of anyone with a gaming GPU. 

[corebob]

Just do it. And keep it coming.

[giszmo]

Why miners care so much to leave the pool they are used to? They are not the ones suffering from this patch. I am saying those who disagrees has no chance to create a new pool to protect themselves.

Miners aren't Bitcoin users?  Not a single miner will be affected by this patch in any way shape or form?  Not a single miner will be convinced by your FUD and doom and gloom and switch in order to save Bitcoin from Luke-Jr?

Is your worlds so black and white that miners are a group outside of the group of users?

We went through the same kind fud with P2SH, we went through the same kind of fud with dust threshold.  Bitcoin survives.  The protocol is robust, clients and service providers will make improvements.  If they don't they lose marketshare to those who do.   

Please calm down and think about it more. A small part of miners may care about this patch does not change the fact that now everyone's fate are in the hands of a few operators of big pools.

Some day you may disagree some actions they will take. But you can do nothing, just like me now.

If you create a pool with a clear mission, miners will join it no matter if you have less than one block per week. Spread enough fud about the big pools and yours will grow. Even though I don't agree on that subject, more pools and more solo miners that care about these behind the scenes politics are a good thing.

Mining reminds me a lot of liquid democracy. This is great

[Littleshop]

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.

+1 

There are many benefits to public addresses and address reuse.  In banking it would NOT BE SAFE to give out your bank account numbers, but with Bitcoin since the transactions are one way, it is not as problematic.  The whole idea is Bitcoin gives the user CHOICE.  Why would we start to take that benefit away from users as a reaction to something that probably will not happen?

[Carlton Banks]

Please calm down and think about it more. A small part of miners may care about this patch does not change the fact that now everyone's fate are in the hands of a few operators of big pools.

No everyone's fate is in the hands of miners.   However it HAS ALWAYS BEEN in the hands of miners (since the genesis block).  Don't like that concept?  Then become a miner.  

Not in the hands of miners, but in the hands of the operators of big mining pools. That's a big difference. A small miner is as powerless as non-miner.

Can't tell if trolling or stupid.... at least try to stick to one mumbling complaint at a time


Your complaint was true yesterday, the day before, the previous week, the previous month, and the entire history of pooled mining. Give yourself a round of applause for finally working out that pools represent multiple miners working for a single node. BITCIONS IS DIEEEING