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 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=190641631iu=/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 6:30 PM, Mike Hearn m...@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. -- 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=190641631iu=/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 ta...@bitsofproof.com wrote: On Feb 19, 2015, at 3:03 PM, Bryan Bishop kanz...@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. -- 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=190641631iu=/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=190641631iu=/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 kanz...@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 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=190641631iu=/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 s...@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=190641631iu=/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=190641631iu=/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 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 Sun, Feb 15, 2015 at 06:13:06PM +0100, Tamas Blummer wrote: On Feb 15, 2015, at 6:02 PM, Peter Todd p...@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 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 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 p...@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 p...@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 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 Feb 15, 2015, at 6:02 PM, Peter Todd p...@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 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?)
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 p...@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 p...@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 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?)
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 ta...@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 p...@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 p...@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 -- 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 a...@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 -- 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 ta...@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. -- 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
