summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTamas Blummer <tamas@bitsofproof.com>2015-08-21 08:46:26 +0200
committerbitcoindev <bitcoindev@gnusha.org>2015-08-21 06:46:31 +0000
commitcb4b862da8306ecd50ae8fa6a3b67ac0a640b589 (patch)
treed0285fd7f3716fbcabcbc767dbffb1c7c147841d
parent4608a9426f7ffaef7fbe818988e7cb114eabb2cf (diff)
downloadpi-bitcoindev-cb4b862da8306ecd50ae8fa6a3b67ac0a640b589.tar.gz
pi-bitcoindev-cb4b862da8306ecd50ae8fa6a3b67ac0a640b589.zip
Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)
-rw-r--r--8c/4e76f26913fa7e04826e42a8b94d7acebd99b7353
1 files changed, 353 insertions, 0 deletions
diff --git a/8c/4e76f26913fa7e04826e42a8b94d7acebd99b7 b/8c/4e76f26913fa7e04826e42a8b94d7acebd99b7
new file mode 100644
index 000000000..e69de713a
--- /dev/null
+++ b/8c/4e76f26913fa7e04826e42a8b94d7acebd99b7
@@ -0,0 +1,353 @@
+Return-Path: <tamas@bitsofproof.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 6DD5E93D
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 21 Aug 2015 06:46:31 +0000 (UTC)
+X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
+Received: from wp059.webpack.hosteurope.de (wp059.webpack.hosteurope.de
+ [80.237.132.66])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 50669AB
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 21 Aug 2015 06:46:29 +0000 (UTC)
+Received: from [37.143.74.116] (helo=[192.168.2.15]); authenticated
+ by wp059.webpack.hosteurope.de running ExIM with esmtpsa
+ (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
+ id 1ZSg5r-0001En-5Y; Fri, 21 Aug 2015 08:46:27 +0200
+Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
+Content-Type: multipart/signed;
+ boundary="Apple-Mail=_63F06019-9190-46A2-A187-C47590462D2C";
+ protocol="application/pgp-signature"; micalg=pgp-sha512
+X-Pgp-Agent: GPGMail 2.5.1
+From: Tamas Blummer <tamas@bitsofproof.com>
+In-Reply-To: <55D64806.5060404@mattcorallo.com>
+Date: Fri, 21 Aug 2015 08:46:26 +0200
+Message-Id: <DE81C494-FB9F-49FA-9281-BF274345E411@bitsofproof.com>
+References: <CABm2gDrApVuxF8DFf32V=pQhDKvvVfcDK=LeCXJ9h9o8CY+wNQ@mail.gmail.com>
+ <55B723EA.7010700@voskuil.org>
+ <CABm2gDok2gH2R8=x3a8PmPiM56WFg3TKzCum_WS=uV9-T1Ss3g@mail.gmail.com>
+ <55B939CF.1080903@voskuil.org>
+ <CABm2gDq1wHP01Tncw3hu=SCWQHaAOMjWOVYQWdQsOZ+E7zp9Yw@mail.gmail.com>
+ <CABm2gDr_ePfPeWB8pEO8QNHDjUZpybVuCAdDmMxJxMaC8+2bGA@mail.gmail.com>
+ <C4EA4A39-1920-4F33-822C-FBD12DF81004@bitsofproof.com>
+ <CABm2gDqkF20ZoexQSV8iORb3ukxxZr5RasTLxJqQfSTsTqHvog@mail.gmail.com>
+ <3390F712-879A-46E9-ABCD-D35B51190304@bitsofproof.com>
+ <55D611FC.6010305@mattcorallo.com>
+ <9861CA5B-A13D-4CFB-9529-511F93E68A72@bitsofproof.com>
+ <55D64806.5060404@mattcorallo.com>
+To: Matt Corallo <lf-lists@mattcorallo.com>
+X-Mailer: Apple Mail (2.2102)
+X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1440139589;
+ d0609c06;
+X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
+ RCVD_IN_DNSWL_LOW,URIBL_BLACK autolearn=no version=3.3.1
+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
+ smtp1.linux-foundation.org
+Cc: bitcoin-dev@lists.linuxfoundation.org
+Subject: Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin
+ Core and hard forks)
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.12
+Precedence: list
+List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
+X-List-Received-Date: Fri, 21 Aug 2015 06:46:31 -0000
+
+
+--Apple-Mail=_63F06019-9190-46A2-A187-C47590462D2C
+Content-Type: multipart/alternative;
+ boundary="Apple-Mail=_7D9F8C56-3DA5-49E0-9495-2B15FDF727FA"
+
+
+--Apple-Mail=_7D9F8C56-3DA5-49E0-9495-2B15FDF727FA
+Content-Transfer-Encoding: quoted-printable
+Content-Type: text/plain;
+ charset=windows-1252
+
+Thinking in Bitcoins only on the level of technology unnecessarily =
+narrows your view.
+
+OK, I hope to be pleasantly surprised.
+
+Tamas Blummer
+
+> On Aug 20, 2015, at 23:35, Matt Corallo <lf-lists@mattcorallo.com> =
+wrote:
+>=20
+>=20
+>=20
+> On 08/20/15 21:26, Tamas Blummer wrote:
+>> I know what you mean as I already have such a component with =
+pluggable
+>> block store and networking.
+>=20
+> I'm not suggesting pluggable networking, I'm suggesting (and I think
+> everyone thinks the design should be) NO networking. The API is
+> ValidationResult libconsensus.HeyIFoundABlock(Block) and
+> ListOfBlocksToDownloadNext =
+libconsensus.HeyIFoundAHeaderList(ListOfHeaders).
+>=20
+>> While you are at it you could aim for isolation of bitcoin specific
+>> decisions and algos from generic block chain code.
+>=20
+> Are you suggesting to support altcoins? I dont think anyone cares =
+about
+> supporting that.
+>=20
+>> The magnitude of refactoring you would have to do to get there from
+>> main.cpp and the rest of the hairball
+>> is harder than a re-write from scratch,
+>=20
+> I think you'd be very pleasantly surprised. It sounds like you havent
+> dug into Bitcoin Core validation code in years.
+>=20
+>> and the result will not be
+>> impressive, just hopefully working.
+>=20
+> Hmm? The result would be an obviously correct consensus implementation
+> that everyone could use, instead of everyone going off and writing =
+their
+> own and either being wrong, or never updating in the case of forks. =
+Its
+> a huge deal to allow people to focus on making their libraries have =
+good
+> APIs/Wallets/etc instead of focusing on making a working validation
+> engine (though maybe for that the p2p layer needs to also be in a =
+library).
+>=20
+>> I think a slim API server was a lower hanging fruit in Core=92s case.
+>=20
+> We have one, it just needs a few already obvious performance =
+improvements.
+>=20
+>> BTW, support for refactoring is an example where you see if your tool
+>> set is modern.
+>=20
+> There are a number of good development tools for C++ that allow =
+this....
+>=20
+>> Tamas Blummer
+>>=20
+>>> On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev
+>>> <bitcoin-dev@lists.linuxfoundation.org
+>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
+>>>=20
+>>> I dont think a libconsensus would have any kind of networking layer, =
+nor
+>>> is C++ an antique tool set (hopefully libconsensus can avoid a boost
+>>> dependency, though thats not antique either). Ideally it would have =
+a
+>>> simple API to give it blocks and a simple API for it to inform you =
+of
+>>> what the current chain is. If you really want to get fancy maybe it =
+has
+>>> pluggable block storage, too, but I dont see why you couldnt use =
+this in
+>>> ~any client?
+>>>=20
+>>> On 08/20/15 08:35, Tamas Blummer via bitcoin-dev wrote:
+>>>> Every re-implementation, re-factoring even copy-paste introduces a
+>>>> risk of disagreement,
+>>>> but also open the chance of doing the work better, in the sense of
+>>>> software engineering.
+>>>>=20
+>>>>> On Aug 20, 2015, at 10:06, Jorge Tim=F3n <jtimon@jtimon.cc
+>>>>> <mailto:jtimon@jtimon.cc>> wrote:
+>>>>>=20
+>>>>>=20
+>>>>> But the goal is not reimplementing the consensus rules but rather
+>>>>> extract them from Bitcoin Core so that nobody needs to =
+re-implement
+>>>>> them again.
+>>>>=20
+>>>>=20
+>>>>=20
+>>>> My goal is different. Compatibility with Bitcoin is important as I
+>>>> also want to deal with Bitcoins,
+>>>> but it is also imperative to be able to create and serve other =
+block
+>>>> chains with other rules and for those
+>>>> I do not want to carry on the legacy of an antique tool set and a
+>>>> spaghetti style.
+>>>>=20
+>>>> Bits of Proof uses scala (akka networking), java (api service), c++
+>>>> (leveledb and now libconsensus)
+>>>> and I am eager to integrate secp256k1 (c) as soon as part of
+>>>> consensus. The choices were
+>>>> made because each piece appears best in what they do.
+>>>>=20
+>>>> Tamas Blummer
+>>>>=20
+>>>>=20
+>>>>=20
+>>>> _______________________________________________
+>>>> bitcoin-dev mailing list
+>>>> bitcoin-dev@lists.linuxfoundation.org
+>>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
+>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>>>>=20
+>>> _______________________________________________
+>>> bitcoin-dev mailing list
+>>> bitcoin-dev@lists.linuxfoundation.org
+>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
+>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>>>=20
+>>=20
+>=20
+
+
+--Apple-Mail=_7D9F8C56-3DA5-49E0-9495-2B15FDF727FA
+Content-Transfer-Encoding: quoted-printable
+Content-Type: text/html;
+ charset=windows-1252
+
+<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
+charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
+-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
+class=3D""><div class=3D"">Thinking in Bitcoins only on the level of =
+technology unnecessarily narrows your view.</div><div class=3D""><br =
+class=3D""></div><div class=3D"">OK, I hope to be pleasantly =
+surprised.</div><br class=3D""><div apple-content-edited=3D"true" =
+class=3D"">
+<div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
+12px; font-style: normal; font-variant: normal; font-weight: normal; =
+letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
+start; text-indent: 0px; text-transform: none; white-space: normal; =
+widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
+class=3D"">Tamas Blummer</div><div style=3D"color: rgb(0, 0, 0); =
+font-family: Helvetica; font-size: 12px; font-style: normal; =
+font-variant: normal; font-weight: normal; letter-spacing: normal; =
+line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
+text-transform: none; white-space: normal; widows: auto; word-spacing: =
+0px; -webkit-text-stroke-width: 0px;" class=3D""><br =
+class=3D""></div></div><div><blockquote type=3D"cite" class=3D""><div =
+class=3D"">On Aug 20, 2015, at 23:35, Matt Corallo &lt;<a =
+href=3D"mailto:lf-lists@mattcorallo.com" =
+class=3D"">lf-lists@mattcorallo.com</a>&gt; wrote:</div><br =
+class=3D"Apple-interchange-newline"><div class=3D""><br class=3D""><br =
+class=3D"">On 08/20/15 21:26, Tamas Blummer wrote:<br =
+class=3D""><blockquote type=3D"cite" class=3D"">I know what you mean as =
+I already have such a component with pluggable<br class=3D"">block store =
+and networking.<br class=3D""></blockquote><br class=3D"">I'm not =
+suggesting pluggable networking, I'm suggesting (and I think<br =
+class=3D"">everyone thinks the design should be) NO networking. The API =
+is<br class=3D"">ValidationResult libconsensus.HeyIFoundABlock(Block) =
+and<br class=3D"">ListOfBlocksToDownloadNext =
+libconsensus.HeyIFoundAHeaderList(ListOfHeaders).<br class=3D""><br =
+class=3D""><blockquote type=3D"cite" class=3D"">While you are at it you =
+could aim for isolation of bitcoin specific<br class=3D"">decisions and =
+algos from generic block chain code. <br class=3D""></blockquote><br =
+class=3D"">Are you suggesting to support altcoins? I dont think anyone =
+cares about<br class=3D"">supporting that.<br class=3D""><br =
+class=3D""><blockquote type=3D"cite" class=3D"">The magnitude of =
+refactoring you would have to do to get there from<br class=3D"">main.cpp =
+and the rest of the hairball<br class=3D"">is harder than a re-write =
+from scratch,<br class=3D""></blockquote><br class=3D"">I think you'd be =
+very pleasantly surprised. It sounds like you havent<br class=3D"">dug =
+into Bitcoin Core validation code in years.<br class=3D""><br =
+class=3D""><blockquote type=3D"cite" class=3D"">and the result will not =
+be<br class=3D"">impressive, just hopefully working.<br =
+class=3D""></blockquote><br class=3D"">Hmm? The result would be an =
+obviously correct consensus implementation<br class=3D"">that everyone =
+could use, instead of everyone going off and writing their<br =
+class=3D"">own and either being wrong, or never updating in the case of =
+forks. Its<br class=3D"">a huge deal to allow people to focus on making =
+their libraries have good<br class=3D"">APIs/Wallets/etc instead of =
+focusing on making a working validation<br class=3D"">engine (though =
+maybe for that the p2p layer needs to also be in a library).<br =
+class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">I think a =
+slim API server was a lower hanging fruit in Core=92s case.<br =
+class=3D""></blockquote><br class=3D"">We have one, it just needs a few =
+already obvious performance improvements.<br class=3D""><br =
+class=3D""><blockquote type=3D"cite" class=3D"">BTW, support for =
+refactoring is an example where you see if your tool<br class=3D"">set =
+is modern.<br class=3D""></blockquote><br class=3D"">There are a number =
+of good development tools for C++ that allow this....<br class=3D""><br =
+class=3D""><blockquote type=3D"cite" class=3D"">Tamas Blummer<br =
+class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">On Aug =
+20, 2015, at 19:44, Matt Corallo via bitcoin-dev<br class=3D"">&lt;<a =
+href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
+class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"">&lt;<a =
+href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
+class=3D"">mailto:bitcoin-dev@lists.linuxfoundation.org</a>&gt;&gt; =
+wrote:<br class=3D""><br class=3D"">I dont think a libconsensus would =
+have any kind of networking layer, nor<br class=3D"">is C++ an antique =
+tool set (hopefully libconsensus can avoid a boost<br =
+class=3D"">dependency, though thats not antique either). Ideally it =
+would have a<br class=3D"">simple API to give it blocks and a simple API =
+for it to inform you of<br class=3D"">what the current chain is. If you =
+really want to get fancy maybe it has<br class=3D"">pluggable block =
+storage, too, but I dont see why you couldnt use this in<br =
+class=3D"">~any client?<br class=3D""><br class=3D"">On 08/20/15 08:35, =
+Tamas Blummer via bitcoin-dev wrote:<br class=3D""><blockquote =
+type=3D"cite" class=3D"">Every re-implementation, re-factoring even =
+copy-paste introduces a<br class=3D"">risk of disagreement,<br =
+class=3D"">but also open the chance of doing the work better, in the =
+sense of<br class=3D"">software engineering.<br class=3D""><br =
+class=3D""><blockquote type=3D"cite" class=3D"">On Aug 20, 2015, at =
+10:06, Jorge Tim=F3n &lt;<a href=3D"mailto:jtimon@jtimon.cc" =
+class=3D"">jtimon@jtimon.cc</a><br class=3D"">&lt;<a =
+href=3D"mailto:jtimon@jtimon.cc" =
+class=3D"">mailto:jtimon@jtimon.cc</a>&gt;&gt; wrote:<br class=3D""><br =
+class=3D""><br class=3D"">But the goal is not reimplementing the =
+consensus rules but rather<br class=3D"">extract them from Bitcoin Core =
+so that nobody needs to re-implement<br class=3D"">them again.<br =
+class=3D""></blockquote><br class=3D""><br class=3D""><br class=3D"">My =
+goal is different. Compatibility with Bitcoin is important as I<br =
+class=3D"">also want to deal with Bitcoins,<br class=3D"">but it is also =
+imperative to be able to create and serve other block<br class=3D"">chains=
+ with other rules and for those<br class=3D"">I do not want to carry on =
+the legacy of an antique tool set and a<br class=3D"">spaghetti =
+style.<br class=3D""><br class=3D"">Bits of Proof uses scala (akka =
+networking), java (api service), c++<br class=3D"">(leveledb and now =
+libconsensus)<br class=3D"">and I am eager to integrate secp256k1 (c) as =
+soon as part of<br class=3D"">consensus. The choices were<br =
+class=3D"">made because each piece appears best in what they do.<br =
+class=3D""><br class=3D"">Tamas Blummer<br class=3D""><br class=3D""><br =
+class=3D""><br =
+class=3D"">_______________________________________________<br =
+class=3D"">bitcoin-dev mailing list<br class=3D""><a =
+href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
+class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
+class=3D"">&lt;mailto:bitcoin-dev@lists.linuxfoundation.org&gt;<br =
+class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
+br class=3D""><br =
+class=3D""></blockquote>_______________________________________________<br=
+ class=3D"">bitcoin-dev mailing list<br class=3D""><a =
+href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
+class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
+class=3D"">&lt;mailto:bitcoin-dev@lists.linuxfoundation.org&gt;<br =
+class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
+br class=3D""><br class=3D""></blockquote><br class=3D""></blockquote><br =
+class=3D""></div></blockquote></div><br class=3D""></body></html>=
+
+--Apple-Mail=_7D9F8C56-3DA5-49E0-9495-2B15FDF727FA--
+
+--Apple-Mail=_63F06019-9190-46A2-A187-C47590462D2C
+Content-Transfer-Encoding: 7bit
+Content-Disposition: attachment;
+ filename=signature.asc
+Content-Type: application/pgp-signature;
+ name=signature.asc
+Content-Description: Message signed with OpenPGP using GPGMail
+
+-----BEGIN PGP SIGNATURE-----
+Comment: GPGTools - https://gpgtools.org
+
+iQEcBAEBCgAGBQJV1slCAAoJEPZykcUXcTkcWvoH/2jhd3cl5Y6IQ6Y5np1z8wqE
+1/8Lxs4tVgzegJa+LYkUGy0rr89ZD3tTBwRD5OvnHh8XoLcgz3jPgGdXX2Gr16OO
+RJ4IZ2xmP7+iEf78fRPANfh7YXkrPJxYiaxPG5B80GNVQvTorwAOvQXyRiaG1ZFb
+tYPulG+cXSNVYsa9ii7vR1cc2Jls9V6nifYbbZ00fGfaSsSsiux7j1RFss0XwBm1
+rUFpNHoS63C22AMKkxkVbItJr91slD0XyAOp+8MuG8vtK5hCOmwCIck+zuSYA51H
+zf/wF0CbWdnCtJEA0P7c6+OpZPA3P8I/tHgIyMN1YFU+vr9OnqrutWI+nnphqAA=
+=2nxX
+-----END PGP SIGNATURE-----
+
+--Apple-Mail=_63F06019-9190-46A2-A187-C47590462D2C--
+