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