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

I will think about the puzzle presented and will want it reported if I claim the test set is complete, or any earlier at your choice.

I think that Bitcoin is not the Satoshi code, that merely proved the concept, we all bought into.
 
You might be furious about this statement, but if that code would be suitable to all, then why on earth did you create BitcoinJ or jgarzik picocoin and pynode, to name a few with likely more credit in your eyes?

There are/will be other implementations that are closed source and you will have less handle on them than on mine. Given the increasing demand on capacity and speed miner are the first asking for and creating their own alternatives. Do you think few years down the road big merchants will connect their accounting systems to an executable that is a digital dogma?

You may warn people using alternative implementations, do your best to shake confidence in my abilities, but do not think that keeps you at the warm place you are used to for too long. That place will be either empty since this project dies or there will be lots of players who are not asking for your wisdom, while I still do.

I was pretty specific about the bug actually. It's a thread safety issue that can cause a split in the consensus, ie, it's in block chain verification. That narrows it down to a pretty specific region of code. It should be easy to spot.

Re: withholding specific bugs. I want to be convinced that this class of errors can be found by Grau in some systematic way. It's scary because finding thread safety bugs can be quite hard, though this one I suspect can be detected by FindBugs, which should make it easy.

If Grau doesn't find it after a few days or so and wants it reported, I'll do that.

I want to ram the point home that Greg is already making. Bitcoin is not like normal software. Fully verifying re-implementations are dangerous. If people use them and their behavior varies from Satoshis code at all, in even the tiniest detail, it can be used to split the consensus and in the worst case steal money from people. Satoshi was dead set against them for that reason and I'm pretty much with him on that.

Even refactorings of the Satoshi codebase scare me given that they have in the past temporarily introduced consensus-splitting bugs. Given that simply re-organizing the existing code is difficult and dangerous, you can imagine how I might feel about a full reimplementation!


There are undoubtably bugs in it, especially as the full verification support is new. That's why it comes with a prominent health warning on its home page and that's why I won't be recommending people rely on its fully-verifying mode any time soon. That's despite the fact that Matt has done a ton of work on testing, his tools are so good they actually found bugs in the Satoshi client after the ultraprune refactoring, so I have some confidence that those tests are thorough. They could easily be re-used here.

Obviously in SPV mode the damage it can cause is far more limited, so that's less of a concern.

One of my biggest worries about merging Matts work on full verification into bitcoinj was that somebody would use it for mining. If I heard anyone even think about that, I'd ask them to reconsider in the strongest possible way. I'm not super comfortable with even having it merged into the codebase, but since the code was written already, it seemed better to integrate it and be able to keep control over the documentation and how it's presented.

If you said "there is a bug in the SPV code of class X in region Y" then I would go and take a close look at that, and bulk up the testing around it to try and flush out the issue. And if I really couldn't find it no matter what I'd ask for help. But that would, I think correctly, shake peoples confidence in the code. If you found a bug in the full verification code, you would merely prove my point.

First, lets be completely clear about this before you start slandering me:  I _offered_ but also said I think it would be best to find it via testing, because we have no other way of knowing if the testing is sufficient. It is utterly essential that the complete rules of the system be faithfully executed. It is very hard to get this right. It's no insult to anyone if it's not quite right at first, but it is very essential that its well tested so that the test turn up every short coming.

Just as a reminder of what I said:

I think it looked mostly complete, that is why I asked though— I wasn't sure if you believed it to be complete already or if you were still working on it. The issue I'm aware of is a part of script validation— though I'd encourage you to not over optimize on what I'm aware of, simply because there may be other useful things you find while testing.

I'm preserving this against further editing. If anyone has any remaining doubts about Mike's motivation please compare this post with his earlier post in the "multi-sig or scalability" thread:

https://bitcointalksearch.org/topic/m.1046848

This type of "logic" is normally called extortion. GMaxwell is a known extortionist, except that he calls it "tipping the incentives". Here is the link his post from the beginning of this year where he was openly asking for payment:

https://bitcointalksearch.org/topic/m.677910

When I joined this forum I was completely wrong calling the Bitcoin core development team "Bitcoin bunker". Now that I understand the situation better I know that there's no single bunker. There are numerous one-or-two-person cubbyholes that may occasionally form the aliances to shoot at the occupant of another cubbyhole. The situation conforms better to the distributed paradigm inherent in the design of Bitcoin.

