Chris Priest [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-08 📝 Original message:I proposed in my Wildcard ...
📅 Original date posted:2015-12-08
📝 Original message:I proposed in my Wildcard Inputs BIP that the version field be split
in two. The first 4 bytes are version number (which in practice is
being used for script version), and the second 4 bits are used for
transaction type.
I don't think the BIP9 mechanism really applies to transactions. A
block is essentially a collection of transactions, therefore voting on
the block applies to the many parties who have transactions in the
block. A transaction on the other hand only effects at most two
parties (the sender and the receiver). In other words, block are
"communal" data structures, transactions are individual data
structures. Also, the nature of soft forks are that wallets can choose
to implement a new feature or not. For instance, if no wallets
implement RBF or SW, then those features effectively don't exist,
regardless of how many nodes have upgraded to handle the feature.
Any new transaction feature should get a new "type" number. A new
transaction feature can't happen until the nodes support it.
On 12/8/15, Vincent Truong via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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?
>
Published at
2023-06-07 17:45:52Event JSON
{
"id": "4b1810fddf6c55890bba6b553024ca4c5c0647bd164ed69c554233f8108f95bc",
"pubkey": "3b5311200328974edeaa105b1a8f60d243e653cc63b6bb29f61dc696e04189ed",
"created_at": 1686159952,
"kind": 1,
"tags": [
[
"e",
"e32f5f580eeeddd8bf1d6ec8b98fe5688507459c25783299ca92810b6802e5e4",
"",
"root"
],
[
"e",
"b71760aff8bf63d469a57a202247a3f9583e201942f9b0f709b9300d5e79cc3b",
"",
"reply"
],
[
"p",
"43d409a3ebd823071d562a2252a9126d5cba7aee3ffea64cf3e28e252af0a8e8"
]
],
"content": "📅 Original date posted:2015-12-08\n📝 Original message:I proposed in my Wildcard Inputs BIP that the version field be split\nin two. The first 4 bytes are version number (which in practice is\nbeing used for script version), and the second 4 bits are used for\ntransaction type.\n\nI don't think the BIP9 mechanism really applies to transactions. A\nblock is essentially a collection of transactions, therefore voting on\nthe block applies to the many parties who have transactions in the\nblock. A transaction on the other hand only effects at most two\nparties (the sender and the receiver). In other words, block are\n\"communal\" data structures, transactions are individual data\nstructures. Also, the nature of soft forks are that wallets can choose\nto implement a new feature or not. For instance, if no wallets\nimplement RBF or SW, then those features effectively don't exist,\nregardless of how many nodes have upgraded to handle the feature.\n\nAny new transaction feature should get a new \"type\" number. A new\ntransaction feature can't happen until the nodes support it.\n\nOn 12/8/15, Vincent Truong via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e So I have been told more than once that the version announcement in blocks\n\u003e is not a vote, but a signal for readiness, used in isSupermajority().\n\u003e Basically, if soft forks (and hard forks) won't activate unless a certain %\n\u003e of blocks have been flagged with the version up (or bit flipped when\n\u003e versionbits go live) to signal their readiness, that is a vote against\n\u003e implementation if they never follow up. I don't like this politically\n\u003e correct speech because in reality it is a vote... But I'm not here to argue\n\u003e about that... I would like to see if there are any thoughts on\n\u003e extending/copying isSupermajority() for a new secondary/non-critical\n\u003e function to also look for a similar BIP 9 style version bit in txns.\n\u003e Apologies if already proposed, haven't heard of it anywhere.\n\u003e\n\u003e If we are looking for a signal of readiness, it is unfair to wallet\n\u003e developers and exchanges that they are unable to signal if they too are\n\u003e ready for a change. As more users are going into use SPV or SPV-like\n\u003e wallets, when a change occurs that makes them incompatible/in need of\n\u003e upgrade we need to make sure they aren't going to break or introduce\n\u003e security flaws for users.\n\u003e\n\u003e If a majority of transactions have been sent are flagged ready, we know\n\u003e that they're also good to go.\n\u003e\n\u003e Would you implement the same versionbits for txn's version field, using 3\n\u003e bits for versioning and 29 bits for flags? This indexing of every txn might\n\u003e sound insane and computationally expensive for bitcoin Core to run, but if\n\u003e it isn't critical to upgrade with soft forks, then it can be watched\n\u003e outside the network by enthusiasts. I believe this is the most politically\n\u003e correct way to get wallet devs and exchanges involved. (If it were me I\n\u003e would absolutely try figure out a way to stick it in isSupermajority...)\n\u003e\n\u003e Miners can watch for readiness flagged by wallets before they themselves\n\u003e flag ready. We will have to trust miners to not jump the gun, but that's\n\u003e the trade off.\n\u003e\n\u003e Thoughts?\n\u003e",
"sig": "1cabe4bc3a700a133c8de6f45ae924e2bbd0261089c8fdbdd9d9d5f44b1e0236c8ce83aa1f6a4f7aad921a79af2fb57713b57ea51d1b77a334c99d9c7107573d"
}