📅 Original date posted:2021-03-04
📝 Original message:On Thu, 4 Mar 2021 at 10:07, John Rand via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Consensus is important for both taproot and separately for the activation
> mechanism. There are more soft-forks that Bitcoin will need, so it is
> important to achieve positive progress on the activation topic also, not
> get impatient and rush something ill-considered. Not all future soft-forks
> maybe as widely supported as taproot, and yet it could become existentially
> critical that Bitcoin prevails in achieving a future upgrade in dramatic
> circumstances, even against powerful interests counter to Bitcoin user and
> investors interests. We should treat the activation topic in a considered
> way and with decorum, provide tight non-emotive reasoning devoid of
> frustration and impatience. This is a low drama and convenient time to
> incrementally improve activation. People have varied views about the
> deciding factor, or even which factors resulted in segwit activating after
> BIP 141 failed using BIP 9. We do not have to solve everything in one
> step, incremental improvement is good, for complex unintuitive topics, to
> learn as we go - and it should not be hard to do less badly than what
> transpired leading up to BIP 148 and BIP 91. Failure to upgrade if
> permanent, or demoralizing to protocol researchers could be a systemic risk
> in itself as there are more upgrades Bitcoin will need. We are not Ents
> but we should use our collective ingenuity to find an incremental
> improvement for activation.
>
Great high level thoughts
The Ents themselves were created in Tolkien's fork of Shakespeare, when he
was frustrated to learn that trees didnt actually march :)
Having followed standards for 10+ years consensus can be tricky
IIRC last time with segwit there was a straw poll in the wiki where devs
could express leanings in an informal, async way. Something like that
could be of value.
There's an insightful spec written at the IETF "On Consensus and Humming in
the IETF", then IMHO is worth reading
https://tools.ietf.org/html/rfc7282
That said, if we could find an incorruptible machine that could gather the
highest fee tx from the mempool and post it every 10 minutes, bitcoin would
largely run itself. So, while understanding the gravity of each change, we
could perhaps have the mindset that there are a finite number, such that
when complete bitcoin will move to an endgame where for the user it 'just
works', much like the internet. If devs and changes are needed less, that
could be viewed as a sign of success. This is a hand wavy way of saying
that forks could potentially be a diminishing issue over time
Just my 2 satoshis
>
> John R
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210304/54504948/attachment-0001.html>;
Melvin Carvalho [ARCHIVE] /
npub1uv…saxrt
2023-06-07 18:30:03
in reply to nevent1q…scr0
Author Public Key
npub1uvtfvcegcn9kds68r8he57emc480vqtx8t22kpsctxgjxae44gvsksaxrtSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:30:03Event JSON
{
"id": "998670f7fd0b8dd94de803773ecc563ec50cf34696d9aeb9b609a5fecbdeca9e",
"pubkey": "e316966328c4cb66c34719ef9a7b3bc54ef601663ad4ab06185991237735aa19",
"created_at": 1686162603,
"kind": 1,
"tags": [
[
"e",
"db7c3b5dcd6fa2ea0cfd70930dae8798bf875d2d7428dbc526697e076d2eb0e8",
"",
"root"
],
[
"e",
"dfa88a6ec87174d1703edadae5e399cba1a66687ea2b5b71a5704729349cc9aa",
"",
"reply"
],
[
"p",
"92ebf3db0fdfa5a49f47ed178462948d7874a13819a6c0f3b6ff45e1ba6523b4"
]
],
"content": "📅 Original date posted:2021-03-04\n📝 Original message:On Thu, 4 Mar 2021 at 10:07, John Rand via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Consensus is important for both taproot and separately for the activation\n\u003e mechanism. There are more soft-forks that Bitcoin will need, so it is\n\u003e important to achieve positive progress on the activation topic also, not\n\u003e get impatient and rush something ill-considered. Not all future soft-forks\n\u003e maybe as widely supported as taproot, and yet it could become existentially\n\u003e critical that Bitcoin prevails in achieving a future upgrade in dramatic\n\u003e circumstances, even against powerful interests counter to Bitcoin user and\n\u003e investors interests. We should treat the activation topic in a considered\n\u003e way and with decorum, provide tight non-emotive reasoning devoid of\n\u003e frustration and impatience. This is a low drama and convenient time to\n\u003e incrementally improve activation. People have varied views about the\n\u003e deciding factor, or even which factors resulted in segwit activating after\n\u003e BIP 141 failed using BIP 9. We do not have to solve everything in one\n\u003e step, incremental improvement is good, for complex unintuitive topics, to\n\u003e learn as we go - and it should not be hard to do less badly than what\n\u003e transpired leading up to BIP 148 and BIP 91. Failure to upgrade if\n\u003e permanent, or demoralizing to protocol researchers could be a systemic risk\n\u003e in itself as there are more upgrades Bitcoin will need. We are not Ents\n\u003e but we should use our collective ingenuity to find an incremental\n\u003e improvement for activation.\n\u003e\n\nGreat high level thoughts\n\nThe Ents themselves were created in Tolkien's fork of Shakespeare, when he\nwas frustrated to learn that trees didnt actually march :)\n\nHaving followed standards for 10+ years consensus can be tricky\n\nIIRC last time with segwit there was a straw poll in the wiki where devs\ncould express leanings in an informal, async way. Something like that\ncould be of value.\n\nThere's an insightful spec written at the IETF \"On Consensus and Humming in\nthe IETF\", then IMHO is worth reading\n\nhttps://tools.ietf.org/html/rfc7282\n\nThat said, if we could find an incorruptible machine that could gather the\nhighest fee tx from the mempool and post it every 10 minutes, bitcoin would\nlargely run itself. So, while understanding the gravity of each change, we\ncould perhaps have the mindset that there are a finite number, such that\nwhen complete bitcoin will move to an endgame where for the user it 'just\nworks', much like the internet. If devs and changes are needed less, that\ncould be viewed as a sign of success. This is a hand wavy way of saying\nthat forks could potentially be a diminishing issue over time\n\nJust my 2 satoshis\n\n\n\u003e\n\u003e John R\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210304/54504948/attachment-0001.html\u003e",
"sig": "f269d84cdd66b7c4113724e02239d3dc44ec92bb3e73c0a8a9d19bc292bdd2e1105fe4a699d78ea3cfcde86f20a3155847b70d2d06c459181004b68913c2cb03"
}