path: root/b7/abcdd8cb708498129e29e4122dd505dfa7c3aa

Return-Path: <adam.back@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E43BE955
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 13 Apr 2017 01:43:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com
	[209.85.220.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CECB7175
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 13 Apr 2017 01:43:47 +0000 (UTC)
Received: by mail-qk0-f178.google.com with SMTP id d131so37799266qkc.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 12 Apr 2017 18:43:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=eV10JI7g2ohUxcXCKEDyGwO1FdmbogDKdfQm8azR3kE=;
	b=EHKVs2gQPX6pAzikxDsXg+NnTlrOwOeJmT1w4fWLwruoGFg9e9EnnxqoFX6a0bfy/o
	FdU5cOCWkVORUQ2Xa5OcJ2FUAV9bsSvd8UxXTyNIa9yN6m7o48PWDi2vyJQd0mmHTojz
	/I6KGHmW7xUG1o+LZqnvYTGVqswU01PueLkTphewQAcy15BKD7ZitetJxm0ivapXtUYD
	kyoOiIXRYARMY0Vp6T/TbWPbEh43kdN9FX/zauvPfA5rNelK8h2Xn5u4EJ0C8Wg1fgaP
	VmRRDMM7LN6231sTpGJpPyJX+e1Xht8gwO9D02qmOmOJMvceHdY3HJHsNw5SgOCwSFfB
	Iv0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:reply-to:in-reply-to:references
	:from:date:message-id:subject:to:cc;
	bh=eV10JI7g2ohUxcXCKEDyGwO1FdmbogDKdfQm8azR3kE=;
	b=HJTZBdi12atkv3+VJSGzo13Ha5cTpuwi6feeEJxT4GgNg2wmHsXsakURUvQHXhnyU8
	Qt7/9br4zzRqt5H23g4cG9SBiuj3WztKsX75zrKeH4NsMCgvZRlCQJOUZyPXvl5bQmsO
	r5OPrzWsS67F2w8CvglAp/jaXnRZhwiyHJL/FaJmC84WIrBWi8/Sn6gYNbrfnEndstTX
	xRhzsTtCw+rPinjCzQeA7dc1X1txzuktx3t2JdOROzX7Mi2I/0BK5CKVMTzDvPwKTCMF
	UPuQ08pIUKlYQi01n3xiC87wZEy2J6A1Xq06IB0fPg3Ysfd0SmX+WOIJxbvIiFh2Z8Vs
	d+PA==
X-Gm-Message-State: AN3rC/4ChFuh03SJIlCNBlrj1logMvy8Y/EXVxrW8XZR8zdT7LjF3zN3
	GUCMyaBFE+8c8xU81VR65IcrqCnw6A==
X-Received: by 10.55.73.6 with SMTP id w6mr483663qka.153.1492047826988; Wed,
	12 Apr 2017 18:43:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.141.13 with HTTP; Wed, 12 Apr 2017 18:43:46 -0700 (PDT)
Received: by 10.12.141.13 with HTTP; Wed, 12 Apr 2017 18:43:46 -0700 (PDT)
Reply-To: adam@cypherspace.org
In-Reply-To: <6DF303E6-E379-45FD-947B-BB5F938177E5@gmail.com>
References: <6DF303E6-E379-45FD-947B-BB5F938177E5@gmail.com>
From: Adam Back <adam.back@gmail.com>
Date: Wed, 12 Apr 2017 18:43:46 -0700
Message-ID: <CALqxMTGPfwxy56PJew0qHbdsy82UAgzwduciOVK18GfBDoSKQQ@mail.gmail.com>
To: Oleg Andreev <oleganza@gmail.com>
Content-Type: multipart/alternative; boundary=001a114a922cb7322f054d027494
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, 
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Deploying CT in Bitcoin without 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, 13 Apr 2017 01:43:49 -0000

--001a114a922cb7322f054d027494
Content-Type: text/plain; charset=UTF-8

See this soft-fork proposal from Felix Weiss

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html

Adam

On Apr 12, 2017 5:43 PM, "Oleg Andreev via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> (This is a sketch, not a fully-formed proposal, just to kick off the
> discussion.)
>
> Confidential Transactions (by GMaxwell & Poelstra) require a new
> accounting model,
> new representation of numbers (EC points as Pedersen commitments) and
> range proofs
> per number. Setting aside performance and bandwidth concerns (3-4Kb per
> output,
> 50x more signature checks), how would we deploy that feature on Bitcoin
> network
> in the most compatible manner?
>
> I'll try to present a sketch of the proposal. I apologize if this
> discussion already
> happened somewhere, although I couldn't find anything on this subject,
> apart from Elements
> sidechain proposal, of course.
>
> At first glance we could create a new extblock and transaction format, add
> a protocol to
> "convert" money into and from such extblock, and commit to that extblock
> from the
> outer block's coinbase transaction. Unfortunately, this opens gates to a
> flood of
> debates such as what should be the block size limit in such block, should
> we
> take opportunity to fix over 9000 of pet-peeve issues with existing
> transactions
> and blocks, should we adjust inflation schedule, insert additional PoW,
> what would
> Satoshi say etc. Federated sidechain suffers from the same issues, plus
> adds
> concerns regarding governance, although it would be more decoupled, which
> is useful.
>
> I tried to look at a possibility to make the change as compatible as
> possible,
> sticking confidential values right into the existing transaction structure
> and
> see how that would look like. As a nice bonus, confidential transactions
> would have
> to fit into the hard-coded 1 Mb limit, preserving the drama around it :-P
>
> We start with a segwit-enabled script versioning and introduce 2 new
> script versions:
> version A has an actual program concatenated with the commitment, while
> version B
> has only the commitment and allows mimblewimble usage (no signatures,
> non-interactive
> cut-through etc). Legacy cleartext amount can nicely act as "min value" to
> minimize
> the range proof size, and range proofs themselves are provided separately
> in the
> segregated witness payload.
>
> Then, we soft fork additional rules:
>
> 1. In non-coinbase tx, sum of commitments on inputs must balance with sum
> of commitments
>    on the outputs plus the cleartext mining fee in the witness.
> 2. Range proof can be confidential, based on borromean ring signature.
> 3. Range proof can be non-confidential, consisting of an amount and raw
> blinding factor.
> 4. Tx witness can have an excess value (cf. MW) and cleartext amount for a
> miner's fee.
> 5. In coinbase tx, total plaintext reward + commitments must balance with
> subsidy,
>    legacy fees and new fees in the witness.
> 6. Extra fees in the witness must be signed with the excess value's key.
>
> The confidential transactions use the same UTXO set, can be co-authored
> with plaintext inputs/outputs
> using legacy software and maybe even improve scalability by compressing
> on-chain transactions
> using mimblewimble cut-through.
>
> The rules above could have been made more complicated with export/import
> logic to allow users
> converting their coins to and from confidential ones, but that would
> require
> more complex support from miners to respect and merge outputs representing
> "plaintext value bank",
> mutate export transactions, which in turn requires introduction of a
> non-malleable TxID
> that excludes miner-adjustable export/import outputs.
>
> The rules above have a nice side effect that miners, being the minters of
> confidential coins,
> can sell them at a premium, which creates an incentive for them to
> actually support
> that feature and work on improving performance of rangeproof validation
> (e.g. in GPUs).
>
> Would love to hear comments and criticism of that approach.
>
> Thanks!
> Oleg.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a114a922cb7322f054d027494
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">See this soft-fork proposal from Felix Weiss=C2=A0<div di=
r=3D"auto"><br></div><div dir=3D"auto"><a href=3D"https://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2016-January/012194.html">https://lists.linu=
xfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html</a><div dir=
=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">Adam</div></div></d=
iv></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Apr 1=
2, 2017 5:43 PM, &quot;Oleg Andreev via bitcoin-dev&quot; &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">(This is a sketch, not a fully-formed proposal, just to kick off the disc=
ussion.)<br>
<br>
Confidential Transactions (by GMaxwell &amp; Poelstra) require a new accoun=
ting model,<br>
new representation of numbers (EC points as Pedersen commitments) and range=
 proofs<br>
per number. Setting aside performance and bandwidth concerns (3-4Kb per out=
put,<br>
50x more signature checks), how would we deploy that feature on Bitcoin net=
work<br>
in the most compatible manner?<br>
<br>
I&#39;ll try to present a sketch of the proposal. I apologize if this discu=
ssion already<br>
happened somewhere, although I couldn&#39;t find anything on this subject, =
apart from Elements<br>
sidechain proposal, of course.<br>
<br>
At first glance we could create a new extblock and transaction format, add =
a protocol to<br>
&quot;convert&quot; money into and from such extblock, and commit to that e=
xtblock from the<br>
outer block&#39;s coinbase transaction. Unfortunately, this opens gates to =
a flood of<br>
debates such as what should be the block size limit in such block, should w=
e<br>
take opportunity to fix over 9000 of pet-peeve issues with existing transac=
tions<br>
and blocks, should we adjust inflation schedule, insert additional PoW, wha=
t would<br>
Satoshi say etc. Federated sidechain suffers from the same issues, plus add=
s<br>
concerns regarding governance, although it would be more decoupled, which i=
s useful.<br>
<br>
I tried to look at a possibility to make the change as compatible as possib=
le,<br>
sticking confidential values right into the existing transaction structure =
and<br>
see how that would look like. As a nice bonus, confidential transactions wo=
uld have<br>
to fit into the hard-coded 1 Mb limit, preserving the drama around it :-P<b=
r>
<br>
We start with a segwit-enabled script versioning and introduce 2 new script=
 versions:<br>
version A has an actual program concatenated with the commitment, while ver=
sion B<br>
has only the commitment and allows mimblewimble usage (no signatures, non-i=
nteractive<br>
cut-through etc). Legacy cleartext amount can nicely act as &quot;min value=
&quot; to minimize<br>
the range proof size, and range proofs themselves are provided separately i=
n the<br>
segregated witness payload.<br>
<br>
Then, we soft fork additional rules:<br>
<br>
1. In non-coinbase tx, sum of commitments on inputs must balance with sum o=
f commitments<br>
=C2=A0 =C2=A0on the outputs plus the cleartext mining fee in the witness.<b=
r>
2. Range proof can be confidential, based on borromean ring signature.<br>
3. Range proof can be non-confidential, consisting of an amount and raw bli=
nding factor.<br>
4. Tx witness can have an excess value (cf. MW) and cleartext amount for a =
miner&#39;s fee.<br>
5. In coinbase tx, total plaintext reward + commitments must balance with s=
ubsidy,<br>
=C2=A0 =C2=A0legacy fees and new fees in the witness.<br>
6. Extra fees in the witness must be signed with the excess value&#39;s key=
.<br>
<br>
The confidential transactions use the same UTXO set, can be co-authored wit=
h plaintext inputs/outputs<br>
using legacy software and maybe even improve scalability by compressing on-=
chain transactions<br>
using mimblewimble cut-through.<br>
<br>
The rules above could have been made more complicated with export/import lo=
gic to allow users<br>
converting their coins to and from confidential ones, but that would requir=
e<br>
more complex support from miners to respect and merge outputs representing =
&quot;plaintext value bank&quot;,<br>
mutate export transactions, which in turn requires introduction of a non-ma=
lleable TxID<br>
that excludes miner-adjustable export/import outputs.<br>
<br>
The rules above have a nice side effect that miners, being the minters of c=
onfidential coins,<br>
can sell them at a premium, which creates an incentive for them to actually=
 support<br>
that feature and work on improving performance of rangeproof validation (e.=
g. in GPUs).<br>
<br>
Would love to hear comments and criticism of that approach.<br>
<br>
Thanks!<br>
Oleg.<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div></div>

--001a114a922cb7322f054d027494--