ANN: Announcing code availability of the bitsofproof supernode

[grau]

Now you have created a security vulnerability that can be used to undermine everyones assumptions about double-spending hardness and potentially defraud people out of millions of dollars. The severity of failure is so much higher. And worse it can affect people who didn't ever even use your software.

People use a system they trust.
Can we spread trust into a behavior we do not define, just experience by running a specific code, to the rest of the world ?
I think most big organizations are not ready for that.

Those bought into the system have to weight their fear of losing their fortune against the chance of further appreciation unlocked by wider adoption.

Would other implementations foster adoption ? Yes, I think the interest I experience supports this.
Can you avoid having other implementations ? Not for such a great Idea in a world full of capable programmer.

Last night I ran FindBugs on the code and discovered at least two different chain-splitting bugs that weren't found by the tests, one of which is also present in bitsofproof. It took me five minutes!

I take your hints and concerns seriously and will test and invite you to challenge.

[Peter Todd]

Now you have created a security vulnerability that can be used to undermine everyones assumptions about double-spending hardness and potentially defraud people out of millions of dollars. The severity of failure is so much higher. And worse it can affect people who didn't ever even use your software.

People use a system they trust.
Can we spread trust into a behavior we do not define, just experience by running a specific code, to the rest of the world ?
I think most big organizations are not ready for that.

...so tell those organizations not to use Bitcoin.

Chain-splitting bugs are inherent to the design of Bitcoin and any other crypto-currency based on the same principles. We just have to live with it and figure out how to deal with the problem, by necessity the hard way.

Given that we are in truly uncharted territory taking a cautious approach makes a lot of sense to me. Bitcoin's only existed as a valuable entity for about two years now, and the use of alternative implementations has been pretty small. Why rush?

Mike's thought about Bitcoin being like avionics software is very prescient in my opinion. I work in electronics design and it's routine for companies that make complex parts, such as ICs, that get used for critical applications to "freeze" whole production lines. They'll give you a formal, documented, change notice for something as simple as changing the type of paint used to put the part-number markings on the chips. The industry has learned the hard way that extremely subtle changes can make things not work, essentially because the reason why these parts work in the first place isn't anywhere near as well understood as the engineers wished it was. When it comes to chain-splitting frankly I think Bitcoin is squarely in that territory. Equally plenty of big organizations just live with these problems; we didn't ditch avionics just because it was hard to always make parts repeatably, but we did stop changing paint formulations unless we really, really had too.

Alt-implementations are a good way to explore this problem, but that's just it: explore. Don't start using them seriously until we've done a whole lot more of that exploration. I suspect we're going to find that even just differences with different installations of the Satoshi client prove problematic enough, and god help us if attackers start trying to introduce changes into system libraries like openssl as a way to attack the Bitcoin software.

[grau]

... god help us if attackers start trying to introduce changes into system libraries like openssl as a way to attack the Bitcoin software.

You just opened my eyes, that the experienced behavior of the Satoshi client includes bugs of OpenSSL, BerkleyDB ...
What if they fix bugs, like:

https://bitcointalk.org/index.php?topic=121122.msg1304761#msg1304761

[Peter Todd]

... god help us if attackers start trying to introduce changes into system libraries like openssl as a way to attack the Bitcoin software.

You just opened my eyes, that the experienced behavior of the Satoshi client includes bugs of OpenSSL, BerkleyDB ...
What if they fix bugs, like:

https://bitcointalk.org/index.php?topic=121122.msg1304761#msg1304761

Exactly. Not to mention differences in compiler bugs, and even potentially CPU bugs, especially with the growing trend of putting dedicated crypto hardware in general-purpose CPUs.

For instance imagine if one day there was a "fast-path" that used a special-purpose SHA256 block available in, say, certain x86 CPU's, and there existed a specific bit-sequence that would cause that specific SHA256 block to produce an erroneous output.

FWIW at the hardware level things like repeated sequences of certain bits are often the cause of erroneous behavior. Now imagine some engineer doing, say, a worst-case power analysis of a high-performance SHA256 hashing unit "there's no way a SHA256 hash will ever have the first 65 bits set to zero"...

[Pieter Wuille]

... god help us if attackers start trying to introduce changes into system libraries like openssl as a way to attack the Bitcoin software.

You just opened my eyes, that the experienced behavior of the Satoshi client includes bugs of OpenSSL, BerkleyDB ...
What if they fix bugs, like:

https://bitcointalk.org/index.php?topic=121122.msg1304761#msg1304761

The fact that we depend on a third party libraries for normative network rules, is indeed a serious problem. In particular, OpenSSL defines what we accept as public keys and signatures on the network, and thus is very sensitive. At least for BDB, it would require at least a bug and probably a deliberate attack to to cause trouble. Still, BDB has been such a problem child that we want to get rid of it in any case. The LevelDB source is included in our repository, so wouldn't suffer from the same problem.

More specifically about the problem you're referring to, there has been an effort to enforce more strict encoding rules on the network. See this mailinglist thread for example, but there have been forum threads about it as well. In any case, the current latest reference code includes validation routines for strict adherence to the encoding strandards which do not depend on OpenSSL themselves. They're not yet enforced as that has network-splitting risks, but a gradual adoption (first have all clients implement the correct encodings, then stop relaying transactions with non-standard encodings like IsStandard(), then make it a network rule so it becomes effectively invalid in blocks) is certainly wanted.

[grau]

... god help us if attackers start trying to introduce changes into system libraries like openssl as a way to attack the Bitcoin software.

You just opened my eyes, that the experienced behavior of the Satoshi client includes bugs of OpenSSL, BerkleyDB ...
What if they fix bugs, like:

https://bitcointalk.org/index.php?topic=121122.msg1304761#msg1304761

Exactly. Not to mention differences in compiler bugs, and even potentially CPU bugs, especially with the growing trend of putting dedicated crypto hardware in general-purpose CPUs.

So Satoshi code in different versions, builds or in different execution environments can also split in opinion.

The probability of such split is certainly lower than a split between two unrelated implementations, but it is positive.

I think the damage is highest in a population where mining nodes are split in equal proportion in their opinion and would be less disastrous if one opinion is in clear minority as the minority will find less blocks and will be overwhelmed by the rest until they give up and upgrade. Transactions on minority blocks will be reverted but might have been already included in the majority ones too.

Am I correct that a heterogenous miner population increases the probability of a split opinion but also contains the damage to its own population that will seek to resolve as soon as it can since likely loosing block rewards if in minority ?

Excuse my ignorance but, where these scenarios discussed or simulated here ?

[grau]

The fact that we depend on a third party libraries for normative network rules, is indeed a serious problem.

In essence you reduce the probability of split by pulling more functionality into the bitcoind source tree.

No objections that this reduces split probability. The price however is a code base that
is not able to participate on advances of surrounding technologies. Let alone use a new one.

I guess the number of lines of code written to parse BDB blockchain exceeds bitcoind code base.
Now I created relational store that you could data mine with sql but we all fear using it for real since
it increases split probability.

What about being progressive on the problem and elaborating strategies for remedy of a split if it happens ?

[Pieter Wuille]

There is quite a difference between BDB and OpenSSL here. Depending on third party libraries is not a problem as such - there's no way we can get around depending on a C library, the OS kernel, ... as you say, that would stop evolution altogether.

The problem is that the rules (as defined by Satoshi's implementation) simply pass data directly to OpenSSL, so the network rule effectively is "whatever cryptographic data OpenSSL accepts", which is bad. OpenSSL has all reasons for trying to accept as much encodings as possible, but we don't want every client to need to replicate the behaviour of OpenSSL. In particular, if they add another encoding in the future (which, again, is not necessarily bad from their point of view), we might get a block chain fork.

So what I aim for is that the network rules are at least just defined by the implementation of just bitcoind. Ideally, we'd have some form of formal specification, but I don't see that happening anytime soon. This should make it easier for alternative full node implementations to have some assurance they do not have forking behaviour. And yes, I agree that a more diverse landscape with multiple trusted full implementations would be better, under the condition that those are well tested. I would find it a pity (but perhaps inevitable) if large miner setups would need to run multiple node implementations, and compare their constructed block against all...

And yes, fraudulent code in BDB can break things too, but that won't cause a massive fork - just a few nodes that were attacked. That is by no means comparable to an implicit rule "yeah, just make sure OpenSSL likes it".

[commonancestor]

Are you basically saying that some evil guy can install some modified Satoshi client on his average botnet and bring the network down? How many nodes would he need? ...

[gmaxwell]

Are you basically saying that some evil guy can install some modified Satoshi client on his average botnet and bring the network down? How many nodes would he need? ...

No.

[jgarzik]

There is quite a difference between BDB and OpenSSL here

The problem is that the rules (as defined by Satoshi's implementation) simply pass data directly to OpenSSL, so the network rule effectively is "whatever cryptographic data OpenSSL accepts", which is bad.

+1, quoted for emphasis.

[grau]

And yes, I agree that a more diverse landscape with multiple trusted full implementations would be better, under the condition that those are well tested. I would find it a pity (but perhaps inevitable) if large miner setups would need to run multiple node implementations, and compare their constructed block against all...

If implementations support an efficient block template exchange and mutual verification then it could be cheap for the miner to run several implementations to test block template against before mining work is spent. They could as well run different versions of Satoshi code to ensure backward compatibility.

The actual implementation of such block template exchange would also be the testing interface implementations could challenge each other. I suggested this idea to Gavin about a month ago and he liked it. Now I see a further significant use of it.

Such use would however only be valuable if it is jointly supported across implementations, therefore suggest to evolve it as a BIP for block template challenge/response.

I am ready to work on the definition and implement it since it fits well to the deliverable of testing. How about you core team ?

[Luke-Jr]

And yes, I agree that a more diverse landscape with multiple trusted full implementations would be better, under the condition that those are well tested. I would find it a pity (but perhaps inevitable) if large miner setups would need to run multiple node implementations, and compare their constructed block against all...

If implementations support an efficient block template exchange and mutual verification then it could be cheap for the miner to run several implementations to test block template against before mining work is spent. They could as well run different versions of Satoshi code to ensure backward compatibility.

The actual implementation of such block template exchange would also be the testing interface implementations could challenge each other. I suggested this idea to Gavin about a month ago and he liked it. Now I see a further significant use of it.

Such use would however only be valuable if it is jointly supported across implementations, therefore suggest to evolve it as a BIP for block template challenge/response.

I am ready to work on the definition and implement it since it fits well to the deliverable of testing. How about you core team ?

Except this has been around for months now already... it's the BIP 23 Proposals I suggested you implement earlier.

[grau]

Except this has been around for months now already... it's the BIP 23 Proposals I suggested you implement earlier.

Yes, credit to you for the block template.

Thanks again and I will come back to your offer and you have mine.

This idea goes a bit further to facilitate testing and perhaps compatible to BIP 23. The requirements could however be close enough for a merged implementation.

Please contribute to the thread https://bitcointalk.org/index.php?topic=130327.0 on this so this refocuses to the bitsofproof supernode.

[Jouke]

I have to say that the feature list of the supernode sounds very promising and I am afraid people are really going to use it. I for one will (altough not for mining).

[Sergio_Demian_Lerner]

If implementations support an efficient block template exchange and mutual verification then it could be cheap for the miner to run several implementations to test block template against before mining work is spent. They could as well run different versions of Satoshi code to ensure backward compatibility.

The actual implementation of such block template exchange would also be the testing interface implementations could challenge each other. I suggested this idea to Gavin about a month ago and he liked it. Now I see a further significant use of it.

Such use would however only be valuable if it is jointly supported across implementations, therefore suggest to evolve it as a BIP for block template challenge/response.

+1
This is the way to go forward.

[gmaxwell]

If implementations support an efficient block template exchange and mutual verification then it could be cheap for the miner to run several implementations to test block template against before mining work is spent. They could as well run different versions of Satoshi code to ensure backward compatibility.

Under that model miners and high value targets would need to run, say, 12 implementations at at least 12x the cost (and probably more because some implementations will be much less efficient).  ... and the effective feature set of the network would be degraded to whatever the most popular broken implementation runs.  …

There can be uses for running multiple nodes for comparison— I do today. It may become a regretful requirement in the future if broken node software becomes commonplace. But this is a _very_ bad answer to the fact that your software is broken while it is not widely used.  Please fix your software before spending time on this.

[grau]

It is primary interest of the miner that blocks they create are accepted by the majority of nodes, right?
Now assume Satoshi 0.8 comes out but conversion of the majority user did not yet achieved. The approach would ensure blocks will be accepted before mining work spent to them by the populatin mix.

This primary interest would be leveraged to facilitate compliance test. Big miner could also run pre-releses and provide feedback on compatibility of future releases before they are released to public.

Note that block templates would be checked that is cheap. A block template is just like the final block only that the work is not yet done (nounce does not produce a nice hash)

[Pieter Wuille]

Sure block templates are a very nice tool for miners who want to run untrusted block creation code (and probably very useful for testing), but it would be sad if evolution forced miners to run several nodes at the same time. It makes it harder to know which rules the network actually uses, and requires a lot more resources (each node will at least require maintaining its own UTXO set or equivalent).

I'm not sure why you think the 0.8 release would require any conversion. As far as I know, no reference client has ever changed the block validity rules (except for some very early bugs, and backward-compatible changes like BIP16 and BIP30). Nobody intends to make a release that risks causes a block chain fork.

[Mike Hearn]

You're right, but the upgrade vs alt-impl scenarios differ in a key way - if you're upgrading from one release of the Satoshi client to another, and everyone is doing so simultaneously, then the period of time where you want to run both in parallel is limited. Once the (vast) majority upgraded to the new release, you can stop running the old one. Also, typically there's only two versions in wide usage simultaneously. And as Pieter points out, many releases aren't at risk of changing block validation (eg, if only the gui or config file loading or whatever changes).

With re-implementations the other users on the network will never "upgrade" to the version you're running, so you would have to run both (or 3 or 4) in parallel forever. Not great.