š
Original date posted:2015-12-08
š Original message: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.
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.
If a majority of transactions have been sent are flagged ready, we know
that they're also good to go.
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...)
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.
Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/7274423d/attachment.html>;
Vincent Truong [ARCHIVE] /
npub1g0ā¦v6wva
2023-06-07 17:45:52
in reply to nevent1qā¦3ygr
Author Public Key
npub1g02qngltmq3sw82k9g3992gjd4wt57hw8ll2vn8nu28z22hs4r5qmv6wvaSeen on
wss://relay.nostr.bandPublished at
2023-06-07 17:45:52Event JSON
{
"id": "b71760aff8bf63d469a57a202247a3f9583e201942f9b0f709b9300d5e79cc3b",
"pubkey": "43d409a3ebd823071d562a2252a9126d5cba7aee3ffea64cf3e28e252af0a8e8",
"created_at": 1686159952,
"kind": 1,
"tags": [
[
"e",
"e32f5f580eeeddd8bf1d6ec8b98fe5688507459c25783299ca92810b6802e5e4",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "š
Original date posted:2015-12-08\nš Original message:So I have been told more than once that the version announcement in blocks\nis not a vote, but a signal for readiness, used in isSupermajority().\nBasically, if soft forks (and hard forks) won't activate unless a certain %\nof blocks have been flagged with the version up (or bit flipped when\nversionbits go live) to signal their readiness, that is a vote against\nimplementation if they never follow up. I don't like this politically\ncorrect speech because in reality it is a vote... But I'm not here to argue\nabout that... I would like to see if there are any thoughts on\nextending/copying isSupermajority() for a new secondary/non-critical\nfunction to also look for a similar BIP 9 style version bit in txns.\nApologies if already proposed, haven't heard of it anywhere.\n\nIf we are looking for a signal of readiness, it is unfair to wallet\ndevelopers and exchanges that they are unable to signal if they too are\nready for a change. As more users are going into use SPV or SPV-like\nwallets, when a change occurs that makes them incompatible/in need of\nupgrade we need to make sure they aren't going to break or introduce\nsecurity flaws for users.\n\nIf a majority of transactions have been sent are flagged ready, we know\nthat they're also good to go.\n\nWould you implement the same versionbits for txn's version field, using 3\nbits for versioning and 29 bits for flags? This indexing of every txn might\nsound insane and computationally expensive for bitcoin Core to run, but if\nit isn't critical to upgrade with soft forks, then it can be watched\noutside the network by enthusiasts. I believe this is the most politically\ncorrect way to get wallet devs and exchanges involved. (If it were me I\nwould absolutely try figure out a way to stick it in isSupermajority...)\n\nMiners can watch for readiness flagged by wallets before they themselves\nflag ready. We will have to trust miners to not jump the gun, but that's\nthe trade off.\n\nThoughts?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/7274423d/attachment.html\u003e",
"sig": "a0c968037cc2ece6a3031c9829d4734d07b027669219dfd84fa81c90e3b3ac1e17c9e6a9a79c5aa34917d09714356bd3ed5558f64ebc0881b9c7667ad470d527"
}