Bitcoin Forum

TL;DR
   Announcing code release of the bitsofproof supernode.
   A modular Bitcoin protocol implementation to build bitcoin enterprises and server nodes on.

WHY
    Satoshi is a genius, but his implementation of the protocol is hard to maintain and extend.
    I believe that peers will specialize and this implementation is suited for the big server,
    tailored for some heavy lifting tasks, not for a mobile.

WHERE
   https://github.com/bitsofproof/supernode.git
   
FEATURES
   Pure Java source code released under Apache 2.0 license.
   Radically modular Assembly using Spring. Extensible and reducible to what you need.
   High performance P2P engine using Java NIO.
   Block storage using JPA into a fully normalized schema.
   Full support for multisig and pay to hash, including address maintanance.
   Parallel validation of transactions of a block.

DEPENDENCIES
   Spring, Bouncy Castle, SL4J
   Does NOT share any code with Satoshi or bitcoinj clients.

   
LIMITATIONS
   Not tested enough for production, therefore does not yet answer getheader and getblock
   and does not feature a wallet.

CONTRIBUTIONS
   Contributions are welcome. Add your own features to the modular design.

WHO
   Tamas Blummer alias grau tamas@bitsofproof.com wrote this implementation in his spare time at home.
   
DONATIONS
    Please honor the time I invested and motivate me to continue by donating to:
   
    13xhxy21to93Lrb7d4ssZVaMnFtQVvRkSk

Details please?
What so "super" in this code that make it better from standard bitcoind?

No idea if it's "better than bitcoind", actually it'd be quite presumptuous to say so.

But usage of JPA is already an interesting point... Different databases could be plugged. Databases that support clustering or partitioning could be used.
"Fully normalized schema" doesn't always go well with high performance though...

I haven't checked the code or anything, but if it's for real, wouldn't this be the first alternative full node implementation of bitcoin?

If anything, it's an improvement in 'diversification'. And I'm glad it uses technologies I'm familiar with. :)
I wonder how the author plans to keep up with all the development done in bitcoind though... they have many competent people improving the code and adding functionality. Just to keep up would be an enormous effort. But anyway, writing such a thing was certainly an enormous effort already!

By the way, OP, why not reuse BitcoinJ code if it fits?

Because one size does not fit all. Bitcoind is a monolithic hard to maintain code base.
Yes, and you can stick in whatever high performance provider your budget allows. This is for the
terabytes coming. Normalization allows to build services on top of the database
that do not have to deal with P2P or binary formats.

The effort of bitcoind team made all this possible. I have highest regards, but I do not think the code
they inherited is for the future.

I would rather worry if bitcoind can keep up with innovation, now that a modular design is available
people can easily stick their modules into. You do not have to wait for a new RPC call to add a new
type of signature. You do not have to wait for ultraprune, just stick in a higher performance database.

BTW: I buit enterprise systems, quant code and algo trading for decades. Look me up on linkedin if curious.  

Because it does not.

Nice! The code looks clean.

caveden, there have been several other full reimplementations. BitcoinJS is one, I think UfaSoft made one, and actually I just finished merging code from Matt that makes bitcoinj a fully verifying ultra-prune style implementation as well (of course, it can still run in SPV mode too).

So this implementation joins the ranks.

That said, from looking over the code, I can't find a few features I expected to be there:

- Where is the wallet implementation? How would I implement the PingService from the bitcoinj examples directory?
- Where are the tests proving conformance with all of Satoshis bugs? I see a few tests but they are fairly minimalist.
- API documentation

eg, there are script tests in bitcoinj (since yesterday) and the Satoshi client that verify the execution of every script opcode is correct in both positive and negative ways. It'd be nice to see them. The hard part of making full nodes is not implementing the protocol, it's ensuring you got every detail right.

Re: your comments about monolithic design. With respect to your experience, I don't think simply using Spring makes something "modular" vs "monolithic". Allowing people to build powerful apps is as much about documentation, examples, well-specified callback interfaces as it is about good use of OO design. For example, there are a variety of listener interfaces throughout bitcoinj, and each one has well specified and consistent behaviour: listeners run locked, they can remove themselves during execution but not other listeners. Also most of them document allowed re-entrancy. This sort of thing makes writing apps a lot easier.

I'd be the first to admit that bitcoinj could use some loving refactoring. The API is in places quite messy. There isn't really a good enough block chain API. The Wallet needs splitting out into customizable policy objects. That said, you don't seem to have a Wallet object at all unless I somehow missed it, so I don't feel too bad about that :) It looks the way it does because bitcoinj is already being used to write all kinds of apps, from end-user facing wallets to SatoshiDice. So at the moment we tend to prioritize new features over refactorings and API churn that makes it hard to keep up.

In future there might be a bitcoinj2 effort that re-organizes things a bit.

By the way:


I'm not sure you understand what ultraprune does or why the performance is higher. Firstly, it does swap out bdb for LevelDB, which is not exactly a difficult change. But more importantly it reduces the size of the databases working set by fundamentally re-organizing how data is used. It doesn't matter what database backend you use or how easy it is to swap in or out if the way you store data is inefficient.

Thanks for the warm welcome. Was nice to talk to you in London Mike.

I released the code since it reached the coverage needed to prove that it is for real. Not for production but to build on it as a platform.

Your points on testing are valid. They are clearly not sufficient. I plan to introduce an interface aimed for testing. That would enable
implementations to test each other.

The Wallet is not there but everything you need to stick it together in a couple hours or days depending on what you want.
I did not yet figured what I wanted. But the point is that this is a feature that does not have to be common.
Do your own at your own taste and stick it in.

I do and JPA certainly does not solve for that. My poorly made point is that normalized database schema allows services built next to the
server that does not need to know about p2p or binary formats. The feasibility of pruning or different levels of that are now
in the hand of the implementor of the persistence layer.

Wow, I'm really impressed!  :o
I haven't tested it yet, but if it works, this could become a really important alternative to the satoshi client.

Ok then. I thought that you had done it on purpose, as if sharing code was something bad.


I'm aware about the efforts to make BitcoinJ a full node, what I find quite good. I don't know about "UfaSoft", and didn't know BitcoinJS was a full node implementation either, I thought it depended on a bitcoind running on the server. Nice to know all this.

I'm glad to see Bitcoin evolving so fast. :)

I actually started using bitcoinj, but decided that it needs significant refactoring (as Mike also admits).

It was also an exercise of real understanding the protocol and uncovering its ambiguities.
The code I wrote is probably the easiest readable but precise existing documentation of
what is really going on under the hood, and I am sharing it with you. Isn't this good?

There will be an out-of-the-box executable jar sometime down the road for demonstration purposes,
but the audience for this is not the end user but the tech savvy implementing new enterprises.

This is an excellent limitation to have, and it should stay this way.

It should have support for communicating with a wallet module or wallet service, but I think having an integrated wallet is a bad design decision that leads to more bad design with all kinds of horrible implications.  (How often do you open a high-value document in Microsoft Word and be treated to a blinking cursor on a blank document as though you did "file - new"..., freak out, call for tech support, and be told "oh yeah, you are doing it wrong, you have to drop to the command line and type winword.exe -rescan")

Nice.

While not a 'must-have-now' feature having a pluggable persistence layer/db is a nice option.  

+1

Of course, this is awesome. In no way I meant otherwise!


I tend to agree with this feeling. Managing a Bitcoin wallet and managing the Bitcoin p2p protocol are two different tasks, there's no need for them to be strongly coupled.

Bear in mind that wallets need to be updated during re-orgs, so you need integration between the block chain handling code and the wallet code. Also if you want to implement optimizations like getheaders the peer to peer code, the block chain and the wallet all need to work together to achieve that.

It's easy to say "make it a loosely coupled module" but harder to actually do, assuming you want features.

I believe that wallet metadata like balances need to be updated during re-orgs as well as any time an incoming transaction is received that affects this information... but I believe that the base case of a wallet is a simple collection of addresses and private keys.

All of those features belong in "derived classes" (or equivalent functionality) that can safely implement those by listening to a stream of incoming events.

With the normalized block database you can derive balances up-to the last node using sql even in an other process. Even build materialized views to cache if you have the database support for that.

The client serving bean (once there will be one) could then only care to listen to recent transactions and query the balance after block update (and evtl. reorg) from the database, that maintains transactional consistency etc...

Key store is a matter of taste and paranoia. I hope people contribute different flavors.

pynode (https://github.com/jgarzik/pynode) is also a full node implementation (sans wallet!).  It fully verifies mainnet and testnet3 chains, passing all available applicable conformance tests.

It's good to see another implementation though.

Congratulations Grau!

Please note that all DoS protections that the Shatoshi client has still haven't been implemented in bitsofproof supernode.
They are needed before putting nodes live on the p2p net.
I will review its security regarding DoS soon.

Thanks a lot Sergio!

I released the code also to harden it through feedback.

There is lot to be done and there are surely quite few bugs in a new implementation. I hope people like you deem it promising enough to invest time into.

Does it run on the testnet blockchain?

Only the bare minimum of testing is done until now, using the entire production chain and a few test cases.

It would be irresponsible to ship it with an installer ready to use by an end user, this is why I do not package,
but it is good enough convince developer to commit time to improve.

I promise to focus on testing and hardening from now on and as I said in a private e-mail will add some sort of peer testing feature.

Grau, I've updated the https://en.bitcoin.it/wiki/Weaknesses wiki to reflect current Satoshi client protections against DoS.

Be sure you include at least the most important ones in bitsofproof supernode before it goes to production.

These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:

•    Does not forward orphan transactions/blocks
•    Does not forward double-spend transactions
•    Restrict the maximum number of signature checks a transaction input may request
•    Continuous rate-limit of free transactions to mitigate 'penny-flooding'
•    Keeping a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.
•    Permanently ban IP addresses that misbehave for a time lapse (24 hours default)
•    Limit the number of stored orphan transactions (10000 by default)
•     Use a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions
•    Limit the number of stored signature in the signature cache (50000 signatures by default)
•    Tries to catch errors in transactions before the time consuming signature verifications.
•    Penalize peers that send us lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.
•    In orphan/signature caches: when removing an item, evict a random entry.
•    Data structures are specially chosen to avoid loops in which the number of iterations can be controller by an attacker that result in exponential complexity.
•    Ignore big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.
•    In RPC: Only send a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.
•    In RPC: Sleep some time if authorization fails to deter brute-forcing short passwords.
•    In GUI: Limit URI length to prevent a DoS against the QR-Code dialog

Best regards, Sergio.

Thanks Sergio, I will definitely verify against the list.

Testing against testnet3 is in good progress.

I proudly announce that the bitsofproof supernode just validated all testnet3 transactions.

That means it now supports all sorts of sigs and scripts.

For those skeptical of the normalized database: The node running on my laptop validated and stored the 6200+ transactions block on the test chain within a few minutes. My server reloads the entire production chain in a couple of hours.

Minor (unconfirmed) DoS Security vulnerability: the "unconfirmed" table is implemented over a HashMap whose key is the hash of the transaction (as a string).

I'm unsure reading your code if the attacker can submit two unconfirmed transactions that spend the same inputs, but in that case it would be easy for an attacker to flood the unconfirmed HashMap with entries that map to the same hash bucket, degenerating to linear access complexity.

It would be better to switch to a TreeMap data structure.

Hello Sergio,

great to see that you took a closer look.

I think that attack however would not work, as the attacker would have to create several otherwise valid spends with different hashes, since transaction validity is checked (and throws ValidationException exception if not) before caching the transaction.



I am currently working on BCCAPI implementation (at about 90%), thereafter I would want to go through systematically with a DoS hat on taking your criteria list.

Let me know if you would want to do a walk through via e.g. Skype.

Is there plans to support BIP 23 Block Proposal? I could probably run a node on Eligius verifying its templates against bitsofproof with this :)

looks like an interesting piece of work and so far the code looks very clean.

i somehow agree that implementing a wallet internally does not make a lot of sense.

my question is, since this is called a "supernode" are there plans to run such a node on a clustered environment, such as with Akka?

Yes, I build this for the server, for enterprises and miner. Bribe or inspire me and you'll get BIP 23.

Not enough "bribe" to get more real-world mining testing? Proposals wouldn't be for Eligius's benefit, but for your own: your code will be tested for checking numerous possible blocks every day, and any failures will be reported to you for analysis/bugfixing. After it's proven to be reasonably reliable, I'd even make Eligius refuse to produce blocks your code rejects as a security measure - this way someone can't get Eligius to mine a block attacking bitsofproof users ;)

Thanks, I believe code that deals with money should be clean. It helps, that I am writing code for trading since decades.

I call it supernode since it is for the big server of near future, not for the kids, not for the mobiles. If we want the world, we need server that digests hundreds of transactions per second and deals with terabytes. To get there we need modularity and yes at some point clusters.

What you attempt is inspiration and are doing a good job. Let me read the proposal, in the meanwhile you think a bit longer about bribing :)

Mining (just for fun and precise understanding), and BIP23 his is next on my list.

great work grau! I like the way you code, and your attitude!  keep it up :)

thanks! That's too much to handle :)

I invest most of my free time into this since months; comments like yours help to keep going.
It would however be canting not to admit that I do eye a profit at the end.

How do you plan to make a profit? Consulting?

Consulting is an option.
I also have end user facing ideas I will build on this fundation.

BCCAPI support is now implemented, that is an interface to lightweight clients (originally invented for BitcoinSpinner)

BCCAPI makes it easy to retrieve balances or account history for a public key. Create and send transactions whereby the server does not store private key.

The implementation is not tested enough for production use, but works for unit tests, so developer might want to look at it.

New feature of the day: Collects and stores and uses peer statistics (version, agent, traffic, response time, ban reason... ) in the database.

New feature of the day: Implemented pruning of the chain to unspent output.

The pruning is on a logical level, add option -p <hash> to the startup and it will calculate and store the unspent txout upto that hash into a separate snapshot table.

The resolution of inputs uses the most resent snapshot plus what comes thereafter. You can delete the snapshots also, the since full data remains, it keeps working...

A step back: Pruning was not correct. Reverting and thinking...

Have you tested block chain reorg?  i.e. where a previous-best chain is overtaken by a stronger chain, causing transactions to be un-confirmed?

I know thats the tricky part.

The bitsofproof node logically "reorgs" by deciding which block is the trunk head (with the most cumulative work). The blocks are only linked backward to previous. Traversing from the trunk head block leads to genesis although there are alternate heads with partially different paths to root. When a block connects somewhere I decide if it has now more cumulative work than the trunk head, then it is the new trunk head. Thats the "logical reorg" since nothing really moves, just a trunk head is identified for the decision on spend-ability of an output:

The decision if an output is spendable is done by traversing back from trunk head using backward pointer of each block only taking into account transactions of blocks on that path.

Since I cache the linked chain (tree) of block hashes traversing to find the right path (that is list of block hashes) for the query is fast. In addition I now build a cache of spendable output (instead of pruning).

To also answer your question: No. I need to create test cases.

I think, best I create basic mining now, so I can mine my own chain creating the weirdest test cases.

are you going to stick to the IVY  build system? i tried to get the environment running in intellij, but this provides no meaningful IVY support. if you had used maven or even just plain old  lib directory with all dependencies it would be much easier for me. currently i am butchering random jars together along with rewriting some code, which makes keeping up do date with your changes hard.

since you do have test cases you should consider running them automated on checkin with jenkins or teamcity. i just pulled in some changes which broke the build because of missing classes. (QKnownPeer is missing along with others)

thats not to be meant as criticism, i think the code looks interesting and i want to see where the project is going. my suggestion about ivy vs maven means that the code would get more accessible to other developers, plus i am lazy and do not want to spend a lot of time setting up my ide for this project :)

I will mavenize the project in the course of serious testing soon.

The classes with Q at the begining are generated during the build, this is rather an indication that you were not using the build process as suggested.

Let me write on the vision of the projet in a next mail.

I understand that you only spend time on a project if it is aligned with your goals, therefore let me give you my vision of it:

The vision is to create THE bitcoin implementation for the merchants and miner, similar to what apache is for the web.
You might think I suffer under delusion of grandeur, but hey, I would not sacrify my precious free time if it were for less.
Let me make the claim plausible by enumerating that the bitsofproof implementation already achieved:

- Complete implementation of the Bitcoin communication protocol with a high speed NIO IO that is able to deal with a large number of peers.
- Complete implementation of the Bitcoin script language, such that it verifies all sorts of sigs and multisigs on production and testnet3 chain
- Normalized store of the chain into a relational database that now allows auditing and arbitary querying of all transactions with the tool of your choice.
- Online calculation of unspent transaction output (UTXO aka. logical pruning)
- Multithreaded evaluation of transactions of a block and even inputs of the same transaction, that gives together with UTXO unparalelled processing power.
- Implementation of the BCCAPI that enables BitcoinSpinner compatible/like lightweight applications to retrieve balance and send transactions without server store of private keys.

I claim that the vast majority of implementation work is done, what remains on the roadmap is:

- Mining support
- Serious testing
- Packaging

I share the foundation with the community for our mutual benefit, thereafter I will focus on my own value added services and consulting.

Should you share the vision and would love to have a strong fundation for your business, then lets join efforts, show me your pull requests.

Let me also use the opportunity to THANK for the first donation onto the address below.

Audit-ability is prerequisite for serious business use, therefore I created a utility that reads the database filled by the bitsofproof node and performs off-line audit.

This tool shares only basic data access and serialization primitives with the server code, so it is fairly independently validating the database content.

You see below an example output:

Let me know if you have further ideas for health check of the chain stored.

Here is one list: https://en.bitcoin.it/wiki/Protocol_rules (https://en.bitcoin.it/wiki/Protocol_rules)

That is already implemented, in the server code.

This is about independent global fiscal checks.

Are you talking about pure binary yes/no consistency check audit?

Or are you talking about open-ended auditing for the purpose of discovering normal vs. abnormal transaction patterns?

I've spoken a while back with an experienced forensic accounting professional and we discussed various things that would require keeping true time vs. block time stamp. It would also require keeping a separate database of the in-flight transactions, ones that aren't yet recorded in the blockchain.


The observation he had made is that the blockchain is a perfect whitewash: it leaves no trace of the attempted double-spends or other malarkey that would be of great interest to a forensic auditor, e.g.

a) list of addresses involved in the attempted double-spends
b) list of addresses involved in transactions recorded in the orphaned sub-chains but not recorded on the winning chain.

I'm not actually suggesting that you actually implement those auditing reports. But it would be nice if your architecture made possible generating such reports.

I meant with audit the proof of consistency of the stored chain independent of the process that maintains it.

Since the bitsofproof node stores all data in a normalized relational database, you should be able to use any data mining package you prefer.

The data currently collected is what is needed to work.

I would be interested to know what extra data would support forensic accounting, and would attempt to derive it from the server's interaction with peers.

The additional data that is not available from the blockchain:

1) true timestamps for transactions first (and last) seen over p2p
2) true timestamps for blocks first seen over p2p
3) non-volatile database of transactions seen over p2p (a.k.a. mempool, but non-volatile) pruned of the entries actually recorded in the blockchain.
4) a way to quickly locate only orphaned blocks without having to scan the whole table of blocks, really just an additional index to the blockchain storage, but explicitly indexing all the losing chains. This in theory is available from the blockchain, but under current architecture it is difficult to obtain this information. In effect the whitewash of the bitcoin transaction history is ongoing when the tools keep only the winning chain.

Thanks.

None of these sounds difficult to add.
In fact 4 is already there since the HEAD table contains pointer to all leaf nodes not only the trunk.

The project just got mavenized by pulling from the first contributor: https://github.com/bartfaitamas/supernode/tree/mavenizing

sounds great! will have more looks at at and try to get it running later this week.

It is time for a project update.

[HYPE]
I enumerate some challenges and the bitsofproof answers to them.

1. Responsiveness to a large number of peers.
This is addressed using non-blocking-IO and a thread pool that forwards fully read messages to their listener, that are otherwise isolated from the complexity of the communication.

2. CPU hunger for signature validation.
This is not a current concern for the bitsofproof node since validation of transactions in a block and inputs the same transaction are executed simultaneously. CPUs are utilized to their limit, as many as you provide.

3. Resolving the inputs of a transaction against the database of previous transactions.
Using a faster database (some NoSQL) or SSD drives only give you a short break until the bottleneck re-appears as the network grows.
A sustainable approach to address the problem is to constantly prune the data set searched. The bitsofproof node uses a separate archive transaction table(s) into which a parallel thread moves fully spent transactions much like a garbage collector reclaims storage. The live transaction table that is searched to satisfy new transaction inputs is kept close to the UTXO set.

4. The client API is implemented as a clone of BCCAPI, that provides services to lightweight clients trusting the server.

5. A server API is in draft, that will provide a high level access to persistent and transient data structures, notifications. The aim is to provide all features provided in bitcoind via JSON-RPC, but in bitsofproof's case using the invoker of your choice on an API defined as a proper java interface.

6. The next layer of scale will be implemented through distributing both storage and computation, considerations for this already influence the design.
[/HYPE]

This is code in development. I do not care of backward compatibility of interfaces or database for now.

Introducing an opportunistic cache of the last 100.000 transactions gave such a boost to the server that I thought it is worth writing about.
Apparently outputs die generally rather young and saving the db roundtrip for them is the single biggest boost I found until now...

Yep, pynode (https://github.com/jgarzik/pynode/) figured many of these things out, long ago.  A block (including TXs) cache is very useful.

For long running nodes, the signature cache is also very helpful.  Over time, transactions are accepted into the memory pool and signature cache.  When a new block arrives, the majority of transactions found in that block will have had their signatures pre-checked and cached, making acceptance of that block go more rapidly.

This looks very promising. Backend bitcoin engines need a nice modular format to allow for the many creative uses people will be coming up with.

are you honestly adding more info.. or just trying to point out that your "pynode" is *so* ahead ??

pynode is quite incomplete, as the TODO notes.  bitsofproof is farther along in many ways.

The point is that these are well known techniques, and it is disappointing that these are being "discovered" when the knowledge is readily available for anyone who looks.

I do not yet see how the signature cache actually helps, would you please elaborate?

A signature is a function of the hash of a modified version of the input transaction. The modification depends on which output of that transaction is to be spent. Aren't chances of seeing the same signature twice negligible?

Seeing a signature twice is the normal case:

• once as an unconfirmed transaction via "tx" message
• once as a confirmed transaction, via "block" message

It is critical to keep "block" message relaying (propagation) times as low as possible, to avoid creating incentives for miners to skip transactions.  Thus, a signature cache ensures that "block" messages are largely already verified, by the time they are received.

If miners are already shrinking their blocks due to propagation time, maybe it's time to consider that protocol improvement suggestion in the scalability page, about not sending the entire block every time, just the portion your peer doesn't have.

I don't know what exactly could be send instead of the body, though. Even if my peer has all transactions in his cache, doesn't he need to know the exact order I put them in my block in order to rebuild the Merkle tree? So just sending the header is not enough. Is there a shorter way to identify a transaction than its hash? Perhaps just an ordinal of the hash... you assume your peer has the same transaction pool you had, then as the body of your block you send a series of numbers which represent the index a tx hash would have in a  sorted array with all of them? Not sure that would work frequently... plus, the hash is probably small enough, it shouldn't be a big deal to send all of them.

I see, I was thinking only in the context of the chain, not chain and unconfirmed. Thank you.

I think offering sufficient fee in the transaction is the incentive that will keep working as the network grows, since CPU spent for validation does not come for free.

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

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.

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.

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

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.

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

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?

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?

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

Actually, I am sure there are bugs.

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

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.

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

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)

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://bitcointalk.org/index.php?topic=56675.msg677910#msg677910

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.

http://pathofhistory.files.wordpress.com/2012/08/1967_life-magazine1.jpg

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://bitcointalk.org/index.php?topic=94453.msg1046848#msg1046848

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:

A problem is that even with good testing it is hard to have confidence that the testing is good, and so the software remains untrustworthy even if its perfect. In fact, the more perfect the software is the more doubtful the tests become— They always pass!

Because of this, the fact that someone knows about an issue is a significant opportunity: If the tests find it then there is some actual evidence that the tests are sufficient. Not complete evidence, but some.  And right now the software is new and pre-production, so there is no harm created by some rules issues persisting for a bit, no risk to the Bitcoin network of someone exploiting the differences, etc. So finding something like this is an opportunity to build confidence in the software quality which would be destroyed by me just throwing out specifics about what is broken.

(And, of course, the tests are far from sufficient in the reference client— otherwise I'd just be saying "run the reference client's tests against your software". But the reference client's behavior is normative, so the bar is higher for alternatives: They have to emulate the rules related 'bugs' in the reference client: All (rules) bugs are features. This is one reason why Satoshi didn't support alternative clients).


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

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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!

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.

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

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 (http://blockchain.info/block-index/317068/00000000000000000ae2dba9951e28a3e6308ac7e9e8536104c503aa772c848f)"...

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 (http://sourceforge.net/mailarchive/message.php?msg_id=29991842) 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.

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 ?

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 ?

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

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.

+1, quoted for emphasis.

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.

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.

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

+1
This is the way to go forward.

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.

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)

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.

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.

I think miner will just stop running an implementation or version as they think it is marginalized in user population or if they think it will not get tracktion. The check is however cheap.

I think the proosal would increase network security against split and as a byproduct create a testing interface accross versions and implementations.

Since challenges would no longer be in the source tree compliant implementations could not just learn them since they have to reply correctly to any new challange.

Mining is already split to the process of block creation and POW since the second is no longer on CPU. Some will continue running both processes but I suspect more small ASICs and GPUs will trust pool operators they connect to for simplicity. Pool operators might differentiate themselves by having checks against several versions and implementations as added value service.

I think I will implement the proposal since it is useful for testing and make an instance of bitsofproof supernode accessible at bitsofproof.com for anyone to run checks against. Technical details will follow as it settles in the proposal I suggested.

Please participate in the design of this protocol extension proposal in the thread https://bitcointalk.org/index.php?topic=130327.0
I would like to refocus this thread to bitsofproof only.

I think that miners are a targetgroup in itself.

I have always wanted to provide bitcoinclients to other people, so they don't need to stay connected all the time and don't have to worry too much about the security of their computers. I wanted to run several instances of the satoshiclient, as I like how it encrypts the wallet and especially the powerful JSON RPC server. There is already so many software that works with the json-commands, it would be a great match to give a user access to a server and let them chose their own front end of their liking.

You already said that you wanted to incorporate the json rpc in your and I am wondering if you'll make it so that it would have access to multiple wallets as well?

The plan is to unlock innovation and new uses by offering a robust and compliant kernel that is modular and extensible as a service.

The primary interface to the kernel will be defined as a Java interface (BCSAPI), available throgh usual ways of remote invocaton just by configuration. For debug insight I prefer implementing JMX.

JSON RPC calls of bitcoind could be implemented on top of that by those seek backward compatibility with existing tools. I may also provide some as it seems appropriate or for demonstration.

I will try hard not to make a specific use part of this code base.

Wallets, client servicing, connection to other enterprise software and whatever people will come up with should build on that BCSAPI kernel interface, preferably remote invoking it.

BCSAPI == Bean Context Services API
or
BCSAPI == Business Connectivity Services API
?

BitCoin Server API

I promised some comparison of leveldb and relational model and have some feature updates:

Performance
bootstrap node from scratch (Merkle root and POW check and store until block 210.000 thereafter full validation of scripts)

in Minutes:
                    until block 210.000      then until most recent block
LevelDB               93                        61
Relational         3664                       297

That roughly 2.5 hours against 2.5 days.

I run this on:
Linux bitsofproof 3.2.0-31-generic #50-Ubuntu SMP Fri Sep 7 16:16:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
with 4 2GHz processors 16GB RAM, Derby 10.9.1 with 400MB cache.

New features
I split the code base into

• supernode - the protocol implementation and storage engine
  
• supernode-api - a java interface that defines (not yet complete) BCSAPI and basic primitives needed in local code base of clients e.g. Hash, sign.
  
• supernode-testclient - a small java app that uses the BCSAPI to demonstrate connection and work with running server
  

The remote calls are accomplished with Java RMI using two way authentication and encryption over SSL.

An example use of securely connecting to remote bitsofproof supernode:
start the server (running on a linux server in a datacenter in Germany):
    nohup java -server -Xmx4g -jar target/supernode-0.7-SNAPSHOT.jar production relational &

ask for the balance of the bitsofproof donation account using the test client (running on my MacOS laptop at home in Hungary):
    java target/supernode-testclient-0.7-SNAPSHOT.jar -a 13xhxy21to93Lrb7d4ssZVaMnFtQVvRkSk
prints:
13xhxy21to93Lrb7d4ssZVaMnFtQVvRkSk balance: 1400000000
thats 14 BTC, retrieved in a roundtrip of 72 miliseconds.

the same momentary balance for 1dice8EMZmqKvrGE4Qc9bUFf9PX3xaYDp balance: 67391770
roundtrip time 658 seconds. (ca. 1.5 million transaction outputs retrieved on server side)

May a bitcoin noob ask what's that node for (or where can i read something about that?). I always thought a bitcoin qt (bitcoind) was a node in the network?

Is this something the "Average Joe" should deal with? ie. run it on a server themselves?

bitcoind defines the network now as most nodes run it.

That one size will not fit all

• Average Joe will be tired of gigabytes of data and traffic and will use e.g. MultiBit or move away from PC to smartphones to use bitcoin.
• Merchants will want to explore new unique uses and connect bitcoin with their other other systems.

I build the bitsofproof supernode for the merchants, who need modularity, scalebility, connectivity.

Ok than you for clarification :)

So this node is for the big boys around here.

Also for those who wanna be big :)

The bitsofproof supernode now features an asynchronous communication bus with corresponding API to subscribe to validated transactions, block chain events (extension, reorg) and block templates.

The bus allows submission of mined blocks and new transactions and is supported by a generic purpose JMS message broker, in my case Apollo MQ. The use of such message broker allows efficient message distribution to a large number of known counterparts, while taking care of authentication and authorization to publish or subscribe to different topics the messages are queued on.

Both server and evtl. clients connect to the bus using SSL sockets over the internet.

Also added documentation on configuration and database schema overview in:

https://github.com/bitsofproof/supernode/wiki

The version is superseded and the file mentioned below is no longer offered

I have an alpha quality preview for those curious of the supernode but do not like dealing with java.

You find a windows installer under ftp://bitsofproof.com/supernode-0.7-SNAPSHOT-setup.exe (ftp://bitsofproof.com/supernode-0.7-SNAPSHOT-setup.exe)

You can download a plain zip of executable here
ftp://bitsofproof.com/supernode.zip (ftp://bitsofproof.com/supernode.zip)

It is a compiled version of the original java code to native windows 32. It does not require you to install a java runtime.

The program does not do anything directly useful since it has no wallet. Should you figure it is still useful for some purpose, do not use it yet for real. It just downloads the chain and then validates and relays transactions. For production chain it validates and Merkle roots and proof of work until block 213900, therafter full validation of scripts. It does full validation from the beginning on testnet3.

Execute the installer and choose some empty new directory as target (without spaces in the path like "Program Files").
Once installed unzipped you may execute as:

1. production net with LevelDB. Data will be stored in a sub directory called data

2. production net with embedded relational db (derby) - data will be stored in a sub directory called derby

3. testnet3 in memdb - data remains in memory and starts over at every execution

It will ask for BCSAPI password at start. Just hit enter.

I am curious if the packaging works well on different machines and how you like it.

Why is it asking for Administrator privileges? Can you post a plain archive?

It should not. Is it because of the location you try to install it ? If not I create an other one.

It clearly shows in the manifest: requestedExecutionLevel="requireAdministrator". Please post something that 7-zip could open before installation.

I apologize that was not intentional. I uploaded a plain zip here:

ftp://bitsofproof.com/supernode.zip (ftp://bitsofproof.com/supernode.zip)

Thanks. It seems safe enough to run. So I tried "testnet3 memdb". It cannot bootstrap itself off the IRC on a machine with a real dual stack IPv4 + IPv6. I think this bug exists in the Satoshi's code too, I just start Satoshi with -noirc. I killed it because the error that keeps scrolling is "Peer connector IRC receive ERROR :Trying to reconnect too fast.". I don't want to DoS anybody's IRC servers.

I am not sure, since I saw this occasionally and could not yet find the reason. Try re-running, you might get an other IRC server assigned. IRC discovery sucks. I can not offer a quick fix there I am afraid. 

Did you try production leveldb that uses DNS discovery ?

"testnet3 memdb" failed 4 times in a row with the same IRC problem.

"production leveldb" starts, but spews too fast to really understand what's going on.

Attempting redirection of standard output gives 'Exception in thread "main" java.io.IOException: unable to obtain console' and exits.

May I also have one suggestion: configure the program to default to "-nolisten", because it pops up the firewall configuration dialog first time it is being run. I let it have the firewall exception enabled, but I would really prefer if the program didn't ask for it first time.

I will try to disable Ipv6 for IRC and not listen by default. The exception is because of the password at the beginning. I disable that too.


This is just a demo and it meant to demonstrate that it is doing a lot and fast.
I will let the log filtered to INFO at the console and write the rest into a file.
But its too late for me today...

Thanks. I don't mind that it spews everything at TRACE level, but I do mind that I cannot redirect and grep/tee/tail through it (on Windows it would be findstr.exe and tailf.exe). If the "no stdout redirection" is not easily fixable then at least make the log file a complete log not "everything less than INFO" log. Thanks again and good night (or good morning.)

I updated so you can now redirect. Since it is a just a preview I will not invest more into it.

An update on testing progress.

The bitsofproof supernode now passes bitcoind´s script and transaction related unit tests as stored in the Satoshi code:

base58_encode_decode.json
script_invalid.json
script_valid.json
tx_invalid.json
tx_valid.json

I think this is a promising result of compatibility. May I honor the compiler of those tests, they really helped to pinpoint very subtle differences.

In 2013 I will write more complex tests for blocks an chain events.

CONGRATULATIONS!  These updates fixed the first of the issues I saw in code review (https://github.com/bitsofproof/supernode/commit/f3a6767a840ab9ef7738e4bfcb8d64fd7f0505f2#L0R203). You also fixed a later issue I found in review, and several issues I did not notice (https://github.com/bitsofproof/supernode/commit/f3a6767a840ab9ef7738e4bfcb8d64fd7f0505f2#L0R224).

This is a big improvement, and even though I've been complaining that you're obligated to get all this right I don't at all mean to imply that its a small accomplishment.  However, some validity issues remain. I'm surprised the tests in the reference codebase got you as far as they did here (well, also because I think I previously though you'd already consulted them.  The next testing point would be Bluematt's blockchain tester.

does an RPC interface like bitcoind ones exist?

This will offer synchronous remote invocation for a few functions and have an asynchronous message bus for notification and broadcast between known extensions or authenticated clients. The API (BCSAPI) is supposed to isolate components that need highest level of compatibility with bitcoind from the rest, where innovation should take place. The BCSAPI seeks to serve low level data, such as validated transactions and blocks chain events or outputs by address eliminating the need to hack into core components or interpret binary storage.

I do not plan to imitate bitcoind's RPC out-of-the-box but, make it possible to implement extensions/proxies connecting to above API that create a compatibility layer if you need.

This is a project in development, so interfaces or database schema will likely change. Keep watching this space for a ready to go before using it for real or committing serious development on top of the API.

Suggestions, wishes are welcome.

thanks, il take a closer look ASAP :)

It's great that you made progress with testing. Unfortunately the first issue I saw is still there. As it's a chain-splitting bug more testing is required.

I just fixed a subtle one that fits your description. Maybe this was it. You might admit without me claiming that I am done :), I know there is still work to do.

https://github.com/bitsofproof/supernode/commit/96c6ffb00f55d2e8b95e55e3237309f86e6e11f2#src/main/java/com/bitsofproof/supernode/core/CachedBlockStore.java

As far as I can tell the issue is still there.

An update on testing.

The bitsofproof server validates testnet3 chain, passes its own and bitcoind's script unit tests and run in sync for the last week without any exception connected to the prod net with 100 peers.

I was pointed to the "blocktester" that was developed by BlueMatt for bitcoinj and adapted for bitcoind as part of the jenkins build after each pull.

My findings with the "blocktester" are:

• It uses the bitcoinj library to generate series of sophisticated block chain test scenarios.
• The generator is part of bitcoinj but is packaged such that it can not be utilized without modification for an other product, it serves bitcoinj maven test.
• The chain that it generates is likely dumped into a file and then sourced into bitcoind, I could not find the process that does that fed through P2P into bitcoind.
• There is a standalone java class that runs on BlueMatt's jenkins build server that downloads the test scenario chain from bitcoind and compares it with expectation (that is simple the residual correct chain)

Above findings explain why the tester could not be used out of the box for bitsofproof, but I made the best out of it in following steps:

• Modified a copy of bitcoinj such that the block generator could be embedded into an other project.
• dumped the generated test chain into a JSON file, that contains the behavior the tester expects and the raw block data as wire dump in hex.
• Wrote a unit test for bitsofproof that sources the JSON encapsulated wire dump as if it would be sent to the validation and storage engine.
• compare accept/reject of the blocks as expected by the test vs. done by bitsofproof.

