馃搮 Original date posted:2015-08-19
馃摑 Original message:Moving it here from the other thread.
On Thu, Aug 20, 2015 at 2:08 AM, Eric Voskuil <eric at voskuil.org> wrote:
> On 08/19/2015 04:27 PM, Jorge Tim贸n wrote:
>> No, as previously explained, once libconsensus is complete it can be
>> moved to a separate repository like libsecp256k1.
>
> I don't see this happening any time soon, and I'm not sure why we should
> wait for it.
Yes, unfortunately I don't see this happening any time soon either, at
least not with the amount of review I'm getting.
My initial hope was to complete libconsensus by 0.12 (one year should
be enough time, right?) but I was being too optimistic.
By "wait for it" I assume you mean waiting for libconsensus to be
complete before we separate it to a different repository.
The reason is just simplicity.
>>> 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...
>
> You might consider this as feedback from your customer base.
Mhmm, not sure I understand this point.
>> 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).
>
> That's a false dichotomy. We never would have considered forking Bitcoin
> Core, and still wouldn't. Why would we set ourselves up for this
> disruption, which would inevitably lead to us factoring the consensus
> portions of libconsensus out of /bitcoin at the 11th hour?
>
> We have to operate as if it can happen at any time. Otherwise we have
> relinquished control of this vote and failed our users. Given that
> operating assumption, it is much safer for us to have already done this
> work (which we did). [It also provides a forcing function for us to
> review in detail any consensus changes that get pushed out.]
Yes, you need to operate as if it can happen at any time. I now
understandbetter your position of having your own repository until a
complete libconsensus is separated.
In the meantime you will have to keep using your re-implementation of
the rest of the consensus rules (besides the script checks), but
fortunately the most risky and harder reimplementation is the part of
the script validation.
> My question is why you would not embrace an independent consensus
> repository? Your work to evolve it doesn't change.
Yes, I want a separated repository. I just wanted to start with a
separated folder first. Right now there's consensus code all over the
place, specially in main.cpp.
I think changing the order (separated repository first, moving code
from Bitcoin Core to libconsensus later) would increase the total
amount of work.
Here's another option that has recently crossed my mind:
1) Finish the libconsensus separation in an independent branch on top
of a given version, for example 0.11.
2) Separate a repository from that. Alternative implementations can
start using a full libconsensus
3) Rebase that branch on top of bitcoin/master and start to PR small
groups of commits. Once the whole branch has been merged, Bitcoin Core
can replace the consensus folder with the libconsensus subtree, so
that Bitcoin Core itself can start using a full libconsensus.
Ironically with this plan Bitcoin Core may not be the full node first
implementation to use a full libconsensus.
There will be some consensus fork bug risks during 3 (which at the
current speed I estimate it could easily take 3 or 4 years) and there
would be some redundant work (replicating every consensus change in
both Bitcoin Core and libconsensus).
On the bright side, we may be able to have a full libconsensus this
year (which was my goal after we exposed VerifyScript in the first
libconsensus).
Thoughts?
Jorge Tim贸n [ARCHIVE] /
npub1fx鈥l2d8
2023-06-07 15:48:44
in reply to nevent1q鈥n78
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 15:48:44Event JSON
{
"id": "867a8305d4449b0f0c71124dc8f86789389088da2d17ed5d5b36a65c7c20157f",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686152924,
"kind": 1,
"tags": [
[
"e",
"2cb77a81d8c40c165dca19129371f9698d50bec611bf964a3c59cbb47a7d1941",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "馃搮 Original date posted:2015-08-19\n馃摑 Original message:Moving it here from the other thread.\n\nOn Thu, Aug 20, 2015 at 2:08 AM, Eric Voskuil \u003ceric at voskuil.org\u003e wrote:\n\u003e On 08/19/2015 04:27 PM, Jorge Tim贸n wrote:\n\u003e\u003e No, as previously explained, once libconsensus is complete it can be\n\u003e\u003e moved to a separate repository like libsecp256k1.\n\u003e\n\u003e I don't see this happening any time soon, and I'm not sure why we should\n\u003e wait for it.\n\nYes, unfortunately I don't see this happening any time soon either, at\nleast not with the amount of review I'm getting.\nMy initial hope was to complete libconsensus by 0.12 (one year should\nbe enough time, right?) but I was being too optimistic.\nBy \"wait for it\" I assume you mean waiting for libconsensus to be\ncomplete before we separate it to a different repository.\nThe reason is just simplicity.\n\n\u003e\u003e\u003e In our discussion leading up to libbitcoin building libbitcoin-consensus\n\u003e\u003e\u003e we disagreed on whether intentional hard forks would (or even could)\n\u003e\u003e\u003e happen. I think that issue is now settled. So my question remains how do\n\u003e\u003e\u003e stakeholders (users/miners) maintain consensus when it's their\n\u003e\u003e\u003e individual intent (the first objective of libconsensus), and diverge\n\u003e\u003e\u003e when intended (which a direct dependency on libconsensus makes harder)?\n\u003e\u003e\u003e IMO it's unreasonable to operate as if this won't happen, given that it has.\n\u003e\u003e\n\u003e\u003e I believe the simplest option...\n\u003e\n\u003e You might consider this as feedback from your customer base.\n\nMhmm, not sure I understand this point.\n\n\u003e\u003e would be to fork the libconsensus\n\u003e\u003e project and do the schism/controversial/contentious hardfork there.\n\u003e\u003e But of course modifying libconsensus will be much easier than\n\u003e\u003e modifying Bitcoin Core (if anything, because the amount of code is\n\u003e\u003e much smaller).\n\u003e\n\u003e That's a false dichotomy. We never would have considered forking Bitcoin\n\u003e Core, and still wouldn't. Why would we set ourselves up for this\n\u003e disruption, which would inevitably lead to us factoring the consensus\n\u003e portions of libconsensus out of /bitcoin at the 11th hour?\n\u003e\n\u003e We have to operate as if it can happen at any time. Otherwise we have\n\u003e relinquished control of this vote and failed our users. Given that\n\u003e operating assumption, it is much safer for us to have already done this\n\u003e work (which we did). [It also provides a forcing function for us to\n\u003e review in detail any consensus changes that get pushed out.]\n\nYes, you need to operate as if it can happen at any time. I now\nunderstandbetter your position of having your own repository until a\ncomplete libconsensus is separated.\nIn the meantime you will have to keep using your re-implementation of\nthe rest of the consensus rules (besides the script checks), but\nfortunately the most risky and harder reimplementation is the part of\nthe script validation.\n\n\u003e My question is why you would not embrace an independent consensus\n\u003e repository? Your work to evolve it doesn't change.\n\nYes, I want a separated repository. I just wanted to start with a\nseparated folder first. Right now there's consensus code all over the\nplace, specially in main.cpp.\nI think changing the order (separated repository first, moving code\nfrom Bitcoin Core to libconsensus later) would increase the total\namount of work.\n\nHere's another option that has recently crossed my mind:\n\n1) Finish the libconsensus separation in an independent branch on top\nof a given version, for example 0.11.\n2) Separate a repository from that. Alternative implementations can\nstart using a full libconsensus\n3) Rebase that branch on top of bitcoin/master and start to PR small\ngroups of commits. Once the whole branch has been merged, Bitcoin Core\ncan replace the consensus folder with the libconsensus subtree, so\nthat Bitcoin Core itself can start using a full libconsensus.\n\nIronically with this plan Bitcoin Core may not be the full node first\nimplementation to use a full libconsensus.\nThere will be some consensus fork bug risks during 3 (which at the\ncurrent speed I estimate it could easily take 3 or 4 years) and there\nwould be some redundant work (replicating every consensus change in\nboth Bitcoin Core and libconsensus).\nOn the bright side, we may be able to have a full libconsensus this\nyear (which was my goal after we exposed VerifyScript in the first\nlibconsensus).\n\nThoughts?",
"sig": "92740a8fa2d7ec6445308a8400a109d189fd0535993b83c95fbbd39dda5abb69ea33015f38d98f1aa39ae833f8674cb76e81925fdf3f0e75f341aae1d5ab69ee"
}