<div dir="ltr"><div dir="ltr"><div>Hi ZmnSCPxj.<br></div><div><br></div><div>>
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.<br>
> 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.
</div><div>
> Under this point-of-view, then, extension block is "not" soft fork. <br></div><div><br></div><div>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)</div><div><br></div><div>>
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.<br>
> (do note that a non-extension-block approach is a definite hardfork)<span class="gmail-im"><br></span>
</div><div><br></div><div>Anyway, the method goes like this:<br></div><div><br></div><div>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.<br></div><div>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.<br></div><div><br></div><div>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.</div><div>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.<br></div><div><br></div><div>>
It is "evil" soft fork since older nodes are forced to upgrade as their intended functionality becomes impossible.<br>> 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.<span class="gmail-im"><br></span>
</div><div><br></div><div>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.</div><div><br></div><div>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 (<a href="https://petertodd.org/2016/forced-soft-forks">https://petertodd.org/2016/forced-soft-forks</a>).<br></div><div><br></div><div>Best</div><div>Hampus<br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tis 12 feb. 2019 kl 13:49 skrev ZmnSCPxj via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Kenshiro,<br>
<br>
> - Soft fork: old nodes see CT transactions as "sendtoany" transactions<br>
<br>
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.<br>
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.<br>
<br>
Under this point-of-view, then, extension block is "not" soft fork.<br>
It is "evil" soft fork since older nodes are forced to upgrade as their intended functionality becomes impossible.<br>
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.<br>
<br>
> - 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<br>
<br>
I think more relevant here is the issue of a future quantum computing breach of the algorithms used to implement confidentiality.<br>
<br>
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.<br>
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.<br>
<br>
(do note that a non-extension-block approach is a definite hardfork)<br>
<br>
> - Capacity increase: the CT signature is stored in the extension block, so CT transactions increase the maximum number of transactions per block<br>
<br>
This is not an unalloyed positive: block size increase, even via extension block, translates to greater network capacity usage globally on all fullnodes.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>