[Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

Peter Todd pete at petertodd.org
Sun Feb 15 17:02:29 UTC 2015


On Sat, Feb 14, 2015 at 03:23:47PM +0100, Tamas Blummer wrote:
> Peter,
> 
> You did not address me but libbitcoin. Since our story and your evaluation is probably similar, I chime in.
> 
> On Feb 14, 2015, at 2:13 PM, Peter Todd <pete at petertodd.org> wrote:
> 
> > So stop wasting your time. Help get the consensus critical code out of
> > Bitcoin Core and into a stand-alone libconsensus library,
> 
> 
> We have seen that the consensus critical code practically extends to Berkley DB limits or OpenSSL laxness, therefore
> it is inconceivable that a consensus library is not the same as Bitcoin Core, less its P2P service rules, wallet and RPC server.

Wallet and RPC server are definitely not consensus critical code.

P2P service rules are weakly consensus critical, in that a failure to
relay valid blocks can in practice cause a loss of consensus. But
relaying valid blocks is very easy, and you only need sone relay
mechanism out of many to work for consensus to be maintained.

OpenSSL is getting replaced by libsecp256k1, a library designed for
consensus-critical applications.

As for databases, look at the good #bitcoin-wizards discussion yesterday
for strategies to make databases less relevant to consensus.

> On Feb 14, 2015, at 2:13 PM, Peter Todd <pete at petertodd.org> wrote:
> > 
> > Or you can be stereotypical programmers and dick around on github for
> > the next ten years chasing stupid consensus bugs in code no-one uses.
> 
> 
> 
> The Core code base is unfriendly to feature extensions because of its criticality, legacy design and ancient technology. It is also a commodity
> that the ecosystem takes for granted and free. 

Are you referring to feature extensions to consensus critical code -
like my own CHECKLOCKTIMEVERIFY? - or extensions to code that isn't
consensus critical?

> I honestly admire the core team that works and progresses within these limits and perception.
> 
> I am not willing to work within the core’s legacy technology limits. Does it mean I am dicking around? I think not.
> It was my way to go down the rabbit hole by re-digging it and I created successful commercial products on the way.

Yes you are dicking around. The effort you're going to spend recreating
the core consensus code and getting it right is orders of magnitude more
work than figuring out how to use the foreign function interface in your
chosen language, or at worse, just running Bitcoin Core to do validation
and using RPC or the p2p protocol locally to track that state.

Don't assume your prior experience with other commercial projects has
any bearing on Bitcoin: consensus-critical crypto is a brand new field
within software engineering with very unique requirements, pioneered by
Bitcoin itself.

-- 
'peter'[:-1]@petertodd.org
00000000000000000a37c901cf2ae6c281f47b237e9bf1d7268fb561b4332345
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150215/a6ad761c/attachment.sig>


More information about the bitcoin-dev mailing list