<p dir="ltr">So I have been told more than once that the version announcement in blocks is not a vote, but a signal for readiness, used in isSupermajority(). Basically, if soft forks (and hard forks) won't activate unless a certain % of blocks have been flagged with the version up (or bit flipped when versionbits go live) to signal their readiness, that is a vote against implementation if they never follow up. I don't like this politically correct speech because in reality it is a vote... But I'm not here to argue about that... I would like to see if there are any thoughts on extending/copying isSupermajority() for a new secondary/non-critical function to also look for a similar BIP 9 style version bit in txns. Apologies if already proposed, haven't heard of it anywhere.</p>
<p dir="ltr">If we are looking for a signal of readiness, it is unfair to wallet developers and exchanges that they are unable to signal if they too are ready for a change. As more users are going into use SPV or SPV-like wallets, when a change occurs that makes them incompatible/in need of upgrade we need to make sure they aren't going to break or introduce security flaws for users.</p>
<p dir="ltr">If a majority of transactions have been sent are flagged ready, we know that they're also good to go.</p>
<p dir="ltr">Would you implement the same versionbits for txn's version field, using 3 bits for versioning and 29 bits for flags? This indexing of every txn might sound insane and computationally expensive for bitcoin Core to run, but if it isn't critical to upgrade with soft forks, then it can be watched outside the network by enthusiasts. I believe this is the most politically correct way to get wallet devs and exchanges involved. (If it were me I would absolutely try figure out a way to stick it in isSupermajority...)</p>
<p dir="ltr">Miners can watch for readiness flagged by wallets before they themselves flag ready. We will have to trust miners to not jump the gun, but that's the trade off.</p>
<p dir="ltr">Thoughts?</p>