Thereby I made following findings:

• The tests allow spending of coinbase earlier than allowed by bitcoind. The method this is fed to bitcoind must surpass that check.
• The accept/reject assumes that checks for double spend are not performed for branches of  the chain until that branch becomes the longest.

Especially the second is a difference to bitsofproof behavior, that is more eager to do this check. The result for the longest chain (that counts) is same in both cases but validations happen in different order. Since tests as they are depend on the validation order, conversion of test cases will remain partial.

I believe that the method bitsofproof works is more elegant and easier to follow, but it comes at the cost of eventually performing throw away validation. The cost is low since double spend checks are done after cheaper checks like POW, so using this difference to DoS bitsofproof is not feasible.

Edit: The described difference is not observable on the P2P interface.

Given the unsatisfactory state of test utility for complex behavior, I began developing a tool similar but more advanced than the block tester. I will explicitelly develop it to be suitable for bitcoind and bitcoinj or any other implementation that is P2P compatible, thereby addressing a problem that is not only mine.

Edit: unsatisfactory is that test cases are programmed in a particular implementation and are tightly coupled with its build.
I would like to create test cases for complex behavior as editable text files, so they can be extended by the maintainer of any implementation
 

IIRC, bitcoind has soft (bitcoind's) and hard (Bitcoin protocol) limits for that. Meaning that it will not spend nor build a block spending coinbase less than 120 blocks old, but it will accept a block which spends it a bit earlier (100 blocks I believe, not sure).

Hard limit: 101 confirmations, i.e. created 100 blocks before (network rule)
Soft limit: 120 confirmations, i.e. created 119 blocks before (client policy, which is probably overly conservative)

Considering cases like these, it occurs to me that it might be desirable to - at some point - split the Satoshi code into three parts: "legacy", "current" and "next".

The "legacy" part would handle the odd corner cases described in the above quote. It would basically pull in all the relevant OpenSSL code into the legacy module (including the bugs in question), where it would stay untouched. This module would only be used to verify already-existing blocks in the chain; no new blocks would be verified with this code, as pulling in OpenSSL code into Bitcoin and managing future patches is next to impossible. This is the part that should be possible for future clients to not implement. They will miss the part of the block chain that follows the rules defined by this module, but I reckon that we really don't need 5+ year old blocks for more than archival purposes.

The "current" module would handle verifying current blocks, and be compatible with the "legacy" module. It would depend on OpenSSL still, and if changes are made to OpenSSL that break compatibility with "legacy", patches would need to be maintained against OpenSSL to work around this. This module cannot code-freeze OpenSSL, as vulnerabilities can become uncovered in OpenSSL, and no one must be able to produce blocks that exploit the uncovered attack vectors. Newly uncovered attack vectors aren't a problem for the "legacy" module, as it only verifies already-existing blocks, produced before the vulnerability in question was uncovered.

The "next" module would be backwards incompatible with the "legacy" and "current" module. This module changes verification rules to not accept, for example, the otherwise invalid signatures that OpenSSL accepts. The "next" module would have a block chain cut-off point into the future where, from that point on, a Bitcoin transaction would be considered invalid if, for example, it includes an invalid signature (was it a negative S-value?) even though it's accepted by the old OpenSSL code. It's sort of a staging module, where undesirable protocol behavior is weeded out. These protocol changes wouldn't take effect until some point in the future (a block number). The block number cut-off point would be advertised well in advance, and from this point on, the "next" module would become the "current" module, and the old "current" module would move into the "legacy" module (and no new blocks would be verified using this module). The new "next" module would then target fixing undesirable protocol behavior that was uncovered when running the previous "current" module, and would set a new cut-off time into the future, at which point new blocks would need to follow this improved protocol to get accepted.

Couldn this work? It would mean we could slowly (very slowly) clean up the protocol, while still maintaining backwards compatibility with clients not older than, say, 2 years, or however long into the future we choose the cut-off point for the "next" module's protocol to become mandatory.

FYI the bug I mentioned way up thread has been found and fixed.

You might expect great progress of this project now that I work full time on it.

bitsofproof now passes the block tester test cases that is also used to validate the Satoshi client.
Mike Hearn was so kind to notify me that the error he spotted is fixed in the meanwhile.

You can review a continuos integration test of it similar to the official client's pull tests at:

https://travis-ci.org/bitsofproof/supernode

I plan to bring this to production quality definitely before San Jose conference where I plan to present and launch.

Please experiment with it. It is a modern full validation implementation that loads the chain from scratch in about 8 hours if using the leveldb option. An instance of this server is constantly working in sync with the network without exceptions for over a month now at bitsofproof.com, feel free to connect and challenge it.

I am working on further tests and a merchant module that will support multiple wallets and payment notifications over its communication bus. The project is also considered as a building block for bitcoinx.

The bitsofproof node sailed through the recent chain turbulences.

It was accepting the forking block in sync with 0.8 and was also able to re-org the 25 blocks as the other branch became longer.

8 hours is a long time, are the bottlenecks known (ie. tested and made publicly)?

I'd say bootstrap duration is on par with the reference client.

You would use this implementation to create functionality not offered by the reference implementation, not to compete with that within its abilities.

Kudos to you. Are you happening to attend the San Jose conference?

ok then il have to rephrase, 8 hours on which HD/CPU/System?
have you tested it with tmpfs? (its not about to pick a software which syncs the fastest, thats stupid. just wanna know where the known bottlenecks are in generell).

Thanks Jan. Yes I will be there. Will hold a lightning session speech on bitsofproof.

I use a 4 dedicated vCPU server with 2GHz each, 16GB RAM and an encrypted virtual file system. Bootstrap time is about 8 hours if using leveled option. Bottleneck in bootstrap before the checkpoint (hard coded chain hash for height 222222 at the moment) is disk I/O thereafter as it does full script validation, bottleneck becomes CPU. Script validation is fully multithreaded all processors are on 98+% during that time.

Once synced this server is able to cope with current transaction traffic using single digit CPU percentage use. There are very short spikes to 100% as it validates new block coming in. Disk I/O is the limit for serving getdata requests and queries during normal use.

The current disk footprint is 12GB for the chain. Beware that this stores several indices do speed up queries by address to tx and blocks.

thats exactly what i wanted, ty!

Is there a more recent snapshot than the one at ftp://bitsofproof.com/supernode.zip? It looks like that was last updated about 3 months ago.

Is there a way to configure where it puts the data file for LevelDB? Right now they appear to go to C:\Users\%UserName%\data (Windows 7). It would feel more standard for them go to C:\Users\%UserName%\AppData\Roaming\BitsOfProof or somewhere inside the folder that contains the exe.

No, that build was a demo, long outdated and not supported. I do not currently plan to release a windows executable build.

What versions of Java, Maven, and protoc are required?

I just tried building ("mvn package" - Windows 7 64bit) from git and it failed. I can't see the exact message because the mvn window closes automatically. It appears to make the \api\target directory, but there are just a couple of subdirectories (no actual files). In addition, it modifies \api\src\main\java\com\bitsofproof\supernode\api\BCSAPIMessage.java by quite a bit.

Any suggestions?

@PRab If you just want more scroll back you have a few options:
-change the command prompt properties in the title bar and increase the "screen buffer height"
-pipe it out to a file, i don't know what mvn goals you are using so these are just examples "mvn clean package -l mvn.log" or "mvn clean package > mvn.log", unfortunately you can only redirect output and won't see the output in the CLI
-use a proper IDE like Eclipse or IntelliJ CE which should give you as much scroll back as you need and code URLs

I haven't tried figuring out what version of protoc he's using either, which is where I'll have to turn my attention to grau

@grau I have some experience as a build manager and going to say "bad grau, bad", repeat after me "i must not include implicit external dependencies in maven builds". In maven you must be explicit in your pom files in such situations. That is the price you pay when including such dependencies, whether you use maven or something else.

If you can't include it due to licensing or any other reason, use a stub pom that declares what version you are using and a link to any licensing terms and/or where to get it. It's painful, but less painful than another developer trying to read your mind.

Here's the default log level error I get:

Also, seeing an ant-run makes me a sad panda, but it's adequate if it's not causing an build problems.

Recent versions of java and protobuf, that is Java 6 or 7, protobuf 2.x are needed.
The protobuf compiler generates BCSAPIMessage.java.

I am sure you find better sources with google on how to install java, protobuf or use maven on windows than my answers, since I avoid using windows whenever I can.


You see the errors because the protobuf compiler is not installed or not in path.
Let me know if protobuf compiler dependency and execution can be formulated more elegantly and I will amend.

The build works as documented on https://github.com/bitsofproof/supernode/wiki/Build. Basically a one liner.

I am confident that this is the case, since the build is executed on a fresh git clone with every commit using random machines supported by the travis-ci project. Also all unit test are running through there. See recent (and historic) build and test outputs here: https://travis-ci.org/bitsofproof/supernode. The travis configuration is also trivial, just asking for default protobuf installation, see here: https://github.com/bitsofproof/supernode/blob/master/.travis.yml

i'm interested in implementing this on aws and building a pristine community image and good documentation or even automated security automation on setup, and also getting running in a worker role on azure...anyone interested in collaboration?

I thought this server will be basis for unique implementations, not a commodity client for end user. Tell me a bit more about the use case you address please.

Ok, I think I a pretty close to having it. I swapped out protoc to version 2.4.1 (was at 2.5.0). Looks like it compiles but then fails while running a self test.

http://pastebin.aquilenet.fr/?7810ca4c946a733a#cvCNsQFIP0bzRKaEzQIIqB6DiEbmiK4zeqmgen61Bf8=

Any suggestions?

Looks like maven would not build the right path for tests, since it can not load the log config. This could be also the explanation for not picking up the right security provider (bouncy castle). You likely have some unique environment or build of maven. Local hosted repositories or patched?

The:
[debug] execute contextualize

lines in your maven output suggests this is some patched maven.

i find your suggestions a bit dissatisfying from a build perspective. You are using platform independent language and a platform independent build stack and yet you are suggesting your actual build may in fact be platform dependent. I understand you have other priorities bringing up the code to a high level of quality, but you should be in the frame of mind where your code and build will be platform independent at some point. PRab swapping out versions of protoc is a perfect example of something Maven is supposed to unequivocally disambiguate. At a casual glance, everything else in the build is looks good, which is why build issue a bit confusing.

I did do some research the other day, and I can see you are including protoc in your build as it has been recommended in various forums. My main issue is that the recommendation is incomplete (some posts even acknowledge this), which is why PRab and I are unable to reproduce your build without a non-trivial amount of effort.

I feel I can contribute to helping you create a platform independent build or at least a clearer build path, so I will try to help you to that end. I'll need to find some more time to look into this and will contact you if I find I need any more information.

You are right, ideally I would care about build process on platforms other than Linux and OS X.
I do not have bandwidth.

I deleted my rant above, but you managed to quote it before I recognized that it was a non-productive outbreak of my long standing hate relationship with Windows. That system did cause frustration to me every time I had to face it.

Your help is appreciated. I understand your frustration (sounds familiar), but I did everything to make the build a no-brainer on any unix system. If you were figuring out build instructions for windows, that would be great to avoid similar frustration.

I believe that this system will be deployed in unix like environments in virtually all cases of production. Even if production environment would be windows it could use the built artifacts without recompiling them, so the issue is really limited to developer who have to use windows for some reason.

Note that I incorporated bits of proof zrt. and transferred the copyright on the bits of proof implementation of the Bitcoin protocol to it.

The license terms remain the same, that is Apache License, Version 2.0.

bits of proof zrt. offers custom extensions and commercial support for this implementation of Bitcoin.
The implementation is at beta stage, features will be further extended.

See further info at: https://github.com/bitsofproof/supernode

keep up the great work :D
(will donate next time a re-up at mt. gox)

Bits of proof website launched http://bitsofproof.com (http://bitsofproof.com) background info, presentations and documentation coming soon.

You might be interested to check the Jobs section.

Do you have host running bitsofproof 24/7?
What are you using for ECDSA? How many sigchecks/sec does it perform?
What's maximum number of peers you tested it with?
What anti-DoS rules do you have?
Thanks.

Yes, bits of proof runs since months in parallel on bitsofproof.com, with a few restarts for upgrades or data migration.
I run it with peers 20 regularly, sometimes 50.
There are a few ban rules similar to bitcoind and limits on message size (identical to max block) also limits on caches of orphan blocks and unconfirmed transactions. There is a limit on unsolicited connections.

Thanks for your answers. What ECDSA implementation do you use and how many signature checks/sec it can perform?

Bouncy castle. Just measured on my laptop with 2.5GHz i5 single threaded validation of ECDSA: 830 sigs/second.

Beware that
1. bits of proof has multithreaded transaction validation, therefore this scales about linear with number of processors available and their speed.
2. In practice signature validation is distributed over time since the server usually receives and validates transactions while unconfirmed, therefore block validation only triggers validation of those transactions it did not receive before.

We currently have a few hundred transactions per block, 95+% of them already validated in the minutes between blocks, therefore block validation is a fraction of a second even with this implementation of ECDSA.
Storing the block is much more effort than validating it in regular production.

The only use case where validation speed plays a role at the moment is initial block chain load and verification. There it can be up to about 2 seconds per block in worst case.
This is addressed by both Satoshi and bits of proof by not validating signatures until a checkpoint height (well behind current last block).

In summary, although this pure Java implementation of the signature validation is about a magnitude slower than the C heavily optimized for secp256k1, I do not consider it a bottleneck for now.
If it ever becomes one, it should not be a big deal to use JNI to call such an optimized native one. bits of proof already uses JNI to drive native LevelDB.

Thank you for detailed response.

bits of proof beta release 0.9 now features:

 - support for SPV clients using bloom filter
 - reduced disk footprint increased speed on server side:
       . block chain with indices is 10GB now.
       . loads from scratch under 4 hours
       . retrieval of transaction history for a set of addresses in a few seconds roundtrip over the bus.
 - a redesigned API
       . with bloom filtered subscription to validated transactions on the bus
       . encrypted wallet local file with several accounts (BIP32) and colors

Wow, that's a lot of new stuff :)

Is there a proof-of-concept client to play with?

Thanks, I know the effort in it :)

A member of my team works on a mobile client, preview likely available in two weeks.

For now, I suggest to look at this integration test to get a feel how a client would work:

https://github.com/bitsofproof/supernode/blob/master/server/src/test/java/com/bitsofproof/supernode/test/APITest.java

Added examples of how bits of proof can be the backbone of your Bitcoin enterprise:

       - BitcoinSpinner running against any bits of proof node, enabled through a BCCAPI over BCSAPI implementation https://github.com/bitsofproof/bop-bccapi (https://github.com/bitsofproof/bop-bccapi)

       - a primitive block explorer REST API, see https://github.com/bitsofproof/bop-explorer.git (https://github.com/bitsofproof/bop-explorer.git)

Please consider that both examples are demo only. Although the BitcoinSpinner clone you can build from there works on any android mobile, I do not advise or support running it for other than test purposes and do not guarantee the continuous availability of the server backing it.

Credits to Jan https://bitcointalk.org/index.php?topic=53353.0 (https://bitcointalk.org/index.php?topic=53353.0) for creating both the BitcoinSpinner application and the BCCAPI spec that enables the connection of lightweight, server trusting clients.

See You in San Jose, 9am Saturday in the Lightning session room and at the exhibit booth #28, where I will give further insight to bits of proof connectivity and launch a limited product offer to attendees. Conference schedule at: http://www.bitcoin2013.com/topics--schedule.html (http://www.bitcoin2013.com/topics--schedule.html)

^^
this link is pointing to the bccapi implementation
---------------

any chance of seeing your block explorer UP & RUNNING somewhere (possibly on your website)?
my dev machine will be tied for a quite a while, but i'd love to see how it works

good luck at the show! :D

Thanks, I amended.


This is definitely part of the plan. :) Let's leave some surprises to attendees in San Jose. Thanks for your support.

waited this long; so what's another 2 weeks

sent you some beer money for the show ;)

Thanks a lot, Cheers!

I'm investigating using bitsofproof or bitcoinj in backend for a service.

I understand bitsofproof is opensource. I'm also assuming the business plan is to keep it that way and monetize on consulting / services.

Is that assumption correct?

Yes, bits of proof is open source and the plan is to remain open source.

My company offers support, custom development, consulting and more ... to be revealed in 5 days in San Jose, 9am the Lightning session room or at the exhibit booth #28.

You might want to take a look of the bop-api-example and bop-bitcoinspinner, bop-explorer projects to see the power of the backend
supporting a command line, an Android app and a web application, in a load balanced enterprise server fashion.

