From: Eric Voskuil <eric@voskuil.org>
To: "Jorge Timón" <jtimon@jtimon.cc>, "Eric Lombrozo" <elombrozo@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
Libbitcoin <libbitcoin@lists.dyne.org>
Subject: Re: [bitcoin-dev] Bitcoin XT Fork
Date: Wed, 19 Aug 2015 16:07:01 -0700 [thread overview]
Message-ID: <55D50C15.9020402@voskuil.org> (raw)
In-Reply-To: <CABm2gDrefdHeYWF2y_o7A9NxRssC=ddHqY--ExxLv00TS4ShKQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]
[cross-posted to libbitcoin]
On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote:> On Wed, Aug
19, 2015 at 10:04 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:
>> But the consensus code should NOT be subject to the same commit
policies…and we should make an effort to separate the two clearly. And
we should find a way to communicate the difference succinctly and
clearly to laypeople (which is something I think the XT opponents have
been horrible at doing so far).
>
> I think that effort is in progress (again, much slower that I would
> like it to be) and it's called libconsensus.
> Once we have libconsensus Bitcoin Core it's just another
> implementation (even if it is the reference one) and it's not "the
> specification of the consensus rules" which is a "privileged" position
> that brings all sorts of misunderstandings and problems (the block
> size debate is just one example).
Jorge,
I applaud your efforts and objectives WRT libconsensus independence. But
as you know I differ with you on this point:
> Once we have libconsensus Bitcoin Core it's just another
> implementation
I do not consider Bitcoin Core just another implementation as long as
libconsensus is built directly out of the bitcoind repository. It's a
finer point, but an important one. Eric makes this point emphatically as
well:
>> But the consensus code should NOT be subject to the same commit
policies...and we should make an effort to separate the two clearly.
As you have implied, it's not likely to happen in the Bitcoin Core repo.
Taking a dependency on Bitcoin Core is a metaphorical deal with the
devil from our perspective. So my question is, how do you expect other
implementations to transition off of that repository (and commit
policies)? Or do you expect the dependency to be perpetual?
In our discussion leading up to libbitcoin building libbitcoin-consensus
we disagreed on whether intentional hard forks would (or even could)
happen. I think that issue is now settled. So my question remains how do
stakeholders (users/miners) maintain consensus when it's their
individual intent (the first objective of libconsensus), and diverge
when intended (which a direct dependency on libconsensus makes harder)?
IMO it's unreasonable to operate as if this won't happen, given that it has.
There are a very small number of implementations that rely on consensus
(fewer that aren't also forks of Bitcoin Core). I think it's time we
discuss how to work together to achieve our mutual goal. I assume you
have been in contact with all of us. If you would like to facilitate
this I'd be happy to join in an offline discussion.
e
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-08-19 23:06 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-19 16:53 [bitcoin-dev] Bitcoin XT Fork Adam Back
2015-08-19 17:22 ` Simon Liu
2015-08-19 18:13 ` Peter Todd
2015-08-19 23:37 ` Simon Liu
2015-08-19 17:28 ` Jorge Timón
2015-08-19 17:32 ` Btc Drak
2015-08-19 18:20 ` Peter Todd
2015-08-19 19:15 ` Btc Drak
2015-08-19 19:32 ` odinn
2015-08-19 19:48 ` Eric Lombrozo
2015-08-19 19:58 ` Jorge Timón
2015-08-19 20:04 ` Eric Lombrozo
2015-08-19 22:00 ` Jorge Timón
2015-08-19 23:07 ` Eric Voskuil [this message]
2015-08-19 23:27 ` Jorge Timón
2015-08-19 23:56 ` Jorge Timón
2015-08-20 1:00 ` GC
2015-08-20 1:17 ` Jorge Timón
2015-08-20 0:08 ` Eric Voskuil
2015-08-19 18:22 ` Jorge Timón
2015-08-19 19:12 ` Santino Napolitano
2015-08-19 19:28 ` Eric Lombrozo
2015-08-20 9:00 ` Mike Hearn
2015-08-20 9:13 ` Peter Todd
2015-08-21 3:01 ` odinn
-- strict thread matches above, loose matches on Subject: below --
2015-08-19 8:25 Btc Drak
2015-08-17 20:24 Theo Chino
2015-08-18 4:56 ` Dave Scotese
2015-08-15 17:43 Satoshi Nakamoto
2015-08-15 19:08 ` Laszlo Hanyecz
2015-08-15 19:10 ` jl2012
2015-08-17 11:40 ` Oliver Egginger
2015-08-17 11:44 ` Jorge Timón
2015-08-17 11:51 ` Oliver Egginger
2015-08-17 16:32 ` Jorge Timón
2015-08-17 17:01 ` Oliver Egginger
2015-08-17 17:15 ` Jorge Timón
2015-08-17 17:30 ` Btc Drak
2015-08-17 17:18 ` Gregory Maxwell
2015-08-17 19:14 ` Peter Todd
2015-08-17 17:28 ` Jeff Garzik
2015-08-17 19:03 ` Warren Togami Jr.
2015-08-17 20:37 ` Oliver Egginger
2015-08-18 5:16 ` Gregory Maxwell
2015-08-18 9:15 ` Warren Togami Jr.
2015-08-18 11:52 ` Micha Bailey
2015-08-18 18:57 ` Oliver Egginger
2015-08-18 20:59 ` Anon Moto
2015-08-19 1:03 ` Sergio Demian Lerner
2015-08-17 19:02 ` Anon Moto
2015-08-17 19:40 ` Marcel Jamin
2015-08-17 19:16 ` Hector Chu
2015-08-17 19:28 ` Gregory Maxwell
2015-08-17 19:39 ` Jorge Timón
2015-08-19 2:54 ` odinn
2015-08-19 2:59 ` Angel Leon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55D50C15.9020402@voskuil.org \
--to=eric@voskuil.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=elombrozo@gmail.com \
--cc=jtimon@jtimon.cc \
--cc=libbitcoin@lists.dyne.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox