📅 Original date posted:2021-02-28
📝 Original message:On Sunday 28 February 2021 16:45:22 Matt Corallo via bitcoin-dev wrote:
> many individuals are committing themselves to running
> incompatible consensus rules.
Yet that is exactly what you propose herein...
> Given this, it seems one way to keep the network in consensus would be to
> simply activate taproot through a traditional, no-frills, flag-day (or
> -height) activation with a flag day of roughly August, 2022.
Concept NACK. This still has the same problems BIP149 would have had, as I
just reminded in my last email to this ML:
1) Such a chain does not indicate activation at all, leaving it unresolved and
debatable whether activation has occurred or not.
2) As a result, it is also impractical to intentionally reject the softfork
should anyone decide to do so.
Signalling is important to activation.
> 2) The high node-level-adoption bar is one of the most critical goals, and
> the one most currently in jeopardy in a BIP 8 approach.
It is only jeopardized if people continue to push for a LOT=False deployment
(or this new proposal of yours).
BIP 8 itself, with LOT=True, does not create such a risk at all.
> Users demanding alternative consensus rules (or, worse, configuration flags
> to change consensus rules on individual nodes with an expectation of use)
> makes this very complicated in the context of BIP 8.
Alternative consensus rules is exactly what you are proposing here.
More alternative rules to choose from just increase the risks. Two options is
annoying, but adding a third for no reason is just absurd.
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 18:29:17
in reply to nevent1q…hw9t
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 18:29:17Event JSON
{
"id": "74b69f1a7d5cd54711569faec932304798e47b32bdf3646ffe5133406665379d",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686162557,
"kind": 1,
"tags": [
[
"e",
"fa02b951f7d42f12ecb1d08d8129fee00ff24850ac6e199295db5844f5cb757f",
"",
"root"
],
[
"e",
"0acc50624826afa43f768b578901b1e5a451e426f8f0e8a22b6e053f8f234818",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2021-02-28\n📝 Original message:On Sunday 28 February 2021 16:45:22 Matt Corallo via bitcoin-dev wrote:\n\u003e many individuals are committing themselves to running\n\u003e incompatible consensus rules.\n\nYet that is exactly what you propose herein...\n\n\u003e Given this, it seems one way to keep the network in consensus would be to\n\u003e simply activate taproot through a traditional, no-frills, flag-day (or\n\u003e -height) activation with a flag day of roughly August, 2022.\n\nConcept NACK. This still has the same problems BIP149 would have had, as I \njust reminded in my last email to this ML:\n\n1) Such a chain does not indicate activation at all, leaving it unresolved and \ndebatable whether activation has occurred or not.\n2) As a result, it is also impractical to intentionally reject the softfork \nshould anyone decide to do so.\n\nSignalling is important to activation.\n\n\u003e 2) The high node-level-adoption bar is one of the most critical goals, and\n\u003e the one most currently in jeopardy in a BIP 8 approach.\n\nIt is only jeopardized if people continue to push for a LOT=False deployment \n(or this new proposal of yours).\n\nBIP 8 itself, with LOT=True, does not create such a risk at all.\n\n\u003e Users demanding alternative consensus rules (or, worse, configuration flags\n\u003e to change consensus rules on individual nodes with an expectation of use)\n\u003e makes this very complicated in the context of BIP 8.\n\nAlternative consensus rules is exactly what you are proposing here.\n\nMore alternative rules to choose from just increase the risks. Two options is \nannoying, but adding a third for no reason is just absurd.\n\nLuke",
"sig": "15f81a62b3f65d71ff3a091a827099c7d25afb0e5ebb87d1769443aea5210c329b642e74972a1abf527792f638ee65b35f535e584900d043df639e9ced35d850"
}