command line (https://github.com/bitsofproof/bop-api-example)
Android (https://github.com/bitsofproof/bop-bitcoinspinner)
Web (https://github.com/bitsofproof/bop-explorer)

Bits of Proof sent complementary access to the BOP Enterprise Bitcoin Server to 70+ visitors of Bitcoin2013 who signed off for a trial.

Significantly enhanced documentation is now available at: http://bitsofproof.com:8082/display/BPD/Bits+of+Proof+Documentation+Home

Those who missed it: Bits of Proof presentation at Bitcoin2013

http://www.youtube.com/watch?v=iBLd_wFmbjg

BOP just got a new 12 CPU 48 GB RAM server.

That box downloaded, verified and address indexed the block chain from scratch in 4.3 hours using 50 random peers.

It is now waiting to serve you.

Wow, I suppose you meant 12 cores :)

BTW: I watched your presentation and the project seems great!

Yes, they are likely less CPUs, but 12 cores for sure. I order them by specifying the CPU power I want to use, how the data center maps that is up to them.

Hello grau, i've been playing with your code for a while - nice work :)

Questions:
1. How about some sort of contracts interface? How do you plan on implementing this?

2. How do I connect to a specified set of IPs only (mimic connect=ip option in bitcoin.conf). FixedAddressDiscorvery makes listed IPs as discovery nodes that can relay their cached nodes to my server instance. After a while my server hits timeout(?) and connects to those relayed nodes.

3. On testnet3 i cannot connect to nodes with getAddress ().isReachable 1000ms timeout, works fine when i change it to 4000ms; temp fix for BBST-7 for me.

Hi netrikare, thanks for evaluating. I am glad you like it.

1. Contracts is an exciting subject. BOP is however a commercial not a research project, therefore I would do whatever needed for a concrete use case, but do not currently plan invest into a generic interface. If you have the bandwidth and ideas I am however ready to discuss or even take a pull.

2. I think that you need to lower the number of connections required (see below from production.xml) to that of the addresses listed in the FixedAddressDiscovery, otherwise the discovery will try to locate more peers.

3. Thanks for the hint on BBST-7!

You already discovered our JIRA (http://bitsofproof.com:8081/browse/BBST). Feel free to raise any issues you face there.
 

I am pleased to announce that the server is now available in an upgraded Version 1.1.

What is new?

1. Enhanced HD Wallet - Read only wallet and server side scan for all addresses derivable from an extended public key.
2. Never out of sync with Satoshi - optional Master-Slave operation option effectively eliminates the risk of a fork.
3. Simplified API

Read about the features in detail on the documentation site: http://bitsofproof.com:8082/display/BPD/What+is+new+in+1.1

So they could have given you 2x Xeon L7455?

*scratch*

Does this supernode support mining of the coins like the bitcoind?

In case you mean support for miner protocols like getwork RPC, then no support for that. As of now I see no upside mining Bitcoin with this, not for the product and not for the network.

In case you are considering to develop an alt-coin,  then it would not be a big trick to add CPU mining with your rules as it has a memory pool of unconfirmed transactions.

Added a new demo project that shows how to sweep a private key to an address using the client library and a BOP server.
https://github.com/bitsofproof/bop-sweep

The trick can be done by a few lines, that execute in seconds. (The project is more elaborate)


Note that the key does not travel to the server, only its address to retrieve all unspent outputs and then the final signed transaction sending those outputs to the destination address.

So as I undestand the getwork protocol in not supported.

So to create a block with a coin base and the mechanism to do that, is not in the current code base?  What I mean is that bitcoind has a setgenerate true argument that starts up a bitcoinminer in CPU.  Is that part implemented or does that need to be reimplemented in your supernode?

There is a unit/integration test that shows how to build a chain on the fly to test the API: https://github.com/bitsofproof/supernode/blob/1.1/server/src/test/java/com/bitsofproof/supernode/test/APITest.java

The mempool is in https://github.com/bitsofproof/supernode/blob/1.1/server/src/main/java/com/bitsofproof/supernode/core/TxHandler.java
called unconfirmed.

I have however no motivation to put those pieces together into a CPU miner as there is no upside for that in Bitcoin and have no alt-coin customer yet. Let me know if you have commercial interest or want to work on it.

I'll probably work on it then.

Unable to build using mvn

My setup:
win7 pro (64bit)
java version "1.6.0_43"

[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] \code\Bitcoin\bitsofproof\supernode\api\src\main\java\com\bitsofproof\supernode\api\BCSAPIMessage.java:[11,22] com.bitsofproof.supernode.api.BCSAPIMessage.Ping is not abstract and does not override abstract method newBuilderForType(com.google.protobuf.GeneratedMessage.BuilderParent) in com.google.protobuf.GeneratedMessage
...

full error here
http://pastebin.com/GfUVKvYi

Why not follow the build instructions and install protobuf 2.4
1?

Grau, where is the schema now located, can't find it via that link? Thanks.

as of 1.2 the relational schema is no longer part of the community version, but moved to the audit server.

A dumb question I'm sure, but how to I set up users and passwords on a community edition server? I have a node running and am trying to connect with the bop-api-example and have had no luck connecting with a user and password.

The authentication is handled by the message broker. The community server is the open source code that you can build and run on your own with your own message broker process. e.g. ActiveMQ, so username and password depends on your configuration.

In case you would like to use an Enterprise Server hosted by BOP, then please drop me a mail or a PM.

Is bitsofproof.com down  ???

You were "lucky" to hit the maintenance window our hosting provider announced and used.

Um, I tried to open it on Sunday and Monday and it was down too, so maybe you need to change your provider.

I am quite sure it was not down. Maybe routing problems. Where are you accessing from?

Added BIP39 support,  that passes Trezor's test vectors.
https://github.com/bitsofproof/supernode/blob/master/api/src/main/java/com/bitsofproof/supernode/wallet/BIP39.java

Added Shamir's secret shares algorithm
https://github.com/bitsofproof/supernode/blob/master/api/src/main/java/com/bitsofproof/supernode/wallet/ShamirsSecretSharing.java

You can create a random word list e.g.:

You may now create a BIP32 master out of a word list as e.g.

Instead of storing the secret word list you could create 3 backups of which 2 is needed to recreate the list (and one is useless alone).


Now take any two of the three to reconstruct the key:


Use the passphrase option (the "" in parameters) to get plausible deniability of the wallet, since you may fund more than one passphrase.

Hi Grau,
thank you very much for your great work on bitsofproof supernode, I've just downloaded it and I'm trying to run it following your instructions but when I run

java -server -Xmx2g -jar server/target/bitsofproof-server-1.3.7-SNAPSHOT.jar testnet3 memdb

I get the following exceptions:

2013-12-12 10:22:02,325 [INFO] Main main bitsofproof supernode (c) 2013 bits of proof zrt.
2013-12-12 10:22:02,636 [INFO] Main main Loading profile: testnet3
2013-12-12 10:22:02,636 [INFO] Main main Loading profile: memdb
2013-12-12 10:22:03,776 [ERROR] Main main Error setting up spring context
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'application' defined in class path resource [context/server.xml]: Cannot resolve reference to bean 'bitcoinNetwork' while setting bean property 'network'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'bitcoinNetwork' defined in file [..\projects\supernode\server\target\classes\context\testnet3-profile.xml]: Cannot resolve reference to bean 'store' while setting bean property 'store'; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'store' is defined
   at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveRe ference(BeanDefinitionValueResolver.java:328)
   at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveVa lueIfNecessary(BeanDefinitionValueResolver.java:106)
   at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.ap plyPropertyValues(AbstractAutowireCapableBeanFactory.java:1360)
   at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.po pulateBean(AbstractAutowireCapableBeanFactory.java:1118)
   at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.do CreateBean(AbstractAutowireCapableBeanFactory.java:517)
   at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.cr eateBean(AbstractAutowireCapableBeanFactory.java:456)
   at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
   at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingl eton(DefaultSingletonBeanRegistry.java:225)
   at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
   at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
   at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstant iateSingletons(DefaultListableBeanFactory.java:609)
   at org.springframework.context.support.AbstractApplicationContext.finishBeanFactor yInitialization(AbstractApplicationContext.java:918)
   at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469)
   at com.bitsofproof.supernode.main.Main.main(Main.java:74)
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'bitcoinNetwork' defined in file [..\projects\supernode\server\target\classes\context\testnet3-profile.xml]: Cannot resolve reference to bean 'store' while setting bean property 'store'; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'store' is defined
   at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveRe ference(BeanDefinitionValueResolver.java:328)
   at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveVa lueIfNecessary(BeanDefinitionValueResolver.java:106)
   at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.ap plyPropertyValues(AbstractAutowireCapableBeanFactory.java:1360)
   at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.po pulateBean(AbstractAutowireCapableBeanFactory.java:1118)
   at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.do CreateBean(AbstractAutowireCapableBeanFactory.java:517)
   at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.cr eateBean(AbstractAutowireCapableBeanFactory.java:456)
   at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
   at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingl eton(DefaultSingletonBeanRegistry.java:225)
   at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
   at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
   at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveRe ference(BeanDefinitionValueResolver.java:322)
   ... 13 more
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'store' is defined
   at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDef inition(DefaultListableBeanFactory.java:553)
   at org.springframework.beans.factory.support.AbstractBeanFactory.getMergedLocalBea nDefinition(AbstractBeanFactory.java:1095)
   at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:277)
   at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
   at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveRe ference(BeanDefinitionValueResolver.java:322)
   ... 23 more
   
   
Am I missing something?

Thanks

Uups, I removed the memdb context by accident. Sorry.

Re-added now, fetch from github.

Great it works now!

Hi Grau,
I'm running BOP Server against production network using LevelDB on a CentOS 6 server, this is the command line

java -server -Xmx1g -jar bitsofproof-server-1.3.7-SNAPSHOT.jar production leveldb BCSAPI activemq

When I run the BOP Server the data directory and all the data files are created, this is the data directory content

drwxr-xr-x. 2 root root  4096 Dec 28 17:59 .
drwxr-xr-x. 7 root root  4096 Dec 28 17:47 ..
-rw-r--r--. 1 root root     0 Dec 28 17:47 000003.log
-rw-r--r--. 1 root root    16 Dec 28 17:47 CURRENT
-rw-r--r--. 1 root root     0 Dec 28 17:47 LOCK
-rw-r--r--. 1 root root 65536 Dec 28 17:47 MANIFEST-000002

but files are never updated so seems like the downloaded blocks do not get stored.
After a while I stop the Bop Server but the data file are not changed, this is a summary of bop-server.log

2013-12-28 17:47:18,604 [INFO] Main main bitsofproof supernode (c) 2013 bits of proof zrt.
2013-12-28 17:47:18,921 [INFO] Main main Loading profile: production
2013-12-28 17:47:18,922 [INFO] Main main Loading profile: leveldb
2013-12-28 17:47:18,922 [INFO] Main main Loading profile: BCSAPI
2013-12-28 17:47:18,922 [INFO] Main main Loading profile: activemq
2013-12-28 17:47:20,890 [DEBUG] LvlDiskStore main                                Compactions
Level  Files Size(MB) Time(sec) Read(MB) Write(MB)
--------------------------------------------------

2013-12-28 17:47:20,901 [INFO] CachedBlockStore main Reset block store
2013-12-28 17:47:20,944 [DEBUG] Supernode main Caching ...
2013-12-28 17:47:20,952 [DEBUG] Supernode main Starting network ...
2013-12-28 17:47:37,066 [INFO] BitcoinPeer Peer-thread-2 Connection to '/Satoshi:0.8.3/' [70001] at dnsseed.bluematt.me/71.236.191.178:8333 Open connections: 1
2013-12-28 17:47:37,610 [INFO] BitcoinPeer Peer-thread-6 Connection to '/Satoshi:0.8.99/' [70001] at bitseed.xf2.org/62.75.216.13:8333 Open connections: 2
2013-12-28 17:47:38,474 [DEBUG] TxHandler Peer-thread-15 REJECTING transaction 7fe8ccdbfc76ca8ede525460fb394aad64c7ed5f95e7a40b091f5bc4b5732280
2013-12-28 17:47:38,528 [DEBUG] ChainLoader Peer-thread-0 received block 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 from dnsseed.bluematt.me/71.236.191.178:8333
2013-12-28 17:47:38,537 [DEBUG] CachedBlockStore Peer-thread-0 stored block 1 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048
2013-12-28 17:47:38,537 [DEBUG] TxHandler Peer-thread-0 Removing 0 blocks
2013-12-28 17:47:38,537 [DEBUG] TxHandler Peer-thread-0 Pool size: 0
2013-12-28 17:47:38,537 [DEBUG] TxHandler Peer-thread-0 Adding 1 blocks
2013-12-28 17:47:38,537 [DEBUG] TxHandler Peer-thread-0 First seen in block: 0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098
2013-12-28 17:47:38,537 [DEBUG] TxHandler Peer-thread-0 Pool size: 0
2013-12-28 17:47:38,568 [INFO] BitcoinPeer Peer-thread-1 Connection to '/Satoshi:0.8.5/' [70001] at dnsseed.bluematt.me/77.249.29.66:8333 Open connections: 4
2013-12-28 17:47:38,616 [DEBUG] ChainLoader Peer-thread-0 received block 000000006a625f06636b8bb6ac7b960a8d03705d1ace08b1a19da3fdcc99ddbd from dnsseed.bluematt.me/71.236.191.178:8333
2013-12-28 17:47:38,618 [DEBUG] CachedBlockStore Peer-thread-0 stored block 2 000000006a625f06636b8bb6ac7b960a8d03705d1ace08b1a19da3fdcc99ddbd
2013-12-28 17:47:38,618 [DEBUG] TxHandler Peer-thread-0 Removing 0 blocks
2013-12-28 17:47:38,618 [DEBUG] TxHandler Peer-thread-0 Pool size: 0
2013-12-28 17:47:38,618 [DEBUG] TxHandler Peer-thread-0 Adding 1 blocks
2013-12-28 17:47:38,618 [DEBUG] TxHandler Peer-thread-0 First seen in block: 9b0fc92260312ce44e74ef369f5c66bbb85848f2eddd5a7a1cde251e54ccfdd5
2013-12-28 17:47:38,618 [DEBUG] TxHandler Peer-thread-0 Pool size: 0
2013-12-28 17:47:38,626 [DEBUG] ChainLoader Peer-thread-0 received block 0000000082b5015589a3fdf2d4baff403e6f0be035a5d9742c1cae6295464449 from dnsseed.bluematt.me/71.236.191.178:8333
2013-12-28 17:47:38,628 [DEBUG] CachedBlockStore Peer-thread-0 stored block 3 0000000082b5015589a3fdf2d4baff403e6f0be035a5d9742c1cae6295464449
2013-12-28 17:47:38,628 [DEBUG] TxHandler Peer-thread-0 Removing 0 blocks
2013-12-28 17:47:38,628 [DEBUG] TxHandler Peer-thread-0 Pool size: 0
2013-12-28 17:47:38,628 [DEBUG] TxHandler Peer-thread-0 Adding 1 blocks
2013-12-28 17:47:38,628 [DEBUG] TxHandler Peer-thread-0 First seen in block: 999e1c837c76a1b7fbb7e57baf87b309960f5ffefbf2a9b95dd890602272f644
2013-12-28 17:47:38,628 [DEBUG] TxHandler Peer-thread-0 Pool size: 0
2013-12-28 17:47:38,635 [DEBUG] ChainLoader Peer-thread-0 received block 000000004ebadb55ee9096c9a2f8880e09da59c0d68b1c228da88e48844a1485 from dnsseed.bluematt.me/71.236.191.178:8333
2013-12-28 17:47:38,636 [DEBUG] CachedBlockStore Peer-thread-0 stored block 4 000000004ebadb55ee9096c9a2f8880e09da59c0d68b1c228da88e48844a1485
2013-12-28 17:47:38,637 [DEBUG] TxHandler Peer-thread-0 Removing 0 blocks
2013-12-28 17:47:38,637 [DEBUG] TxHandler Peer-thread-0 Pool size: 0
2013-12-28 17:47:38,637 [DEBUG] TxHandler Peer-thread-0 Adding 1 blocks

......

2013-12-28 17:47:40,964 [DEBUG] ChainLoader Peer-thread-12 received block 00000000b98fcbc3ffa5735bca2dddb8ae01b75c01a1f055ba48b515eebef020 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,964 [DEBUG] ChainLoader Peer-thread-7 received block 000000003b3b42e8af3178e581f468b6d83e5acd419b00656d3d5c22b82ff29c from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,965 [DEBUG] ChainLoader Peer-thread-12 received block 000000002689f3021912d78bc8d5b046d2828a75dc695905b8743222b9907a8d from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,965 [DEBUG] ChainLoader Peer-thread-7 received block 000000004f2c63cf028a37e7fc793a47ace7c27d44aac2a82fd9d90dbfc1750d from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,965 [DEBUG] ChainLoader Peer-thread-12 received block 00000000417404b256f7fb76d9b6ec6a8077536369d120ac8ad1aa246b6e9da1 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,965 [DEBUG] ChainLoader Peer-thread-7 received block 000000005cd735eccf4aefbc7427efee70ee4adc886be67cc68f6f925c9c7e41 from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,965 [DEBUG] ChainLoader Peer-thread-12 received block 00000000292b0f6a658cfab5e4d69a7d5753a6fef74ced4ef82e7026042a97de from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,965 [DEBUG] ChainLoader Peer-thread-7 received block 00000000ecc3ba4a80a6d61ea3abc22a8fddf11d1f8019b7fbbde92e2b4dd4a8 from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,966 [DEBUG] ChainLoader Peer-thread-12 received block 0000000055f9514359114a754ab74471f39a5fe6034ca6d05ec14e2d03dbd626 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,966 [DEBUG] ChainLoader Peer-thread-7 received block 000000002436274e351576ee5c9d6a96ce64072d02713d20c32c36bf70f9fbb5 from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,966 [DEBUG] ChainLoader Peer-thread-12 received block 00000000a99927e355bb8699c583c2214cc796c42aa28b82337979b60ef3af1d from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,966 [DEBUG] ChainLoader Peer-thread-7 received block 0000000011e36edf0c01ecffe36ac4be9f4674c5438d5bd02f47a59c798f663c from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,967 [DEBUG] ChainLoader Peer-thread-12 received block 00000000d3ebca0f1cf140987959ba9231e9da43f3f76aed02d0cfe9d88b71d7 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,967 [DEBUG] ChainLoader Peer-thread-7 received block 00000000c3a81d9932edc9a2e3358e631b094d9628178bbf6089b12f75b08815 from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,967 [DEBUG] ChainLoader Peer-thread-12 received block 000000002b5e03ee6029c1f5703b7baaf097630ca55f91d93ddd412eb0d054e5 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,967 [DEBUG] ChainLoader Peer-thread-7 received block 0000000074e77a1e561ab5247bec8a977977d3dde3d70a74fabf0adc3d6bf4ac from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,967 [DEBUG] ChainLoader Peer-thread-12 received block 000000008e1bd9998d126a037a31e20c2be174f6c760ba32d1cfe2498f570cc7 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,967 [DEBUG] ChainLoader Peer-thread-7 received block 00000000dd9588e8b12025e5257267abe0e9134d493ab3b449a47db8d22567d2 from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,968 [DEBUG] ChainLoader Peer-thread-12 received block 00000000563679ac0304f948a6a515b06077b3b6ef118036d9dbe4ef32122597 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,968 [DEBUG] ChainLoader Peer-thread-7 received block 0000000084935be8a5b06525aea383d2988df6003963222f5adc5ddf5951e7fd from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,968 [DEBUG] ChainLoader Peer-thread-12 received block 00000000f977441badb36a6bbac2057f7c6464dea83fabde00636803ae536534 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,968 [DEBUG] ChainLoader Peer-thread-7 received block 000000000568dd391b3261d51ad4fcb68db5539200a15acc5bd6ece8b218601b from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,968 [DEBUG] ChainLoader Peer-thread-12 received block 00000000180b5bdbeb61d547a04adf658f7c9be695cd2c5d8fdf3e27e022d833 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,969 [DEBUG] ChainLoader Peer-thread-7 received block 000000005b30f48ef450de8ebdb8829a931e8cd86e2f11f48f381c61c845379b from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,969 [DEBUG] ChainLoader Peer-thread-12 received block 00000000915f7a477e3df905e1625c9e59ce63e6c26fa349f427b9cc314a4a76 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,969 [DEBUG] ChainLoader Peer-thread-7 received block 00000000d3d4c3b9014bd51bd891d1161d7ead2dbe8597561eb17b1b9c6465c3 from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,969 [DEBUG] ChainLoader Peer-thread-12 received block 00000000219c44b7a974528cfe22f831631ba20a4bd8e7a238918d1d2f13aec3 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,969 [DEBUG] ChainLoader Peer-thread-12 received block 0000000046ff6c4f9a7224aa331c407c7e37f49434571307d6fca58695bcba38 from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,969 [DEBUG] ChainLoader Peer-thread-1 received block 000000006aad240f2485670793fcc62eb5006a42aba22e32b6918d710a2583b3 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,970 [DEBUG] ChainLoader Peer-thread-12 received block 000000000d0d23516c5efd3af4eb951603bb30b2c93884b522a318b30e918ee7 from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,970 [DEBUG] ChainLoader Peer-thread-1 received block 00000000de071e247a1f44be9908714f0cc8282e2ddcdf7d2c4b3dbca9a624d3 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,970 [DEBUG] ChainLoader Peer-thread-12 received block 00000000fa041c4905c4eca1cc0c75204c2cd118da3ffd129c41840152038d20 from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,970 [DEBUG] ChainLoader Peer-thread-1 received block 00000000ef6644f79c0e3363c0359de10bc485d9d032af7c8097b325b54a2497 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,970 [DEBUG] ChainLoader Peer-thread-12 received block 00000000b9d2de60c26ad0ff1289bb6c97529cac7c5a37571900a0e6be77dca8 from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,970 [DEBUG] ChainLoader Peer-thread-1 received block 0000000067329a9d48d204813cc35e8b89a8c476f292d92f58691b9535b8da63 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,971 [DEBUG] ChainLoader Peer-thread-12 received block 00000000b96305605f1eb5ab800024ff3fa260deedf6005e1e3987daa11d3935 from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,971 [DEBUG] ChainLoader Peer-thread-1 received block 00000000ae07b04e64e658c2dd85bfab0da646352a42037940dd0d18ea6ed8a4 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,971 [DEBUG] ChainLoader Peer-thread-12 received block 0000000090e31ebfb5734092b91f0d8b1dc5f40cd7ff9c18b3f0e999278c7c91 from dnsseed.bluematt.me/71.236.191.178:8333
2013-12-28 17:47:40,971 [DEBUG] ChainLoader Peer-thread-2 received block 000000008ba08cce0c4845673a55800603a6e24be4c9977bc977fbb359db0078 from dnsseed.bluematt.me/85.17.88.56:8333
2013-12-28 17:47:40,972 [DEBUG] CachedBlockStore Peer-thread-12 stored block 352 0000000090e31ebfb5734092b91f0d8b1dc5f40cd7ff9c18b3f0e999278c7c91
2013-12-28 17:47:40,972 [DEBUG] TxHandler Peer-thread-12 Removing 0 blocks
2013-12-28 17:47:40,972 [DEBUG] TxHandler Peer-thread-12 Pool size: 0
2013-12-28 17:47:40,972 [DEBUG] TxHandler Peer-thread-12 Adding 1 blocks
2013-12-28 17:47:40,972 [DEBUG] TxHandler Peer-thread-12 First seen in block: 4c4c29d07679bfdad5f037ba429419d206a656782d5aa88ecd728a0033ac1a67
2013-12-28 17:47:40,972 [DEBUG] TxHandler Peer-thread-12 Pool size: 0
2013-12-28 17:47:40,976 [DEBUG] ChainLoader Peer-thread-12 received block 00000000dec5e5fbf851495db241e624012d675bbef96ec6dab5cdc91fa3b53b from dnsseed.bluematt.me/71.236.191.178:8333
2013-12-28 17:47:40,976 [DEBUG] ChainLoader Peer-thread-1 received block 00000000158b0585927acbb1fec533a7883045dabff45a3ee95fb9750a514344 from bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:47:40,977 [DEBUG] CachedBlockStore Peer-thread-12 stored block 353 00000000dec5e5fbf851495db241e624012d675bbef96ec6dab5cdc91fa3b53b
2013-12-28 17:47:40,977 [DEBUG] TxHandler Peer-thread-12 Removing 0 blocks
2013-12-28 17:47:40,977 [DEBUG] TxHandler Peer-thread-12 Pool size: 0
2013-12-28 17:47:40,977 [DEBUG] TxHandler Peer-thread-12 Adding 1 blocks


......

2013-12-28 17:47:52,113 [DEBUG] CachedBlockStore Peer-thread-11 stored block 1870 0000000039d64ce3bb6f073707a6ba831e6e2fbc7d9fae40709d162012b1253e
2013-12-28 17:47:52,113 [DEBUG] TxHandler Peer-thread-11 Removing 0 blocks
2013-12-28 17:47:52,113 [DEBUG] TxHandler Peer-thread-11 Pool size: 0
2013-12-28 17:47:52,113 [DEBUG] TxHandler Peer-thread-11 Adding 1 blocks
2013-12-28 17:47:52,113 [DEBUG] TxHandler Peer-thread-11 First seen in block: 5b7ab6b51cfaa24cfb92ea9a30bc6e539a684786a6ae71e72d9d897ed8e95657
2013-12-28 17:47:52,113 [DEBUG] TxHandler Peer-thread-11 Pool size: 0
2013-12-28 17:47:52,115 [DEBUG] CachedBlockStore Peer-thread-11 stored block 1871 000000009b258aba4631bcd3e763667edd28ca4960da6cfedf98f42e2631314c
2013-12-28 17:47:52,115 [DEBUG] TxHandler Peer-thread-11 Removing 0 blocks
2013-12-28 17:47:52,115 [DEBUG] TxHandler Peer-thread-11 Pool size: 0
2013-12-28 17:47:52,115 [DEBUG] TxHandler Peer-thread-11 Adding 1 blocks
2013-12-28 17:47:52,115 [DEBUG] TxHandler Peer-thread-11 First seen in block: 7c3d29ebc40581a5f6ac6891e3a3c83c8195c09aa9ce1f3123bbcce5b71013e0
2013-12-28 17:47:52,115 [DEBUG] TxHandler Peer-thread-11 Pool size: 0
2013-12-28 17:47:52,118 [DEBUG] CachedBlockStore Peer-thread-11 stored block 1872 00000000c2dfe3968ef3133e68e9d56fee1eee7409ea6986aafb5bd003f38478
2013-12-28 17:47:52,118 [DEBUG] TxHandler Peer-thread-11 Removing 0 blocks
2013-12-28 17:47:52,118 [DEBUG] TxHandler Peer-thread-11 Pool size: 0
2013-12-28 17:47:52,118 [DEBUG] TxHandler Peer-thread-11 Adding 1 blocks
2013-12-28 17:47:52,118 [DEBUG] TxHandler Peer-thread-11 First seen in block: f99b03f8875723c4df808a7a5aa3c457614c8b92fb0655d2c7799076e5293268
2013-12-28 17:47:52,118 [DEBUG] TxHandler Peer-thread-11 Pool size: 0
2013-12-28 17:47:52,120 [DEBUG] CachedBlockStore Peer-thread-11 stored block 1873 000000002aacdf4f815942c612af16cbd181b0102c1d9a09f41c6862815f9d89
2013-12-28 17:50:44,241 [INFO] BitcoinPeer Peer-thread-9 Disconnected '/Satoshi:0.8.99/' at bitseed.xf2.org/62.75.216.13:8333
2013-12-28 17:50:50,146 [INFO] BitcoinPeer Peer-thread-13 Disconnected '/Satoshi:0.8.3/' at dnsseed.bluematt.me/71.236.191.178:8333
2013-12-28 17:52:11,299 [DEBUG] P2P Peer connector Unhandled exception in peer queue
java.net.SocketException: Network is unreachable
   at java.net.Inet6AddressImpl.isReachable0(Native Method)
   at java.net.Inet6AddressImpl.isReachable(Inet6AddressImpl.java:77)
   at java.net.InetAddress.isReachable(InetAddress.java:441)
   at java.net.InetAddress.isReachable(InetAddress.java:400)
   at com.bitsofproof.supernode.core.P2P$2.run(P2P.java:709)
   at java.lang.Thread.run(Thread.java:722)
2013-12-28 17:53:12,672 [DEBUG] P2P Peer connector Unhandled exception in peer queue
java.net.SocketException: Network is unreachable
   at java.net.Inet6AddressImpl.isReachable0(Native Method)
   at java.net.Inet6AddressImpl.isReachable(Inet6AddressImpl.java:77)
   at java.net.InetAddress.isReachable(InetAddress.java:441)
   at java.net.InetAddress.isReachable(InetAddress.java:400)
   at com.bitsofproof.supernode.core.P2P$2.run(P2P.java:709)
   at java.lang.Thread.run(Thread.java:722)
2013-12-28 17:53:52,345 [DEBUG] P2P Peer connector Unhandled exception in peer queue
java.net.SocketException: Network is unreachable
   at java.net.Inet6AddressImpl.isReachable0(Native Method)
   at java.net.Inet6AddressImpl.isReachable(Inet6AddressImpl.java:77)
   at java.net.InetAddress.isReachable(InetAddress.java:441)
   at java.net.InetAddress.isReachable(InetAddress.java:400)
   at com.bitsofproof.supernode.core.P2P$2.run(P2P.java:709)
   at java.lang.Thread.run(Thread.java:722)
2013-12-28 17:53:56,350 [DEBUG] P2P Peer connector Unhandled exception in peer queue
java.net.SocketException: Network is unreachable
   at java.net.Inet6AddressImpl.isReachable0(Native Method)
   at java.net.Inet6AddressImpl.isReachable(Inet6AddressImpl.java:77)
   at java.net.InetAddress.isReachable(InetAddress.java:441)
   at java.net.InetAddress.isReachable(InetAddress.java:400)
   at com.bitsofproof.supernode.core.P2P$2.run(P2P.java:709)
   at java.lang.Thread.run(Thread.java:722)
2013-12-28 17:54:17,756 [DEBUG] P2P Peer connector Unhandled exception in peer queue
java.net.SocketException: Network is unreachable
   at java.net.Inet6AddressImpl.isReachable0(Native Method)
   at java.net.Inet6AddressImpl.isReachable(Inet6AddressImpl.java:77)
   at java.net.InetAddress.isReachable(InetAddress.java:441)
   at java.net.InetAddress.isReachable(InetAddress.java:400)
   at com.bitsofproof.supernode.core.P2P$2.run(P2P.java:709)
   at java.lang.Thread.run(Thread.java:722)
2013-12-28 17:54:17,756 [DEBUG] P2P Peer connector Unhandled exception in peer queue
java.net.SocketException: Network is unreachable
   at java.net.Inet6AddressImpl.isReachable0(Native Method)
   at java.net.Inet6AddressImpl.isReachable(Inet6AddressImpl.java:77)
   at java.net.InetAddress.isReachable(InetAddress.java:441)
   at java.net.InetAddress.isReachable(InetAddress.java:400)
   at com.bitsofproof.supernode.core.P2P$2.run(P2P.java:709)
   at java.lang.Thread.run(Thread.java:722)
2013-12-28 17:54:17,757 [DEBUG] P2P Peer connector Unhandled exception in peer queue
java.net.SocketException: Network is unreachable
   at java.net.Inet6AddressImpl.isReachable0(Native Method)
   at java.net.Inet6AddressImpl.isReachable(Inet6AddressImpl.java:77)
   at java.net.InetAddress.isReachable(InetAddress.java:441)
   at java.net.InetAddress.isReachable(InetAddress.java:400)
   at com.bitsofproof.supernode.core.P2P$2.run(P2P.java:709)
   at java.lang.Thread.run(Thread.java:722)
2013-12-28 17:54:17,757 [DEBUG] P2P Peer connector Unhandled exception in peer queue
java.net.SocketException: Network is unreachable
   at java.net.Inet6AddressImpl.isReachable0(Native Method)
   at java.net.Inet6AddressImpl.isReachable(Inet6AddressImpl.java:77)
   at java.net.InetAddress.isReachable(InetAddress.java:441)
   at java.net.InetAddress.isReachable(InetAddress.java:400)
   at com.bitsofproof.supernode.core.P2P$2.run(P2P.java:709)
   at java.lang.Thread.run(Thread.java:722)
2013-12-28 17:55:59,265 [DEBUG] P2P Peer connector Unhandled exception in peer queue
java.net.SocketException: Network is unreachable
   at java.net.Inet6AddressImpl.isReachable0(Native Method)
   at java.net.Inet6AddressImpl.isReachable(Inet6AddressImpl.java:77)
   at java.net.InetAddress.isReachable(InetAddress.java:441)
   at java.net.InetAddress.isReachable(InetAddress.java:400)
   at com.bitsofproof.supernode.core.P2P$2.run(P2P.java:709)
   at java.lang.Thread.run(Thread.java:722)
2013-12-28 17:57:05,442 [DEBUG] P2P Peer connector Unhandled exception in peer queue
java.net.SocketException: Network is unreachable
   at java.net.Inet6AddressImpl.isReachable0(Native Method)
   at java.net.Inet6AddressImpl.isReachable(Inet6AddressImpl.java:77)
   at java.net.InetAddress.isReachable(InetAddress.java:441)
   at java.net.InetAddress.isReachable(InetAddress.java:400)
   at com.bitsofproof.supernode.core.P2P$2.run(P2P.java:709)
   at java.lang.Thread.run(Thread.java:722)
2013-12-28 17:57:07,588 [DEBUG] P2P Peer connector Unhandled exception in peer queue
java.net.SocketException: Network is unreachable
   at java.net.Inet6AddressImpl.isReachable0(Native Method)
   at java.net.Inet6AddressImpl.isReachable(Inet6AddressImpl.java:77)
   at java.net.InetAddress.isReachable(InetAddress.java:441)
   at java.net.InetAddress.isReachable(InetAddress.java:400)
   at com.bitsofproof.supernode.core.P2P$2.run(P2P.java:709)
   at java.lang.Thread.run(Thread.java:722)
2013-12-28 17:58:02,038 [DEBUG] P2P Peer connector Unhandled exception in peer queue
java.net.SocketException: Network is unreachable
   at java.net.Inet6AddressImpl.isReachable0(Native Method)
   at java.net.Inet6AddressImpl.isReachable(Inet6AddressImpl.java:77)
   at java.net.InetAddress.isReachable(InetAddress.java:441)
   at java.net.InetAddress.isReachable(InetAddress.java:400)
   at com.bitsofproof.supernode.core.P2P$2.run(P2P.java:709)
   at java.lang.Thread.run(Thread.java:722)

There are different java.net.SocketException, is it normal?

In the same machine I can run bitcoind without any problem so there should be no problem to run Bop Server too.

Can you please help me?

Thank you in advance

Seems like peers were suddenly no longer reachable. Hard to tell, but looks like some general networking problem. In case you run on the production network I would suggest you run it as a slave behind satoshi.

Thank you Grau,
but the network should be ok as bitcoind runs correctly and what about leveldb data, should the blocks be persisted as they are received?
This should write data to leveldb files, isn't it?

Yes, that is also rather strange. The blocks should be persisted as received in the data directory. I am reluctant to believe that it just does not work as I have several instances running fine since months in production, but will do a fresh bootstrap in the next days to see how it should look like at the beginning.

Maybe CentOS related problem. I use ubuntu or OS X on all machines.

Hi Grau,
I've found that if I comment all the memdb-profile.xml content then the leveldb is correctly used otherwise memdb is always used even if I run the BOP Server with "leveldb" argument.
Seems to be a bug on profile loading.

I think this is due to
ctx.load("classpath:context/*-profile.xml");
in Main.java

Good catch! Thank you.

The reason is that the context on memdb-rofile.xml was missing. it should have started with:

<?xml version="1.0" encoding="UTF-8"?>
<beans profile="memdb"

The reason it worked for me is, that without the context the load order of the files determined precedence beetween leveldb and memdb - and it seems this load order was different on CentOS. Fixing on github soon.

Note that version 2.0.0 of the BOP Community Bitcoin Server is released. Notable features (since 1.3):

  * BIP39
  * Shamir's Secret Sharing
  * Encrypted HD Root - preview
  * RFC 6979 - Deterministic ECDSA signatures
  * shaded jar nor runnable with external configuration files
  * server-in-a-box
  * upgrade to Active MQ 5.9.0, Spring 4.0.0, LevelDB 1.8, Bouncy Castle 1.50
  

Discontinued support for BOP Community Bitcoin Server as it diverged from BOP Enterprise Bitcoin Server to an extent that maintenance was not economical.

Given the muted interest (to remain polite) of the community to contribute, it seems this is not a loss.

Contact sales@bitsofproof.com if you are interested to get the BOP Enterprise Server.

Too bad :(

What does this mean?  That there are no more new releases?

What about the current release?

Was this ever released to the community?

  * BIP39
  * Shamir's Secret Sharing
  * Encrypted HD Root - preview
  * RFC 6979 - Deterministic ECDSA signatures

are part of the API, that is open source at its usual place: https://github.com/bitsofproof/supernode

The Server is available to customer.

Too bad is, that the community did not submit any substantial pulls and valued BOPs work to 0.3 BTC in 2013.

Not sure what you mean by 0.3 BTC in 2013?

That is the amount of donations BOP received in its tip jar.

Just so you know, you're not doing your product any favours in the thread.

Complaining about not receiving much in the way of tips makes it look like you don't actually have any customers at all (otherwise you wouldn't care about your tip address), and regardless acting like this in public is going to turn off potential customers.

Overall I get the impression that you consider the community defective for not adopting your software instead of taking the weak response as an indication that your marketing outreach requires improvement.

I am also a developer and I've asked for donations many times.

However, for some reason, people who own coins don't think its worth their while to pay for development work.

You can look around at a lot of projects that barely got a drop of coins as tips.   Many have been abandoned simply because developers realized that it eventually was not worth their while.

Maybe you could get some Devcoin for your work?  Have you tried that route?

I tried for one year, but the open source did not deliver any benefit to me. No substantial code contribution, no donation no offers from those who claim supporting the open source development of Bitcoin.

In contrary I was frequently attacked for being irresponsible releasing an alternative implementation, or rushing out features too early.

The same time I have paying customer and venture capitalists who wonder why I give away IP for free. I run out of arguments.

I hope you're not proving them right, but it's hard to be optimistic about that.

I worked very hard, and your above note is a great example of the thankfulness I received. To you too.

I think the dirty little truth about Bitcoin development and developers is that the code is deliberately made difficult to understand but for only the few.   An alternative cleaner implementation like bitsofproof or conformal is actually internally frowned upon because it reveals the 'secrets' of Bitcoin. 

In typical open source projects developers will be rushing enmass into the better structured version of the code.  But not with this community.

The Bitcoin community is not based on 'sharing' and 'community' that one finds in other open source groups.  Rather is is based on entirely the opposite 'hoarding' and 'exclusivity'.  Where any alternative idea is shot down with the most violent of arguments.

It is the worse community I have ever been associatated with.     

There are bright minds here and I learned a lot.

Bitcoin is special as mastering the code is becoming money and power without much indirection. Refactoring and alternate implementations are considered more of risk than a chance at community level.

At the project level BOP software is used to build services that would have been more difficult to build with satoshi.
I want to provide a good service to those customer and create more higher level products that convince others of the BOP platform.

Competing at the server level is at the moment an altruistic uphill battle. The open source code only attracted free rider and hater.

Could you explain this a bit further?

What sort of services were created using BOP that you have done that would have been very difficult with the Satoshi client?

An example that is known in the community is http://btc1k.com that deploys BopShop a payment processor built on top of BOP and a multi-signature P2SH vault and accompanying wallet used by the organizer. The entry to the event will also be validated by a BOP app.

BopShop is used by several web sites and the BeBop wallet also built on BOP servers in a few restaurants. I am in final testing of an exchange with truly unique technical proposition and back an other community wide known project. I will let them talk the right time.

Added: Each of above products have features you will not find in, and would be difficult to emulate with satoshi.

Substantiating some claims, more to come...

myTREZOR Web Wallet to use BOP Bitcoin Server

http://www.bitcointrezor.com/news/2014-02-10-mytrezor-bop-bitcoin-server

Hat off :)

Substantiating some claims ...

https://bullionbitcoin.com

The first real-time audit able exchange, utilizing a  2-of-3 keyed P2SH vault.

grau, can you also please release a precompiled version of bop?

Yes, I think that could become a good evaluation option. I will create a signed build with setup instructions within the next weeks.

I am very busy at the moment with launching AUREALS.

http://www.iconcapitalsa.com/posts/8-icon-capital-reserve-s-a-acquires-leading-digital-currency-developer-bits-of-proof-zrt

You've done a lot of great and hard work on this, thank you.



I respect and appreciate where your VCs are coming from, but look at it this way: I am a potential customer. I, as the operator of xyz company, am fully aware of the risks involved in searching for implementations outside the core code. One small mistake can lead to disastrous effects (see: gox).

I want to trust you and your platform, but I can't wholeheartedly. Without being able to audit your code I don't know if you haven't made a mistake in your implementation. And there is nothing you could really do to convince me otherwise without open sourcing it. You lost me as a customer, unfortunately.

The open source business model did not generate sufficient cash flow for expansion through support contracts.

We have some profitable projects like https://bullionbitcoin.com, http://bopshop.bitsofproof.com and http://www.bitcointrezor.com/news/2014-02-10-mytrezor-bop-bitcoin-server and a few undisclosed that proved the value of the software, that I could trade in for meaningful expansion See: http://www.iconcapitalsa.com/posts/8-icon-capital-reserve-s-a-acquires-leading-digital-currency-developer-bits-of-proof-zrt

