Bitcoin is not as advertised

[FreeMoney]

So this vulnerability is that we might all download a false chain checkpointed in with the next update?

[ShadowOfHarbringer]

Are you willing to bet your wallet on that?
Let's remove it then!

Clearly I am willing to bet my Bitcoin balance on the security of the system.

Feel free to make a different version with stupid rules. No one will use it.

And what if I make a different version with better rules?
Will you use it?

You are talking jibberish man.
If you can make a longer chain and break bitcoin, prove it.

[davout]

When the checkpoint lockin system was implemented (a while ago), everyone had the opportunity to check that the included hash was correct. If it was not, no one would have updated and the change would have been rejected. Satoshi proposed a change, the participants voted with their CPUs, and the change was passed.

Obviously few people checked. They trust Satoshi and the other members of the community enough to take them at their word.

The checkpoint system is only "insurance" against unknown attacks. There are no known attacks that are prevented only by the checkpoints. So you can safely remove it if you want.

This makes me really curious as to why it was implemented in the first place ?
The near impossibility of forging a longer chain of PoW makes the system secure in my understanding without the need to add random "insurance" checks.

The more code you have the more potential vulnerabilities, so why add code that is theoretically not necessary?

I think that tentative is basically implying he could break bitcoin without these checkpoints if I understand well.

[Timo Y]

The way I see it, there needs to be some sort of "official" or consensus set of parameters and rules that a block chain needs to obey.

Otherwise, if the only requirement for acceptance was chain length, someone could just arbitrarily change the rules, say, that 1000 coins are awarded instead of 50 every time a block is solved.

Right now, this "official" set of rules comes from satoshi, and you are quite right, if he changed the source code to his own personal advantage (and to the disadvantage of other users), he could probably manage to rip off a few people, simply because this is a very early stage in this project and most people automatically download from sourceforge as soon as a new version is realeased.

But that would be a one-off. People would no longer trust either satoshi or sourceforge, and some other consensus would soon emerge. After that, satoshi couldn't change the rules even if he wanted to.

[grondilu]

The way I see it, there needs to be some sort of "official" or consensus set of parameters and rules that a block chain needs to obey.

Otherwise, if the only requirement for acceptance was chain length, someone could just arbitrarily change the rules, say, that 1000 coins are awarded instead of 50 every time a block is solved.

Right now, this "official" set of rules comes from satoshi, and you are quite right, if he changed the source code to his own personal advantage (and to the disadvantage of other users), he could probably manage to rip off a few people, simply because this is a very early stage in this project and most people automatically download from sourceforge as soon as a new version is realeased.

But that would be a one-off. People would no longer trust either satoshi or sourceforge, and some other consensus would soon emerge. After that, satoshi couldn't change the rules even if he wanted to.

I think that's pretty much the same for any free software.  At some point, there is someone who is responsible from signing an official release, and people must have some confidence in this person.   I mean, everything that tentative is saying could be said about SSL, for instance.  And SSL is the root of current security on internet, isn't it ?  We could also say that about Linus Torwalds towards the linux kernel.  Maybe someday Linus will modify the kernel and put a troyan horse in it.  It would be a one shot scam, as everybody will soon find out and he won't be trusted anymore.  We will put our confidence in someone else.

[Anonymous]

When the checkpoint lockin system was implemented (a while ago), everyone had the opportunity to check that the included hash was correct. If it was not, no one would have updated and the change would have been rejected. Satoshi proposed a change, the participants voted with their CPUs, and the change was passed.

Obviously few people checked. They trust Satoshi and the other members of the community enough to take them at their word.

The checkpoint system is only "insurance" against unknown attacks. There are no known attacks that are prevented only by the checkpoints. So you can safely remove it if you want.

This makes me really curious as to why it was implemented in the first place ?
The near impossibility of forging a longer chain of PoW makes the system secure in my understanding without the need to add random "insurance" checks.

The more code you have the more potential vulnerabilities, so why add code that is theoretically not necessary?

I think that tentative is basically implying he could break bitcoin without these checkpoints if I understand well.

Its one thing to say these things its another to actually do it.

[tentative]

The way I see it, there needs to be some sort of "official" or consensus set of parameters and rules that a block chain needs to obey.

Otherwise, if the only requirement for acceptance was chain length, someone could just arbitrarily change the rules, say, that 1000 coins are awarded instead of 50 every time a block is solved.

