rich1.0npub1vtwuk4rjyj6zrq3tv2z9lvdm6a7g8zujf0gz9q2vljlztdaqw36sjjsjpghttps://nostr.ae/npub1vtwuk4rjyj6zrq3tv2z9lvdm6a7g8zujf0gz9q2vljlztdaqw36sjjsjpgnjumphttps://nostr.ae📅 Original date posted:2022-04-26 📝 Original message:You may be interested in these posts on transaction signalling: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014202.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.html On Tue, Apr 26, 2022 at 3:12 PM Keagan McClelland via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > Hi all, > > Alongside the debate with CTV right now there's a second debate that was > not fully hashed out in the activation of Taproot. There is a lot of > argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't > etc. A significant reason for the breakdown in civility around this debate > is that because we don't have a means of measuring user support for > proposed sof-fork changes, it invariably devolves into people claiming that > their circles support/reject a proposal, AND that their circles are more > broadly representative of the set of Bitcoin users as a whole. > > It seems everyone in this forum has at one point or another said "I would > support activation of ____ if there was consensus on it, but there isn't". > This statement, in order to be true, requires that there exist a set of > conditions that would convince you that there is consensus. People have > tried to dodge this question by saying "it's obvious", but the reality is > that it fundamentally isn't. My bubble has a different "obvious" answer > than any of yours. > > Secondly, due to the trauma of the block size wars, no one wants to utter > a statement that could imply that miners have any influence over what > rulesets get activated or don't. As such "miner signaling" is consistently > devalued as a signal for market demand. I don't think this is reasonable > since following the events of '17 miners are aware that they have the > strong incentive that they understand market demand. Nevertheless, as it > stands right now the only signal we have to work with is miner signaling, > which I think is rightly frustrating to a lot of people. > > So how can we measure User Support for a proposed rule change? > > I've had this idea floating around in the back of my head for a while, and > I'd like to solicit some feedback here. Currently, all forms of activation > that are under consideration involve miner signaling in one form or > another. What if we could make it such that users could more directly > pressure miners to act on their behalf? After all, if miners are but the > humble servants of user demands, this should be in alignment with how > people want Bitcoin to behave. > > Currently, the only means users have of influencing miner decisions are A. > rejection of blocks that don't follow rules and B. paying fees for > transaction inclusion. I suggest we combine these in such a way that > transactions themselves can signal for upgrade. I believe (though am not > certain) that there are "free" bits in the version field of a transaction > that are presently ignored. If we could devise a mapping between some of > those free bits, and the signaling bits in the block header, it would be > possible to have rules as follows: > > - A transaction signaling in the affirmative MUST NOT be included in a > block that does not signal in the affirmative > - A transaction that is NOT signaling MAY be included in a block > regardless of that block's signaling vector > - (Optional) A transaction signaling in the negative MUST NOT be included > in a block that signals in the affirmative > > Under this set of conditions, a user has the means of sybil-resistant > influence over miner decisions. If a miner cannot collect the fees for a > transaction without signaling, the user's fee becomes active economic > pressure for the miner to signal (or not, if we include some variant of the > negative clause). In this environment, miners could have a better view into > what users do want, as would the Bitcoin network at large. > > Some may take issue with the idea that people can pay for the outcome they > want and may try to compare a method like this to Proof of Stake, but there > are only 3 sybil resistant mechanisms I am aware of, and any "real" view > into what social consensus looks like MUST be sybil resistant: > > - Hashpower > - Proof of personhood (KYC) > - Capital burn/risk > > Letting hashpower decide this is the thing that is currently contentious, > KYC is dead on arrival both on technical and social grounds, which really > just leaves some means of getting capital into the process of consensus > measurement. This mechanism I'm proposing is measurable completely > en-protocol and doesn't require trust in institutions that fork futures > would. Additionally it could be an auxiliary feature of the soft fork > deployment scheme chosen making it something you could neatly package all > together with the deployment itself. > > There are many potential tweaks to the design I propose above: > 1. Do we include a notion of negative signaling (allowing for the > possibility of rejection) > 2. Do we make it such that miner signaling must be congruent with >X% of > transactions, where congruence is that the signal must match any > non-neutral signal of transaction. > > Some anticipated objections: > > 1. signaling isn't voting, no deployment should be made without consensus > first. > - yeah well we can't currently measure consensus right now, so that's not > a super helpful thing to say and is breeding ground for abuse in the form > of certain people making the unsubstantiated claim that consensus does or > does not exist for a particular initiative > > 2. This is just a proposal for "pay to play", we should not let the > wealthy make consensus decisions. > - I agree that wealth should not be able to strong-arm decision making. > But the status quo seems even worse where we let publicly influential > people decide consensus in such a way where not only do they not "lose > ammunition" in the process of campaigning, but actually accrue it, creating > really bad long-term balances of power. > > 3. Enforcing this proposal requires its own soft fork. > - Yes. It does...and there's a certain cosmic irony to that, but before we > consider how to make this happen, I'd like to even discuss whether or not > it's a good idea. > > 4. This gives CoinJoin pool operators and L2 protocol implementations > power over deciding consensus. > - I see this as an improvement over the status quo > > 5. This encourages "spam" > - If you pay the fees, it's not spam. > > The biggest question I'd like to pose to the forum is: > - Does a scheme like this afford us a better view into consensus than we > have today? > - Can it be gamed to give us a *worse* view into consensus? How? > - Does it measure the right thing? If not, what do you think is the right > thing to measure? (assuming we could) > - Should I write a BIP spec'ing this out in detail? > > Cheers, > Keagan > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- - Bryan https://twitter.com/kanzure -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220426/64c2013e/attachment.html>