Topic: ANN: Announcing code availability of the bitsofproof supernode - page 9. (Read 35116 times)

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 ?

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 ?

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.

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

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://bitcointalksearch.org/topic/m.1304761

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

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.


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

Yes, like I said, Bitcoin is not like normal software. Of course in a normal software environment the protocol would be defined by some specification documents, test suites would be produced to check compliance, etc.

But then in normal software environments the cost of failure is really low. OK, you wrote a web browser that doesn't correctly implement the JavaScript specs. Some web pages fail to display properly. No big deal, just fix the bugs and try again. Users temporarily switch to another browser, life carries on.

With Bitcoin it's, OK, you wrote a program that follows the specs, but the spec was incomplete in some minor detail. It got some users. 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. Maybe only avionics software comes close to this.

Chain-splitting bugs are really an entirely new class of security vulnerability that existing software doesn't have to think about.

So with Bitcoin, and especially bitsofproof supernode, we're in uncharted waters. There have been several re-implementations, but none of the authors ever supported mining before. That is one of the things you said you'd work on next, hence the attention this thread is getting. For the first time ever the prospect of a non-Satoshi implementation being used by real miners or real merchants is coming up.

The question we have to answer is - is it possible to achieve the level of accuracy needed to do a safe re-implementation? We used to think the answer was yes, just document the protocol, write some decent unit tests and you're done, like any other program. My opinion is changing on this quite fast, because we keep finding bugs that could be used by an attacker to split the chain but which weren't found via testing or automated analysis.

So far, I think Matts work on testing for the bitcoinj full mode is the most thorough yet - he wrote a tool that compares block acceptance step by step against two different nodes and runs through it a set of carefully crafted test blocks. It's impressive and was a ton of work. 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!

The practice I referred to and do not comprehend is: not attempting to capture the compliance requirements. This is as if unknown and untold implementation details would serve security. This is not a mainstream thinking in cryptography.

I do understand your concern but think it is short sighted to assume this will go mainstream without defining its nature.

A practical suggestion: test cases you created for the Satoshi client check for features you ensure to pass at each release. I think it would be beneficial to state what exactly they check for in a wiki.

I'm sorry guys, but I feel like we're not getting through to you.

There is no canonical list of quirks. We don't know them all and discover more all the time, so trying to build a wiki page with them in would be misleading. That's why we're saying Bitcoin is not like normal software and re-implementing it is dangerous - the list of things you might get wrong is both long and unknown.

It's not a "practice" to require unlimited compliance. It's inherent in the nature of how Bitcoin works. Any deviation from the standard behaviour at all can lead to chaos if the deviant implementation gets enough users. This includes behaviour that is implicit in libraries like OpenSSL or the database code.

The best way to find out what quirks or bugs have to be re-implemented is really, really thorough testing practices. So far, nobody has been able to achieve this successfully - even the best tested re-implementations have on inspection been found to contain consensus-splitting bugs. The more often this happens the more I come to think re-implementing Bitcoin successfully isn't possible and we will never have a reference specification that is usable.

Yes. The current practice of requiring undefined but unlimited compliance is a break on innovation.
Those posess the details would serve the community by documenting them.

Could you create a list of issues that you know and upload it to the https://en.bitcoin.it wiki ?
Or if you post the list here, I can edit the wiki.

It's very important that this information is made public.

Whilst I was playing around to see if the bug I saw was real (it is), I noticed a few others too, all chain splitting unfortunately.

Let us know when you want to know what they are. Otherwise as you improve test coverage I'll sync to git master every so often and see if they got fixed.

I should have also said:
configurations are under: src/main/resources/context and src/main/resources/etc file names correspond to the ones I listed in the previous mail. Configurations are packaged into the jar, so you have to do
mvn package
after modifying, to use them.

X=Wallet Y=reorganize()

Details and fix sugestion  posted here: http://code.google.com/p/bitcoinj/issues/detail?id=257

Sorry couldn't help it 

I do feel what you say. My journey started with the hunger for details and similar ignorance of the size of the problem. My belief however remained that alternative implementations strengthen not weaken the system as they are the real test cases of each other.

Yes, it does work well and it would be rather surprising if all of the core teams effort would not have stellar results in areas they focus. The point is that they won't solve problems that are not sexy or global enough. 

There are sets of configurations e.g. server, lserver, audit, demo

java -jar target/supernode-0.6-SNAPSHOT.jar server

starts the relational model, but you have to configure the datasource you use (it is defaulted to derby) Make sure you add derby a lot of buffers since default configuration of the distribution is a joke.

java -jar target/supernode-0.6-SNAPSHOT.jar lserver

starts LevelDB configuration. I also use -Xmx4g and -server flags to java but that should depend on your conf.

Please report bugs you will surely find in issues at github.

I reproduced the bugs you listed as they are widely known "features" of the protocol. Point me to any further collection of "features" and I follow them. I read and tried to reason the Satoshi code and some of yours, while might have missed to identify features that need to be replicated. That code base evolves too, therefore boundaries have to be clear where the definition ends since other implementations will not follow that for ever.


If that makes a difference I make sure I say the same

I'm not furious about it I've often wondered that myself!

I created bitcoinj because I wanted to use Bitcoin on my Android smart phone. This led to two problems:

1) Integrating with an Android GUI requires you to use Java. Of course, you can try to use JNI. It is complex and the binding code is a lot of work. Especially when you take into account the need for many complex callbacks. Still, it could have been done and I considered that for a while.

2) Satoshis code did not support SPV mode (it still doesn't). I had a partial patch from him but it was unfinished and clearly not going to work on something as constrained as a phone, partly because his code assumes it can load all block headers into RAM and that assumption is pretty prevalent through the code. You can't do that on Android, there isn't enough space. So it was clear that Satoshis code would need major work to do what I wanted.

There was a third concern I had, which is that back then the Satoshi client didn't really have any unit tests and the changes needed were pretty deep. My understanding of the code was much worse than today and I was afraid of breaking things. So a fresh implementation meant there was no risk of me being the cause of anyone losing money.

At the time, I thought it would be about as much work to do a new SPV implementation than adapt Satoshis code, because you don't have to validate all the rules, just manage the block chain. And as I thought it was about the same amount of work, I figured I could make an API for writing Bitcoin apps whilst I was at it.

In the end, I found I was mistaken - it was a lot more work than I expected

So, knowing what I know now, would I have done things differently? Well, maybe. I'm not sure. On one hand, I massively underestimated the amount of work required. On the other hand, I've also seen several times how easy it is to break Satoshis code in subtle ways. So my enthusiasm for writing a new codebase would have been less, but my fear of changing the existing one would have been more. Perhaps ignorance is bliss


Pieter has been able to get the satoshi client verifying the chain at thousands of transactions per second, which is excellent and I doubt we'll need any more performance than that for the forseeable future (PayPal processes a grand total of 40 transactions per second).

So I'm not sure I agree with you that this executable will be "digital dogma" - I think it'll still be in wide use as it'll have a long track record and good performance.

By the way, how do I switch your code to sync the production chain? I cloned it from git and ran the demo, but I can't see any command line switch or obvious XML config tweak to make it use the main network. I'm sure I'm missing something obvious.

Yes until the approach is constructive, that is to support creation of the product and not to bring the proof that it can't be done.

Thanks, the brief evaluation made me feel better. I will walk away with this puzzle too for now.

Not true.  We are stuck with the bugs found in early Satoshi code.  We must faithfully reproduce these bugs, to avoid splitting the network.  Examples include but are not limited to:

• Genesis block is not spendable
• CHECKMULTISIG requires an OP_0 to work around a bug
• Some transactions' hashes duplicate earlier transaction hashes, effectively making those earlier transactions unspendable.  Your code must similarly do the same.

picocoin and pynode both carry "under construction, alpha quality, do not trust with money" warnings because they are incomplete and risk splitting the network because they do not follow the reference client 100% yet.