From: "Kenshiro []" <tensiam@hotmail•com>
To: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
ZmnSCPxj <ZmnSCPxj@protonmail•com>
Subject: Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
Date: Mon, 11 Feb 2019 10:19:15 +0000 [thread overview]
Message-ID: <DB6PR10MB1832F0E339FD9B76E87BC64FA6640@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <U-ugv1xWdp4czsN38WhD6KQUPcYa4VLxNzUusM3YLRu4825eigldn3xTOw6IyoqpyFbymdKxWUGOQdlknr3L7rBOtssEKeYMkW4RKj5Rc1o=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3651 bytes --]
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 <ZmnSCPxj@protonmail•com>
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
[-- Attachment #2: Type: text/html, Size: 6249 bytes --]
next prev parent reply other threads:[~2019-02-11 10:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-08 10:12 Kenshiro []
2019-02-11 4:29 ` ZmnSCPxj
2019-02-11 10:19 ` Kenshiro [] [this message]
2019-02-12 17:27 ` Trey Del Bonis
2019-02-14 22:32 ` Hampus Sjöberg
2019-02-14 21:14 Kenshiro []
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DB6PR10MB1832F0E339FD9B76E87BC64FA6640@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM \
--to=tensiam@hotmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox