public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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.


  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 [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
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.cc \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=eric@voskuil.org \
    --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