Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F0DDBB4A for ; Thu, 14 Feb 2019 22:32:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CC862FE for ; Thu, 14 Feb 2019 22:32:28 +0000 (UTC) Received: by mail-wm1-f54.google.com with SMTP id b11so8055782wmj.1 for ; Thu, 14 Feb 2019 14:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=lmF+gDOLTeNtTg5VCC/cOrl2TxGOwVY3t0n0dQNVgVM=; b=eD+vckBdmP3zrTIX/zzMFMHbZSWFagj42JKHRMoJpJUpKvKbdf+6ShSw3ld722jAH0 VCzpK8sgIdMsCCI/+uucCB6iNzMD8cp4UlYfoU5qZvUg1dkvlTTfIhyh4qVJivVfO52Q qcB+txvpPv/lvsBKU25qv7bMKitI8f51c0S+b1p2sLZd/AxnBeX6eFzD+qUHb7LSdRox tsEQhO3k3XpKG453b6n9nlpvMSV0Cjbo7w73+ij/UjH9SOZvXrQa89FokFLDA8MkSv23 SwBev3eRqO4sWHLfL7w0mkqIK1P4XXG+UQec2XMKqSRjKbidk2dPXf1WT8xX1GMEP7qR OGiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=lmF+gDOLTeNtTg5VCC/cOrl2TxGOwVY3t0n0dQNVgVM=; b=dc8gW9l1T/HbFZTRsT97J1D1kJz0uIx2v3LVynyHt/IltlcffuB6Go83j9fdPaELvV nNheFN/ruz0ddX+uVD9SVB7bNzh6Sj4+jSry+IoC/suwAmI8x+nzOEi9C8xPXr1c51Bk 8sj35CqY9O0rKajg6iC/UYxnhb34XftlrTFtt6C9Liqw2fO2pJIlHqloL8mST7p6tDUZ N+nO/DOAiNavbFWV9LHQYqHfmxmOcCM6wQMzUSu3RkGbUWI4/IaHRUCQK3sfRNpb93OJ tIP0A72tbx4GgtCmVkvfIfUg3usrgM8+W+EdPdw5osVVMYJ97HaQZ8cFUPudb5ko//v3 HZEw== X-Gm-Message-State: AHQUAubDA41BM77FpBj2esVYCpk6U7vDqvikXWOUVvrWquhURPfHG4MA 0QJ6WiDMJ9AHpSSJKiTMX5gv2GmffROlJ7axJ80= X-Google-Smtp-Source: AHgI3IaX6MKohLf1vSP84i6/zEayvS8Xe8rRVlbrUCqIwpwcfoKhekHJWdukv1EhgO8na+lM+DSGts6tS1h55AG4gM8= X-Received: by 2002:a7b:c76a:: with SMTP id x10mr4442251wmk.101.1550183547212; Thu, 14 Feb 2019 14:32:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= Date: Thu, 14 Feb 2019 23:32:17 +0100 Message-ID: To: ZmnSCPxj , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000ab19ff0581e23beb" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 16 Feb 2019 15:44:11 +0000 Subject: Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 22:32:30 -0000 --000000000000ab19ff0581e23beb Content-Type: text/plain; charset="UTF-8" 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 > --000000000000ab19ff0581e23beb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi ZmnSCPxj.

>=20 There is a position that fullnodes must be able to get a view of the=20 UTXO set, and extension blocks (which are invisible to=20 pre-extension-block fullnodes) means that fullnodes no longer have an=20 accurate view of the UTXO set.
> SegWit still provides pre-SegWit fullnodes with a view of the UTXO set= ,=20 although pre-SegWit fullnodes could be convinced that a particular UTXO=20 is anyone-can-spend even though they are no longer anyone-can-spend.
> Under this point-of-view, then, extension block is "not" sof= t fork.

There's a way to do CT without an= extension block and while still maintaining a correct UTXO set for old nod= es. Perhaps it is similar what you meant with this comment (I believe you d= on't need to do a hardfork though)

>=C2=A0 Then it becomes impossible to move from confidential to public=20 transactions with a value more than this counter, thus preventing=20 inflation even if a future QC breach allows confidential transaction=20 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 perha= ps somewhere else.

To enter CT-mode, you'l= l need to make a commitment. The transaction contains two outputs, one to t= he 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 bec= h32 address specifically for CT. Sending to a CT address could be done as e= asily as sending to a P2SH. In other words, it doesn't have to be two s= teps to send to someone over at CT space.

>= =20 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=20 is very noisy about how older fullnode versions will simply stop=20 working.

Regarding normal extension blocks, I think it is = definitely better than a hardfork since there's no way to be derailed f= rom the network, even though you do not understand the rules fully.

Sidenote, I think Trey Del Bonis is right regarding the t= erminology here, evil softforks/soft hardforks usually mean that you abando= n the old chain to force all nodes to upgrade (https://petertodd.org/2016/forced-soft-forks).


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" tr= ansactions

There is a position that fullnodes must be able to get a view of the UTXO s= et, and extension blocks (which are invisible to pre-extension-block fullno= des) 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, alt= hough pre-SegWit fullnodes could be convinced that a particular UTXO is any= one-can-spend even though they are no longer anyone-can-spend.

Under this point-of-view, then, extension block is "not" soft for= k.
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 publ= ic transactions

I think more relevant here is the issue of a future quantum computing breac= h of the algorithms used to implement confidentiality.

I believe this is also achievable with a non-extension-block approach by im= plementing 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 f= uture QC breach allows confidential transaction value commitments to be ope= ned 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<= br>
This is not an unalloyed positive: block size increase, even via extension = block, translates to greater network capacity usage globally on all fullnod= es.

Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000ab19ff0581e23beb--