path: root/4f/2f87bc9234794596472be601797fd7049fa923

Return-Path: <mail@felixweis.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id AC9F5FCC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  6 Jan 2016 15:19:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com
	[209.85.218.49])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9648814C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  6 Jan 2016 15:19:06 +0000 (UTC)
Received: by mail-oi0-f49.google.com with SMTP id l9so267238411oia.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 06 Jan 2016 07:19:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=felixweis-com.20150623.gappssmtp.com; s=20150623;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=6XiXLyTmGuJKK+HRd+tNMOKi7r+3SlF8C+EgAuiBcew=;
	b=tjvNlxEj9ieMi/Dh1tjyV5K2CymEu5Lemn+1wqM0Agk+eRkD8hOoNk987EHFfaRRwy
	57Am/hzmTuwjU3rWPWBVnschzBqBaVZNzci6p4MxDQSbHwibDRwWJOpkrv+tbV4XDq9n
	EJV+cbL/k0I6Q/s4Ejw7gSY8pZusQE6iiyV9tPlSdBGL2GEvR57SWskWdALcUlr7It6k
	RvFrEN4CxzmtHBnx4uKmAwb34wWdXjbPNLxTUTxSXmafZrhtc60QkTvioAdSE/OmiJd5
	jpliDHZtFUMLtH/rPspEUygpHGceVxOQAWaHGyvcw30+OM9Omj+djSzzhMQEfs4Dbpr4
	Bt1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:from:date:message-id:subject:to
	:content-type;
	bh=6XiXLyTmGuJKK+HRd+tNMOKi7r+3SlF8C+EgAuiBcew=;
	b=eO7z4Nl+eulr/ekYLUTzZhQpy0XAe8DDq8x8T0VIzIy5Zz4q5Vpuh0GtV8DkSq4FMr
	3A7tGSeCgvwBuUd43IjdWp8cghiedKvO4DWm4N9CEKJRMnnOu8lNe7R/7HkVC/rA1PEb
	AbuOIls+VrcF/xW3RYCR3Wdf7VC/8HjQ0yimSZmJSjJlftqp2vhlHYXDPyzUE/B1nOD5
	rmOSZkFhjwPJWiOmmW4kzYbBTXYgPkQEwoxOHjbNjAxoCe/wy5CDt3sTRI6QRnuSg2Sw
	kmX/VRyIgbGLhH1TqXMmSGL1beKnGhs31wYMyzrQouyQi14Sy3xwvFaVVRgnmbtKqjiL
	PeSQ==
X-Gm-Message-State: ALoCoQn6YUO1KYQbwVDIZJdf52v7TqFpQVh/PX4dYY/VhMCT1UWLycR8rmarUp/+vVpFeQUU8zJFj0CCPDWeiN5YKzUSH62Waw==
X-Received: by 10.202.94.10 with SMTP id s10mr60967886oib.99.1452093545632;
	Wed, 06 Jan 2016 07:19:05 -0800 (PST)
MIME-Version: 1.0
From: Felix Weis <mail@felixweis.com>
Date: Wed, 06 Jan 2016 15:18:56 +0000
Message-ID: <CAMnWzuVi2qK6FhML=R5M1r95i1346J5YpUuOd1=StSdAZXfG3g@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a113d5cd2f7f1650528abdfa3
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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: Wed, 06 Jan 2016 15:27:14 +0000
Subject: [bitcoin-dev] Confidential Transactions as a soft fork (using
	segwit)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Wed, 06 Jan 2016 15:19:10 -0000

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

Since the release of sidechains alpha, confidential transactions[1] by Greg
Maxwell have show how they could greatly improve transaction privacy and
fungibility of bitcoin. Unfortunately without a hardfork or pegged
sidechain it was not easy to enable them in bitcoin.

The segregated witness[2] proposal by Pieter Wuille allows to reduce the
blockchain to a mere utxo changeset while putting all cryptographic proofs
(redeemscript/pubkeys/signatures) for the inputs into a witness part.
Segwit also allows upgradable scripting language. All can be done with a
soft fork.

We propose an upgrade to segwit to allow transactions to have both
witnessIns and witnessOuts.

We also propose 3 new transactions types: blinding, unblinding and
confidential. Valid blocks containing any of these new transactions MUST
also include a mandatory special output in their coinbase transaction and a
new special confidential base transaction.

