I’ve been reading deeper into the code and the B&C whitepaper
I see two parts to the question:
- the fork from the Bitcoin client upon which all of this is built that is way old (using old versions of Qt, etc)
- the implementation of B&C as layed out in the whitepaper
Re: being based on the Bitcoin client
– I’ve been seriously considering writing an alternative implementation, that would reduce the dependencies to just Qt and openssl (for example), make it easier to get additional developers involved, make for faster builds, and perhaps a codebase that can be extended to iOS or Android. It bothers me that something like a blockchain explorer needs to be a separate pile of code, and can’t just run out of the wallet that already has an http server. 70k lines of code is ambitious but plausible.
Re: the B&C concept
I am still catching up with the concepts in the whitepaper. I do see a lot of data that is written into the blockchain, which is permanent space usage, and may require blocks to age to execute.
I wonder if there isn’t a simpler way – as there appear to be a lot of steps.
Also, I wonder if it makes sense to use pegged currencies in a “hub and spoke” model. The hub asset being pegged to BTC, or USD (or PPC). At the end of the spokes would be other assets like (example) currencies like CNY, EUR, or other crypto assets. The spokes itself would be the exchange from/to the hub asset. Especially given the post by George from Bitspark that one may need to handle hundreds of assets, n^2 becomes impractical.
If all assets are on the blockchain, then the protocol can to all sorts of awesome tricks to do settlements – the orders would be (signed, rate-limited) messages, but settled atomically in a block. Perhaps even route thru the “hub”. (And take fees / a spread along the way of course)
To get into and out of the ecosystem, there may be the need to run pairs on exchanges and/or do things like what Henry did with NuLagoon Tube. (And instead of registering addresses – “just send” to a translator, and the funds will be sent to the address whose private key matches.)
Fully knowing I was an advocate to have separate blockchains for the pegged asset vs. the trading part, but the sum may be more powerful than the parts.
I’d really like to pick sigmike’s brain on this, as he is listed as a co-author to B&C, and I’m sure plenty of hours of thought went into this.
But those are the thoughts at the moment.