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

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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 5758 bytes --]

I haven't bothered reading the thread, but I'll put this out there:

The consensus critical Satoshi-derived sourcecode is a protocol
*specification* that happens to also be machine readable and executable.
Rewriting it is just as silly as as taking RFC 791 and rewriting it
because you wanted to "decentralize control over the internet"

My replace-by-fee fork of Bitcoin Core is a perfect case in point: it
implements different non-consensus-critical policy than Bitcoin Core
does, while adhering to the same Bitcoin protocol by virtue of being the
same sourcecode - the same protocol specification. When I went to miners
asking them to implement it, the biggest concern for them is "Will it
stay in consensus with other miners?" If I had rewritten the whole thing
from scratch the fact is the honest answer to them would be no way in
hell - reimplementing Bitcoin and getting it right is software
engineering's Apollo Project and none of us have the resources to pull
that off. But I didn't, which means we might soon have a significant
chunk of hashing power implementing a completely different mining policy
than what is promoted by the Bitcoin Core maintainers.

By reimplementing consensus code - rewriting the protocol spec - you
drop out of the political process that is Bitcoin development. You're
not decentralizing Bitcoin at all - you're contributing to its
centralization by not participating, leaving behind a smaller and more
centralized development process. Fact is, what you've implemented in
libbitcoin just isn't the Bitcoin protocol and isn't going to get
adopted by miners nor used by serious merchants and exchanges - the
sources of real political power.


Right now we could live in a world where a dozen different groups
maintain Bitcoin implementations that are actually used by miners. We
could have genuine innovation on the p2p networking layer, encryption,
better privacy for SPV clients, better resistance to DoS attacks. We
could have diverse tx acceptance policies rather than wasting hundreds
of man hours bitching about how many bytes OP_RETURN should allow. We
could have voices from multiple groups at the table when the community
discusses how to scale Bitcoin up.

Instead we have a world with a half dozen teams wasting hundreds if not
thousands of of man hours dicking around trying to rewrite consensus
critical *specifications* because they happen to be perfectly good
executable code, and the first thing a programmer thinks when they see
perfectly good battle-hardened code is "Hey! Let's rewrite that from
scratch!"


You know you does have significant political power over the development
of the Bitcoin protocol *other* than the Bitcoin Foundation?

Luke Dashjr.

Because he maintains the Eligius fork of Bitcoin Core that something
like %30 of the hashing power run. It Actually Works because it uses the
Actual Protocol Specification, and miners know if they run it they
aren't going to lose tens of thousands of dollars. It's why it's easy to
get transactiosn mined that don't meet the Bitcoin Core's IsStandard()
rules: they aren't part of the protocol spec, and Luke-Jr has different
views on what transactions should and should not be allowed into the
blockchain.

And when Gavin Andresen starts negotiating with alt-implementations to
get his bloat coin proposals implemented, you know who's going to be at
the table? Luke-Jr again! Oh sure, the likes of btcd, libbitcoin, toshi,
etc. will get invited, but no-one's going to really care what they say.
Because at best only a tiny - and foolish - sliver of hashing power will
be using their implementations of Something Almost But Not Quite
Bitcoin™, and any sane merchant or exchange will be running at least one
or two Bitcoin Foundation Genuine Bitcoin Core™ nodes in front of any
from-scratch alt-implementation.


So stop wasting your time. Help get the consensus critical code out of
Bitcoin Core and into a stand-alone libconsensus library, wrap it in the
mempool policy, p2p networking code, and whatever else you feel like,
and convince some hashing power to adopt it. Then enjoy the fruits of
your efforts when the next time we decide to soft-fork Bitcoin the
process isn't some secretive IRC discussion by a half-dozen "core
developers" - and one guy who finds the term hilarious - but a full on
DIRECT DEMOCRACY OCCUPY WALL STREEET MODIFIED CONSENSUS POW-WOW,
complete with twinkle fingers. A pow-wow that you'll be an equal part
of, and your opinions will matter.

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 choice is yours.


On Sat, Feb 14, 2015 at 03:16:16AM -0800, Eric Voskuil wrote:
> On 02/14/2015 01:51 AM, Jorge Timón wrote:
> > I agree that this conversation is not being productive anymore. I'm
> > doing my best to understand you but I just happen to disagree with
> > many of your arguments.
> > I doubt it makes you feel better but it's being tedious and
> > frustrating for me as well.
> > I don't know about other people's intentions, but I know that my only
> > intention when recommending libbitcoin to depend on libconsensus is to
> > prevent its direct and indirect users from accidentally being forked
> > off the network due to a consensus failure.
> 
> If you want to achieve that goal, I would again recommend that a
> standard suite of test vectors be published that other implementations
> can easily consume. Everyone runs the tests and compares results - just
> like deterministic build verification.

-- 
'peter'[:-1]@petertodd.org
00000000000000000e95dcd2476d820f6fd26eb1a9411e961347260342458e9c

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 1678 bytes --]

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


On Feb 14, 2015, at 2:13 PM, Peter Todd <pete@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. 

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.

It is entirely rational for me to focus on innovation that uses the core as a border router for this block chain. 

I am rather thankful for the ideas of the side chains, that enable innovation that is no longer measured on unapologetic compatibility with a given code base, but its services to end user.

Tamas Blummer
Bits of Proof


[-- Attachment #1.2: Type: text/html, Size: 3144 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

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

[Adam Back]

[-- Attachment #1: Type: text/plain, Size: 3272 bytes --]

Strongly with Peter on this.  That its highly complex to maintain strict
consensus between bitcoin versions, does not justify consensus rewrite
experiments; it tells you that the risk is exponentially worse and people
should use and rally around libconsensus.

I would advise any bitcoin ecosystem part, wallet, user to not use software
with consensus protocol rw-writes nor variants, you WILL lose money.

You could view bitcoin as a digital signature algorithm speculatively
tinkering with the algo is highly prone to binary failure mode and
unbounded funds loss.

Want to be clear this is not a political nor emotive issue. It is a
critical technical requirement for security if users of software people
write.

Please promote this meme.

Adam
On Feb 14, 2015 6:24 AM, "Tamas Blummer" <tamas@bitsofproof.com> 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@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.
>
>
> On Feb 14, 2015, at 2:13 PM, Peter Todd <pete@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.
>
> 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.
>
> It is entirely rational for me to focus on innovation that uses the core
> as a border router for this block chain.
>
> I am rather thankful for the ideas of the side chains, that enable
> innovation that is no longer measured on unapologetic compatibility with a
> given code base, but its services to end user.
>
> Tamas Blummer
> Bits of Proof
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 4826 bytes --]

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

[Bryan Bishop]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

On Sat, Feb 14, 2015 at 1:04 PM, Adam Back <adam@cypherspace.org> wrote:

> That its highly complex to maintain strict consensus between bitcoin
> versions, does not justify consensus rewrite experiments


Correct. However, those maintenance costs absolutely do justify working
towards formal proofs of correctness for the existing implementation. These
plans are no secret and are publicly discussed, but I think it would be
instrumental to outsiders if the correctness plans and ongoing progress
could be mentioned whenever a warning is made about unjustified and
dangerous Bitcoin consensus rewrite attempts.

- Bryan
http://heybryan.org/
1 512 203 0507

[-- Attachment #2: Type: text/html, Size: 1026 bytes --]

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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

On Sat, Feb 14, 2015 at 11:04:49AM -0800, Adam Back wrote:
> Strongly with Peter on this.  That its highly complex to maintain strict
> consensus between bitcoin versions, does not justify consensus rewrite
> experiments; it tells you that the risk is exponentially worse and people
> should use and rally around libconsensus.

It's worth remembering that one of the goals in writing - or to be more
precise, separating - libconsensus from the Bitcoin Core codebase is to
make it easier to maintain strict consensus between Bitcoin Core
versions.

> I would advise any bitcoin ecosystem part, wallet, user to not use software
> with consensus protocol rw-writes nor variants, you WILL lose money.
> 
> You could view bitcoin as a digital signature algorithm speculatively
> tinkering with the algo is highly prone to binary failure mode and
> unbounded funds loss.
> 
> Want to be clear this is not a political nor emotive issue. It is a
> critical technical requirement for security if users of software people
> write.

The necessity of it isn't a political or emotive issue, but the
consequences are definitely political. Just not in the way that most of
the ecosystem appears to think.

-- 
'peter'[:-1]@petertodd.org
000000000000000016b6444e463c7d92da1579360c5f71d4fbd3dab45d13990a

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

[Jorge Timón]

On Sat, Feb 14, 2015 at 3:23 PM, Tamas Blummer <tamas@bitsofproof.com> wrote:
> Peter,
> 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.

Right now libconsensus' only dependency is openSSL. Most of the
testing in libsecp256k1 has been in signing rather than verifying
signatures (please, anyone with more knowledge in the library don't
hesitate to correct me or clarify things). But eventually openSSL will
be completely replaced by libsecp256k1.
It does not store anything, 0.1 is just a dynamic library with a c API
to a single function: VerifyScript().
This function saves the hassle of reimplementing signature checking
(which is a really hard part) and reimplementing an interpreter that
must function in exactly the same way in many as many other nodes with
different software and/or hardware.
Guido van Rossum can say "some behaviours in python the language are
not specified, so it is ok if cpython and pypy do different things,
they're still both running python which is more abstract than any of
its implementation".
But a consensus system like bitcoin doesn't have the luxury of leaving
consensus rules unspecified. And the simplest way to fully specify a
language interpreter is by implementing it.
But coupling the consensus rules specification with a bigger project
like bitcoin core can result in implementation details of that bigger
project accidentally and unexpectedly becoming consensus rules. This
is what happened with bdb and nobody wants that to happen again,
that's the whole point.
Note that many parts of the bitcoin protocol (like the p2p messages)
are NOT part of the consensus rules.
You can have a look at
https://github.com/jtimon/bitcoin/commits/consensus2 and maybe you
would be surprised about how small they actually are. This branch is
incomplete and still a mess that needs to be cleaned up. And none of
that is included in libconsensus yet.
I was planning on writing a post here asking for feedback on the
interfaces for these higher level checks. I'm just putting the code
together in the same module, but obviously class CCoinsViewCache
cannot be an argument in functions of a c API.

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

Nobody is attacking alternative implementations. This tool was created
mostly with alternative implementations in mind.
So input from them it's very welcomed on how to continue libconsensus
(or of course correct any flaws in verifyScript if there's any).
I just wanted to wait to have some more code to make things easier to
explain (and have a clearer idea of it myself).
There's a more limited branch on "next steps for libconsensus" in #5669.

> It is entirely rational for me to focus on innovation that uses the core as
> a border router for this block chain.

Sure, I think he is complaining that at the moment that's probably the
only safe way to operate with alternative implementations and still
have full node guarantees.

> I am rather thankful for the ideas of the side chains, that enable
> innovation that is no longer measured on unapologetic compatibility with a
> given code base, but its services to end user.

Sidechains are completely orthogonal to this discussion and, in fact,
it would be good to have libconsensuses for sidechains too, since
their nodes also need to come to consensus.

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

[Luke Dashjr]

On Saturday, February 14, 2015 2:23:47 PM Tamas Blummer wrote:
> 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.

You can describe 'A' from a group of A, B, C, D, E as "the group minus B, C, 
D, E", sure - but I don't see how this is relevant?

UTXO storage is indeed consensus critical, as you say, but it is a lot simpler 
to get right than the rest combined. Thus, the end goal is to have a 
libbitcoinconsensus with "the rest", and a (as of yet named) 
libbitcoincompleteconsensus that ties in the canonical UTXO storage. Ideally, 
software should use the latter when it is available, but if there is a strong 
reason to change UTXO storage, one can remain mostly-safe with just the 
former. I'm not sure why this topic is of relevance, though...

Luke

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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2888 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 488 bytes --]


On Feb 15, 2015, at 6:02 PM, Peter Todd <pete@petertodd.org> wrote:
> Yes you are dicking around.

I thought I was clear, that I am using Bitcoin Core as border router talking to its P2P interface.

The reimplementation of consensus code helped me to deeply understand the protocol, aids debugging
and now comes handy to create a side chain.

> Don't assume your prior experience with other commercial projects 


Acquire some before you claim its useless.

Tamas Blummer

[-- Attachment #1.2: Type: text/html, Size: 1328 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]

On Sun, Feb 15, 2015 at 06:13:06PM +0100, Tamas Blummer wrote:
> 
> On Feb 15, 2015, at 6:02 PM, Peter Todd <pete@petertodd.org> wrote:
> > Yes you are dicking around.
> 
> I thought I was clear, that I am using Bitcoin Core as border router talking to its P2P interface.

Ah, sorry, that wasn't clear to me.

> The reimplementation of consensus code helped me to deeply understand the protocol, aids debugging
> and now comes handy to create a side chain.

Indeed, which is why I've done a lot of work on a reimplementation of
the Bitcoin scripting system as well:

https://github.com/petertodd/python-bitcoinlib/blob/master/bitcoin/core/scripteval.py

Which has this cheery warning at the top:

"""Script evaluation

Be warned that there are highly likely to be consensus bugs in this
code; it is unlikely to match Satoshi Bitcoin exactly. Think carefully
before using this module.
"""

I'll be adding a FFI interface to libconsensus in the future... and I
probably should make that warning scarier...

-- 
'peter'[:-1]@petertodd.org
000000000000000000ffb7a576b7aa5236c53f51ec07ccf174067beed3398056

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

[joliver]

On 2015-02-15 17:13, Tamas Blummer wrote:
> On Feb 15, 2015, at 6:02 PM, Peter Todd <pete@petertodd.org> wrote:
> 
>> Yes you are dicking around.
> 
> I thought I was clear, that I am using Bitcoin Core as border router
> talking to its P2P interface.
> 
> The reimplementation of consensus code helped me to deeply understand
> the protocol, aids debugging
> and now comes handy to create a side chain.
> 
>> Don't assume your prior experience with other commercial projects
> 
> Acquire some before you claim its useless.

^^^ THIS ^^^

Can we recognize Peter Todd's lack of respect and outright 
unprofesionalism here?

Peter: Someone so young with so little actual experience shouldn't be 
going around so casually bad-mouthing the work of others or dismissing 
people with decades more experience than you. Don't write long angry 
rants against the ideas of others when you haven't even read what they 
have to say. Own up to it when you get caught doing it. You'll find out 
the hard way that blackmailing people, even your clients, into using 
your ideas may get you attention, but it'll make you a pariah in the 
long run. (does encouraging illegal fraud belong on this mailing list?) 
Remember that twitter is public. Do you really want future employers 
reading jokes about pedophilia and rape? Do you want to be known for 
snappy one liners and giving journalists headlines or writing solid code 
that gets used by real businesses? (not "DarkLeaks") Are you trying to 
be a rock star or team member?

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

[Troy Benjegerdes]

On Sun, Feb 15, 2015 at 06:13:06PM +0100, Tamas Blummer wrote:
> 
> On Feb 15, 2015, at 6:02 PM, Peter Todd <pete@petertodd.org> wrote:
> > Yes you are dicking around.
> 
> I thought I was clear, that I am using Bitcoin Core as border router talking to its P2P interface.
> 
> The reimplementation of consensus code helped me to deeply understand the protocol, aids debugging
> and now comes handy to create a side chain.

The work that Tamas did re-implementing is probably one of the most valuable
things he ever did.

It would significantly improve the quality of the consensus code if this
community would start treating it as a buggy & poorly defined proof-of-concept
that just happens to actually run, rather than some holy scripture upon which
we must never question (or change)

I'm impressed by the secp256k1 work, and other modularity efforts, but at 
some point main.cpp needs to get untangled, and have some critical review
if bitcoin wants to remain relevant.

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@hozed.org

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

[Peter Todd]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 18 February 2015 22:32:05 GMT-05:00, Troy Benjegerdes <hozer@hozed.org> wrote:
>The work that Tamas did re-implementing is probably one of the most
>valuable
>things he ever did.

...in the same way going to university may be one of the more valuable things you ever do. But using the code resulting from that process over Satoshi Bitcoin/libconsensus is foolish.

>It would significantly improve the quality of the consensus code if
>this
>community would start treating it as a buggy & poorly defined
>proof-of-concept
>that just happens to actually run, rather than some holy scripture upon
>which
>we must never question (or change)

I suggest you actually look at the git commit history for the consensus-critical part of the Bitcoin Core codebase - so much work cleaning it up and refactoring has been done for v0.10.0/libconsensus that I think we're risking the introduction of a consensus bug unnecessarily and should slow down a little.

"holy scripture" it ain't.

>I'm impressed by the secp256k1 work, and other modularity efforts, but
>at
>some point main.cpp needs to get untangled, and have some critical
>review
>if bitcoin wants to remain relevant.

Again, this is exactly what people are working towards, at a speed that if anything is probably a bit too rapid.
-----BEGIN PGP SIGNATURE-----

iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU5Vwc
AAoJEMCF8hzn9Lnco2EH/3bXwUTJ9iVLfYH0d/nvSXmt+C0Mpj5YFYr1h1vJv/3M
e/By1ORRdre9fdJjgMmr3pj9lIiZfd/qEKEnrmULqBsoSd/5EmMjFB2gpZmQ1xyM
ndUyy56S2TFr//3hpJukvuG01X6q+GRGymlpk+fYfNlna3IjpARUabmlB9dKKRPI
/XfyfpYyZh9G6DLsRg6+5BgKeW9OFRFm9aQY/yHiDgxpffIvYJ9QyOVm5vjtMgBQ
bs0P7yuCUJ06xdSrYK1ylTcEbFyVIXa5w+AYQRHfx5aw7fZkD7q5pmwv8mWJfy8n
IroSkmd1Erk0L3e+wJtAZn8S/6094IJ3v+2NajEC2hQ=
=MfY/

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

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 428 bytes --]

Libconsensus will create an in-process alternative to the border router setup I currently advocate in a production environment.
It is not sufficient yet, since only checking scripts, but is the move I was long waiting for. 

I  launched a Lighthouse project to add Java Language Binding to lib consensus. Let's turn the debate to a constructive vote.

See on https://www.reddit.com/r/LighthouseProjects

Tamas Blummer


[-- Attachment #1.2: Type: text/html, Size: 1518 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

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

[Tamas Blummer]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

On Feb 19, 2015, at 6:22 AM, Tamas Blummer <tamas@bitsofproof.com> wrote:
> I  launched a Lighthouse project to add Java Language Binding to lib consensus. Let's turn the debate to a constructive vote.
> 
> See on https://www.reddit.com/r/LighthouseProjects

I should have added the project description here, as above is only readable with lighthouse:

Java Language Binding for Core Consensus Library

Bitcoin Core 0.10.0 comes with a library for external services that validates Bitcoin transactions with the code base of the core.

The proposed language binding would unleash innovation of JVM application developer without raising concern of a network fork through incompatible alternate implementations of the protocol.

The language binding would be written with lightweight, immutable, self contained data classes that use only language standard libraries, therefore suitable for any service framework.


Tamas Blummer


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

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

[Bryan Bishop]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

On Wed, Feb 18, 2015 at 11:22 PM, Tamas Blummer <tamas@bitsofproof.com>
wrote:

> I  launched a Lighthouse project to add Java Language Binding to lib
> consensus. Let's turn the debate to a constructive vote.


First, I strongly disagree with voting here for reasons that I hope others
will elaborate on. Second, I think that squeezing all possible language
bindings into a project is also unproductive. What is it that the webkit
people did for this? I think they had gobject bindings, and then all of the
languages have their own gobject bridge to take advantage of that.
Naturally the downside here is that gobject means you have a gtk
dependency. A similar solution would be interesting and worth exploring,
though, especially if something similar without gtk exists.

- Bryan
http://heybryan.org/
1 512 203 0507

[-- Attachment #2: Type: text/html, Size: 1204 bytes --]

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

[Tamas Blummer]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

On Feb 19, 2015, at 3:03 PM, Bryan Bishop <kanzure@gmail.com> wrote:
> First, I strongly disagree with voting here for reasons that I hope others will elaborate on.

I meant voting by pledging on the lighthouse project, not here on the list. Sorry for not stating this explicitelly.

> Second, I think that squeezing all possible language bindings into a project is also unproductive.

The language binding would be an independent and separately hosted project only using the C interface of the libconsensus library.

Tamas Blummer


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

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

[Jorge Timón]

On Thu, Feb 19, 2015 at 3:09 PM, Tamas Blummer <tamas@bitsofproof.com> wrote:
> On Feb 19, 2015, at 3:03 PM, Bryan Bishop <kanzure@gmail.com> wrote:
>> Second, I think that squeezing all possible language bindings into a project is also unproductive.
>
> The language binding would be an independent and separately hosted project only using the C interface of the libconsensus library.

He didn't said "a project for all possible language bindings", just
java bindings. Other languages' bindings would be separate projects.

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

>
> He didn't said "a project for all possible language bindings", just
> java bindings. Other languages' bindings would be separate projects.


Yes/no/sorta.

Java/JNA bindings can be used from Python, Ruby, Javascript, PHP as well as
dialects of Haskell, Lisp, Smalltalk and a bunch of more obscure languages
like Scala, Kotlin, Ceylon, etc.

It makes more sense to talk about bindings to particular runtimes these
days, rather than particular languages.

[-- Attachment #2: Type: text/html, Size: 744 bytes --]

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

[Sean Gilligan]

On 2/19/15 9:30 AM, Mike Hearn wrote:
>
> Java/JNA bindings can be used from Python, Ruby, Javascript, PHP as
> well as dialects of Haskell, Lisp, Smalltalk and a bunch of more
> obscure languages like Scala, Kotlin, Ceylon, etc.
>
> It makes more sense to talk about bindings to particular runtimes
> these days, rather than particular languages.

I'm definitely interested in helping to create and test JVM bindings.
Where should such a project be launched? As a subproject of bitcoinj?

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

[Angel Leon]

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

I strongly suggest you take a look at swig for doing this. It's very
straightforward generating bindings in an automated fashion with it.
http://www.swig.org/

You could probably  have it done in one or two days with Swig.

Once you do the Java bindings with it, it'll be a few adjustments and
you'll have bindings for other languages as well.

http://twitter.com/gubatron

On Thu, Feb 19, 2015 at 4:43 PM, Sean Gilligan <sean@msgilligan.com> wrote:

> On 2/19/15 9:30 AM, Mike Hearn wrote:
> >
> > Java/JNA bindings can be used from Python, Ruby, Javascript, PHP as
> > well as dialects of Haskell, Lisp, Smalltalk and a bunch of more
> > obscure languages like Scala, Kotlin, Ceylon, etc.
> >
> > It makes more sense to talk about bindings to particular runtimes
> > these days, rather than particular languages.
>
> I'm definitely interested in helping to create and test JVM bindings.
> Where should such a project be launched? As a subproject of bitcoinj?
>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2546 bytes --]

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

[Jorge Timón]

On Thu, Feb 19, 2015 at 6:30 PM, Mike Hearn <mike@plan99.net> wrote:
>> He didn't said "a project for all possible language bindings", just
>> java bindings. Other languages' bindings would be separate projects.
>
>
> Yes/no/sorta.
>
> Java/JNA bindings can be used from Python, Ruby, Javascript, PHP as well as
> dialects of Haskell, Lisp, Smalltalk and a bunch of more obscure languages
> like Scala, Kotlin, Ceylon, etc.
>
> It makes more sense to talk about bindings to particular runtimes these
> days, rather than particular languages.

Oh, I didn't knew that. Thanks for the clarification.

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

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

On 02/14/2015 05:13 AM, Peter Todd wrote:
> So stop wasting your time. Help get the consensus critical code out of
> Bitcoin Core and into a stand-alone libconsensus library...

done

https://github.com/libbitcoin/libbitcoin-consensus

> ...
> Then ... when the next time we decide to soft-fork Bitcoin the
> process isn't some secretive IRC discussion by a half-dozen "core
> developers" - and one guy who finds the term hilarious - but a full on
> DIRECT DEMOCRACY OCCUPY WALL STREEET MODIFIED CONSENSUS POW-WOW,
> complete with twinkle fingers.

You seriously made me laugh out loud with this one Peter.

e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]