I gave source code access to current customer and I evaluate every new piece of code we write if it is appropriate to open source it. Older versions and lots of useful functions are generally accessible open source even now.

BOPs development focus is now to create a software stack capable of issuing, trading, auditing digital assets. I am sure that we will open source huge portions of that and that others will be licensed with source code access.

Ah okay, so you share the source with your customers. That's good to know.

Too bad a viable business model that included leaving the bop server open source (an apache project would be great) couldn't be found.

The Bitcoin economy is still in its infancy and many years shell pass before a community of contributors can form and evolve your project.

One problem I always had with BoP (I've been contemplating to use it several times, but never did): the site seems to severely undersell the product! I mean, I have no idea what BoP can do for me, how scalable it is, what the advantages are over using bitcoind etc.

In short: why should I use BoP rather than bitcoind?

This situation has gotten worse since it's not open source anymore. Unless I am missing something, there seems to be only a single page with very sparse info on it. Documentation? Code samples? Use cases? Anything?

I have the impression that you have more of a marketing problem rather than a community problem.

Just my 2 cents..

Thanks for the warm welcome. Was nice to talk to you in London Mike.

I released the code since it reached the coverage needed to prove that it is for real. Not for production but to build on it as a platform.

Your points on testing are valid. They are clearly not sufficient. I plan to introduce an interface aimed for testing. That would enable
implementations to test each other.

The Wallet is not there but everything you need to stick it together in a couple hours or days depending on what you want.
I did not yet figured what I wanted. But the point is that this is a feature that does not have to be common.
Do your own at your own taste and stick it in.

+1  :)

You are right.

The value is not visible from what is publicly available.
My current strategy is to create products that demonstrate that.

Ah, I actually bought 2 months of Bits of Proof support late last year with the understanding the project would be open source.  Oh well, that sucks.

I'm starting a bitcoin project and I was really looking to use bop for it, but I'm now forced to go with bitcoinj, too bad.

Stay tuned. You'll have a choice soon.

I suppose you meant this: 
https://cointerra.com/acquires-bits-of-proof/ (https://cointerra.com/acquires-bits-of-proof/)

Yes.

It is our common plan with CoinTerra to make the Bits of Proof software stack an industry standard for enterprise use of Bitcoin. Details of the plan will follow in a few days.

Hat off!

Looking forward to know the details.

Posted 6 months ago?

You might have seen that CoinTerra did not work out as expected. It filed for bankrupcy a few days ago.
CoinTerra's default does not affect Bits of Proof as their option to buy the assets expired unused.

If mining would have provided stable income and growth, as it looked like as I joined them,
then I would have open sourced the plattform to create a standard on a longer run.

I live from Bitcoin software development about two years now.

Without alternate revenue or significant funding, I have to act selfish and short sigthed and protect
my competitive advantage, that enabled me to create products like the Bullion Bitcoin exchange or
myTREZOR back end and undisclosed others.

I am currently working on a side chain with huge business potential. Should the new plan work out,
then I will revisit the idea of open sourcing the stack.

Thanks for the honest update. I sure know how hard it is at the moment to survive as an independent developer in the space, especially when you bet on the wrong horse. And unfortunately, we can't work on all these exiting projects at once. :) Let's hope that your new venture works out!

@everyone: btcd (not the coin, but the daemon: https://bitcointalk.org/index.php?topic=192880.0) seems like a very good alternative for a server-side/enterprise bitcoin node.