From: "Jorge Timón" <jtimon@jtimon•cc>
To: Eric Voskuil <eric@voskuil•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>,
Libbitcoin <libbitcoin@lists•dyne.org>
Subject: Re: [bitcoin-dev] Bitcoin XT Fork
Date: Thu, 20 Aug 2015 01:27:51 +0200 [thread overview]
Message-ID: <CABm2gDpzAL9Rci8m60ruhHeDXx3gvGgPHMbupZKUZA1wys-AiQ@mail.gmail.com> (raw)
In-Reply-To: <55D50C15.9020402@voskuil.org>
On Thu, Aug 20, 2015 at 1:07 AM, Eric Voskuil <eric@voskuil•org> wrote:
> [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?
No, as previously explained, once libconsensus is complete it can be
moved to a separate repository like libsecp256k1.
At first it will need to be a subtree/subrepository of Bitcoin Core
(like libsecp256k1 currently is), but I still don't undesrtand how
that can possibly be a problem for alternative implementations (they
can use a subtree as well if they want to). Depending on a separated
libconsensus doesn't "make Bitcoin Core a dependency" more than
depending on libsecp256k1 currently does.
> 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.
I believe the simplest option would be to fork the libconsensus
project and do the schism/controversial/contentious hardfork there.
But of course modifying libconsensus will be much easier than
modifying Bitcoin Core (if anything, because the amount of code is
much smaller).
> 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.
Unfortunately I only directly contacted libbitcoin because I was
subscribed to the list at the time (maybe I'm still subscribed, not
really sure).
The other attempts to get feedback from other alternative
implementations have been just mostly-ignored threads in bitcoin-dev.
So, no, I cannot facilitate such a discussion, but I'm more than happy
to collaborate to achieve our mutual goal.
next prev parent reply other threads:[~2015-08-19 23:27 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-19 16:53 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
2015-08-19 23:27 ` Jorge Timón [this message]
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=CABm2gDpzAL9Rci8m60ruhHeDXx3gvGgPHMbupZKUZA1wys-AiQ@mail.gmail.com \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eric@voskuil$(echo .)org \
--cc=libbitcoin@lists$(echo .)dyne.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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