Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2014-04-24 📝 Original message:On Thu, Apr 24, 2014 at ...
📅 Original date posted:2014-04-24
📝 Original message:On Thu, Apr 24, 2014 at 12:58 AM, Mike Hearn <mike at plan99.net> wrote:
> The complexity overhead is trivial - we already used coinbase scriptSigs for
> voting on P2SH, I'm sure it'll be used for voting on other things in future
> too.
We use coinbase sigs to gauge the safety of enforcing a soft fork
several times and not just for P2SH, to determine when enforcement of
it will be decisive and not result in risking a partition in the
network that might permit transaction reversals. This is not voting.
As a feature decision mechanism his is a rather coercive thing because
it gives the highest hash-power bidders control even when their
interests may be rather thoroughly unaligned with population that owns
and uses bitcoin in general, but as a plain indicator of when its safe
to enforce a new rule (same mechanism, different motivation— though a
point is that safe usage means using much more than 50% as the
threshold) it works pretty well.
> .... that's hugely complex and messy.
Yes, making really distributed systems that work in a complex world is
hard. It certantly would be /easier/ to just declare miners "trusted
parties" and require them to always collude to produce a single
consensus view of the world that is always honest and never
contradictory, except that it doesn't work. Because they aren't
individually trusted or even trustworthy.
> Why? Remember deleting coinbases with nothing more than a simple majority is
> already possible in the existing protocol and always has been.
Temporarily censoring transactions by orphaning otherwise valid blocks
that contain them for as long as you retain a majority is possible and
impossible to prevent in this architecture. This isn't the same as
deleting. Deleting suggests the common misconception that a majority
of miners can do anything they want.
Published at
2023-06-07 15:19:50Event JSON
{
"id": "7ac6353f48124a7e8af85f4c28e4563a172ec4996b490fc41c1c95a846198c61",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151190,
"kind": 1,
"tags": [
[
"e",
"5090665aad23a77b012135979db1e16bc811db23aa511d1ac7d17a56045795a8",
"",
"root"
],
[
"e",
"d07c327d35e0c19a904b9694a5ed7f97526d27deda822a9c6a33685440556fec",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-04-24\n📝 Original message:On Thu, Apr 24, 2014 at 12:58 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e The complexity overhead is trivial - we already used coinbase scriptSigs for\n\u003e voting on P2SH, I'm sure it'll be used for voting on other things in future\n\u003e too.\n\nWe use coinbase sigs to gauge the safety of enforcing a soft fork\nseveral times and not just for P2SH, to determine when enforcement of\nit will be decisive and not result in risking a partition in the\nnetwork that might permit transaction reversals. This is not voting.\nAs a feature decision mechanism his is a rather coercive thing because\nit gives the highest hash-power bidders control even when their\ninterests may be rather thoroughly unaligned with population that owns\nand uses bitcoin in general, but as a plain indicator of when its safe\nto enforce a new rule (same mechanism, different motivation— though a\npoint is that safe usage means using much more than 50% as the\nthreshold) it works pretty well.\n\n\u003e .... that's hugely complex and messy.\n\nYes, making really distributed systems that work in a complex world is\nhard. It certantly would be /easier/ to just declare miners \"trusted\nparties\" and require them to always collude to produce a single\nconsensus view of the world that is always honest and never\ncontradictory, except that it doesn't work. Because they aren't\nindividually trusted or even trustworthy.\n\n\u003e Why? Remember deleting coinbases with nothing more than a simple majority is\n\u003e already possible in the existing protocol and always has been.\n\nTemporarily censoring transactions by orphaning otherwise valid blocks\nthat contain them for as long as you retain a majority is possible and\nimpossible to prevent in this architecture. This isn't the same as\ndeleting. Deleting suggests the common misconception that a majority\nof miners can do anything they want.",
"sig": "b25d4274dbeed5b393dcb41f032c04e8138dbc4d81014297c0681da06b9434e23b4bdf3b3e6e80282525e3490e32d2478bd03d4f6033a62706286fc629ee5be4"
}