Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
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 signature.asc Description: OpenPGP digital signature -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Thu, Feb 19, 2015 at 6:30 PM, Mike Hearn 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. -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
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 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 > -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
> > 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. -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Thu, Feb 19, 2015 at 3:09 PM, Tamas Blummer wrote: > On Feb 19, 2015, at 3:03 PM, Bryan Bishop 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. -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Feb 19, 2015, at 3:03 PM, Bryan Bishop 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Wed, Feb 18, 2015 at 11:22 PM, Tamas Blummer 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 -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Feb 19, 2015, at 6:22 AM, Tamas Blummer 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18 February 2015 22:32:05 GMT-05:00, Troy Benjegerdes 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/ -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Sun, Feb 15, 2015 at 06:13:06PM +0100, Tamas Blummer wrote: > > On Feb 15, 2015, at 6:02 PM, Peter Todd 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' ho...@hozed.org -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On 2015-02-15 17:13, Tamas Blummer wrote: > On Feb 15, 2015, at 6:02 PM, Peter Todd 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? -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Sun, Feb 15, 2015 at 06:13:06PM +0100, Tamas Blummer wrote: > > On Feb 15, 2015, at 6:02 PM, Peter Todd 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 00ffb7a576b7aa5236c53f51ec07ccf174067beed3398056 signature.asc Description: Digital signature -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Feb 15, 2015, at 6:02 PM, Peter Todd 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
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 16b6444e463c7d92da1579360c5f71d4fbd3dab45d13990a signature.asc Description: Digital signature -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
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 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 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 0a37c901cf2ae6c281f47b237e9bf1d7268fb561b4332345 signature.asc Description: Digital signature -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
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 -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Sat, Feb 14, 2015 at 3:23 PM, Tamas Blummer 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. -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Sat, Feb 14, 2015 at 1:04 PM, Adam Back 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 -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
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" 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 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 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 > > -- 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
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
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 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 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
