* [bitcoin-dev] Implementing Confidential Transactions in extension blocks
@ 2019-02-08 10:12 Kenshiro []
2019-02-11 4:29 ` ZmnSCPxj
0 siblings, 1 reply; 6+ messages in thread
From: Kenshiro [] @ 2019-02-08 10:12 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1213 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
2019-02-08 10:12 [bitcoin-dev] Implementing Confidential Transactions in extension blocks Kenshiro []
@ 2019-02-11 4:29 ` ZmnSCPxj
2019-02-11 10:19 ` Kenshiro []
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: ZmnSCPxj @ 2019-02-11 4:29 UTC (permalink / raw)
To: Kenshiro \[\], Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
2019-02-11 4:29 ` ZmnSCPxj
@ 2019-02-11 10:19 ` Kenshiro []
2019-02-12 17:27 ` Trey Del Bonis
2019-02-14 22:32 ` Hampus Sjöberg
2 siblings, 0 replies; 6+ messages in thread
From: Kenshiro [] @ 2019-02-11 10:19 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, ZmnSCPxj
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
2019-02-11 4:29 ` ZmnSCPxj
2019-02-11 10:19 ` Kenshiro []
@ 2019-02-12 17:27 ` Trey Del Bonis
2019-02-14 22:32 ` Hampus Sjöberg
2 siblings, 0 replies; 6+ messages in thread
From: Trey Del Bonis @ 2019-02-12 17:27 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion
>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
<bitcoin-dev@lists•linuxfoundation.org> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
2019-02-11 4:29 ` ZmnSCPxj
2019-02-11 10:19 ` Kenshiro []
2019-02-12 17:27 ` Trey Del Bonis
@ 2019-02-14 22:32 ` Hampus Sjöberg
2 siblings, 0 replies; 6+ messages in thread
From: Hampus Sjöberg @ 2019-02-14 22:32 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5015 bytes --]
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
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 6201 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
@ 2019-02-14 21:14 Kenshiro []
0 siblings, 0 replies; 6+ messages in thread
From: Kenshiro [] @ 2019-02-14 21:14 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 4635 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-02-14 22:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-08 10:12 [bitcoin-dev] Implementing Confidential Transactions in extension blocks Kenshiro []
2019-02-11 4:29 ` ZmnSCPxj
2019-02-11 10:19 ` Kenshiro []
2019-02-12 17:27 ` Trey Del Bonis
2019-02-14 22:32 ` Hampus Sjöberg
2019-02-14 21:14 Kenshiro []
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox