* [bitcoin-dev] BIP 9 style version bits for txns @ 2015-12-08 12:27 Vincent Truong 2015-12-08 19:40 ` Chris Priest 0 siblings, 1 reply; 4+ messages in thread From: Vincent Truong @ 2015-12-08 12:27 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1935 bytes --] 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? [-- Attachment #2: Type: text/html, Size: 2074 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] BIP 9 style version bits for txns 2015-12-08 12:27 [bitcoin-dev] BIP 9 style version bits for txns Vincent Truong @ 2015-12-08 19:40 ` Chris Priest 2015-12-08 21:02 ` Vincent Truong 0 siblings, 1 reply; 4+ messages in thread From: Chris Priest @ 2015-12-08 19:40 UTC (permalink / raw) To: Vincent Truong; +Cc: bitcoin-dev 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@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? > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] BIP 9 style version bits for txns 2015-12-08 19:40 ` Chris Priest @ 2015-12-08 21:02 ` Vincent Truong 2015-12-08 22:27 ` Chris Priest 0 siblings, 1 reply; 4+ messages in thread From: Vincent Truong @ 2015-12-08 21:02 UTC (permalink / raw) To: Chris Priest; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3558 bytes --] I suppose whether the wallet devs want to implement the soft fork or not is irrelevant. They only need to indicate if they are ready i.e. they've tested the new soft fork, hard fork or feature and validated that it doesn't break their nodes or wallet software. On Dec 9, 2015 6:40 AM, "Chris Priest" <cp368202@ohiou•edu> wrote: > 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@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? > > > [-- Attachment #2: Type: text/html, Size: 4210 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] BIP 9 style version bits for txns 2015-12-08 21:02 ` Vincent Truong @ 2015-12-08 22:27 ` Chris Priest 0 siblings, 0 replies; 4+ messages in thread From: Chris Priest @ 2015-12-08 22:27 UTC (permalink / raw) To: Vincent Truong; +Cc: bitcoin-dev A wallet doesn't receive transactions from other wallets. That is what a node does. Wallets just make transactions and then sends them to the nodes. Nodes then send them to other nodes. In the early days of bitcoin, all wallets were nodes, but now a lot of wallets are just wallets with out any specific node. For instance, SPV wallets, they don't get their UTXO data from any one node that can or can not support a feature. They get UTXO data from many nodes, some of which could support said feature, others may not. The nature of the work that nodes perform, they *should* broadcast what features they support. The only nodes that matter to the network are nodes that produce blocks. Nodes that don't produce blocks are kind of just there, serving whoever happens to connect... I guess nodes could broadcast their supported implementations of via part of the version message that is part of the p2p handshake process... On 12/8/15, Vincent Truong <vincent.truong@procabiak•com> wrote: > I suppose whether the wallet devs want to implement the soft fork or not is > irrelevant. They only need to indicate if they are ready i.e. they've > tested the new soft fork, hard fork or feature and validated that it > doesn't break their nodes or wallet software. > On Dec 9, 2015 6:40 AM, "Chris Priest" <cp368202@ohiou•edu> wrote: > >> 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@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? >> > >> > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-12-08 22:27 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-12-08 12:27 [bitcoin-dev] BIP 9 style version bits for txns Vincent Truong 2015-12-08 19:40 ` Chris Priest 2015-12-08 21:02 ` Vincent Truong 2015-12-08 22:27 ` Chris Priest
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox