Bitcoin is not as advertised

[Bitquux]

Also, no one actually answered as to why there was a block chain lockdown hardcoded, it doesn't solve anything, not even CPU overpowering attack on the network.

I guess this would be the official answer:
http://bitcointalk.org/index.php?topic=437.0

[1714211443]

1714211443

[1714211443]

1714211443

[1714211443]

1714211443

[1714211443]

1714211443

[1714211443]

1714211443

[davout]

Also, no one actually answered as to why there was a block chain lockdown hardcoded, it doesn't solve anything, not even CPU overpowering attack on the network.

I guess this would be the official answer:
http://bitcointalk.org/index.php?topic=437.0

thank you,
i still disagree with it tho

[caveden]

Also, no one actually answered as to why there was a block chain lockdown hardcoded, it doesn't solve anything, not even CPU overpowering attack on the network.

It does prevent someone with super-duper-computer-power to replace the entire chain with a new one... why not do it?

And I suppose they had a good reason to do so... in the particular case, there was an invalid chain with an invalid transaction that needed to be ignored, even if it was bigger than the correct chain.

[davout]

Also, no one actually answered as to why there was a block chain lockdown hardcoded, it doesn't solve anything, not even CPU overpowering attack on the network.

It does prevent someone with super-duper-computer-power to replace the entire chain with a new one... why not do it?

That's a feature.
Also bitcoin advertises there is no central authority, and that's obviously untrue, this code should either be dropped or its effects should be stated clearly in the docs according to me.

And I suppose they had a good reason to do so... in the particular case, there was an invalid chain with an invalid transaction that needed to be ignored, even if it was bigger than the correct chain.

Yes, absolutely. In some very rare exceptions a check for a particular block should be hardcoded.
However, it should be the exception, and not the norm as satoshi stated in some previous thread that's referenced a little higher.

The protocol is safe without it, it is thus unneeded and should be removed since no one should claim authority about whether some particular block chain is valid or not.
Longest, hardest to compute wins.

Therefore I completely agree with the thread title. The client, or the way it is advertised should be changed to reflect that.

People suggesting to submit a patch are silly, if it reverts some of satoshi's code he'll never accept it.
People suggesting to fork should be slightly more patient

[MoonShadow]

Also, no one actually answered as to why there was a block chain lockdown hardcoded, it doesn't solve anything, not even CPU overpowering attack on the network.

It does prevent someone with super-duper-computer-power to replace the entire chain with a new one... why not do it?

That's a feature.
Also bitcoin advertises there is no central authority, and that's obviously untrue, this code should either be dropped or its effects should be stated clearly in the docs according to me.

 

Why according to you?  I understand why it is there, and generally how it works, and you do not.  Your approval is not neccessary, and it's not our concern if you use Bitcoin or not.  If you don't trust it, don't use it.  No one is going to attempt to convince you otherwise.

And although Bitcoin is safe enough without the blockchain benchmark, it's safer still with it.  And the blockchain benchmark doesn't constitute a central authority.  It is only an extension of the authority that we users entrust to the developers when we download and upgrade their code.  You can change it, or remove the blockchain benchmark altogether, and release a client without said code.  If others agree with your concerns and your fix, then they will download your version; and the will of the developers would be irrelevent.  For that matter, you could change the code so that the total number of bitcoins never stops, but you would still have to convince the majority of users that your version is better.  I think that unlikely.

