Bitcoin is not as advertised

[tentative]

Hi all,

Having studied Bitcoin in depth for a long time,
I've come to realize the following:

Bitcoin is not peer-to-peer.
The consensus block chain is determined more by the official node implementation than by the individual nodes.
If ever you stop updating your software to the latest version, you rapidly become vulnerable to attack. This will never change.
If you implement your own node, you have to choose between:
1. Agreeing to be dictated the "consensus" block chain by the official release.
2. Being vulnerable to attack

I'm willing to back these allegations with proof.
The question is, is anyone interested?

[1714252085]

1714252085

[1714252085]

1714252085

[1714252085]

1714252085

[1714252085]

1714252085

[grondilu]

Hi all,

Having studied Bitcoin in depth for a long time,
I've come to realize the following:

Bitcoin is not peer-to-peer.
The consensus block chain is determined more by the official node implementation than by the individual nodes.
If ever you stop updating your software to the latest version, you rapidly become vulnerable to attack. This will never change.
If you implement your own node, you have to choose between:
1. Agreeing to be dictated the "consensus" block chain by the official release.
2. Being vulnerable to attack

I'm willing to back these allegations with proof.
The question is, is anyone interested?

Behind the concept of "money", there is necessarly some kind of a "consensus".  The current block chain is accepted because it is the longest one in existence.

The software could easily be modified to accept an other block chain.  So if you can build a longer block chain, I will accept to buy some of your "coins" and I'd use a modified version of the software to do so.  But it would be extremely difficult for you to build such a chain, since it would require a huge amount of CPU.  You could not do this alone.  Nobody could.

[tentative]

Behind the concept of "money", there is necessarly some kind of a "consensus".  The current block chain is accepted because it is the longest one in existence.

If you can build a longer block chain, I will accept to buy it.  But it woudl be extremely difficult for you, since it would require a huge amount of CPU.

I understand what you say perfectly well.
You're mostly correct for the first part.
For the second part, you quote what's been advertised.
Unfortunately, it's false.

I can, in fact, generate a longer block chain.
If you have a recent official release, you will not accept it, because "they" dictate your block chain.
If you don't, I can attack you.

[bober182]

He could if he lowers the production of a block to 1000 an hour or some other higher value, and then increases the total amount of bitcoins to match. Keeping the ratio the same the amount of blocks. The blocks will go up but not the amount of coin % generated.

[grondilu]

I can, in fact, generate a longer block chain.

Please do so and thus prove us wrong.

[ShadowOfHarbringer]

you will not accept it, because "they" dictate your block chain.

I don't think You get the whole concept of open source properly.

In open source there is no "they", no entity that you could say "runs" the buisness.
Open source is governed by consensus of programmers, hackers, mathematicans & other geeky people involved in the project.

If one day satoshi says "ok guys, it was just a joke with this bitcoin thing, i'm closing down the project", then we (the hackers) would simply fork the code, move to another forum, and pick up where we left here. Bitcoin would stay as it was or in a little modified form.

There is no single mastermind in Open Source. It's more of a brain where a single human is just a cell. Also, bitcoin works as it works and has the block chain it has, because people involved with the project want it. If somebody doesn't like it, he can start his own project.

----
EDIT:
Also, if you don't like what we are doing with the bitcoin or block chain, then start your own fork of bitcoin. Nobody forbids it.

[tentative]

I can, in fact, generate a longer block chain.

Please do so and thus prove us wrong.

That's a healthy approach, but may I suggest a better one.

Allow me to save days of coding and weeks of number crunching by simply explaining what it is I could do.
I'd be glad to disclose this to the right audience at the right opportunity.

However, that's not the real issue here.
The issue is that there are multiple problems with the current design and implementation of bitcoin.
I can name at least 4 or 5 now.

I think we can fix this.
We can take bitcoin from the proof-of-concept stage to a real system that works.
What I'm trying to do here is find enough people who are interested in doing that.

[kiba]

