Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
Hi ZmnSCPxj. > There is a position that fullnodes must be able to get a view of the UTXO set, and extension blocks (which are invisible to pre-extension-block fullnodes) means that fullnodes no longer have an accurate view of the UTXO set. > SegWit still provides pre-SegWit fullnodes with a view of the UTXO set, although pre-SegWit fullnodes could be convinced that a particular UTXO is anyone-can-spend even though they are no longer anyone-can-spend. > Under this point-of-view, then, extension block is "not" soft fork. There's a way to do CT without an extension block and while still maintaining a correct UTXO set for old nodes. Perhaps it is similar what you meant with this comment (I believe you don't need to do a hardfork though) > Then it becomes impossible to move from confidential to public transactions with a value more than this counter, thus preventing inflation even if a future QC breach allows confidential transaction value commitments to be opened to any value. > (do note that a non-extension-block approach is a definite hardfork) Anyway, the method goes like this: Funds that go in to CT-mode are placed in a consensus/miner controlled reserve pool. To go out from CT back to normal, funds are then transferred back to the user from this pool. CT transactions seen from a non-upgraded node will be a transaction with 0 sat outputs. The actual rangeproof commitment could be placed in the script output or perhaps somewhere else. To enter CT-mode, you'll need to make a commitment. The transaction contains two outputs, one to the reserve pool containing the funds that can only be reclaimed when you go back to normal and one CT-output that you can start doing CT transactions from. I believe this could be made seamlessly with just a new bech32 address specifically for CT. Sending to a CT address could be done as easily as sending to a P2SH. In other words, it doesn't have to be two steps to send to someone over at CT space. > It is "evil" soft fork since older nodes are forced to upgrade as their intended functionality becomes impossible. > In this point-of-view, it is no better than a hard fork, which at least is very noisy about how older fullnode versions will simply stop working. Regarding normal extension blocks, I think it is definitely better than a hardfork since there's no way to be derailed from the network, even though you do not understand the rules fully. Sidenote, I think Trey Del Bonis is right regarding the terminology here, evil softforks/soft hardforks usually mean that you abandon the old chain to force all nodes to upgrade (https://petertodd.org/2016/forced-soft-forks ). Best Hampus Den tis 12 feb. 2019 kl 13:49 skrev ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > Good morning Kenshiro, > > > - Soft fork: old nodes see CT transactions as "sendtoany" transactions > > There is a position that fullnodes must be able to get a view of the UTXO > set, and extension blocks (which are invisible to pre-extension-block > fullnodes) means that fullnodes no longer have an accurate view of the UTXO > set. > SegWit still provides pre-SegWit fullnodes with a view of the UTXO set, > although pre-SegWit fullnodes could be convinced that a particular UTXO is > anyone-can-spend even though they are no longer anyone-can-spend. > > Under this point-of-view, then, extension block is "not" soft fork. > It is "evil" soft fork since older nodes are forced to upgrade as their > intended functionality becomes impossible. > In this point-of-view, it is no better than a hard fork, which at least is > very noisy about how older fullnode versions will simply stop working. > > > - Safe: if there is a software bug in CT it's impossible to create new > coins because the coins move from normal block to normal block as public > transactions > > I think more relevant here is the issue of a future quantum computing > breach of the algorithms used to implement confidentiality. > > I believe this is also achievable with a non-extension-block approach by > implementing a globally-verified publicly-visible counter of the total > amount in all confidential transaction outputs. > Then it becomes impossible to move from confidential to public > transactions with a value more than this counter, thus preventing inflation > even if a future QC breach allows confidential transaction value > commitments to be opened to any value. > > (do note that a non-extension-block approach is a definite hardfork) > > > - Capacity increase: the CT signature is stored in the extension block, > so CT transactions increase the maximum number of transactions per block > > This is not an unalloyed positive: block size increase, even via extension > block, translates to greater network capacity usage globally on all > fullnodes. > > Regards, > ZmnSCPxj > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org >
Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
Greetings, I think extension blocks could be optional, and it could be many different extension blocks with different functionalities like Confidential Transactions or smart contracts. Only the interested nodes would enable this extension blocks, the rest would see only the classic blockchain without extension blocks. So it's not a matter of "old" and "new" nodes, all are updated nodes with extension blocks enabled or not. The only ones that need to understand the protocols of all existing extension blocks are the miners, which must verify that transactions from "anyone-can-spend" to a "classic" address are legal. So this is what a node with all extension blocks disabled would see in the blockchain: * Classic address to classic address: as always * Classic address to extension block address: transaction to "anyone-can-spend" * Extension block address to classic address: transaction from "anyone-can-spend" * Extension block address to extension block address: it doesn't see it because it doesn't download the extension blocks, only the main blocks. All coins that are in extension blocks are also in the "anyone-can-spend" address of the main blocks, so basic nodes are aware of the total number of coins. It's totally safe. So for the particular case of Confidential Transactions, it would work as explained. The CT transaction details would be in the extension block which could have the same size as the main block so the total size of the blockchain (main blocks + extension blocks) would be double. With this method bitcoin could add new features without losing the "store of value" property, as the base protocol never changes. Again, maybe I'm missing some technical detail here, I'm still learning Regards ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
>Under this point-of-view, then, extension block is "not" soft fork. >It is "evil" soft fork since older nodes are forced to upgrade as their >intended functionality becomes impossible. >In this point-of-view, it is no better than a hard fork, which at least is >very noisy about how older fullnode versions will simply stop working Offtopic: I believe that this kind of "evil soft fork" where nodes who don't upgrade can continue to read the blockchain, update their utxoset, etc. but can't actually spend some or all of the coins they have has been referred to as a "firm fork". I think this is a pretty useful term to pass around when talking about potential future forks. The earliest reference I can find to that term from a quick search is this talk from 2016 by Adam Back: http://diyhpl.us/wiki/transcripts/adam3us-bitcoin-scaling-tradeoffs/ -Trey Del Bonis On Tue, Feb 12, 2019 at 7:48 AM ZmnSCPxj via bitcoin-dev wrote: > > Good morning Kenshiro, > > > - Soft fork: old nodes see CT transactions as "sendtoany" transactions > > There is a position that fullnodes must be able to get a view of the UTXO > set, and extension blocks (which are invisible to pre-extension-block > fullnodes) means that fullnodes no longer have an accurate view of the UTXO > set. > SegWit still provides pre-SegWit fullnodes with a view of the UTXO set, > although pre-SegWit fullnodes could be convinced that a particular UTXO is > anyone-can-spend even though they are no longer anyone-can-spend. > > Under this point-of-view, then, extension block is "not" soft fork. > It is "evil" soft fork since older nodes are forced to upgrade as their > intended functionality becomes impossible. > In this point-of-view, it is no better than a hard fork, which at least is > very noisy about how older fullnode versions will simply stop working. > > > - Safe: if there is a software bug in CT it's impossible to create new > > coins because the coins move from normal block to normal block as public > > transactions > > I think more relevant here is the issue of a future quantum computing breach > of the algorithms used to implement confidentiality. > > I believe this is also achievable with a non-extension-block approach by > implementing a globally-verified publicly-visible counter of the total amount > in all confidential transaction outputs. > Then it becomes impossible to move from confidential to public transactions > with a value more than this counter, thus preventing inflation even if a > future QC breach allows confidential transaction value commitments to be > opened to any value. > > (do note that a non-extension-block approach is a definite hardfork) > > > - Capacity increase: the CT signature is stored in the extension block, so > > CT transactions increase the maximum number of transactions per block > > This is not an unalloyed positive: block size increase, even via extension > block, translates to greater network capacity usage globally on all fullnodes. > > Regards, > ZmnSCPxj > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
Good morning ZmnSCPxj, Thank you for your answer. There is a position that fullnodes must be able to get a view of the UTXO set, and extension blocks (which are invisible to pre-extension-block fullnodes) means that fullnodes no longer have an accurate view of the UTXO set. I think old nodes don't need to know the CT part of the UTXO set. It would be possible to move coins from normal address to CT address and the opposite, it would be written as "anyone-can-spend" transactions in the main block so old nodes are fully aware of these transactions. Miners would enforce that "anyone-can-spend" transactions are true. The full details of the transactions involving CT would be in the extension block. CT to CT transactions don't need to be written in the main block. Maybe I'm missing some technical detail here but it looks good for me. > - Capacity increase: the CT signature is stored in the extension block, so CT > transactions increase the maximum number of transactions per block This is not an unalloyed positive: block size increase, even via extension block, translates to greater network capacity usage globally on all fullnodes. Yes, there is an increase in block size and network usage but I think it would still be possible for people with regular computers to run a full node, an people in developing countries could use light wallets. Regards From: ZmnSCPxj Sent: Monday, February 11, 2019 5:29 To: Kenshiro \[\]; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks Good morning Kenshiro, > - Soft fork: old nodes see CT transactions as "sendtoany" transactions There is a position that fullnodes must be able to get a view of the UTXO set, and extension blocks (which are invisible to pre-extension-block fullnodes) means that fullnodes no longer have an accurate view of the UTXO set. SegWit still provides pre-SegWit fullnodes with a view of the UTXO set, although pre-SegWit fullnodes could be convinced that a particular UTXO is anyone-can-spend even though they are no longer anyone-can-spend. Under this point-of-view, then, extension block is "not" soft fork. It is "evil" soft fork since older nodes are forced to upgrade as their intended functionality becomes impossible. In this point-of-view, it is no better than a hard fork, which at least is very noisy about how older fullnode versions will simply stop working. > - Safe: if there is a software bug in CT it's impossible to create new coins > because the coins move from normal block to normal block as public > transactions I think more relevant here is the issue of a future quantum computing breach of the algorithms used to implement confidentiality. I believe this is also achievable with a non-extension-block approach by implementing a globally-verified publicly-visible counter of the total amount in all confidential transaction outputs. Then it becomes impossible to move from confidential to public transactions with a value more than this counter, thus preventing inflation even if a future QC breach allows confidential transaction value commitments to be opened to any value. (do note that a non-extension-block approach is a definite hardfork) > - Capacity increase: the CT signature is stored in the extension block, so CT > transactions increase the maximum number of transactions per block This is not an unalloyed positive: block size increase, even via extension block, translates to greater network capacity usage globally on all fullnodes. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
Good morning Kenshiro, > - Soft fork: old nodes see CT transactions as "sendtoany" transactions There is a position that fullnodes must be able to get a view of the UTXO set, and extension blocks (which are invisible to pre-extension-block fullnodes) means that fullnodes no longer have an accurate view of the UTXO set. SegWit still provides pre-SegWit fullnodes with a view of the UTXO set, although pre-SegWit fullnodes could be convinced that a particular UTXO is anyone-can-spend even though they are no longer anyone-can-spend. Under this point-of-view, then, extension block is "not" soft fork. It is "evil" soft fork since older nodes are forced to upgrade as their intended functionality becomes impossible. In this point-of-view, it is no better than a hard fork, which at least is very noisy about how older fullnode versions will simply stop working. > - Safe: if there is a software bug in CT it's impossible to create new coins > because the coins move from normal block to normal block as public > transactions I think more relevant here is the issue of a future quantum computing breach of the algorithms used to implement confidentiality. I believe this is also achievable with a non-extension-block approach by implementing a globally-verified publicly-visible counter of the total amount in all confidential transaction outputs. Then it becomes impossible to move from confidential to public transactions with a value more than this counter, thus preventing inflation even if a future QC breach allows confidential transaction value commitments to be opened to any value. (do note that a non-extension-block approach is a definite hardfork) > - Capacity increase: the CT signature is stored in the extension block, so CT > transactions increase the maximum number of transactions per block This is not an unalloyed positive: block size increase, even via extension block, translates to greater network capacity usage globally on all fullnodes. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Implementing Confidential Transactions in extension blocks
Greetings, What do you think about implementing Confidential Transactions in extension blocks? CT transactions go from extension block to extension block passing through normal blocks. It looks the perfect solution: - Soft fork: old nodes see CT transactions as "sendtoany" transactions - Safe: if there is a software bug in CT it's impossible to create new coins because the coins move from normal block to normal block as public transactions - Legal: Exchanges can use public transactions so regulators can monitor their activity - Capacity increase: the CT signature is stored in the extension block, so CT transactions increase the maximum number of transactions per block Regards ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