I applaud Grau for doing all this work. I don't get the logic of withholding known bugs. If you don't want to help this is fine, but claiming that you found a bug, you just don't want to tell about it, is silly at best. We had a similar situation a year back or so where an alt-coin developer claimed to have found a bug in the satoshi-code, he just didn't want to tell Gavin (sorry can't find the reference).

Grau, maybe you should see if you can find a bug in BitcoinJ so you have something to trade with  
(Jan tries to dodge the flames)

I disagree with Mike and GMaxwell.

Remember when Bitcoin was v0.2 ?

The only thing that made it possible to reach 0.8 is by people sending as much information regarding bugs as possible.

Developers can never test everything, because resources are always scarce in every software development I've ever seen in the world.

With lots of bug reports, the developers can think of the best strategy for testing, concentrate in the common patterns, focus on certain modules, etc.

The quality of software will always rely on the development procedures implemented. But Grau is not part of an big organization with statistical information regarding 100 previous projects, nor he has the funding for one.

The best way to design the best software engineering procedures and the right testing plans for a software project with limited resources is to have the deepest knowledge about its current bugs.

Since you think, I am not helpful to you, you do not feel being obligated to help me. That's fair.
Using your authority and no specifics on claiming a bug is not.

I remain hoping that you uncover the issue while I am testing.

I'm pretty sure there is a bug, yes. If I'm wrong then I will of course apologise and go back to update my previous post.

The point of being vague is that us finding bugs on random code reviews isn't reliable or scalable. With your new codebase you're not solving a problem any of the current core developers have, so there isn't much incentive for us to go finding bugs for you. But if people were to use or mine upon a new implementation with bugs, that would definitely cause problems.

So what's important to demonstrate is that your code can be used without presenting a danger to the network, and that means really solid processes and testing to ensure the behavior matches exactly. If we can find one or two issues, there could well be more, so a rigorous testing and protocol compliance regime is the only way to build confidence.

Actually, I am sure there are bugs.

The common quest should however be creating a good product, not proving that testing is insufficient.

I made this open source for mutual benefit, that is the community gets my work for I get constructive feedback and not just hints on potential issues after a quick look.

Are you sure there is a bug?

I took a quick look at the latest code also, it seems there is  a thread safety issue that could potentially cause a split in the consensus. I guess I'll go with Gregs approach too and not say exactly where it is, though that should be a big hint. Thread safety is tricky to get right as you know, especially, it's hard to check with unit tests. So it would be good to see how it is resolved.

I am ready to take the challenge.

How would you rate the current coverage of rules after your review (100% being complete)?

May I have a pointer if the omission you found is in script, message format, protocol, block-chaining (reorg), caching or any other more specific area?

Okay. You're missing at least one important rule, but I don't know what else is missing that I missed in review.

Unless you object, I'm contemplating keeping this missing rule to myself for now so that it can function as a test of the testing. E.g. if the test don't find it, they're incomplete.  Obviously I don't want to withhold information which could undermine the network, but absent better testing the software shouldn't be in production use anyways... and there are scarcely few good ways of testing the tests.   Does this sound reasonable to you?

For caching, you may consider the open source "ehcache"
Which can be used with a disk backing store or in memory, complete with aging out to disk or removal.


HC

All rules I found are enforced. I am eager to learn any outstanding.

The biggest deliverable is serious testing.

I would love to get this production ready this year, but since I only work on this on my spare time and my family has other plans with me around Christmas, I can not commit.

Whats the current timeframe for enforcing all of the script rules so that mining on this code isn't a forking risk? (if there is one?)

What do I mean with raw power?

Download full blocks from 0-210.000, validate all Merkle roots, proof of work and check for double spending, stored in LevelDB
in 93 minutes. The constraint until about block 130.000 is the peer/network speed, thereafter one CPU is busy.

Full validation (as above + scripts) and store of blocks 210.001 - 211558 on 4 CPUs (near constant 90%+ utilization of each)
in 61 minutes

Bootstrap of a full node with above split parameters in 2 1/2 hours.

I will do comparison with the relational model next week.

Now you have the option to use LevelDB or any relational database, just by configuration.

Use the relational store if you are after data mining and ad-hoc queries and have more time.
Use LevelDB if you want raw power.

The bitsofproof supernode validates the chain with LevelDB at a speed only constrained by CPU.
EDIT: And I mean all processors you have

Nice proof of modularity isn't?

I am working to enable higher order search functions (via API) to LevelDB.

i think the point jgarzik was making is about block relaying from other nodes who did not find the block.