[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.

If you don't trust it, don't use it.  No one is going to attempt to convince you otherwise.

If I didn't trust the blockchain I wouldn't be here.
Also, feel free to ignore me.

And the blockchain benchmark doesn't constitute a central authority.  It is only an extension of the authority that we users entrust to the developers when we download and upgrade their code.

So, what happens if they go rogue ? (protip: satoshi is a human being)
If the SVN repo gets hacked ?

You can change it, or remove the blockchain benchmark altogether, and release a client without said code. If others agree with your concerns and your fix, then they will download your version; and the will of the developers would be irrelevent.
For that matter, you could change the code so that the total number of bitcoins never stops, but you would still have to convince the majority of users that your version is better.  I think that unlikely.

Yep, that's called open source, and I happen to like it a lot, just as I think voicing concerns about potential problems is part of it.

[Bitquux]

So, what happens if they go rogue ? (protip: satoshi is a human being)
If the SVN repo gets hacked ?

I'm guessing the attacker would go for something easier and less correctable than replacing the locked-in block chain with a custom one.

[Gavin Andresen]

So, what happens if they go rogue ? (protip: satoshi is a human being)
If the SVN repo gets hacked ?

If Satoshi goes rogue, then the project forks.  He has a very strong incentive (success of the project, growth of the value of the bitcoins he owns) not to do that.

If the SVN repo gets hacked, then we back out the hacked changes (that's easy to see; several of us look at every svn commit) and warn people who might have compiled with bad source to recompile.

I'm having trouble figuring out exactly what you would like to happen-- is your complaint that you have a different definition of what "open source, peer-to-peer" means than the rest of us?

[FreeMoney]

That's a feature.
Also bitcoin advertises there is no central authority, and that's obviously untrue, this code should either be dropped or its effects should be stated clearly in the docs according to me.

The point is that you can change it. We currently choose to run the official software, we won't if it becomes a problem. That's not central control, it's just people making the rational choice at the moment. If the situation changes we can choose a different implementation.

Locking in the chain 1000 blocks back doesn't seem important to me at all. If the most used client starts locking in every 3 blocks, then I'm out.

This thread is just making a huge deal about a temporary, easily changed, unnecessary to change issue. Write or pay for a client that doesn't lock in the chain at 76000 or whatever and you'll operate the exact same way, tada, "problem" solved.

[davout]

I'm having trouble figuring out exactly what you would like to happen-- is your complaint that you have a different definition of what "open source, peer-to-peer" means than the rest of us?

I'm not complaining, just pointing out something that doesn't really seem consistent to me. [advertising that the longest blockchain wins VS stating hardcoded checkpoints will be added at *each* release]

If a block got hardcoded from time to time to avoid some bug then I agree it is a good thing. I don't really agree with the fact it should be a policy to hardcode blocks at each new release, and by doing so, endorsing an *official* block chain.

And yes I know, I can fork the project, make my own client... no worries, i can svn co, up from time to time, keep a couple of patches around and compile my own stuff, that's not really my point, my point is simply to get people's opinions on what they feel is right. Because, even if what tentations statements seem really exaggerated to me, I still think he raises an interesting question and I thank people that actually tried to be constructive and didn't suggest I didn't have a clue about what I was talking about without backing their statements

And yes, the SVN example was really bad =)

[caveden]

It does prevent someone with super-duper-computer-power to replace the entire chain with a new one... why not do it?

That's a feature.
Also bitcoin advertises there is no central authority, and that's obviously untrue, this code should either be dropped or its effects should be stated clearly in the docs according to me.

You say that the (minuscule) possibility of all transactions done since the very beginning of bitcoins being completely lost is a feature? Dude, that would be a catastrophe! It better never happen!

It seems you don't get why there is this "larger chain wins" rule. As far as I know at least, this rule only exists to solve "chain splits" as quick as possible.
Suppose node A produces a new block practically at the same time node B does the same. Some nodes receive block A, others receive block B. We have now two different chains, A and B. That's bad, we should have just one. So, to solve it, we assume that the first chain to get bigger first will replace the other. So if sub-network A produces a block before sub-network B, all nodes in B will ignore their chain and accept the larger one from A.

That's the only reason I see this rule to exist. Somebody correct me if I'm wrong, but as far as I understand, this rule was not create to explicitly allow someone with super-computer-power to rewrite the entire block chain.

[davout]

It does prevent someone with super-duper-computer-power to replace the entire chain with a new one... why not do it?

That's a feature.
Also bitcoin advertises there is no central authority, and that's obviously untrue, this code should either be dropped or its effects should be stated clearly in the docs according to me.

You say that the (minuscule) possibility of all transactions done since the very beginning of bitcoins being completely lost is a feature? Dude, that would be a catastrophe! It better never happen!

It seems you don't get why there is this "larger chain wins" rule. As far as I know at least, this rule only exists to solve "chain splits" as quick as possible.
Suppose node A produces a new block practically at the same time node B does the same. Some nodes receive block A, others receive block B. We have now two different chains, A and B. That's bad, we should have just one. So, to solve it, we assume that the first chain to get bigger first will replace the other. So if sub-network A produces a block before sub-network B, all nodes in B will ignore their chain and accept the larger one from A.

That's the only reason I see this rule to exist. Somebody correct me if I'm wrong, but as far as I understand, this rule was not create to explicitly allow someone with super-computer-power to rewrite the entire block chain.

No block chain would ever be lost as long as at least a client holds it.
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.

And also I think you're mostly wrong about the reason for the longest-blockchain-wins rule. This rule means that the blockchain that required the most expensive proof of work wins. In other words, you can get the network to accept a forged chain, if it's longer than the chain it currently sees as the "good" one. However, that would mean that it took more CPU power than the whole network to generate and therefore the more powerful the network is as a whole, the more  the likelihood of this happening decreases.

So no, this rule's justification is not to handle a marginal simultaneous generation case, but it's at the very core of the whole bitcoin concept.

That's my understanding of the reason for this rule.

[BitLex]

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

and how do you know for sure that its a *good chain* and not one of lots *a/b/c-sub-chains* that your connected to,
if the client you just downloaded doesnt have that *checkpoint-feature*?

[davout]

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

and how do you know for sure that its a *good chain* and not one of lots *a/b/c-sub-chains* that your connected to,
if the client you just downloaded doesnt have that *checkpoint-feature*?

Because it's peer-to-peer, you connect to multiple other nodes, each one of which will send you info about the chain they see as valid, your client picks the longest, simple and beautiful =)

[ShadowOfHarbringer]

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

and how do you know for sure that its a *good chain* and not one of lots *a/b/c-sub-chains* that your connected to,
if the client you just downloaded doesnt have that *checkpoint-feature*?

Because it's peer-to-peer, you connect to multiple other nodes, each one of which will send you info about the chain they see as valid, your client picks the longest, simple and beautiful =)

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.
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.

If you want, you can make your own client, and then hard-code some checkpoints for **your** own main chain in **your** client. Or not. Whatever.

[Bitquux]

Would it make any sense to build in a way to manually lock your own client to a chain or even schedule it at regular intervals?

[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.

And the blockchain benchmark doesn't constitute a central authority.  It is only an extension of the authority that we users entrust to the developers when we download and upgrade their code.

So, what happens if they go rogue ? (protip: satoshi is a human being)
If the SVN repo gets hacked ?

Most likely the same thing that would happen if any other such project were hacked or hijacked, the developer with the broken SVN/broken moral code would loose the trust they have earned in very short order, the majority would revert to earlier trusted code, and some other developer would advance more trustworthy code.

Much the same thing as what would happen should Satoshi die.

You can change it, or remove the blockchain benchmark altogether, and release a client without said code. If others agree with your concerns and your fix, then they will download your version; and the will of the developers would be irrelevent.
For that matter, you could change the code so that the total number of bitcoins never stops, but you would still have to convince the majority of users that your version is better.  I think that unlikely.

Yep, that's called open source, and I happen to like it a lot, just as I think voicing concerns about potential problems is part of it.

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

[xc]

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

[caveden]

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.

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.

And also I think you're mostly wrong about the reason for the longest-blockchain-wins rule. This rule means that the blockchain that required the most expensive proof of work wins. In other words, you can get the network to accept a forged chain, if it's longer than the chain it currently sees as the "good" one. However, that would mean that it took more CPU power than the whole network to generate and therefore the more powerful the network is as a whole, the more  the likelihood of this happening decreases.

So no, this rule's justification is not to handle a marginal simultaneous generation case, but it's at the very core of the whole bitcoin concept.

That's my understanding of the reason for this rule.

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.

[ShadowOfHarbringer]

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.