I think we can fix this.
We can take bitcoin from the proof-of-concept stage to a real system that works.
What I'm trying to do here is find enough people who are interested in doing that.

It works well enough for me.

[Anonymous]

I can, in fact, generate a longer block chain.

Please do so and thus prove us wrong.

That's a healthy approach, but may I suggest a better one.

Allow me to save days of coding and weeks of number crunching by simply explaining what it is I could do.
I'd be glad to disclose this to the right audience at the right opportunity.

However, that's not the real issue here.
The issue is that there are multiple problems with the current design and implementation of bitcoin.
I can name at least 4 or 5 now.

I think we can fix this.
We can take bitcoin from the proof-of-concept stage to a real system that works.
What I'm trying to do here is find enough people who are interested in doing that.

irc://freenode/bitcoin-dev

Feel free to chat on the dev channel tentative. If you've found some kind of flaw or bug it would be great if you could let them know first.

[tentative]

you will not accept it, because "they" dictate your block chain.

I don't think You get the whole concept of open source properly.

In open source there is no "they", no entity that you could say "runs" the buisness.
Open source is governed by consensus of programmers, hackers, mathematicans & other geeky people involved in the project.

If one day satoshi says "ok guys, it was just a joke with this bitcoin thing, i'm closing down the project", then we (the hackers) would simply fork the code, move to another forum, and pick up where we left here. Bitcoin would stay as it was or in a little modified form.

There is no single mastermind in Open Source. It's more of a brain where a single human is just a cell. Also, bitcoin works as it works and has the block chain it has, because people involved with the project want it. If somebody doesn't like it, he can start his own project.

----
EDIT:
Also, if you don't like what we are doing with the bitcoin or block chain, then start your own fork of bitcoin. Nobody forbids it.

The "they" part was a bit tongue-in-cheek.
Sorry.

Yes, I know what open source is.
Just to prove that, I took the pain of navigating http://bitcoin.svn.sourceforge.net/viewvc/bitcoin/trunk/main.cpp?view=log
to find out that the code in question was indeed added by s_nakamoto.

This code prevents nodes from accepting a chain that is valid in every way and longest,
simply based on the fact that it's not the "official" chain.
Prior to that code being added, I guess the network was indeed vulnerable to the attack vector I found.
It will be once again, if ever the chain stops being dictated.
If you have forks that don't contain that code, you are vulnerable.

Finally, the reason I'm not just stepping in and fixing it myself is that the issues I found require more than just some patching.
We must redesign the whole thing from the ground up.

So do you think anyone here will be willing to do that?

[bober182]

I don't see what your arguing you said bitcoin is not peer 2 peer or p2p.

Peer-to-peer (P2P) computing or networking is a distributed application architecture that partitions tasks or work loads between peers. Peers are equally privileged, equipotent participants in the application. They are said to form a peer-to-peer network of nodes.

Peers make a portion of their resources, such as processing power, disk storage or network bandwidth, directly available to other network participants, without the need for central coordination by servers or stable hosts. Peers are both suppliers and consumers of resources, in contrast to the traditional client–server model where only servers supply, and clients consume.

Clearly it is your stating that someone controls what block chain is used and that is not true you choose the block chain you want. Each block chain is a market. If you choose an attacking chain like yours you a joining a market where you will lose bitcoins.

[davout]

I can, in fact, generate a longer block chain.
If you have a recent official release, you will not accept it, because "they" dictate your block chain.
If you don't, I can attack you.

I'm interested, now prove it, code is public, point out the lines, in my understanding the longest blockchain wins since it has the most expensive proof of work.

Allow me to save days of coding and weeks of number crunching by simply explaining what it is I could do.

Do it.

The issue is that there are multiple problems with the current design and implementation of bitcoin.
I can name at least 4 or 5 now.

Do it.

I think we can fix this.

Fix what ?

What I'm trying to do here is find enough people who are interested in doing that.

Why not, i bet lots of people would be interested in protecting their assets or be the first ones to start generating in a "fixed" bitcoin brand new blockchain.

