馃搮 Original date posted:2015-08-19
馃摑 Original message:On Thu, Aug 20, 2015 at 1:07 AM, Eric Voskuil <eric at 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 at gmail.com> wrote:
>>> But the consensus code should NOT be subject to the same commit
> policies鈥nd 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.
Jorge Tim贸n [ARCHIVE] /
npub1fx鈥l2d8
2023-06-07 17:35:54
in reply to nevent1q鈥m4x
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 17:35:54Event JSON
{
"id": "915c7716cdbf1fa098b68c62c686ca16ebf76894381f2a3590140dec535a4e05",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686159354,
"kind": 1,
"tags": [
[
"e",
"1978e32d03d4503888c51ee921351a9cd2252143db43ca22f3f2ea46247d3802",
"",
"root"
],
[
"e",
"db789e39ab27ed3723ee762f642d68d4402248156da5895616c8de565a5eb38b",
"",
"reply"
],
[
"p",
"82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e"
]
],
"content": "馃搮 Original date posted:2015-08-19\n馃摑 Original message:On Thu, Aug 20, 2015 at 1:07 AM, Eric Voskuil \u003ceric at voskuil.org\u003e wrote:\n\u003e [cross-posted to libbitcoin]\n\u003e\n\u003e On 08/19/2015 03:00 PM, Jorge Tim贸n via bitcoin-dev wrote:\u003e On Wed, Aug\n\u003e 19, 2015 at 10:04 PM, Eric Lombrozo \u003celombrozo at gmail.com\u003e wrote:\n\u003e\u003e\u003e But the consensus code should NOT be subject to the same commit\n\u003e policies鈥nd we should make an effort to separate the two clearly. And\n\u003e we should find a way to communicate the difference succinctly and\n\u003e clearly to laypeople (which is something I think the XT opponents have\n\u003e been horrible at doing so far).\n\u003e\u003e\n\u003e\u003e I think that effort is in progress (again, much slower that I would\n\u003e\u003e like it to be) and it's called libconsensus.\n\u003e\u003e Once we have libconsensus Bitcoin Core it's just another\n\u003e\u003e implementation (even if it is the reference one) and it's not \"the\n\u003e\u003e specification of the consensus rules\" which is a \"privileged\" position\n\u003e\u003e that brings all sorts of misunderstandings and problems (the block\n\u003e\u003e size debate is just one example).\n\u003e\n\u003e Jorge,\n\u003e\n\u003e I applaud your efforts and objectives WRT libconsensus independence. But\n\u003e as you know I differ with you on this point:\n\u003e\n\u003e\u003e Once we have libconsensus Bitcoin Core it's just another\n\u003e\u003e implementation\n\u003e\n\u003e I do not consider Bitcoin Core just another implementation as long as\n\u003e libconsensus is built directly out of the bitcoind repository. It's a\n\u003e finer point, but an important one. Eric makes this point emphatically as\n\u003e well:\n\u003e\n\u003e\u003e\u003e But the consensus code should NOT be subject to the same commit\n\u003e policies...and we should make an effort to separate the two clearly.\n\u003e\n\u003e As you have implied, it's not likely to happen in the Bitcoin Core repo.\n\u003e Taking a dependency on Bitcoin Core is a metaphorical deal with the\n\u003e devil from our perspective. So my question is, how do you expect other\n\u003e implementations to transition off of that repository (and commit\n\u003e policies)? Or do you expect the dependency to be perpetual?\n\nNo, as previously explained, once libconsensus is complete it can be\nmoved to a separate repository like libsecp256k1.\nAt first it will need to be a subtree/subrepository of Bitcoin Core\n(like libsecp256k1 currently is), but I still don't undesrtand how\nthat can possibly be a problem for alternative implementations (they\ncan use a subtree as well if they want to). Depending on a separated\nlibconsensus doesn't \"make Bitcoin Core a dependency\" more than\ndepending on libsecp256k1 currently does.\n\n\u003e In our discussion leading up to libbitcoin building libbitcoin-consensus\n\u003e we disagreed on whether intentional hard forks would (or even could)\n\u003e happen. I think that issue is now settled. So my question remains how do\n\u003e stakeholders (users/miners) maintain consensus when it's their\n\u003e individual intent (the first objective of libconsensus), and diverge\n\u003e when intended (which a direct dependency on libconsensus makes harder)?\n\u003e IMO it's unreasonable to operate as if this won't happen, given that it has.\n\nI believe the simplest option would be to fork the libconsensus\nproject and do the schism/controversial/contentious hardfork there.\nBut of course modifying libconsensus will be much easier than\nmodifying Bitcoin Core (if anything, because the amount of code is\nmuch smaller).\n\n\u003e There are a very small number of implementations that rely on consensus\n\u003e (fewer that aren't also forks of Bitcoin Core). I think it's time we\n\u003e discuss how to work together to achieve our mutual goal. I assume you\n\u003e have been in contact with all of us. If you would like to facilitate\n\u003e this I'd be happy to join in an offline discussion.\n\nUnfortunately I only directly contacted libbitcoin because I was\nsubscribed to the list at the time (maybe I'm still subscribed, not\nreally sure).\nThe other attempts to get feedback from other alternative\nimplementations have been just mostly-ignored threads in bitcoin-dev.\nSo, no, I cannot facilitate such a discussion, but I'm more than happy\nto collaborate to achieve our mutual goal.",
"sig": "4c0eafc3e0f6bfae0df47d217ea79ccb2b9e88efe66225ad48ed51d78e438cc8f4680c7d570365496261247c6c671695a5bc6fb48671917b69f4c364aaedd984"
}