Also, what about once ASIC devices not as large as those come out, how much for a little thing that only uses one ASIC chip and maybe is about the size of a IDE hard drive or a walkman?
Will depend on volume. With ASICs, marginal costs for producing extra units are very low. So if they produce a single unit, it will cost around five million dollars. If they produce five million units the chips themselves can be sold for one dollar per piece. Add to that the housing and control circuit that is needed to make a usable consumer device. 
Topic: Dynamic Defensive Hashing for the Bitcoin Network (Read 3177 times)
We are already seeing the significant cost to mining as being the electricity usage. Even with the massive change per year in hashing efficiency gained by new technologies.
Over time it is likely that the cost to mining will become much more dependent on the cost of electricity than it is now. The main reason is that the technology isn’t going to progress at the same rate as it is progressing now.
We have seen the 500x improvement from going from CPU mining to GPU mining, 2years ago.
We are now seeing the 10x improvement from going from GPU to FPGA.
And we are just now beginning the 5x improvement from going from FPGA to ASIC.
No. Going from CPU to GPU mining was a ~50x increase in efficiency (0.1Mhash/J to 5Mhash/J). Going form GPU to FPGA (using Butterfly Labs' Bitforce Single as an example) was a ~2x increase in efficiency (to 10Mhash/J (~800Mhash@80W). This is simply because a GPU employs an ASIC, albeit not a mining-specific one. So an FPGA isn't that much of an advantage (when total system power is excluded).Over time it is likely that the cost to mining will become much more dependent on the cost of electricity than it is now. The main reason is that the technology isn’t going to progress at the same rate as it is progressing now.
We have seen the 500x improvement from going from CPU mining to GPU mining, 2years ago.
We are now seeing the 10x improvement from going from GPU to FPGA.
And we are just now beginning the 5x improvement from going from FPGA to ASIC.
No dedicated mining ASIC exists yet. Largecoin claims to have an sASIC unit ready in July that does ~200Mhash/J - a 20x increase in efficiency.
A SHA-256 ASIC already exists that does 500Mhash/J (a further 2.5x increase in efficiency).
So going from FPGA to true ASIC is more like a 50x increase in efficiency (the same as going from CPU to GPU).
Other than that, I don't think your suggestion will bring any benefits to the network. Why would it help the network that people have offline miners they can turn on at will? Why not always have them turned on? How will these people recover the costs of their equipment if it's turned off all the time? I think you have a genuine interest in making the network more secure, but I don't relying on people to waste large amounts of money is the solution.
Hello. I just want to clear up some half-truths about this topic.
First: Difficulty != Security. - However generally there lots of correlation between the two.
Security is defined by: Cost of carrying out a successful attack against the bitcoin network v.s. direct gain to the attacker.
[...]
Interesting post. I haven't been around here in a while, so forgive me if I'm misunderstanding...but there's quite a lot in your proposal that I find confusing.First: Difficulty != Security. - However generally there lots of correlation between the two.
Security is defined by: Cost of carrying out a successful attack against the bitcoin network v.s. direct gain to the attacker.
[...]
If I'm reading you correctly, you believe that at any given moment there is little idle capacity in the network, and existing miners don't have the ability or incentive to add capacity quickly enough to ward off an attack of sufficient computing power. The inelasticity of network capacity combined with the observable hashrate & difficulty gives a wealthy enough attacker the information needed to gain control of the blockchain if difficulty/hashrate drops below the attacker's cost vs benefit threshold.
Your solution is to establish a hidden reserve of computing power that could be brought online if an attack is detected. Since the network's true capacity wouldn't be observable by potential attackers, they could no longer calculate a threshold - so serious attempts to attack the network would be minimized. This standby hashing power would be maintained and operated by insurance companies, bitcoin banks, bitcoin traders (exchanges?), and “individuals whom have a large stake in the success of bitcoin”. The standby capacity would be financed by revenues from insurance policies sold to businesses accepting bitcoin as payments for their goods & services. (have I got that right?)
If I'm close to the mark, I've got the following questions:
- Assuming there's a critical mass of BTC merchants willing to buy transaction insurance for their businesses, how would your insurance companies price their policies in the absence of actuarial data?
- If I'm a BTC merchant unwilling to buy transaction insurance, won't I be getting a free ride off those that do purchase insurance?
- Why would an insurance company bother with building out standby network capacity if they have the option to simply pay out the value of double spend/supply blocked transactions?
- How will your 2nd and 3rd lines of dynamic hashing power (bitcoin banks/traders/large stakeholders) finance the costs of establishing their idle reserve capacity? Are they selling insurance policies to BTC merchants also?
- How do you propose limiting block rewards so that they only cover the costs of “trivial internal annoyances” resulting from a low network hashrate? Why would you need to? Aren't trivial attacks due to low hashrate covered by your reserve hashing power insurers?
- Who determines the appropriate level of reserve hashing power? How would they arrive at a standby hashrate figure? How would the standby capacity be verified?
Finally, doesn't your proposal slap a lot of trusted intermediaries (and their associated fees) on top of a system meant to minimize/eliminate these things?
ps - I keep seeing the term "bitcoin banks" being used on this forum now. Boy have things changed since I was here last.
The offline 51% (or really 101%) attack problem is preventable if we want it to be. No insurance companies or outside complications needed.
Electricity is the major cost of a long-term mining operation.
This is true for GPU:s but not for FPGA:s. The more energy efficient devices we see, the less true it will be.
But hardware will still be the major cost.
The only way I could be convinced to be "on call" with some of my hashpower is if it were already paid off - and for many people this is not the case.
Once it were paid off, I could run my BFL single 24/7, and fire up my two 6x 5870 rigs when the hash power was demanded.
Once it were paid off, I could run my BFL single 24/7, and fire up my two 6x 5870 rigs when the hash power was demanded.
The suggestion is people with decent wealth who presumably have no problem maintaining significant offline hashing capacity; this doesn't need to be most people.
The only way I could be convinced to be "on call" with some of my hashpower is if it were already paid off - and for many people this is not the case.
Once it were paid off, I could run my BFL single 24/7, and fire up my two 6x 5870 rigs when the hash power was demanded.
Once it were paid off, I could run my BFL single 24/7, and fire up my two 6x 5870 rigs when the hash power was demanded.
i think this whole argument is upside down.
insurance only exists to protect against an unlikely event. your whole argument is that this is a likely event. insurance companies are extremely risk averse and like to deal with risks that are highly measurable and not likely to occur.
this is a highly unmeasurable proposal in that how is one supposed to measure this hidden reserve hashing rate that is kept offline in case of an attack? even if you could measure it then everyone would know as would the attacker. then we're back to square one which is that the attacker would know precisely how much hashing rate to bring online to ensure success of the attack.
what is to prevent cheating via one insurance company bringing online a small amount of its hashing rate to scoop up whatever tx fees exist in the ongoing verification process?
this also is a form of centralization in that you discourage all smaller players from plugging in their new Butterfly's b/c you've artificially suppressed the tx fees and i would argue that we want lots of newbies plugging these units in to strengthen the network.
a visible open p2p large hashing rate as we have now seems to be working and acts as an effective deterrent.
the risk of a likely attack causing chaos and a systemic failure for a purposely weakened, stripped down hashing rate invites trouble. no insurance company would take this risk.
you might be thinking of starting an insurance business yourself and this might be why you think it will work; i don't know. but i don't think most ppl will buy in.
insurance only exists to protect against an unlikely event. your whole argument is that this is a likely event. insurance companies are extremely risk averse and like to deal with risks that are highly measurable and not likely to occur.
this is a highly unmeasurable proposal in that how is one supposed to measure this hidden reserve hashing rate that is kept offline in case of an attack? even if you could measure it then everyone would know as would the attacker. then we're back to square one which is that the attacker would know precisely how much hashing rate to bring online to ensure success of the attack.
what is to prevent cheating via one insurance company bringing online a small amount of its hashing rate to scoop up whatever tx fees exist in the ongoing verification process?
this also is a form of centralization in that you discourage all smaller players from plugging in their new Butterfly's b/c you've artificially suppressed the tx fees and i would argue that we want lots of newbies plugging these units in to strengthen the network.
a visible open p2p large hashing rate as we have now seems to be working and acts as an effective deterrent.
the risk of a likely attack causing chaos and a systemic failure for a purposely weakened, stripped down hashing rate invites trouble. no insurance company would take this risk.
you might be thinking of starting an insurance business yourself and this might be why you think it will work; i don't know. but i don't think most ppl will buy in.
Insurance companies are businesses first, insurance companies second. The goal of any for profit business is profit first, not necessarily to be risk averse. This means it's logical to provide tornado insurance in "tornado alley" or earthquake insurance in California; just calculate high enough premiums to ensure profitability. The question boils down to whether or not enough customers will agree to your fees. Given the opportunities/possibilities Bitcoin provides I think there would be some tolerance of rates.
Overall I think the OP is definitely on to something with "on call" surprise hashing capacity. I also think insurance companies might play a role. However, I think a more straightforward source is bitcoin banks, businesses, etc. - anyone with decent wealth having interest in seeing bitcoin succeed as the OP notes. There can be an understanding promoted people are encouraged to participate in such a concerted defense action.
I personally expect an explosion in hashing power as more fpga and butterfly like units come online. Who won't want to hedge the USD against a nice small form unit plugged into their PC at the side of their desk?
This will be very good for Bitcoin.
This will be very good for Bitcoin.
On the cost of having massive offline hashing capabilities:
We are already seeing the significant cost to mining as being the electricity usage. Even with the massive change per year in hashing efficiency gained by new technologies.
Over time it is likely that the cost to mining will become much more dependent on the cost of electricity than it is now. The main reason is that the technology isn’t going to progress at the same rate as it is progressing now.
We have seen the 500x improvement from going from CPU mining to GPU mining, 2years ago.
We are now seeing the 10x improvement from going from GPU to FPGA.
And we are just now beginning the 5x improvement from going from FPGA to ASIC.
The trend is clear. Do you think that the generation 4 ASIC miner is going much, faster than the generation 3? Then what about the generation 6 or 7 or 10 miners?? The improvement as the technology for hashing for bitcoin matures, always decreases.
This means that while it is ‘better’ to buy the newest generation miners. The old miners are not completely made oblique. CPU’s are never going to be useful in hashing for bitcoin again… However FPGA’s may have quite a long life-time.
When it is no-longer profitable to run your FPGA all the time… What happens when a group of insurance companies offer you a quite profitable rate for on-demand hashing? Do you just say ‘no’ or do you take up the offer for additional income.
The hashing needs of the network are going to become more and more dynamic, depending on the price. If an attack is happening against the network, there will be many players who will be happy to pay, temporally, a higher price, for more hashing power. Meaning that the old miners will be dusted off, and switched on… probably automatically via auctions for hashing power.
There still seems to be quite some confusion about some of the potential attacks to a bitcoin network where the vast majority of the hashing power is only used when an attack is detected.
To add some clarity, I’ll go through each attack independently.
Double Spending Attack
The ideal double spending attack involves:
1. Making a transaction for another ‘hard’ asset; such as physical face-to-face transfer of cash.
2. As soon as this transaction is complete, secretly mine a chain that spends the above coins to a different address.
3. Once well-ahead of the publicly known chain, attack release the hidden chain and the network reorganises onto the more-ahead chain.
Now this attack seems pretty fool-proof, until you do the numbers. If (for whatever reason, I’ll come to that later), the bitcoin network wants to quickly orphan the offending chain, it will do so.
Say that the attacker has 2x the base-load of the network, and waits for 6 blocks of the public chain before releasing. This means that the attacker (on average) will have a 6-block lead against the rest of the network.
When this attacking chain is released, let’s say 100x the base load hashing power is used to orphan the chain. When the attacker has completed block number 13, the other chain has just completed 50 blocks, and now has a 43 block lead. This completely orphans the attacker’s chain.
Effects:
When quite a few attackers have ‘attempted’ to double spend, then quickly get squashed in the 1st or 2nd block after they release their chain, this will naturally ‘raze the barrier’ to attack while no significant continuous hashing resources are being spent. Attackers don’t attack ‘just for fun,’ but they attack to win. If the attacker wants to double spend, and win; they and the network holds 100x hashing resources to defend an attack. Any-individual attacker must also have 100x the hashing power to win. (Of course they get a very trivial head-start, by starting the attack in private).
This will make attacks on the network rare.
Supply Blocking attack
(Please note, that this attack must be externally funded to the bitcoin economy, as an internal malicious attacker would never be able to recoup the resources used to conduct this attack from the bitcoin economy itself).
This attack involves having more than 51% of the hashing power of the network, and orphaning any block that doesn’t agree with the attackers goals. (Be it to kill bitcoin, or force high transaction fees, or regulate bitcoin in some way).
One would do this now by:
1. Judge how much hashing power there is on the network
2. Halve that number, and put a bit more on for margin of error
3. Turn on this hashing power, and orphan any block that doesn’t agree with your rules.
This attack is quite simple to do with the current network. Also you can be virtually confident that your attack will success if the attacker gathers more than 75% of the current hashing power.
With dynamic hashing power, the base-load hashing power becomes irrelevant; the ‘maximum, sustainable’ hashing power becomes the important metric.
The attacker must ‘guess’ what amount of the dynamic hashing load is sustainable, by the network, gaining much more hashing power than this for a safety margin. This brings both up the uncertainly of the attack, and the cost.
However, the network will not just say, ‘I’m getting tired now.’ It will become a big game of bluff. If the attackers chain is orphaned by the network by a significant margin (say more than 2000 blocks), then the network may automatically ‘cement’ into the new chain.
Overall… The same security issues with this externally funded attack remain for either a static hashing load or a dynamic hashing load. However the dynamic hashing load makes the uncertainties in attacking the network much higher as well as not wasting as much electricity when there is no attack happening.
To add some clarity, I’ll go through each attack independently.
Double Spending Attack
The ideal double spending attack involves:
1. Making a transaction for another ‘hard’ asset; such as physical face-to-face transfer of cash.
2. As soon as this transaction is complete, secretly mine a chain that spends the above coins to a different address.
3. Once well-ahead of the publicly known chain, attack release the hidden chain and the network reorganises onto the more-ahead chain.
Now this attack seems pretty fool-proof, until you do the numbers. If (for whatever reason, I’ll come to that later), the bitcoin network wants to quickly orphan the offending chain, it will do so.
Say that the attacker has 2x the base-load of the network, and waits for 6 blocks of the public chain before releasing. This means that the attacker (on average) will have a 6-block lead against the rest of the network.
When this attacking chain is released, let’s say 100x the base load hashing power is used to orphan the chain. When the attacker has completed block number 13, the other chain has just completed 50 blocks, and now has a 43 block lead. This completely orphans the attacker’s chain.
Effects:
When quite a few attackers have ‘attempted’ to double spend, then quickly get squashed in the 1st or 2nd block after they release their chain, this will naturally ‘raze the barrier’ to attack while no significant continuous hashing resources are being spent. Attackers don’t attack ‘just for fun,’ but they attack to win. If the attacker wants to double spend, and win; they and the network holds 100x hashing resources to defend an attack. Any-individual attacker must also have 100x the hashing power to win. (Of course they get a very trivial head-start, by starting the attack in private).
This will make attacks on the network rare.
Supply Blocking attack
(Please note, that this attack must be externally funded to the bitcoin economy, as an internal malicious attacker would never be able to recoup the resources used to conduct this attack from the bitcoin economy itself).
This attack involves having more than 51% of the hashing power of the network, and orphaning any block that doesn’t agree with the attackers goals. (Be it to kill bitcoin, or force high transaction fees, or regulate bitcoin in some way).
One would do this now by:
1. Judge how much hashing power there is on the network
2. Halve that number, and put a bit more on for margin of error
3. Turn on this hashing power, and orphan any block that doesn’t agree with your rules.
This attack is quite simple to do with the current network. Also you can be virtually confident that your attack will success if the attacker gathers more than 75% of the current hashing power.
With dynamic hashing power, the base-load hashing power becomes irrelevant; the ‘maximum, sustainable’ hashing power becomes the important metric.
The attacker must ‘guess’ what amount of the dynamic hashing load is sustainable, by the network, gaining much more hashing power than this for a safety margin. This brings both up the uncertainly of the attack, and the cost.
However, the network will not just say, ‘I’m getting tired now.’ It will become a big game of bluff. If the attackers chain is orphaned by the network by a significant margin (say more than 2000 blocks), then the network may automatically ‘cement’ into the new chain.
Overall… The same security issues with this externally funded attack remain for either a static hashing load or a dynamic hashing load. However the dynamic hashing load makes the uncertainties in attacking the network much higher as well as not wasting as much electricity when there is no attack happening.
Are there any consumer-electronics devices or at least "used in large numbers" devices using ASICs that are comparable in complexity to the ASIC offering that currently costs $30,000?
Also, what about once ASIC devices not as large as those come out, how much for a little thing that only uses one ASIC chip and maybe is about the size of a IDE hard drive or a walkman?
How much does a cash-register cost? I recall monocrome computer-terminals being widely sold for $4500 or so (Canadian) once upon a time (aka when CAD was worth a lot more probably than it is now), maybe cash-registers cost quite a bit even now? (I wonder because maybe putting a mining ASIC in every cash register might not actually look all that crazy in a decade or two or maybe even less than a decade... just a few years?)
(Remember when "numeric co-processors" were crazy-expensive rare cutting-edge items? How much are they now? Oh wait, are they on-chip with the CPU already?)
-MarkM-
Also, what about once ASIC devices not as large as those come out, how much for a little thing that only uses one ASIC chip and maybe is about the size of a IDE hard drive or a walkman?
How much does a cash-register cost? I recall monocrome computer-terminals being widely sold for $4500 or so (Canadian) once upon a time (aka when CAD was worth a lot more probably than it is now), maybe cash-registers cost quite a bit even now? (I wonder because maybe putting a mining ASIC in every cash register might not actually look all that crazy in a decade or two or maybe even less than a decade... just a few years?)
(Remember when "numeric co-processors" were crazy-expensive rare cutting-edge items? How much are they now? Oh wait, are they on-chip with the CPU already?)
-MarkM-
Electricity is the major cost of a long-term mining operation.
This is true for GPU:s but not for FPGA:s. The more energy efficient devices we see, the less true it will be.
I personally expect an explosion in hashing power as more fpga and butterfly like units come online. Who won't want to hedge the USD against a nice small form unit plugged into their PC at the side of their desk?
This will be very good for Bitcoin.
Electricity is the major cost of a long-term mining operation.
This is true for GPU:s but not for FPGA:s. The more energy efficient devices we see, the less true it will be.
i think this whole argument is upside down.
insurance only exists to protect against an unlikely event. your whole argument is that this is a likely event. insurance companies are extremely risk averse and like to deal with risks that are highly measurable and not likely to occur.
this is a highly unmeasurable proposal in that how is one supposed to measure this hidden reserve hashing rate that is kept offline in case of an attack? even if you could measure it then everyone would know as would the attacker. then we're back to square one which is that the attacker would know precisely how much hashing rate to bring online to ensure success of the attack.
what is to prevent cheating via one insurance company bringing online a small amount of its hashing rate to scoop up whatever tx fees exist in the ongoing verification process?
this also is a form of centralization in that you discourage all smaller players from plugging in their new Butterfly's b/c you've artificially suppressed the tx fees and i would argue that we want lots of newbies plugging these units in to strengthen the network.
a visible open p2p large hashing rate as we have now seems to be working and acts as an effective deterrent.
the risk of a likely attack causing chaos and a systemic failure for a purposely weakened, stripped down hashing rate invites trouble. no insurance company would take this risk.
you might be thinking of starting an insurance business yourself and this might be why you think it will work; i don't know. but i don't think most ppl will buy in.
insurance only exists to protect against an unlikely event. your whole argument is that this is a likely event. insurance companies are extremely risk averse and like to deal with risks that are highly measurable and not likely to occur.
this is a highly unmeasurable proposal in that how is one supposed to measure this hidden reserve hashing rate that is kept offline in case of an attack? even if you could measure it then everyone would know as would the attacker. then we're back to square one which is that the attacker would know precisely how much hashing rate to bring online to ensure success of the attack.
what is to prevent cheating via one insurance company bringing online a small amount of its hashing rate to scoop up whatever tx fees exist in the ongoing verification process?
this also is a form of centralization in that you discourage all smaller players from plugging in their new Butterfly's b/c you've artificially suppressed the tx fees and i would argue that we want lots of newbies plugging these units in to strengthen the network.
a visible open p2p large hashing rate as we have now seems to be working and acts as an effective deterrent.
the risk of a likely attack causing chaos and a systemic failure for a purposely weakened, stripped down hashing rate invites trouble. no insurance company would take this risk.
you might be thinking of starting an insurance business yourself and this might be why you think it will work; i don't know. but i don't think most ppl will buy in.
The idea of a Bitcoin insurance to hash for the blockchain on-demand has its merits and was suggested before. The secret-hashing attack and the difficulty to prove that standby hashing power is really on standby make such a service somewhat non-trivial. In the long run I think it will be necessary to make some compromises regarding the detection of the valid chain. Requiring 51% of the earth's hashing power for the rest of time is neither feasible nor really necessary, given we can find and agree on some smart and reasonably secure mechanism to assign the "evil-bit" on the hashing power of an attacker.
We're currently all putting our trust in the majority of the hashing power, silently hoping it to be sufficiently distributed among different parties so that nothing bad will happen. Mining pools already make this assumption somewhat naive and as was pointed out, we're pretty much defenseless against determined attacks of wealthy adversaries.
I don't think this is a problem right now or in the foreseeable future because for the current market capitalization we have a more than sufficient hashrate. In the long run, relying only on pure hashrate is probably not the most cost-efficient and secure way to go for Bitcoin. There are already some other ideas (apart from an insurance service), like proof of stake or node reputation and I think it's good to get this discussion going now, long before we really need it. The final "solution" will probably be a combination of a few new rules for the Bitcoin clients and maybe even some specialized nodes (which might be required for scalability reasons anyway). I am confident that we will end up with a more secure Bitcoin network that is still decentralized enough for people to trust it.
TL;DR: relying on hashing power alone for the security of Bitcoin is probably not the best long-term strategy
We're currently all putting our trust in the majority of the hashing power, silently hoping it to be sufficiently distributed among different parties so that nothing bad will happen. Mining pools already make this assumption somewhat naive and as was pointed out, we're pretty much defenseless against determined attacks of wealthy adversaries.
I don't think this is a problem right now or in the foreseeable future because for the current market capitalization we have a more than sufficient hashrate. In the long run, relying only on pure hashrate is probably not the most cost-efficient and secure way to go for Bitcoin. There are already some other ideas (apart from an insurance service), like proof of stake or node reputation and I think it's good to get this discussion going now, long before we really need it. The final "solution" will probably be a combination of a few new rules for the Bitcoin clients and maybe even some specialized nodes (which might be required for scalability reasons anyway). I am confident that we will end up with a more secure Bitcoin network that is still decentralized enough for people to trust it.
TL;DR: relying on hashing power alone for the security of Bitcoin is probably not the best long-term strategy
you yourself said that an insurance company would look out for its own customers to reverse any tx's that had been manipulated. well if i'm not that insurance company but a competitor i'll just stand back and let you take care of it at your expense and not expend my resources in defending your client. can you imagine the havoc and confusion that would take if multiple tx's from diff insurances companies get changed?
If only one insurance companies transactions get reversed... Then id expect only that company to pay for orphaning the attacking chain.
If more than one companies transactions are getting reversed, then they all have a vested intrest to work together in orphaning the offending chain. If one company didn't join in to help; that company would in the future receive less corporation. As well as loosing public reputation.
you said a one time investment. hah, hardware is changing all the time and this is valuable resources sitting on the sideline doing nothing. in the current system at least you can amortize its costs over a given amount of time and hopefully make some money off it.
Electricity is the major cost of a long-term mining operation.
Yes, the hardware is changing rapidly now... However bitcoin is new. Doing many many Sha256 sums isn't a problem that has been important to do, like it is now.
In 20 or 40 years when the block reward is much much lower... I would expect there would be a huge number of miners who would have already paid off there equipment, but don't mine, as it isn't profitable.
An insurance company could make an application that automaticaly buys hashing power at the cheapest market rate, when it needs it. When there is an attack,the insurance company could be willing to buy much more hashing than when there is no attack.
Yes. Cementing has a risk.
However the risk is inversely proportional to the number of blocks you go back.
There are two 'in particular' attacks here.
1. Segmenting a particular client from the rest of the bitcoin network.
2. Trusting 'someone' to declare blocks 'evil'.
The first attack is mitigated by having a basic connection web-of-trust. Where a client displays a warning when it hasn't got any messages from known good nodes. This only defends against only being connected to an attacker. It didn't centralize the core part of bitcoin. It just makes a network re-org much harder to make without being completely seceret.
You don't need to have an "evil bit". You can detect a reorganization chain as being malicious uner the following conditions:
Is more than 100 blocks long.
Contains double spending transactions, when compared with the previously accepted chain.
Unspends transactions that were in the previous chain for more than 6 blocks.
However the risk is inversely proportional to the number of blocks you go back.
There are two 'in particular' attacks here.
1. Segmenting a particular client from the rest of the bitcoin network.
2. Trusting 'someone' to declare blocks 'evil'.
The first attack is mitigated by having a basic connection web-of-trust. Where a client displays a warning when it hasn't got any messages from known good nodes. This only defends against only being connected to an attacker. It didn't centralize the core part of bitcoin. It just makes a network re-org much harder to make without being completely seceret.
You don't need to have an "evil bit". You can detect a reorganization chain as being malicious uner the following conditions:
Is more than 100 blocks long.
Contains double spending transactions, when compared with the previously accepted chain.
Unspends transactions that were in the previous chain for more than 6 blocks.
theres way too much hidden information in what you're proposing to allow it too work.
you yourself said that an insurance company would look out for its own customers to reverse any tx's that had been manipulated. well if i'm not that insurance company but a competitor i'll just stand back and let you take care of it at your expense and not expend my resources in defending your client. can you imagine the havoc and confusion that would take if multiple tx's from diff insurances companies get changed?
you said a one time investment. hah, hardware is changing all the time and this is valuable resources sitting on the sideline doing nothing. in the current system at least you can amortize its costs over a given amount of time and hopefully make some money off it.
your proposal is like starving yourself now to prevent from getting fat but in the meantime you'll never get strong.
you yourself said that an insurance company would look out for its own customers to reverse any tx's that had been manipulated. well if i'm not that insurance company but a competitor i'll just stand back and let you take care of it at your expense and not expend my resources in defending your client. can you imagine the havoc and confusion that would take if multiple tx's from diff insurances companies get changed?
you said a one time investment. hah, hardware is changing all the time and this is valuable resources sitting on the sideline doing nothing. in the current system at least you can amortize its costs over a given amount of time and hopefully make some money off it.
your proposal is like starving yourself now to prevent from getting fat but in the meantime you'll never get strong.
Perhaps your most important statement is the Difficulty != Security, which is true. Security derives from the cost of mounting an attack. If all miners today used FPGA boards and were much more efficient per Gh/s, then difficulty would be much higher... but if these FPGA boards are just as cheap as the GPU's which preceded them, then the cost of the attack hasn't increased and thus the higher difficulty is irrelevant.
This is completely banal. It's all about invariants. If the type and technology level of the hardware used is invariant, then the "difficulty" number very strongly correlates with security. If not, then of course the difficulty correlates more than anything with the hardware technology.I don't think it's banal. Many people probably assume that a difficulty twice as high equals a network twice as difficult to attack, and this is not true. Hardware is always variant, so it's important for people to realize this dynamic.
Jump to: