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.
Topic: Miners: Time to deprioritise/filter address reuse! - page 6. (Read 51790 times)
"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?
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.
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?
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.
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.
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?
In other words, I would vote "We should have waited longer, but I guess it needs to move forward now."
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?
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.
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.
Some day you may disagree some actions they will take. But you can do nothing, just like me now.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
I. Auction bidding.
This can be accomplished with a BIP32 address chain
Is this supported with blockchain.info or bitcoin-qt at this time?
No, and that's the point. Unless some pressure is exerted, adoption of BIP0032 will always be on the back burner. This is an example of how miners can exert pressure on the entire ecosystem.
With current difficulty, there's almost no chance for a new pool to survive and hence no democracy at all in BTC now. We are now all controlled by the operators of BTCGuild and other couple of pools.
So let me get this right: A mining pool operator implemented a change that, with (wider) acceptance, would delay payments to his own miners? Should his miners change their payout addresses every single mined block?
BIP_32 is not in effect, so that argument is currently moot.
BIP_32 is not in effect, so that argument is currently moot.
And thus create incentive for wallet operators to implement BIP32 now. In doing so they will also attract more users to their brand of wallet since they will be the frist to adopt. This doesnt harm bitcoin in the slightest.
I. Auction bidding.
This can be accomplished with a BIP32 address chain
Is this supported with blockchain.info or bitcoin-qt at this time?
No, and that's the point. Unless some pressure is exerted, adoption of BIP0032 will always be on the back burner. This is an example of how miners can exert pressure on the entire ecosystem.
Jump to: