{"type":"rich","version":"1.0","author_name":"npub1f2nxequ09nz44775vv6lkffq2plzqvrqramnk29eddmwcc9z7jys8ms289","author_url":"https://nostr.ae/npub1f2nxequ09nz44775vv6lkffq2plzqvrqramnk29eddmwcc9z7jys8ms289","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-04-26\n📝 Original message:Hi all,\n\nAlongside the debate with CTV right now there's a second debate that was\nnot fully hashed out in the activation of Taproot. There is a lot of\nargument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't\netc. A significant reason for the breakdown in civility around this debate\nis that because we don't have a means of measuring user support for\nproposed sof-fork changes, it invariably devolves into people claiming that\ntheir circles support/reject a proposal, AND that their circles are more\nbroadly representative of the set of Bitcoin users as a whole.\n\nIt seems everyone in this forum has at one point or another said \"I would\nsupport activation of ____ if there was consensus on it, but there isn't\".\nThis statement, in order to be true, requires that there exist a set of\nconditions that would convince you that there is consensus. People have\ntried to dodge this question by saying \"it's obvious\", but the reality is\nthat it fundamentally isn't. My bubble has a different \"obvious\" answer\nthan any of yours.\n\nSecondly, due to the trauma of the block size wars, no one wants to utter a\nstatement that could imply that miners have any influence over what\nrulesets get activated or don't. As such \"miner signaling\" is consistently\ndevalued as a signal for market demand. I don't think this is reasonable\nsince following the events of '17  miners are aware that they have the\nstrong incentive that they understand market demand. Nevertheless, as it\nstands right now the only signal we have to work with is miner signaling,\nwhich I think is rightly frustrating to a lot of people.\n\nSo how can we measure User Support for a proposed rule change?\n\nI've had this idea floating around in the back of my head for a while, and\nI'd like to solicit some feedback here. Currently, all forms of activation\nthat are under consideration involve miner signaling in one form or\nanother. What if we could make it such that users could more directly\npressure miners to act on their behalf? After all, if miners are but the\nhumble servants of user demands, this should be in alignment with how\npeople want Bitcoin to behave.\n\nCurrently, the only means users have of influencing miner decisions are A.\nrejection of blocks that don't follow rules and B. paying fees for\ntransaction inclusion. I suggest we combine these in such a way that\ntransactions themselves can signal for upgrade. I believe (though am not\ncertain) that there are \"free\" bits in the version field of a transaction\nthat are presently ignored. If we could devise a mapping between some of\nthose free bits, and the signaling bits in the block header, it would be\npossible to have rules as follows:\n\n- A transaction signaling in the affirmative MUST NOT be included in a\nblock that does not signal in the affirmative\n- A transaction that is NOT signaling MAY be included in a block regardless\nof that block's signaling vector\n- (Optional) A transaction signaling in the negative MUST NOT be included\nin a block that signals in the affirmative\n\nUnder this set of conditions, a user has the means of sybil-resistant\ninfluence over miner decisions. If a miner cannot collect the fees for a\ntransaction without signaling, the user's fee becomes active economic\npressure for the miner to signal (or not, if we include some variant of the\nnegative clause). In this environment, miners could have a better view into\nwhat users do want, as would the Bitcoin network at large.\n\nSome may take issue with the idea that people can pay for the outcome they\nwant and may try to compare a method like this to Proof of Stake, but there\nare only 3 sybil resistant mechanisms I am aware of, and any \"real\" view\ninto what social consensus looks like MUST be sybil resistant:\n\n- Hashpower\n- Proof of personhood (KYC)\n- Capital burn/risk\n\nLetting hashpower decide this is the thing that is currently contentious,\nKYC is dead on arrival both on technical and social grounds, which really\njust leaves some means of getting capital into the process of consensus\nmeasurement. This mechanism I'm proposing is measurable completely\nen-protocol and doesn't require trust in institutions that fork futures\nwould. Additionally it could be an auxiliary feature of the soft fork\ndeployment scheme chosen making it something you could neatly package all\ntogether with the deployment itself.\n\nThere are many potential tweaks to the design I propose above:\n1. Do we include a notion of negative signaling (allowing for the\npossibility of rejection)\n2. Do we make it such that miner signaling must be congruent with \u003eX% of\ntransactions, where congruence is that the signal must match any\nnon-neutral signal of transaction.\n\nSome anticipated objections:\n\n1. signaling isn't voting, no deployment should be made without consensus\nfirst.\n- yeah well we can't currently measure consensus right now, so that's not a\nsuper helpful thing to say and is breeding ground for abuse in the form of\ncertain people making the unsubstantiated claim that consensus does or does\nnot exist for a particular initiative\n\n2. This is just a proposal for \"pay to play\", we should not let the wealthy\nmake consensus decisions.\n- I agree that wealth should not be able to strong-arm decision making. But\nthe status quo seems even worse where we let publicly influential people\ndecide consensus in such a way where not only do they not \"lose ammunition\"\nin the process of campaigning, but actually accrue it, creating really bad\nlong-term balances of power.\n\n3. Enforcing this proposal requires its own soft fork.\n- Yes. It does...and there's a certain cosmic irony to that, but before we\nconsider how to make this happen, I'd like to even discuss whether or not\nit's a good idea.\n\n4. This gives CoinJoin pool operators and L2 protocol implementations power\nover deciding consensus.\n- I see this as an improvement over the status quo\n\n5. This encourages \"spam\"\n- If you pay the fees, it's not spam.\n\nThe biggest question I'd like to pose to the forum is:\n- Does a scheme like this afford us a better view into consensus than we\nhave today?\n- Can it be gamed to give us a *worse* view into consensus? How?\n- Does it measure the right thing? If not, what do you think is the right\nthing to measure? (assuming we could)\n- Should I write a BIP spec'ing this out in detail?\n\nCheers,\nKeagan\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220426/f3d1f2bf/attachment.html\u003e"}