Ryan Grant [ARCHIVE] on Nostr: 📅 Original date posted:2021-03-05 📝 Original message:On Thu, Mar 4, 2021 at ...
📅 Original date posted:2021-03-05
📝 Original message:On Thu, Mar 4, 2021 at 7:32 PM Keagan McClelland via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> So that leads me to believe here that the folks who oppose LOT=true
> primarily have an issue with forced signaling, which personally I
> don't care about as much, not the idea of committing to a UASF from
> the get go.
The biggest disconnect is between two goals: modern soft-fork
activation's "Don't (needlessly) lose hashpower to un-upgraded
miners"; and UASF's must-signal strategy to prevent inaction.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.htmlThis question dives to the heart of Bitcoin's far-out future.
Of two important principles, which principle is more important:
- to allow everyone (even miners) to operate on the contract they
accepted when entering the system; or
- to protect against protocol sclerosis for the project as a whole?
Do miners have a higher obligation to evaluate upgrades than economic
nodes implementing cold storage and infrequent spends? If they do,
then so far it has been implicit. LOT=true would make that obligation
explicit.
Published at
2023-06-07 18:29:59Event JSON
{
"id": "1ef785c7d0e6761224b78f695932717efb07d38da75fcda30a56ec73030c7555",
"pubkey": "2f55bf03677afdb15d004a39383afba6220aa6c059cafa7b8827b87934d3c254",
"created_at": 1686162599,
"kind": 1,
"tags": [
[
"e",
"06f81a4772cfd591a3ba851990b1b3701b74c7460ca0f5e45bb7dfe492b7e3a1",
"",
"root"
],
[
"e",
"179bb1a944d228ca4aed80e33a15d91fc5399ae6d4f5ddd9282b30571a21348e",
"",
"reply"
],
[
"p",
"4aa66c838f2cc55afbd46335fb2520507e2030601f773b28b96b76ec60a2f489"
]
],
"content": "📅 Original date posted:2021-03-05\n📝 Original message:On Thu, Mar 4, 2021 at 7:32 PM Keagan McClelland via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e So that leads me to believe here that the folks who oppose LOT=true\n\u003e primarily have an issue with forced signaling, which personally I\n\u003e don't care about as much, not the idea of committing to a UASF from\n\u003e the get go.\n\nThe biggest disconnect is between two goals: modern soft-fork\nactivation's \"Don't (needlessly) lose hashpower to un-upgraded\nminers\"; and UASF's must-signal strategy to prevent inaction.\n\n https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html\n\nThis question dives to the heart of Bitcoin's far-out future.\nOf two important principles, which principle is more important:\n\n - to allow everyone (even miners) to operate on the contract they\n accepted when entering the system; or\n\n - to protect against protocol sclerosis for the project as a whole?\n\nDo miners have a higher obligation to evaluate upgrades than economic\nnodes implementing cold storage and infrequent spends? If they do,\nthen so far it has been implicit. LOT=true would make that obligation\nexplicit.",
"sig": "0e8b13d2830f4231750e9bc7bb27ac7c23ea81b70dafb35401b84731a5c9e5fca45e2e9ebd5383e2d675a87835c24d2bc194d1f1e58b87f09f7dd7d7301e07f6"
}