Right now, this "official" set of rules comes from satoshi, and you are quite right, if he changed the source code to his own personal advantage (and to the disadvantage of other users), he could probably manage to rip off a few people, simply because this is a very early stage in this project and most people automatically download from sourceforge as soon as a new version is realeased.

But that would be a one-off. People would no longer trust either satoshi or sourceforge, and some other consensus would soon emerge. After that, satoshi couldn't change the rules even if he wanted to.

I think that's pretty much the same for any free software.  At some point, there is someone who is responsible from signing an official release, and people must have some confidence in this person.   I mean, everything that tentative is saying could be said about SSL, for instance.  And SSL is the root of current security on internet, isn't it ?  We could also say that about Linus Torwalds towards the linux kernel.  Maybe someday Linus will modify the kernel and put a troyan horse in it.  It would be a one shot scam, as everybody will soon find out and he won't be trusted anymore.  We will put our confidence in someone else.

Exactly.

All I'm saying is that with bitcoin, this has already happened.
Not as a scam, mind you.
I trust that it was an honest mistake.

I'm suggesting we reach "some other consensus", as you say,
and make bitcoin all it promises to be.

As soon as I have a few minutes I promise to post the details here.

[Anonymous]

The way I see it, there needs to be some sort of "official" or consensus set of parameters and rules that a block chain needs to obey.

Otherwise, if the only requirement for acceptance was chain length, someone could just arbitrarily change the rules, say, that 1000 coins are awarded instead of 50 every time a block is solved.

Right now, this "official" set of rules comes from satoshi, and you are quite right, if he changed the source code to his own personal advantage (and to the disadvantage of other users), he could probably manage to rip off a few people, simply because this is a very early stage in this project and most people automatically download from sourceforge as soon as a new version is realeased.

But that would be a one-off. People would no longer trust either satoshi or sourceforge, and some other consensus would soon emerge. After that, satoshi couldn't change the rules even if he wanted to.

I think that's pretty much the same for any free software.  At some point, there is someone who is responsible from signing an official release, and people must have some confidence in this person.   I mean, everything that tentative is saying could be said about SSL, for instance.  And SSL is the root of current security on internet, isn't it ?  We could also say that about Linus Torwalds towards the linux kernel.  Maybe someday Linus will modify the kernel and put a troyan horse in it.  It would be a one shot scam, as everybody will soon find out and he won't be trusted anymore.  We will put our confidence in someone else.

Exactly.

All I'm saying is that with bitcoin, this has already happened.
Not as a scam, mind you.
I trust that it was an honest mistake.

I'm suggesting we reach "some other consensus", as you say,
and make bitcoin all it promises to be.

As soon as I have a few minutes I promise to post the details here.

Thanks for that.

[ShadowOfHarbringer]

I'm suggesting we reach "some other consensus", as you say,
and make bitcoin all it promises to be.

As soon as I have a few minutes I promise to post the details here.

And why would be your "consensus" any better than the consensus we have now ?
I seriously doubt You are going to achieve anything here.

Also, i think You are either spreading FUD around to make BTC weaker or you are some kind of scammer. For the record, if you are looking for stupid people that can be easily influenced, You are not going to find many of them here.

If you have a suggestion how bitcoin could be made better, just join the bitcoin IRC or post a patch somewhere.
If you don't like bitcoin the way it is now, start a fork and encourage people to use Your version - that's really simple.

[Anonymous]

I'm suggesting we reach "some other consensus", as you say,
and make bitcoin all it promises to be.

As soon as I have a few minutes I promise to post the details here.

And why would be your "consensus" any better than the consensus we have now ?
I seriously doubt You are going to achieve anything here.

Also, i think You are either spreading FUD around to make BTC weaker or you are some kind of scammer. For the record, if you are looking for stupid people that can be easily influenced, You are not going to find many of them here.

If you have a suggestion how bitcoin could be made better, just join the bitcoin IRC or post a patch somewhere.
If you don't like bitcoin the way it is now, start a fork and encourage people to use Your version - that's really simple.

Id still like to encourage him to post what he has come up with. You dont want to scare away people who think there is a major issue.

[ribuck]

Id still like to encourage him to post what he has come up with.

Absolutely. Without that, it's just puffery.

I think he's referring to nothing more than the way that the standard client arbitrarily "locks in" a settled part of the block chain. I think his assertion is that, without this "lock in", there is some major potential vulnerability.

Even if that's the case, one could safely run a client that didn't have this "lock in". If the promised vulnerability did emerge, one could upgrade the client (after-the-event) to a modified version that re-established a valid block chain. I don't see how the risk in this scenario goes beyond the possibility of a double-spend in recent transactions.

[davout]

I think he's referring to nothing more than the way that the standard client arbitrarily "locks in" a settled part of the block chain. I think his assertion is that, without this "lock in", there is some major potential vulnerability.

I think so too, but as of now, nobody has come up with a valid and sensible answer about why parts of the blockchain are locked by the standard client.

The possible answers are :
 1. In order to prevent some possible unknown vulnerability
 2. In order to prevent some government to overtake bitcoin instantly
 2. In order to cover-up for some known but not published vulnerability of the protocol


Since, in my understanding, the protocol itself does not allow any other vulnerability than "beat me up with boatloads of CPU power" (which in my opinion is a feature, not a vulnerability) such an extra unneeded lock-up seems kindof suspicious.

So I'm still waiting for a sensible explanation; if the protocol is as secure as I think it is, the lock is not needed. If the protocol is not that secure, then some exploit needs to get published and the protocol fixed.

Either tentative is just trolling and trying to manipulate the market, or he needs to post some facts or outline of an exploit.

[ShadowOfHarbringer]

Since, in my understanding, the protocol itself does not allow any other vulnerability than "beat me up with boatloads of CPU power" (which in my opinion is a feature, not a vulnerability) such an extra unneeded lock-up seems kindof suspicious.

So I'm still waiting for a sensible explanation; if the protocol is as secure as I think it is, the lock is not needed. If the protocol is not that secure, then some exploit needs to get published and the protocol fixed.

Publishing an open source app with an exploit in source ?
That would be foolish. I don't think Satoshi is stupid. After all, he invented bitcoin.

Sooner or later somebody would find the exploit easily. A lot of hackers & programmers have invested their time in this code (and as people invest a lot of money in bitcoin, they will surely do full code review), so it is highly improbable that somebody wouldn't find the exploit by accident.

[tentative]

Id still like to encourage him to post what he has come up with.

Absolutely. Without that, it's just puffery.

I think he's referring to nothing more than the way that the standard client arbitrarily "locks in" a settled part of the block chain. I think his assertion is that, without this "lock in", there is some major potential vulnerability.

Even if that's the case, one could safely run a client that didn't have this "lock in". If the promised vulnerability did emerge, one could upgrade the client (after-the-event) to a modified version that re-established a valid block chain. I don't see how the risk in this scenario goes beyond the possibility of a double-spend in recent transactions.

Thanks, noag, but it's perfectly reasonable for people to be skeptical until they hear the details.

Yes, ribuck, you are correct, but you're missing my point.

My point is that the lock-in system eliminates the p2p aspect of bitcoin.

Let's say at some point the network gets split into 2 unconnected parts.
That causes some known issues of double spending and such,
but all these issues are supposed to be temporary.
They will be fixed once the parts get connected again.

But now let's say that during the period of separation satoshi decides on another lock-in point.
Let's say he's in the smaller part of the network, and has the shorter chain.
Now either a) the shorter chain permanently becomes the official one, which is biased towards satoshi's node,
or b) someone with the longer chain has to appeal to the central authority of sourceforge to fix this.

Of course the chances of every developer (who bothers to check) being in the smaller part are low.
But that still leaves us with a committee-managed system, not p2p.

One may argue (as some here have) that every open source is managed by the committee of involved developers.
But that should only be so for the design and implementation of the system, not for its entire operation!
For comparison, imagine the developers of bittorrent hardcoding into the client a blacklist of fake torrents.
What a disaster that would be.
(Not a perfect analogy, I know.)

Now I'm not urging you to drop the lock-in system,
because that would break the security of the clients.
I was trying to see if redesigning the system to be both p2p and secure (and many other things it should be but isn't)
is something that could catch on.
I think I've learned that people here are too invested in the current system to allow a better one to gain popularity.
Oh well, such is life.

[Anonymous]

I think he's referring to nothing more than the way that the standard client arbitrarily "locks in" a settled part of the block chain. I think his assertion is that, without this "lock in", there is some major potential vulnerability.

I think so too, but as of now, nobody has come up with a valid and sensible answer about why parts of the blockchain are locked by the standard client.

The possible answers are :
 1. In order to prevent some possible unknown vulnerability
 2. In order to prevent some government to overtake bitcoin instantly
 2. In order to cover-up for some known but not published vulnerability of the protocol


Since, in my understanding, the protocol itself does not allow any other vulnerability than "beat me up with boatloads of CPU power" (which in my opinion is a feature, not a vulnerability) such an extra unneeded lock-up seems kindof suspicious.

So I'm still waiting for a sensible explanation; if the protocol is as secure as I think it is, the lock is not needed. If the protocol is not that secure, then some exploit needs to get published and the protocol fixed.

Either tentative is just trolling and trying to manipulate the market, or he needs to post some facts or outline of an exploit.

Once the transaction history is already in place why would you need to change it unless you wanted to create an entirely new transaction history?

[Anonymous]

Id still like to encourage him to post what he has come up with.

Absolutely. Without that, it's just puffery.

I think he's referring to nothing more than the way that the standard client arbitrarily "locks in" a settled part of the block chain. I think his assertion is that, without this "lock in", there is some major potential vulnerability.

Even if that's the case, one could safely run a client that didn't have this "lock in". If the promised vulnerability did emerge, one could upgrade the client (after-the-event) to a modified version that re-established a valid block chain. I don't see how the risk in this scenario goes beyond the possibility of a double-spend in recent transactions.

Thanks, noag, but it's perfectly reasonable for people to be skeptical until they hear the details.

Yes, ribuck, you are correct, but you're missing my point.

My point is that the lock-in system eliminates the p2p aspect of bitcoin.

Let's say at some point the network gets split into 2 unconnected parts.
That causes some known issues of double spending and such,
but all these issues are supposed to be temporary.
They will be fixed once the parts get connected again.

But now let's say that during the period of separation satoshi decides on another lock-in point.
Let's say he's in the smaller part of the network, and has the shorter chain.
Now either a) the shorter chain permanently becomes the official one, which is biased towards satoshi's node,
or b) someone with the longer chain has to appeal to the central authority of sourceforge to fix this.

Of course the chances of every developer (who bothers to check) being in the smaller part are low.
But that still leaves us with a committee-managed system, not p2p.

One may argue (as some here have) that every open source is managed by the committee of involved developers.
But that should only be so for the design and implementation of the system, not for its entire operation!
For comparison, imagine the developers of bittorrent hardcoding into the client a blacklist of fake torrents.
What a disaster that would be.
(Not a perfect analogy, I know.)

Now I'm not urging you to drop the lock-in system,
because that would break the security of the clients.
I was trying to see if redesigning the system to be both p2p and secure (and many other things it should be but isn't)
is something that could catch on.
I think I've learned that people here are too invested in the current system to allow a better one to gain popularity.
Oh well, such is life.

The checks were put in place because there was a bug in an older version of the software and the majority switched to the updated version. If you have solutions for what you are saying lets hear them.


As long as the majority decide to change it doesnt matter what satoshi or anyone else does....but there needs to be a good reason to scrap what exists now.

[tentative]

The checks were put in place because there was a bug in an older version of the software and the majority switched to the updated version.

Will more checks be added periodically?

[Anonymous]

The checks were put in place because there was a bug in an older version of the software and the majority switched to the updated version.

Will more checks be added periodically?

Yes they will. That doesnt mean a better implementation couldnt be taken up by the majority . Theres nothing stopping anyone from creating a separate project and if people think its better they will use it.

[theymos]

I think so too, but as of now, nobody has come up with a valid and sensible answer about why parts of the blockchain are locked by the standard client.

The purpose is to prevent an attacker from replacing the entire chain, either due to "boatloads of CPU power" or an unknown bug. See:

The security safeguard makes it so even if someone does have more than 50% of the network's CPU power, they can't try to go back and redo the block chain before yesterday.  (if you have this update)

I'll probably put a checkpoint in each version from now on.  Once the software has settled what the widely accepted block chain is, there's no point in leaving open the unwanted non-zero possibility of revision months later.

But now let's say that during the period of separation satoshi decides on another lock-in point.

If the checkpoint is 1000+ blocks older than the current one, the chance of this happening is almost zero. No one could be stuck in a shorter chain for 1000 blocks without realizing it.

[ribuck]

... why parts of the blockchain are locked by the standard client.

The possible answers are :
 1. In order to prevent some possible unknown vulnerability ...

... in my understanding, the protocol itself does not allow any other vulnerability than "beat me up with boatloads of CPU power"

I think your "possible answer number 1" is the right one, but the vulnerability being protected against isn't in the protocol. The protection is against programming errors, to limit the disruption if a bug is discovered and exploited.

Satoshi added it in the immediate aftermath of the discovery of the overflow bug.