Bitcoin is not as advertised

[nelisky]

What I see as a feature is what some people see as a vulnerability : the fact that someone could make a longer block chain by overpowering the network in massive proportions, but that's very very very unlikely to happen.

Are you serious about this at all ?
Because no serious financial institution would ever use a currency with such "feature".

Currency must be stable by design. The more stable & predictable it is, the better. This is the exact reasons for hard-coded block chain locks in bitcoin client.

Unless, of course, you have lots of computing power at your disposal and are planning to use it to overpower the network... that being the case you would try to argue as best you could that the "feature" is really needed, and not really a vulnerability.

... oh, wait ...

[1714230210]

1714230210

[1714230210]

1714230210

[1714230210]

1714230210

[1714230210]

1714230210

[1714230210]

1714230210

[1714230210]

1714230210

[davout]

Why according to you?  I understand why it is there, and generally how it works, and you do not.

Ok sure, if you'd be kind enough to point out my misunderstandings. Oh silly me, you can't.

I could try, but others could do a better job on the details, but that is beside the point.  If you don't understand something, it is up to you to educate yourself.  It is not the responsibility of anyone else, and you have the authority to decide for only yourself.  I would say that the most common reason that no one has bothered to explain it to you thus far, is because those who do understand it get tired of trying to explain things to forum members with 'newbie' next to their name.  Go search the archives if you can't find the answers that you seek. Only then, should that not help, do you politely ask the forum to explain the logic behind the current security features.

If you call me an ignorant i think it's up to you to point out what i misunderstood.
I'm not requesting that you explain stuff to me, just that you elaborate on your blunt and aggressive statement.
So please point out my mistakes but keep your politeness lessons to yourself and don't yell at someone who actually did read the archive yet disagrees with the design decisions that were made, and would like to share some thoughts about it.

So please do not feel like I'm asking you any sort of favor except for basic politeness when it comes to back the statements you abruptly make.

My problem is not with your concerns, but with the manner in which you present your concerns.

Again, if you feel offended by the way i voice things feel free, absolutely free to ignore me altogether.

The problem is that without proper security, somebody with mega-super-duper computing power could make a longer, fake chain, and Your app could accept it.

Someone with super duper computing power would simply generate coins to make a super duper profit

And bitcoin is all about the security, because (i think) it will get serious soon, and we want it to be seen as serious currency.

In my view bitcoin is also about complete independence from anything else than network consensus, the bigger the network, the stronger the security (and not the more hardcoded checkpoints, the better the security).

These concerns seem to miss the point that the genesis hash itself is hardcoded and that this is essential to the whole system (in contrast, the test network I believe uses a different genesis hash).  Locking in the block chain 1000+ blocks before the most current block is akin to simply extending the genesis hash; limiting the potential for an opponent with overwhelming computing power to massively alter transaction history.  All that follows after is classic p2p, as advertised. 

XC

I agree with you, it's obviously a minor concern about some implementation detail, I just think they are unneeded and could potentially create more problems in the future than they solve. Some people disgagree and thats fine as long as they elaborate =)

No block chain would ever be lost as long as at least a client holds it.

The clients will replace their chain by the longer. And if there is no hardcoded snapshot, the entire chain could be replaced.

I agree, but you'll have to admit that hardcoding the hash of any particular block is going to protect against that. Having a hash enables you to check some block in the chain, it doesn't address the problem you're talking about, chain lost, is lost whether you hardcoded some hash or not.

We definitely have a different understanding of requirements here, then. There's no way I can see the possibility of losing all past transactions as a "feature" for a monetary system. Imagine... All your money could get lost, and not only yours, everybody's money! That's a vulnerability, for sure. The fact that an absurdly enormous processing power is required for such attack is already a pretty good protection against it, but why not adding extra protection like hardcoded snapshots of the chain? It's like someone said, if done for old blocks, that's not a problem at all. It should not be done on recent blocks, of course.

Yea, I mostly agree, it's not a problem to hardcode a block hash from time to time, make sure someone doesn't generate a bogus chain from a bogus release etc. Now, making a policy to hardcode the state of the chain in *each* release is something different, of course it is an implementation detail that does no harm, nonetheless as you said the network is very very very secure the way it is and as a software developer i know that extra unneeded features sometimes bring more trouble than solutions.

Unless, of course, you have lots of computing power at your disposal and are planning to use it to overpower the network... that being the case you would try to argue as best you could that the "feature" is really needed, and not really a vulnerability.

If I had craploads of CPU I'd generate + collect tx fees my friend =).
I wouldn't try to break something as fascinating as bitcoin !

[ShadowOfHarbringer]

bitcoin is also about complete independence from anything else than network consensus

You completely missed the point. Hardcoded security checkpoints are part of the consensus.
Consensus is created & confirmed simply by people's usage of satoshi's client.

If we wouldn't like that consensus, we would find ourself a different, forked consensus.

If I had craploads of CPU I'd generate + collect tx fees my friend =).
I wouldn't try to break something as fascinating as bitcoin !

And i have no reason to trust & believe either you, or the topic starter.

[Bitquux]

Someone with super duper computing power would simply generate coins to make a super duper profit

Or brute force individual private keys.

[Anonymous]

If a bitcoin was sent 2 months ago and someone changes the block chain did a bitcoin actually exist?

 

[ByteCoin]

If a bitcoin was sent 2 months ago and someone changes the block chain did a bitcoin actually exist?

It is indeed a problem if spent coinbase transactions get "rolled back" as those coins are deemed never to have existed.

An attack based on an adversary with huge computing power rehashing a decent chunk of block chain to invalidate coinbase transactions that have been spent can be prevented or at least detected as follows:

When a hash of sufficient quality is found for a particular block, all the clients which have generated hashes for that block which are not quite good enough send those hashes to each other, signed by some per client key. Each client that receives this information can use it to get a good estimate of the total hashing power at a given time. If the hashing power falls abruptly to a small value then the client suspects that the network has fragmented and it's on a small fragment and new coins must not be spent. When the hash rate it sees ramps up again then it must compare the incoming near-miss client signatures with the ones it's used to seeing. If they're a lot different then an attack is in progress.
Similarly, clients that seem suddenly to find lots of blocks thereby rewriting the block chain, without previously finding even more lots of near misses must be under suspicion of misleading the other peers about the aggregate hashing power and attacking the scheme.
The block chain could be eligable for locking with no ill effects, a few blocks back from at any point where the current estimated hashing power is some fraction greater than half the max estimated hashing power ever seen.

The astute will notice that these suggestions are dual to "balance sheet" and "regular block creation" ideas.

ByteCoin

[ByteCoin]

I still would like to see tentative explain me how he could create a chain of 90,000 proofs of work with the same difficulties that are inside the current block chain, and then be faster than the current bitcoin network, so that he could always make sure his chain is longer than the bitcoin one.

You could always make a block chain in which all the blocks are generated on an easy difficulty. After a certain time the difficulty jumps up and you don't bother creating any blocks until it jumps down again whereupon you generate loads of blocks again. It still wouldn't be easy but to generate a longer block chain I don't think you'd have to do it at the same difficulties as the current one.

ByteCoin

[MoonShadow]

If a bitcoin was sent 2 months ago and someone changes the block chain did a bitcoin actually exist?

It is indeed a problem if spent coinbase transactions get "rolled back" as those coins are deemed never to have existed.

An attack based on an adversary with huge computing power rehashing a decent chunk of block chain to invalidate coinbase transactions that have been spent can be prevented or at least detected as follows:

When a hash of sufficient quality is found for a particular block, all the clients which have generated hashes for that block which are not quite good enough send those hashes to each other, signed by some per client key. Each client that receives this information can use it to get a good estimate of the total hashing power at a given time. If the hashing power falls abruptly to a small value then the client suspects that the network has fragmented and it's on a small fragment and new coins must not be spent. When the hash rate it sees ramps up again then it must compare the incoming near-miss client signatures with the ones it's used to seeing. If they're a lot different then an attack is in progress.

A similar fragmentation detection scheme was worked out a month or two ago.  The easiest way is to simply watch for an excessively long block interval.  Although one such interval is only suspicious, multiple intervals in a row that take 80% longer than the target increase the certainty of a network fragmentation, which could then either set off an alarm to notify the user of the risks or automaticly suspend trading in the case of automatic clients such as is used by the markets.  Another method is to selectively choose your peers, choosing peers who are representative of large sectors of the Internet that you are not; so that a lost connection could be taken as a sign of a possible fragmentation.  As far as I know, no one has been worried enough about it to write the watchdog code.

[MoonShadow]

I still would like to see tentative explain me how he could create a chain of 90,000 proofs of work with the same difficulties that are inside the current block chain, and then be faster than the current bitcoin network, so that he could always make sure his chain is longer than the bitcoin one.

You could always make a block chain in which all the blocks are generated on an easy difficulty. After a certain time the difficulty jumps up and you don't bother creating any blocks until it jumps down again whereupon you generate loads of blocks again. It still wouldn't be easy but to generate a longer block chain I don't think you'd have to do it at the same difficulties as the current one.

ByteCoin

The total proof-of-work of the blockchain is considered by the clients when deciding upon which chain is the "longest", so it's more complicated than the simple number of blocks solved since the genesis block.  Otherwise someone might be able to attack the blockchain by altering the target interval on a darknet and create a blockchain of greater block length with a much lower average difficulty.  Satoshi and crew have really vetted this one well.  This was one of my own misconceptions when I was new to this idea.

[MoonShadow]

Why according to you?  I understand why it is there, and generally how it works, and you do not.

Ok sure, if you'd be kind enough to point out my misunderstandings. Oh silly me, you can't.

I could try, but others could do a better job on the details, but that is beside the point.  If you don't understand something, it is up to you to educate yourself.  It is not the responsibility of anyone else, and you have the authority to decide for only yourself.  I would say that the most common reason that no one has bothered to explain it to you thus far, is because those who do understand it get tired of trying to explain things to forum members with 'newbie' next to their name.  Go search the archives if you can't find the answers that you seek. Only then, should that not help, do you politely ask the forum to explain the logic behind the current security features.

If you call me an ignorant i think it's up to you to point out what i misunderstood.
I'm not requesting that you explain stuff to me, just that you elaborate on your blunt and aggressive statement.

I wasn't calling you ignorant, I was going out of my way to avoid that implication.  I was calling you new to the idea, which is different.  Regardless, it is still not the responsibility of others to do anything on your behalf. 

Again, if you feel offended by the way i voice things feel free, absolutely free to ignore me altogether.

I was doing that, right up until you implied that according to you something was wrong and should be fixed according to you.  It is this arrogant statement that set me off.  Who died and made you the king of Bitcoin, to come in here and start demanding answers?  That is how you read to me.

[ByteCoin]

The total proof-of-work of the blockchain is considered by the clients when deciding upon which chain is the "longest", so it's more complicated than the simple number of blocks solved since the genesis block.  

Good catch. My mistake! I presume they sum the logs of the difficulties? Could someone point out or message me where this happens in the code please?

ByteCoin

[ByteCoin]

The easiest way is to simply watch for an excessively long block interval.  Although one such interval is only suspicious, multiple intervals in a row that take 80% longer than the target increase the certainty of a network fragmentation, which could then either set off an alarm to notify the user of the risks or automaticly suspend trading in the case of automatic clients such as is used by the markets. 

This doesn't prevent the scenario whereby someone isolates a client or group of clients by fragmenting the network or running lots of clients on different IPs and relying on luck  or crashing CUDA clients with a magic transaction and then jumping in with lots of CPU power to maintain a plausible block rate. I know it's a hard attack but my scheme prevents it, possibly at the cost of some privacy.

Another method is to selectively choose your peers, choosing peers who are representative of large sectors of the Internet that you are not; so that a lost connection could be taken as a sign of a possible fragmentation. 

Sounds horrible to try to code and then debug/test/prove correct.

As far as I know, no one has been worried enough about it to write the watchdog code.

Bigger problem fish to fry at the moment!

ByteCoin

[Anonymous]

hmmm we need a bitcoin watchdog...

[davout]

I was doing that, right up until you implied that according to you something was wrong and should be fixed according to you.  It is this arrogant statement that set me off.  Who died and made you the king of Bitcoin, to come in here and start demanding answers?  That is how you read to me.

I merely stated my opinion about a design decision that doesn't go much further than an implementation detail seeking the opinion of others.
I didn't say it needed to be fixed ASAP, if I did I would have submitted a patch altogether.

The same goes for example for the decision not to include the listtransactions method in the json api, I think it's a wrong decision, some people agree, but satoshi has the final say on what goes into his svn and what doesn't and that's fine with me, as we say around here "c'est le jeu ma pauvre lucette". If I really want listtransactions I compile a patched client, thanking people who actually got the patch together in the process.

The easiest way is to simply watch for an excessively long block interval.  Although one such interval is only suspicious, multiple intervals in a row that take 80% longer than the target increase the certainty of a network fragmentation, which could then either set off an alarm to notify the user of the risks or automaticly suspend trading in the case of automatic clients such as is used by the markets.

This doesn't prevent the scenario whereby someone isolates a client or group of clients by fragmenting the network or running lots of clients on different IPs and relying on luck  or crashing CUDA clients with a magic transaction and then jumping in with lots of CPU power to maintain a plausible block rate. I know it's a hard attack but my scheme prevents it, possibly at the cost of some privacy.

Wouldn't forcing standard clients to generate at 5% or 10% CPU be a big step towards security ?
Maybe that would help ditribute more evenly CPU power and thus rely in a more balanced way on different implementations of the client ?

[MoonShadow]

I was doing that, right up until you implied that according to you something was wrong and should be fixed according to you.  It is this arrogant statement that set me off.  Who died and made you the king of Bitcoin, to come in here and start demanding answers?  That is how you read to me.

I merely stated my opinion about a design decision that doesn't go much further than an implementation detail seeking the opinion of others.
 

That's not the way it sounded.  Lets start over.  Hi, I'm Creighto, is English your first language?

Wouldn't forcing standard clients to generate at 5% or 10% CPU be a big step towards security ?
Maybe that would help ditribute more evenly CPU power and thus rely in a more balanced way on different implementations of the client ?

I would think that having the option of a client that can truely 'nice' itself on demand would be a great thing, but I can't see how cutting down the contributions of the standard client to less than a tenth of it's current abilities can do anything positive for the security of the system.  It would give those with the ability to remove the governing code a huge generation advantage, however.

The total proof-of-work of the network is a major factor in it's overal security, equitable distribution of that proof-of-work is not so much an issue.  Intentionally limiting that proof-of-work is counter productive, IMHO.

[MoonShadow]

The easiest way is to simply watch for an excessively long block interval.  Although one such interval is only suspicious, multiple intervals in a row that take 80% longer than the target increase the certainty of a network fragmentation, which could then either set off an alarm to notify the user of the risks or automaticly suspend trading in the case of automatic clients such as is used by the markets.

This doesn't prevent the scenario whereby someone isolates a client or group of clients by fragmenting the network or running lots of clients on different IPs and relying on luck  or crashing CUDA clients with a magic transaction and then jumping in with lots of CPU power to maintain a plausible block rate. I know it's a hard attack but my scheme prevents it, possibly at the cost of some privacy.

A very hard attack, one that depends on the attackers' ability to jump in and maintain a plausible block rate.  If the attacker has that much computional ability, there are more plausible attack vectors.  This may be an issue, I don't know.

Another method is to selectively choose your peers, choosing peers who are representative of large sectors of the Internet that you are not; so that a lost connection could be taken as a sign of a possible fragmentation.

Sounds horrible to try to code and then debug/test/prove correct.

Probably so, I'm not a code monkey so I can't say.  The block interval watchdog code should be relatively simple, however.  I understand that the simple nature of the watchdog code makes it imperfect, but it's something.

[wscott]

OK.  Sorry I am too lazy to read all the replies to this thread to see if someone else has already said this...

I can see how to exploit the current client if the checkpoints where not in the code.

You just start from one of the first blocks and create a new block history from that point forward where the difficulty never increases and all generated coins go to yourself.  Since you will always be using the original difficulty, it wouldn't be too hard to construct a machine that could recreate all that history.  Then when your chain is longer than the current chain the clients would all have to accept your chain as authoritative.

The checkpoints prevent this.   But still, I can start at the last checkpoint and recontruct a history where the difficulty drops at the maximum rate until I can start producing blocks faster than the mainline chain and catch up.  All I have to do is fool the oldest clients in active use.

Hopefully I am wrong, or perhaps the "longest chain" takes into account difficultly.

[wscott]

Before people have too much fun tearing apart my post, allow me to do it. 

"The 'length' of the entire block chain refers to the chain with the most combined difficulty, not the one with the most blocks. "

That kills most of my approach.   But I still think some like what I posted is what the OP had in mind.

[Anonymous]

I had some thoughts about this.

It is my observation that the current block chain has a "reputation". The combined transaction history and proof of work give it a unique identity similar to DNA or fingerprints. Everyone who uses bitcoin will therefore have exactly the same block chain and you should be able to check it somehow.

If paypal started its own chain it would have a different DNA as would one started by microsoft or the governement. There is nothing wrong with someone starting a competing currency,in fact that is the beauty of open source and bitcoin - voluntary association of individuals. The issue is how do you know the block chain you have on your computer is the same as the one you have trusted in the past ?

We need a tool that allows you to monitor your blockchain which compares it with everyone elses . You should be able to blacklist blockchains you dont want to deal with. The client does not check for trust it only checks that the block chain has the longest proof of work so how are you going to know an untrusted entity has replaced the blockchain you trust with its own ? The network would automatically replace your trusted blockchain with an attack one and you would have no way to choose because it is the way things work.

The blockchain is essentially one big file. It could be signed by trusted sites or users somehow.  You can then compare your chain with the trust network. This means a separate network would monitor the chain . An attacker would then have to replace not only the trusted block chain but all the nodes that monitor the trust of the block chain. This means one person or group is not certifying the correct block chain but it becomes as distributed as possible. Anyone should be able to use the software that can confirm their block chain is the one they choose to associate with. This allows for the community to ostracise blockchains that might be malicious. It also lets you say "this is a bitcoin" "this is a govcoin" "this is a microsoftcoin" etc....

The way things are now you could theoretically be taken over by an entity with massive computational resources creating the largest proof of work blockchain and this means "might is right". Thats not fair or free market but attracts the biggest "cpu bully" to control things. I simply want the ability to choose - which has not been the case with the current central bank system. I know this is only a theoretical possibility and as the network grows the chance of it happening recedes...but the stakes are high and we all know the control freaks want to impose their way of doing things on everyone. If there is a way for them to do so it should be removed or assuaged.

[ShadowOfHarbringer]

The way things are now you could theoretically be taken over by an entity with massive computational resources creating the largest proof of work blockchain and this means "might is right".

Weird. Even with the locks in source code ?
I thought we were talking that the "checkpoints" in source make that kind of attack impossible.

Thats not fair or free market but attracts the biggest "cpu bully" to control things. I simply want the ability to choose - which has not been the case with the current central bank system. I know this is only a theoretical possibility and as the network grows the chance of it happening recedes...but the stakes are high and we all know the control freaks want to impose their way of doing things on everyone. If there is a way for them to do so it should be removed or assuaged.

You already have an ability to choose: You can write/fork Your own client, which will use a different chain. It is a little complicated, but choice exists.
But adding an option to select different chain from official one.... that would only create unnecessary mess and perhaps even panic on the markets.

I think we want bitcoin to be stable before all else, so if somebody wants to use different chain or different network, perhaps simply a forked client should be made for that.