The basic idea for confidential transaction is to use 0 value inputs and
outputs while having the encrypted amounts (petersen-commitment +
range-proof) in the witnessOut part. These transactions are valid under old
rules (but currently non-standard). For blinding, unblinding and miner fees
we use a single anyone-can-spend output (GCTXO) which will be updated in
every block containing confidential transactions.

Blinding transaction:
  Ins:
    All non-confidential inputs are valid
  Outs:
  - 0..N: (new confidential outputs)
    amount: 0
    scriptPubkey: OP_2 <0x{32-byte-hash-value}>
    witnessOut: <0x{petersen-commitment}> <0x{range-proof}>
  - last:
    amount: 0
    scriptPubkey: OP_RETURN OP_2 {blinding-fee-amount}
  Fee: Sum of the all inputs value
The last output's script is also a marker of the transaction being a
blinding tx. After the soft fork, a block is invalid if the miner claims
the fees for himself instead of putting it into a special coinbase output.


Coinbase transaction:
If the block contains blinding transactions, it MUST send the sum of all
their fees to a new output: GCTXO[coinbase]
The scriptPubkey does not really matter since it will be only spendable
under strict rules in the same block's confidential base transaction. Maybe
OP_TRUE.


Unblinding transaction:
  Ins:
    prev: CTXO[n]
    scriptSig: (empty)
    witnessIn: <signature> <0x{redeemscript}>
  Outs:
  - 0..N:
    amount: 0
  scriptPubkey: OP_RETURN OP_2 {amount-to-be-unblinded} {p2sh-destination}
    witnessOut: (empty)
  - last:
    amount: 0
    scriptPubkey: OP_RETURN OP_2 {unblinding-fee-amount}
  Fee: 0