Now facts please.

[tentative]

I don't see what your arguing you said bitcoin is not peer 2 peer or p2p.

Peer-to-peer (P2P) computing or networking is a distributed application architecture that partitions tasks or work loads between peers. Peers are equally privileged, equipotent participants in the application. They are said to form a peer-to-peer network of nodes.

Peers make a portion of their resources, such as processing power, disk storage or network bandwidth, directly available to other network participants, without the need for central coordination by servers or stable hosts. Peers are both suppliers and consumers of resources, in contrast to the traditional client–server model where only servers supply, and clients consume.

Clearly it is your stating that someone controls what block chain is used and that is not true you choose the block chain you want. Each block chain is a market. If you choose an attacking chain like yours you a joining a market where you will lose bitcoins.

Let's put it this way:

Suppose I change the code so that the only chain accepted is one in which I have all the money.
Then when the next version is release and everybody updates, the consensus is that I have all the money.
Would that be fair? Of course not.
I'm sure the other developers won't let that happen. They would revert my changes.

The point is that this is exactly what s_nakamoto did!
Well, except for the "have all the money" part...
I imagine he did this with the longest chain that was present on his node at some time.
And that makes his node unequally privileged and potent, to address your wikipedia-inspired definition.

[grondilu]

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.

[theymos]

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.

[tentative]

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.

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

[theymos]

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. There's no way to generate a longer chain without expending more CPU power than the current chain did, even without the checkpoints.

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

[tentative]

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?

[theymos]

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

I will if the changes are compatible with Bitcoin.

More importantly: I will not use versions of Bitcoin that have stupid rules.

[Anonymous]

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?

Only if the code is open completely. You havent explained anything clearly at all but are skirting around the issues. You still havent approached the devs on irc either. Unless you are merely using FUD to try and suppress prices on the market ....thats always a possibilty I suppose.

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

[ribuck]

... appeal to the central authority of sourceforge to fix this ...

If you think sourceforge can somehow function as a central authority rather than just being a software repository, then I know that I don't share your other concerns.

[davout]

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.

The linux kernel is made by lots of smart people, that didn't make it free from any vulnerabilities.

[tentative]

... appeal to the central authority of sourceforge to fix this ...

If you think sourceforge can somehow function as a central authority rather than just being a software repository, then I know that I don't share your other concerns.

I was speaking figuratively.

[ShadowOfHarbringer]

The linux kernel is made by lots of smart people, that didn't make it free from any vulnerabilities.

Of course, but these are accidental vulnerabilities.
I meant putting vulnerabilities on purpose. Vulnerabilities like this are usually easily detectable.

[Anonymous]

I dont see how this prevents anyone from creating a better implementation. Isnt that what open source is about?

[tentative]

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.

Let's say that the person or community controlling the official release are ever corrupted or make a mistake.
Let's say I have a legitimate longer chain than the one they plan to lock-in.

What do I do?
Who do I appeal to?
Do I report to the police? The blogosphere?
Who will take the effort to verify my claims?
What will be the consequences if I'm proven right?

[kiba]

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.

Let's say that the person or community controlling the official release are ever corrupted or make a mistake.
Let's say I have a legitimate longer chain than the one they plan to lock-in.

What do I do?
Who do I appeal to?
Do I report to the police? The blogosphere?
Who will take the effort to verify my claims?
What will be the consequences if I'm proven right?

Just release the god damn bug fix instead of sitting here?

[Anonymous]

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.

Let's say that the person or community controlling the official release are ever corrupted or make a mistake.
Let's say I have a legitimate longer chain than the one they plan to lock-in.

What do I do?
Who do I appeal to?
Do I report to the police? The blogosphere?
Who will take the effort to verify my claims?
What will be the consequences if I'm proven right?

Just release the god damn bug fix instead of sitting here?

lol there is no central control which freaks some people out. Welcome to the voluntary society.

[tentative]

lol there is no central control which freaks some people out. Welcome to the voluntary society.

