path: root/4d/bfaef89de0cfee0f536d88267870d31920e450

Return-Path: <hampus.sjoberg@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F0DDBB4A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 14 Feb 2019 22:32:28 +0000 (UTC)
Received: by mail-wm1-f54.google.com with SMTP id b11so8055782wmj.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <DB6PR10MB183228F27750132F9A6A3542A6690@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
	<U-ugv1xWdp4czsN38WhD6KQUPcYa4VLxNzUusM3YLRu4825eigldn3xTOw6IyoqpyFbymdKxWUGOQdlknr3L7rBOtssEKeYMkW4RKj5Rc1o=@protonmail.com>
In-Reply-To: <U-ugv1xWdp4czsN38WhD6KQUPcYa4VLxNzUusM3YLRu4825eigldn3xTOw6IyoqpyFbymdKxWUGOQdlknr3L7rBOtssEKeYMkW4RKj5Rc1o=@protonmail.com>
From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Date: Thu, 14 Feb 2019 23:32:17 +0100
Message-ID: <CAFMkqK9tt3P+svrPNU7vG5oc06jscOQSzomjELUscegNQhwP4g@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi ZmnSCPxj.<br></div><div><br></div=
><div>&gt;=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.<br>
&gt; 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.

</div><div>
&gt; Under this point-of-view, then, extension block is &quot;not&quot; sof=
t fork. <br></div><div><br></div><div>There&#39;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&#39;t need to do a hardfork though)</div><div><br></div><div>&gt;=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.<br>
&gt; (do note that a non-extension-block approach is a definite hardfork)<s=
pan class=3D"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 perha=
ps somewhere else.<br></div><div><br></div><div>To enter CT-mode, you&#39;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.</div><div>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&#39;t have to be two s=
teps to send to someone over at CT space.<br></div><div><br></div><div>&gt;=
=20
It is &quot;evil&quot; soft fork since older nodes are forced to upgrade as=
 their intended functionality becomes impossible.<br>&gt; 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.<span class=3D"gmail-im"><br></span>

</div><div><br></div><div>Regarding normal extension blocks, I think it is =
definitely better than a hardfork since there&#39;s no way to be derailed f=
rom the network, even though you do not understand the rules fully.</div><d=
iv><br></div><div>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 (<a href=3D"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=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">Den tis 12 feb. 2019 kl 13:49 skrev ZmnSCPxj via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt;:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">Good morning Kenshiro,<br>
<br>
&gt; - Soft fork: old nodes see CT transactions as &quot;sendtoany&quot; tr=
ansactions<br>
<br>
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.<br>
<br>
Under this point-of-view, then, extension block is &quot;not&quot; soft for=
k.<br>
It is &quot;evil&quot; 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>
&gt; - Safe: if there is a software bug in CT it&#39;s impossible to create=
 new coins because the coins move from normal block to normal block as publ=
ic transactions<br>
<br>
I think more relevant here is the issue of a future quantum computing breac=
h of the algorithms used to implement confidentiality.<br>
<br>
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.<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 f=
uture QC breach allows confidential transaction value commitments to be ope=
ned to any value.<br>
<br>
(do note that a non-extension-block approach is a definite hardfork)<br>
<br>
&gt; - 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 fullnod=
es.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000ab19ff0581e23beb--