This transaction remove removes the confidential outputs from the utxo set.
This outpoint itself is not spendable (it's OP_RETURN), but the same block
will contain a confidential base transaction created by the miner that will
satisfy the amount and p2sh-destination (refunded using GCTXO).
Confidential transaction:
  Ins:
  - 0..N:
    prev: CTXO[n]
    scriptSig: (empty)
    witnessIn: <signature> <0x{redeemscript}>
  Outs:
  - 0..N:
    amount: 0
    scriptPubkey: OP_2 <0x{32-byte-hash-value}>
    witnessOut: <0x{petersen-commitment}> <0x{range-proof}>
  - last:
    amount: 0
    scriptPubkey: OP_RETURN OP_2 {confidential-fee-amount}
  Fee: 0

All inputs and outputs and have amount 0 and are everyone can spend V2
segwit, thus valid under old rules. Transaction valid under new rules
obviously only if petersen commitment and range-proof in witnessOut valid.
Minerfee for this transaction is expressed as one extra output:


Confidential base transaction:
  Ins:
    GCTXO[last_block],
    GCTXO[coinbase]
  Outs:
    0: GCTXO[current_block]
    amount: {last_block + coinbase - unblindings}
    scriptPubkey: OP_TRUE
    1..N:
    amount/scriptPubkey: as requested by unblinding transactions in this
block
  Fee:
    Sum of all the explicit OP_RETURN OP_2 {...} expressed fees from
    confidential transactions in this block

This special transaction in last position in every block that contains at
least one of the new transaction types. Created by the miner of the block
and used to do the actual unblinding and redeeming transaction fees for all
confidential transactions.

There will always be only 1 GCTXO in the utxo set. This allows for full
accountability for 21 million bitcoin. Should a vulnerability in CT be
discovered all unconfidential bitcoins remain safe. Under these new rules,
a block is only valid if all amounts/commitments/range-proofs match. A a
miner trying use GCTXO other than allowed in the single confidential base
transaction
will be orphaned.

[1] https://people.xiph.org/~greg/confidential_values.txt
[2]
https://github.com/CodeShark/bips/blob/segwit/bip-codeshark-jl2012-segwit.mediawiki


Sorry for the form, this is just a quick draft of a thought I had today.
Please comment.

Felix Weis

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

<div dir=3D"ltr"><div>Since the release of sidechains alpha, confidential t=
ransactions[1] by Greg Maxwell have show how they could greatly improve tra=
nsaction privacy and fungibility of bitcoin. Unfortunately without a hardfo=
rk or pegged sidechain it was not easy to enable them in bitcoin.</div><div=
><br></div><div>The segregated witness[2] proposal by Pieter Wuille allows =
to reduce the blockchain to a mere utxo changeset while putting all cryptog=
raphic proofs (redeemscript/pubkeys/signatures) for the inputs into a witne=
ss part. Segwit also allows upgradable scripting language. All can be done =
with a soft fork.</div><div><br></div><div>We propose an upgrade to segwit =
to allow transactions to have both witnessIns and witnessOuts.</div><div><b=
r></div><div>We also propose 3 new transactions types: blinding, unblinding=
 and=C2=A0</div><div>confidential. Valid blocks containing any of these new=
 transactions MUST also include a mandatory special output in their coinbas=
e transaction and a new special confidential base transaction.</div><div><b=
r></div><div>The basic idea for confidential transaction is to use 0 value =
inputs and=C2=A0</div><div>outputs while having the encrypted amounts (pete=
rsen-commitment + range-proof) in the witnessOut part. These transactions a=
re valid under old rules (but currently non-standard). For blinding, unblin=
ding and miner fees we use a single anyone-can-spend output (GCTXO) which w=
ill be updated in every block containing confidential transactions.</div><d=
iv><br></div><div>Blinding transaction:</div><div>=C2=A0 Ins:=C2=A0</div><d=
iv>=C2=A0 =C2=A0 All non-confidential inputs are valid</div><div>=C2=A0 Out=
s:=C2=A0</div><div>=C2=A0 - 0..N: (new confidential outputs)</div><div>=C2=
=A0 =C2=A0 amount: 0</div><div>=C2=A0 =C2=A0 scriptPubkey: OP_2 &lt;0x{32-b=
yte-hash-value}&gt;</div><div>=C2=A0 =C2=A0 witnessOut: &lt;0x{petersen-com=
mitment}&gt; &lt;0x{range-proof}&gt;</div><div>=C2=A0 - last:</div><div>=C2=
=A0 =C2=A0 amount: 0</div><div>=C2=A0 =C2=A0 scriptPubkey: OP_RETURN OP_2 {=
blinding-fee-amount}</div><div>=C2=A0 Fee: Sum of the all inputs value</div=
><div>The last output&#39;s script is also a marker of the transaction bein=
g a blinding tx. After the soft fork, a block is invalid if the miner claim=
s the fees for himself instead of putting it into a special coinbase output=
.</div><div><br></div><div><br></div><div>Coinbase transaction:</div><div>I=
f the block contains blinding transactions, it MUST send the sum of all the=
ir fees to a new output: GCTXO[coinbase]</div><div>The scriptPubkey does no=
t really matter since it will be only spendable under strict rules in the s=
ame block&#39;s confidential base transaction. Maybe OP_TRUE.</div><div><br=
></div><div><br></div><div>Unblinding transaction:</div><div>=C2=A0 Ins:</d=
iv><div>=C2=A0 =C2=A0 prev: CTXO[n]</div><div>=C2=A0 =C2=A0 scriptSig: (emp=
ty)</div><div>=C2=A0 =C2=A0 witnessIn: &lt;signature&gt; &lt;0x{redeemscrip=
t}&gt;</div><div>=C2=A0 Outs:</div><div>=C2=A0 - 0..N:</div><div>=C2=A0 =C2=
=A0 amount: 0</div><div>=C2=A0 <span style=3D"white-space:pre-wrap">	</span=
>scriptPubkey: OP_RETURN OP_2 {amount-to-be-unblinded} {p2sh-destination}</=
div><div>=C2=A0 =C2=A0 witnessOut: (empty)</div><div>=C2=A0 - last:</div><d=
iv>=C2=A0 =C2=A0 amount: 0</div><div>=C2=A0 =C2=A0 scriptPubkey: OP_RETURN =
OP_2 {unblinding-fee-amount}</div><div>=C2=A0 Fee: 0</div><div><br></div><d=
iv>This transaction remove removes the confidential outputs from the utxo s=
et. This outpoint itself is not spendable (it&#39;s OP_RETURN), but the sam=
e block will contain a confidential base transaction created by the miner t=
hat will satisfy the amount and p2sh-destination (refunded using GCTXO).</d=
iv><div><span style=3D"white-space:pre-wrap">	</span></div><div><span style=
=3D"white-space:pre-wrap">	</span></div><div>Confidential transaction:</div=
><div>=C2=A0 Ins:</div><div>=C2=A0 - 0..N:</div><div>=C2=A0 =C2=A0 prev: CT=
XO[n]</div><div>=C2=A0 =C2=A0 scriptSig: (empty)</div><div>=C2=A0 =C2=A0 wi=
tnessIn: &lt;signature&gt; &lt;0x{redeemscript}&gt;</div><div>=C2=A0 Outs:<=
/div><div>=C2=A0 - 0..N:</div><div>=C2=A0 =C2=A0 amount: 0</div><div>=C2=A0=
 =C2=A0 scriptPubkey: OP_2 &lt;0x{32-byte-hash-value}&gt;</div><div>=C2=A0 =
=C2=A0 witnessOut: &lt;0x{petersen-commitment}&gt; &lt;0x{range-proof}&gt;<=
/div><div>=C2=A0 - last:</div><div>=C2=A0 =C2=A0 amount: 0</div><div>=C2=A0=
 =C2=A0 scriptPubkey: OP_RETURN OP_2 {confidential-fee-amount}</div><div>=
=C2=A0 Fee: 0</div><div><br></div><div>All inputs and outputs and have amou=
nt 0 and are everyone can spend V2 segwit, thus valid under old rules. Tran=
saction valid under new rules obviously only if petersen commitment and ran=
ge-proof in witnessOut valid. Minerfee for this transaction is expressed as=
 one extra output:</div><div><br></div><div><br></div><div>Confidential bas=
e transaction:</div><div>=C2=A0 Ins:=C2=A0</div><div>=C2=A0 =C2=A0 GCTXO[la=
st_block],=C2=A0</div><div>=C2=A0 =C2=A0 GCTXO[coinbase]</div><div>=C2=A0 O=
uts:=C2=A0</div><div>=C2=A0 =C2=A0 0: GCTXO[current_block]</div><div>=C2=A0=
 =C2=A0 amount: {last_block + coinbase - unblindings}</div><div>=C2=A0 =C2=
=A0 scriptPubkey: OP_TRUE</div><div>=C2=A0 =C2=A0 1..N:</div><div>=C2=A0 =
=C2=A0 amount/scriptPubkey: as requested by unblinding transactions in this=
 block</div><div>=C2=A0 Fee:=C2=A0</div><div>=C2=A0 =C2=A0 Sum of all the e=
xplicit OP_RETURN OP_2 {...} expressed fees from=C2=A0</div><div>=C2=A0 =C2=
=A0 confidential transactions in this block</div><div><br></div><div>This s=
pecial transaction in last position in every block that contains at=C2=A0</=
div><div>least one of the new transaction types. Created by the miner of th=
e block and used to do the actual unblinding and redeeming transaction fees=
 for all confidential transactions.</div><div><br></div><div>There will alw=
ays be only 1 GCTXO in the utxo set. This allows for full=C2=A0</div><div>a=
ccountability for 21 million bitcoin. Should a vulnerability in CT be=C2=A0=
</div><div>discovered all unconfidential bitcoins remain safe. Under these =
new rules, a block is only valid if all amounts/commitments/range-proofs ma=
tch. A a miner trying use GCTXO other than allowed in the single confidenti=
al base transaction=C2=A0</div><div>will be orphaned.</div><div><br></div><=
div>[1] <a href=3D"https://people.xiph.org/~greg/confidential_values.txt" t=
arget=3D"_blank">https://people.xiph.org/~greg/confidential_values.txt</a><=
/div><div>[2] <a href=3D"https://github.com/CodeShark/bips/blob/segwit/bip-=
codeshark-jl2012-segwit.mediawiki" target=3D"_blank">https://github.com/Cod=
eShark/bips/blob/segwit/bip-codeshark-jl2012-segwit.mediawiki</a></div><div=
><br></div><div><br></div><div>Sorry for the form, this is just a quick dra=
ft of a thought I had today.=C2=A0</div><div>Please comment.</div><div dir=
=3D"ltr"><div><br></div><div>Felix Weis</div><div><br></div></div></div>

--001a113d5cd2f7f1650528abdfa3--