I was probably a member of the open source community before you were born.
I'm not freaking out.
These are legitimate questions when you're dealing with a project controlling the equivalent of over .5M Euro and aspiring for billions.
A handful of active developers can be corrupted.
These dodging answers are not encouraging me to think that this hasn't already happened.

I was starting this investigation to decide whether to invest big money in bitcoin.
Fat chance.

[kiba]

lol there is no central control which freaks some people out. Welcome to the voluntary society.

I was probably a member of the open source community before you were born.
I'm not freaking out.
These are legitimate questions when you're dealing with a project controlling the equivalent of over .5M Euro and aspiring for billions.
A handful of active developers can be corrupted.
These dodging answers are not encouraging me to think that this hasn't already happened.

I was starting this investigation to decide whether to invest big money in bitcoin.
Fat chance.

If there are heavy corruption, you can make lot of money inventing a competing currency. Right now you're just spreading FUD.

[ribuck]

Let's say I have a legitimate longer chain than the one they plan to lock-in...

Who do I appeal to?

You could appeal to the developers who plan to lock in the other chain. If it's due to a bug or other mistake, they will naturally fix the problem. However, if it's due to evil intent, see your next question.

Do I report to the police? The blogosphere?

There's not (yet) a law relating to the lock-in of chains, so I doubt the police will be interested (or even understanding).

You can report the problem here, and you could report it to the blogosphere if you like.

Who will take the effort to verify my claims?

Anyone who shares your interest in a valid block chain will be motivated to make the effort, and those who are technically able to do so will be happy to look into your claims provided they are expressed in such a way that people are motivated to take them seriously.

It's in your interests to explain the problem clearly, and it's in other people's interests to take your report seriously (because their bitcoin balance depends on a valid block chain too).

What will be the consequences if I'm proven right?

Someone will release a version of the client software that works properly, which you and others will use. It's of no consequence to you if there are still some people who choose to use the "corrupt" version of Bitcoin, because you are free to use the version with the correct block chain.

I was starting this investigation to decide whether to invest big money in bitcoin. Fat chance.

No problem. We will welcome you back when you are ready.

I was probably a member of the open source community before you were born.

Then you'll understand how it works, and you'll understand why you don't report bugs to the police, and you'll understand that sourceforge is a tool and not a central authority.

[Timo Y]

I was starting this investigation to decide whether to invest big money in bitcoin.
Fat chance.

Good. More BTC for me then.  

On a more serious note, I wouldn't advise anyone to invest "big money" in bitcoin, even the modified version you propose.

*The security of bitcoin hasn't been thouroughly tested
*there hasn't been any peer review by cryptography/security experts
*critical mass hasn't been reached
*competition from other p2p cryptocurrencies
*the economy is still tiny (liquidation value of all BTC in existence is probably closer to 50,000 EUR than 500,000 EUR).
*danger of massive government crackdown
...

This project is in a very early stage and there are still many big hurdles to overcome.

For the time being, investing in Bitcoins should be seen as high risk investment or nothing more than a fun hobby.

[Anonymous]

lol there is no central control which freaks some people out. Welcome to the voluntary society.

I was probably a member of the open source community before you were born.
I'm not freaking out.
These are legitimate questions when you're dealing with a project controlling the equivalent of over .5M Euro and aspiring for billions.
A handful of active developers can be corrupted.
These dodging answers are not encouraging me to think that this hasn't already happened.

I was starting this investigation to decide whether to invest big money in bitcoin.
Fat chance.

Im not dodging anything. Im  not a developer so I told you where you can talk to the devs on irc. They can more easily answer your questions.

[ShadowOfHarbringer]

I was probably a member of the open source community before you were born.
I'm not freaking out.
These are legitimate questions when you're dealing with a project controlling the equivalent of over .5M Euro and aspiring for billions.
A handful of active developers can be corrupted.
These dodging answers are not encouraging me to think that this hasn't already happened.

I was starting this investigation to decide whether to invest big money in bitcoin.
Fat chance.

1. Because you are not asking correct questions, so You will never receive the answers You are seeking. Learn to articulate your wishes without spreading unnecessary FUD.

2. Most of us here are not BTC developers, just random geeks. If You have a serious question, then either:
a) Go ask the developers on IRC OR
b) Release a patch OR
c) Release a fork

3. You haven't even properly explained your stance in technical details, or proposed a patch. You expect serious answers without being serious Yourself.

[Cdecker]

I think the main problem is that currently we have a single client that can be used. This puts a lot of trust in the developers of this client. So what I think tentative is alluding to is the possibility that the developers may become greedy and release a modified version of the client that plays unfair and gives them a certain advantage. The problem with proving this is that users are not forced to update to the latest version if they do not trust the developers, in fact (except for bug fixes) people could run their current client endlessly, since the protocol itself seems to have solid foundations.

As soon as we have multiple implementations the trust that we have to put into the developers of any of those clients is reduced, but sincerely I don't see satoshi turn evil anytime soon

[grondilu]

As soon as we have multiple implementations the trust that we have to put into the developers of any of those clients is reduced,...

Any progress in that direction ?  I red somewhere that some people wanted to work on a Python implementation of the protocol.

[Gavin Andresen]

tentative: I don't get it.

You seem to be saying that somebody might be secretly working on a longer block chain, and all their hard work will be ruined because they won't be able to replace the block chain everybody else is using non-secretly because the block chain everybody else is using might get locked in.   Ummm... yeah!  Don't work on longer block chains in secret.

Either that, or you're saying Satoshi might accidently lock in a shorter block chain, and most people either not noticing or not caring.  Umm... no, I don't see that happening.

The block chain lock-in check is only done when new blocks are accepted.  Here is what would happen if Satoshi tried to commit a block lock-in that most of the network thought was shorter:

1. Imagine everybody downloads the new client with the bad lock-in.
2. Everybody who had the longer chain before ignores the lock-in, and continues to push the longer chain.
  (unless the longer chain contains a bad transaction-- the chain is checked for bad transactions on startup, see  CBlock::CheckBlock)
3. Newbies who are downloading the chain for the first time will hit the lock-in code, and will be running with a shorter chain.

There will be chaos as newbies generate blocks on the shorter chain, which only other newbies will accept.  "oldies" will also continue to generate on the longer chain.  Transactions will get added to both chains... and the "oldies" will beat Satoshi into submission.  Unless there is a legitimate bug (like the overflow bug that inspired the block chain lock-in code in the first place).

If I am misunderstanding your concerns, please speak up.  The number one development priority for bitcoin is security.  If you have found a problem, please email or private-message Satoshi, or post here (besides possible network denial-of-service attacks-- only email about those if you have a brilliant idea for how to prevent them...).

[davout]

The linux kernel is made by lots of smart people, that didn't make it free from any vulnerabilities.

Of course, but these are accidental vulnerabilities.
I meant putting vulnerabilities on purpose. Vulnerabilities like this are usually easily detectable.

Yeah, they're called backdoors, an exploit is something completely different.
An exploit is a documented and reproductible way to use a particular vulnerability in order to get to a given result (privilege escalation, DOS etc.)

Smartly engineered backdoors can be very difficult to spot.

[davout]

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.

Bugfix = remove block chain lock, not very likely to happen since satoshi added it on purpose
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.

Let's say that the person or community controlling the official release are ever corrupted or make a mistake.
Let's say I have a legitimate longer chain than the one they plan to lock-in.

What do I do?
Who do I appeal to?
Do I report to the police? The blogosphere?
Who will take the effort to verify my claims?
What will be the consequences if I'm proven right?

Just release the god damn bug fix instead of sitting here?

EDIT : Fixing = reverting some of satoshi's code, for some reason I don't see that happening
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.

[Cdecker]

As soon as we have multiple implementations the trust that we have to put into the developers of any of those clients is reduced,...

Any progress in that direction ?  I red somewhere that some people wanted to work on a Python implementation of the protocol.

Still working on it but 2 jobs and my studies are taking their toll on free time to spend on Bitcoin related projects. People offering to help understand the protocol are always welcome: http://code.google.com/p/pybitcoin/wiki/BitcoinProtocol

[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

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

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

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

[andrew]

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 =)

This would never work. You could screw this up simply by disconnecting a lot of nodes from the network and having the most computing power. Case in point many Asian countries which often get disconnected or blocked from international connections.

Also taking the checks out leaves new clients vulnerable if they begin by downloading from bad peers. It would also be extremely slow again to download everything.

[Gavin Andresen]

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.

The test network (run bitcoin with the -testnet flag) is a different block chain, implemented so that the two chains never get confused.  If anybody wants to start yet another block chain, it isn't technically hard, and won't cause any problems for "real bitcoin".

The hard part would be getting anybody to use your alternative; it would have to be better in some way other than just "I started the new chain, so I've got a lot of the easy-to-generate-at-the-beginning-coins."

[ribuck]

...it would have to be better in some way other than just "I started the new chain, so I've got a lot of the easy-to-generate-at-the-beginning-coins."

You say that now, but if bitcoin really takes off I can see lots of get-rich-quick imitators coming on the scene: gitcoin, nitcoin, witcoin, titcoin, shitcoin... Some of them are sure to attract users with promises like "Why use bitcoin, where you can only generate 50 bitcoins every few months? Use shitcoin instead, and you'll get 51 shitcoins every 2 minutes".

Of course the cheap imitators will disappear as quickly as those 1990s "internet currencies" like flooz and beenz, but lots of people will get burned along the way.

[Gavin Andresen]

Of course the cheap imitators will disappear as quickly as those 1990s "internet currencies" like flooz and beenz, but lots of people will get burned along the way.

I agree-- we're in the Wild West days of open-source currency.  I expect people will get burned by scams, imitators, ponzi schemes and price bubbles..

I tend not to worry about things that are out of my control; I don't think there's a whole lot that can be done about scammers, imitators, and ponzi schemes besides warning people to be careful with their money (whether dollars, euros or bitcoins).

[ShadowOfHarbringer]

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.

The test network (run bitcoin with the -testnet flag) is a different block chain, implemented so that the two chains never get confused.  If anybody wants to start yet another block chain, it isn't technically hard, and won't cause any problems for "real bitcoin".

The hard part would be getting anybody to use your alternative; it would have to be better in some way other than just "I started the new chain, so I've got a lot of the easy-to-generate-at-the-beginning-coins."

Well it's good as long as the user is required to enter some "advanced hardcore settings", but it shoould never be in a way, where You install bitcoin, and the first thing that pops up is "would you like to use the official chain or one of the less-official chains X, Y or Z" window.

Sure, official client can support multiple chains, but only through some hardcore/advanced configuration option i think. Also, multiple warnings like "do you really know what are you doing" should appear if user chooses another chain.

[MoonShadow]

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.

It's still not impossible, but it is astronomicly unlikely.  At least beyond the last checkpoint honored by the majority of the nodes on the network.

But yes, that is the point of it.

[MoonShadow]

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 ?

By checking that genesis block matches the one that you already trust, and by a full blockchain re-check.  No honest alternative blockchain will use a matching genesis block, because they want to be different.  No dishonest alternative blockchain using the same genesis in an attempt to deceive nodes should survive a total re-check of the blockchain, even without the blockchain checkpoints that have been argued about on this thread.

It is not neccessary to have a trust structure, just keep a copy of your desired blockchain's genesis block separately.

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

By checking that genesis block matches the one that you already trust, and by a full blockchain re-check.  No honest alternative blockchain will use a matching genesis block, because they want to be different.  No dishonest alternative blockchain using the same genesis in an attempt to deceive nodes should survive a total re-check of the blockchain, even without the blockchain checkpoints that have been argued about on this thread.

It is not neccessary to have a trust structure, just keep a copy of your desired blockchain's genesis block separately.

Doesn't that mean whoever controls the genesis block can control the entire block chain?

ie:A hit squad can take out that person and introduce a new blockchain  

It would be enough to export the latest hash from the chain and compare it to the latest hash on theymos's block chain explorer site. A simple script to do this would be helpful .

[theymos]

It would be enough to export the latest hash from the chain and compare it to the latest hash on theymos's block chain explorer site. A simple script to do this would be helpful .

Here's a text-only version of that information from Bitcoin Block Explorer, for anyone writing a script:
http://theymos.ath.cx:64150/q/latesthash

BBE is not "released" yet, so I certainly don't guarantee that this will be accurate all the time.

[ByteCoin]

BBE is not "released" yet, so I certainly don't guarantee that this will be accurate all the time.

I have used it a little and I think it's great. Minor observation: If I enter 111111111111111111111 it doesn't come up with anything but if I enter 000000000000000000000 it does. There seems to be a problem searching for addresses.
I used this link http://theymos.ath.cx:64150/bbe

Doesn't that mean whoever controls the genesis block can control the entire block chain?

The genesis block is one of the few pieces of arbitrary data that is coded into the client. Nobody controls it. It was specified when bitcoin was first generated and it can nobody can change it without throwing away the block chain and the current client.

ByteCoin

[MoonShadow]

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 ?

By checking that genesis block matches the one that you already trust, and by a full blockchain re-check.  No honest alternative blockchain will use a matching genesis block, because they want to be different.  No dishonest alternative blockchain using the same genesis in an attempt to deceive nodes should survive a total re-check of the blockchain, even without the blockchain checkpoints that have been argued about on this thread.

It is not neccessary to have a trust structure, just keep a copy of your desired blockchain's genesis block separately.

Doesn't that mean whoever controls the genesis block can control the entire block chain?

ie:A hit squad can take out that person and introduce a new blockchain  

It would be enough to export the latest hash from the chain and compare it to the latest hash on theymos's block chain explorer site. A simple script to do this would be helpful .

There is no one to "control" the genesis block.  Once a unique genesis block has been created, presumedly with the intent of starting a new and separate blockchain, the genesis block simply is.  There is no way to alter the genesis block in the official Bitcoin blockchain to any gainful (or malicious) purpose, nor even in the test blockchain.  If some way is ever discovered, Bitcoin will fail completely, as this is central to the security of the system.  If you did so on your own client, your client would simply break; or if you rigged it so that it would not break, no new clients would accept your genesis block beyond block #2.  The clients don't assume that the first copy of a block received is correct, even upon startup.  The only way for the client to choose an alternative blockchain would be to force the client to use a particular genesis block, so that the "longest" (i.e. greatest totoal proof of work) blockchain couldn't overide it.

[MoonShadow]

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 ?

By checking that genesis block matches the one that you already trust, and by a full blockchain re-check.  No honest alternative blockchain will use a matching genesis block, because they want to be different.  No dishonest alternative blockchain using the same genesis in an attempt to deceive nodes should survive a total re-check of the blockchain, even without the blockchain checkpoints that have been argued about on this thread.

It is not neccessary to have a trust structure, just keep a copy of your desired blockchain's genesis block separately.

Doesn't that mean whoever controls the genesis block can control the entire block chain?

ie:A hit squad can take out that person and introduce a new blockchain  

It would be enough to export the latest hash from the chain and compare it to the latest hash on theymos's block chain explorer site. A simple script to do this would be helpful .

This requires trust in both Theymos and the ongoing security of his explorer site.  I was simply pointing out that trust in any particular party isn't required.

[theymos]

I have used it a little and I think it's great. Minor observation: If I enter 111111111111111111111 it doesn't come up with anything but if I enter 000000000000000000000 it does. There seems to be a problem searching for addresses.
I used this link http://theymos.ath.cx:64150/bbe

Fixed. Thanks.