path: root/7d/83eba737ca4e0beb9a5380ed4daba191a9c760

Return-Path: <jlrubin@mit.edu>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id F1597C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Aug 2020 15:25:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id ED373881B8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Aug 2020 15:25:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id h0FYeb5xBYKA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Aug 2020 15:25:03 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 802C088111
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Aug 2020 15:25:03 +0000 (UTC)
Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com
 [209.85.208.53]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07PFOxMH001540
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 25 Aug 2020 11:25:00 -0400
Received: by mail-ed1-f53.google.com with SMTP id f24so9291646edw.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Aug 2020 08:25:00 -0700 (PDT)
X-Gm-Message-State: AOAM5311Bp9zW+PK7j6afNPRCNhN+DApPv+X/BPgMw6nqNBQLkvBbhW2
 fYAl2Cpqp+smzIQGWgvEJYpqGcj9tA++JF+Xu+c=
X-Google-Smtp-Source: ABdhPJx5KEZC8/RGDbxSGKcQIKeY34Qi28CL5Yoj/e5CgIO4+u4XgtJ4Vzdvhl7TOdkZjv4BAvuac1uiKrZ4gJyoY20=
X-Received: by 2002:a05:6402:1b02:: with SMTP id
 by2mr7681936edb.95.1598369099008; 
 Tue, 25 Aug 2020 08:24:59 -0700 (PDT)
MIME-Version: 1.0
References: <4J4ILDzMrP8LgBtLcgYxftOAhGNX8BVFdamKbkbmD3fxz912nBxOLJnoq2hBgrD9OP5RUeMH7VrBcBItG2Tqz2b9SZokVI5qtiuO2RokY78=@protonmail.com>
In-Reply-To: <4J4ILDzMrP8LgBtLcgYxftOAhGNX8BVFdamKbkbmD3fxz912nBxOLJnoq2hBgrD9OP5RUeMH7VrBcBItG2Tqz2b9SZokVI5qtiuO2RokY78=@protonmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Tue, 25 Aug 2020 08:24:46 -0700
X-Gmail-Original-Message-ID: <CAD5xwhjca8CnTda88EviFWz2wc0qVGYFF50TwT+kbguhLfdS6w@mail.gmail.com>
Message-ID: <CAD5xwhjca8CnTda88EviFWz2wc0qVGYFF50TwT+kbguhLfdS6w@mail.gmail.com>
To: "Jule.Adka" <Jule.Adka@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005dd2a605adb54e3b"
Subject: Re: [bitcoin-dev] New tipe of outputs that saves space and give
	more privacy
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Tue, 25 Aug 2020 15:25:07 -0000

--0000000000005dd2a605adb54e3b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

You may wish to review bip-119 ChecktemplateVerify, as it is designed to
support something very similar to what you've described. You can see more
at https://utxos.org

On Tue, Aug 25, 2020, 6:48 AM Jule.Adka via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hey, there! I have a new proposal to help Bitcoin=E2=80=99s scalability, =
while
> helping privacy.
>
> *Motivation*
>
> All transactions in the Bitcoin=E2=80=99s network have a header, an input=
 list and
> an output list. Every transaction must consume some previous outputs and
> create new ones, this creates huge amounts of data through the years, and
> creates scalability problems. With segwit we solved some problems by movi=
ng
> part of the data to a separate structure that stores data useful to verif=
y
> the transaction itself, but not its state and the state of the whole
> blockchain[1]. But we still have a problem with the outputs list, some
> transactions create various outputs, generating munch data and increasing
> the size of the unspent transactions outputs(UTXOs) that are held for eve=
ry
> full node into the network.
>
> Another problem with this approach is the fact that all outputs are
> recorded, disclosed and accessible to everyone that looks at the
> transaction. This creates various privacy problems that are exploited for
> the chain analize companies and governments to track individuals and link
> it to their own personality.
>
> *Description*
>
> I propose a new type of output, called Mekelized Output Set and the
> p2mos(pay to Mekelized Output Set) standard. Instead of listing all the
> output set, as in an ordinary transaction, Alice only specifies a Markle
> root, and only when she tries to spend the coin, she may to show a path
> into the Merkle from her transaction to the recorded root (a.k.a Merkle
> Path), and proof that her output really exists.
>
> The extra data (the path) are stored into the witness structure, and can
> be striped after verification. Once the size of the witness structure is
> ignored/discounted when calculating the block size, it gives more space f=
or
> transactions in a unique block, without increasing it=E2=80=99s actual si=
ze. As
> well, decrease the UTXO=E2=80=99s size, taking less resource from validat=
ors node.
>
>  An ordinary(the current standard) p2wpkh transaction with one output hav=
e
> 8 bytes to amount, 1-9 varInt for the locking-script size and 22 bytes
> (OP_0 OP_PUSHBYTES_20 <20-bytes-hash>), at most 39 bytes for each
> output[2]. If we use sha256 to encode the merkle, we need only 32 of scri=
pt
> data, 49 in the total. 10 bytes more than an ordinary transaction with on=
e
> output. But usually the transactions have 2 outputs (the actual payment a=
nd
> a change) or more. If the transaction have 2 outputs, we only record one
> commitment and the two outputs keep hidden until it has been spent (also
> the UTXO set is have one transaction instead of 2), the 2 outputs would
> require 78 bytes to record, we can do it with the same 49 bytes. For a 12
> outputs[3] transaction, it would require 468 bytes, and so on=E2=80=A6
>
> By using p2mos saves space by reducing any transaction to a 49 bytes-wide
> output set, no matter how many outputs actually exist. Also, once only th=
e
> peers are able to know the number and the value of the outputs, a third
> party has no way to know the ownership of the remaining coins, many of th=
e
> privacy troubles associated with outputs, like Equal-output CoinJoin and
> different outputs types[4] are solved.
>
> *An example*
>
> When Alice=E2=80=99s wallet create a transaction, sending 5 bitcoins to B=
ob and
> spending from a 10 bitcoins output (forget the fees, for a while), Alice
> must send 5 bitcoins to Bob and 5 back to she as change, when Bob=E2=80=
=99s wallet
> create the invoice to be paid by Alice, he gives an output to Alice and s=
he
> adds it together into a Merkle Tree, takes the root and build a transacti=
on
> paying to this hash. Alice=E2=80=99s wallet then sends a path into the tr=
ee to
> prove to Bob that his output is really into a transaction and is fully
> expendable from Bob=E2=80=99s wallet. Bob now looks for the mempool (and =
the
> chain, of course) to find transactions that pay to the given Markle Root.
>
> Now let=E2=80=99s see how Bob spends from this UTXO. His wallet knows the=
 path
> that has taken from his transaction to the top, and the wallet reveals it
> to the network, before evaluating the output. Bob sends the actual output=
,
> the path to the root of the tree as well the data to solve the lockscript
> on it(note that =E2=80=9Cactual output=E2=80=9D means the output that kee=
ps hidden from the
> world until Bob spends it). After checking if Bob=E2=80=99s output really=
 exists,
> an node can evaluate it exactly in the same way as ordinary transactions,
> the output will look like any other.
>
> Alice=E2=80=99s wallet does the same to spend her 5 BTC, but presenting a=
 totally
> different output, that she spends from a script that only she has a way t=
o
> do, if they use p2wpkh she must present the public key and a valid
> signature. After evaluation, the node can discard all this data and keeps
> only with the 1-input-1-output transaction.
>
> This new transaction has the same fields of an ordinary one, amount,
> script size and script. Probably we will need an opcode to make reference
> to p2mos (pay to Merkelized output set), instructing the node to look at
> the witness data in order to find the actual output. So, we have 1 byte o=
f
> opcode and 32 bytes of the Merkle Root. The amount is preserved for
> compatibility as well for calculating mining fees, once the miner has no
> idea of the actual value locked into the output. The fee calculus doesn't
> change.
>
> The amount also is helpful to determine whether the UTXO still have any
> locked coins, if the total =E2=80=9Cremoved=E2=80=9D outputs value (i.e t=
he outputs that
> has been revealed and spent) are equal to the locked value, the output is
> now totally spend and may be removed from the UTXO=E2=80=99s set. If one =
tries to
> retrieve more than it=E2=80=99s actually locked in, it fails.
>
> Let=E2=80=99s say that Alice locks her 10 BTC, but creates two outputs: 6=
 BTC to
> she and 5 BTC to Bob, if she spends from this output, now Bob have no way
> to spend from this, because if he broadcast his 5 BTC he will  exceed the
> total value, and the evaluation will fall. The 5 BTC will be locked up
> forever, and he can=E2=80=99t create an alternative transaction, because =
it will
> never mech with the Merkle path and hence the root. To prevent this, some
> kind of verification of the values may be made by the wallets, all wallet=
s
> must verify the values.
>
> To one wallet verify all the outputs, without revealing the sigscript, we
> can hash the other 2 fields and exchange the hashes, the leafs of the tre=
e
> are made by the hash(sigscript || scriptSize) || amount. Only the amounts
> are disclosed, keeping the privacy, after verifying the process of hashin=
g
> can be done by all the parties, reaching the same root, at the end.
>
> *Pros*
>
> Using the p2mos, one keeps private the information about the outputs unti=
l
> it has been spent, as well saving space into the block and makes the
> transactions (without taking in account the witness data) smaller,
> decreasing the data used for SPV nodes. We still have an input and an
> output with explicit given values, that is useful for verifying the state
> of the chain.
>
> *                                                          Cons*
>
> Needs more coordination between the wallets (this is a problem, especiall=
y
> with scenarios that one part is offline), is a bit more hard to compute f=
or
> a validator, and would require some extra bandwidth for downloading the
> witness data.
>
> *Retro Compatibility*
>
> On one hand, old nodes that don=E2=80=99t follow the new consensus rule c=
an accept
> this kind of transaction if it=E2=80=99s made as a anyone can spend in th=
e current
> consensus, but with other meanings in the new one(as segwit), but on the
> other hand, at a second spend, the node will interpret it as double spend=
,
> hence invalidating it. So the main problem with this approach is to
> implement it as a soft-fork.
>
> I would like to receive any thoughts and considerations about this
> proposal. At the most, thank you very much. Sincerely, Jule Adka (
> Jule.Adka@protonmail.com)
>
> [1] *BIP141*
> <https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki>,
> Segregated Witness
>
> [2] ANTONOPOLOS, Andres. Mastering Bitcoin
>             [3] A 12-output transaction in *blockstream.info*
> <https://blockstream.info/tx/1bdde4ec3486ac67018727cfb4aa7fd84011db29bc0f=
db525a810ad2ab1eb24d>
> .
>
> [4] Privacy on *Bitcoin wiki* <https://en.bitcoin.it/wiki/Privacy>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000005dd2a605adb54e3b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">You may wish to review bip-119 ChecktemplateVerify, as it=
 is designed to support something very similar to what you&#39;ve described=
. You can see more at <a href=3D"https://utxos.org">https://utxos.org</a></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Tue, Aug 25, 2020, 6:48 AM Jule.Adka via bitcoin-dev &lt;<a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.o=
rg</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"box=
-sizing:inherit"><span style=3D"background-color:transparent"><span style=
=3D"color:rgb(0,0,0)"><span style=3D"font-family:Arial"><span style=3D"font=
-size:11pt">Hey, there! I have a new proposal to help Bitcoin=E2=80=99s sca=
lability, while helping privacy.</span></span></span></span><br></div><p di=
r=3D"ltr" style=3D"box-sizing:inherit;line-height:1.38;text-indent:36pt;tex=
t-align:center;margin-top:0pt;margin-bottom:0pt"><span style=3D"background-=
color:transparent"><span style=3D"color:rgb(0,0,0)"><b style=3D"box-sizing:=
inherit;font-weight:bolder"><span style=3D"font-family:Arial"><span style=
=3D"font-size:11pt">Motivation</span></span></b></span></span><br></p><p di=
r=3D"ltr" style=3D"box-sizing:inherit;line-height:1.38;text-indent:36pt;mar=
gin-top:0pt;margin-bottom:0pt"><span style=3D"background-color:transparent"=
><span style=3D"color:rgb(0,0,0)"><span style=3D"font-family:Arial"><span s=
tyle=3D"font-size:11pt">All transactions in the Bitcoin=E2=80=99s network h=
ave a header, an input list and an output list. Every transaction must cons=
ume some previous outputs and create new ones, this creates huge amounts of=
 data through the years, and creates scalability problems. With segwit we s=
olved some problems by moving part of the data to a separate structure that=
 stores data useful to verify the transaction itself, but not its state and=
 the state of the whole blockchain[1]. But we still have a problem with the=
 outputs list, some transactions create various outputs, generating munch d=
ata and increasing the size of the unspent transactions outputs(UTXOs) that=
 are held for every full node into the network.</span></span></span></span>=
<br></p><p dir=3D"ltr" style=3D"box-sizing:inherit;line-height:1.38;text-in=
dent:36pt;margin-top:0pt;margin-bottom:0pt"><span style=3D"background-color=
:transparent"><span style=3D"color:rgb(0,0,0)"><span style=3D"font-family:A=
rial"><span style=3D"font-size:11pt">Another problem with this approach is =
the fact that all outputs are recorded, disclosed and accessible to everyon=
e that looks at the transaction. This creates various privacy problems that=
 are exploited for the chain analize companies and governments to track ind=
ividuals and link it to their own personality.</span></span></span></span><=
br></p><p dir=3D"ltr" style=3D"box-sizing:inherit;line-height:1.38;text-ind=
ent:36pt;text-align:center;margin-top:0pt;margin-bottom:0pt"><span style=3D=
"background-color:transparent"><span style=3D"color:rgb(0,0,0)"><b style=3D=
"box-sizing:inherit;font-weight:bolder"><span style=3D"font-family:Arial"><=
span style=3D"font-size:11pt">Description</span></span></b></span></span><b=
r></p><p dir=3D"ltr" style=3D"box-sizing:inherit;line-height:1.38;text-inde=
nt:36pt;margin-top:0pt;margin-bottom:0pt"><span style=3D"background-color:t=
ransparent"><span style=3D"color:rgb(0,0,0)"><span style=3D"font-family:Ari=
al"><span style=3D"font-size:11pt">I propose a new type of output, called M=
ekelized Output Set and the p2mos(pay to Mekelized Output Set) standard. In=
stead of listing all the output set, as in an ordinary transaction, Alice o=
nly specifies a Markle root, and only when she tries to spend the coin, she=
 may to show a path into the Merkle from her transaction to the recorded ro=
ot (a.k.a Merkle Path), and proof that her output really exists.</span></sp=
an></span></span><br></p><p dir=3D"ltr" style=3D"box-sizing:inherit;line-he=
ight:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style=3D=
"background-color:transparent"><span style=3D"color:rgb(0,0,0)"><span style=
=3D"font-family:Arial"><span style=3D"font-size:11pt">The extra data (the p=
ath) are stored into the witness structure, and can be striped after verifi=
cation. Once the size of the witness structure is=C2=A0 ignored/discounted =
when calculating the block size, it gives more space for transactions in a =
unique block, without increasing it=E2=80=99s actual size. As well, decreas=
e the UTXO=E2=80=99s size, taking less resource from validators node.</span=
></span></span></span><br></p><p dir=3D"ltr" style=3D"box-sizing:inherit;li=
ne-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span sty=
le=3D"background-color:transparent"><span style=3D"color:rgb(0,0,0)"><span =
style=3D"font-family:Arial"><span style=3D"font-size:11pt">=C2=A0An ordinar=
y(the current standard) p2wpkh transaction with one output have 8 bytes to =
amount, 1-9 varInt for the locking-script size and 22 bytes (OP_0 OP_PUSHBY=
TES_20 &lt;20-bytes-hash&gt;), at most 39 bytes for each output[2]. If we u=
se sha256 to encode the merkle, we need only 32 of script data, 49 in the t=
otal. 10 bytes more than an ordinary transaction with one output. But usual=
ly the transactions have 2 outputs (the actual payment and a change) or mor=
e. If the transaction have 2 outputs, we only record one commitment and the=
 two outputs keep hidden until it has been spent (also the UTXO set is have=
 one transaction instead of 2), the 2 outputs would require 78 bytes to rec=
ord, we can do it with the same 49 bytes. For a 12 outputs[3] transaction, =
it would require 468 bytes, and so on=E2=80=A6</span></span></span></span><=
br></p><p dir=3D"ltr" style=3D"box-sizing:inherit;line-height:1.38;text-ind=
ent:36pt;margin-top:0pt;margin-bottom:0pt"><span style=3D"background-color:=
transparent"><span style=3D"color:rgb(0,0,0)"><span style=3D"font-family:Ar=
ial"><span style=3D"font-size:11pt">By using p2mos saves space by reducing =
any transaction to a 49 bytes-wide output set, no matter how many outputs a=
ctually exist. Also, once only the peers are able to know the number and th=
e value of the outputs, a third party has no way to know the ownership of t=
he remaining coins, many of the privacy troubles associated with outputs, l=
ike Equal-output CoinJoin and different outputs types[4] are solved.</span>=
</span></span></span><br></p><p dir=3D"ltr" style=3D"box-sizing:inherit;lin=
e-height:1.38;text-indent:36pt;text-align:center;margin-top:0pt;margin-bott=
om:0pt"><span style=3D"background-color:transparent"><span style=3D"color:r=
gb(0,0,0)"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt"=
><b>An example</b></span></span></span></span><br></p><p dir=3D"ltr" style=
=3D"box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;mar=
gin-bottom:0pt"><span style=3D"background-color:transparent"><span style=3D=
"color:rgb(0,0,0)"><span style=3D"font-family:Arial"><span style=3D"font-si=
ze:11pt">When Alice=E2=80=99s wallet create a transaction, sending 5 bitcoi=
ns to Bob and spending from a 10 bitcoins output (forget the fees, for a wh=
ile), Alice must send 5 bitcoins to Bob and 5 back to she as change, when B=
ob=E2=80=99s wallet create the invoice to be paid by Alice, he gives an out=
put to Alice and she adds it together into a Merkle Tree, takes the root an=
d build a transaction paying to this hash. Alice=E2=80=99s wallet then send=
s a path into the tree to prove to Bob that his output is really into a tra=
nsaction and is fully </span></span></span></span>expendable<span style=3D"=
background-color:transparent"><span style=3D"color:rgb(0,0,0)"><span style=
=3D"font-family:Arial"><span style=3D"font-size:11pt"> from Bob=E2=80=99s w=
allet. Bob now looks for the mempool (and the chain, of course) to find tra=
nsactions that pay to the given Markle Root.</span></span></span></span></p=
><p dir=3D"ltr" style=3D"box-sizing:inherit;line-height:1.38;text-indent:36=
pt;margin-top:0pt;margin-bottom:0pt"><span style=3D"background-color:transp=
arent"><span style=3D"color:rgb(0,0,0)"><span style=3D"font-family:Arial"><=
span style=3D"font-size:11pt">Now let=E2=80=99s see how Bob spends from thi=
s UTXO. His wallet knows the path that has taken from his transaction to th=
e top, and the wallet reveals it to the network, before evaluating the outp=
ut. Bob sends the actual output, the path to the root of the tree as well t=
he data to solve the lockscript on it(note that =E2=80=9Cactual output=E2=
=80=9D means the output that keeps hidden from the world until Bob spends i=
t). After checking if Bob=E2=80=99s output really exists, an node can evalu=
ate it exactly in the same way as ordinary transactions, the output will lo=
ok like any other.</span></span></span></span><br></p><p dir=3D"ltr" style=
=3D"box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;mar=
gin-bottom:0pt"><span style=3D"background-color:transparent"><span style=3D=
"color:rgb(0,0,0)"><span style=3D"font-family:Arial"><span style=3D"font-si=
ze:11pt">Alice=E2=80=99s wallet does the same to spend her 5 BTC, but prese=
nting a totally different output, that she spends from a script that only s=
he has a way to do, if they use p2wpkh she must present the public key and =
a valid signature. After evaluation, the node can discard all this data and=
 keeps only with the 1-input-1-output transaction.</span></span></span></sp=
an><br></p><p dir=3D"ltr" style=3D"box-sizing:inherit;line-height:1.38;text=
-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style=3D"background-co=
lor:transparent"><span style=3D"color:rgb(0,0,0)"><span style=3D"font-famil=
y:Arial"><span style=3D"font-size:11pt">This new transaction has the same f=
ields of an ordinary one, amount, script size and script. Probably we will =
need an opcode to make reference to p2mos (pay to<span>=C2=A0</span></span>=
</span></span></span><span style=3D"background-color:rgb(255,255,255)"><spa=
n style=3D"color:rgb(34,34,34)"><span style=3D"font-family:Arial"><span sty=
le=3D"font-size:10.5pt">Merkelized output set), instructing the node to loo=
k at the witness data in order to find the actual output. So, we have 1 byt=
e of opcode and<span>=C2=A0</span></span></span></span></span><span style=
=3D"background-color:transparent"><span style=3D"color:rgb(0,0,0)"><span st=
yle=3D"font-family:Arial"><span style=3D"font-size:11pt">32 bytes of the Me=
rkle Root. The amount is preserved for compatibility as well for calculatin=
g mining fees, once the miner has no idea of the actual value locked into t=
he output. The fee calculus doesn&#39;t change.</span></span></span></span>=
<br></p><p dir=3D"ltr" style=3D"box-sizing:inherit;line-height:1.38;text-in=
dent:36pt;margin-top:0pt;margin-bottom:0pt"><span style=3D"background-color=
:transparent"><span style=3D"color:rgb(0,0,0)"><span style=3D"font-family:A=
rial"><span style=3D"font-size:11pt">The amount also is helpful to determin=
e whether the UTXO still have any locked coins, if the total =E2=80=9Cremov=
ed=E2=80=9D outputs value (i.e the outputs that has been revealed and spent=
) are equal to the locked value, the output is now totally spend and may be=
 removed from the UTXO=E2=80=99s set. If one tries to retrieve more than it=
=E2=80=99s actually locked in, it fails.</span></span></span></span><br></p=
><p dir=3D"ltr" style=3D"box-sizing:inherit;line-height:1.38;text-indent:36=
pt;margin-top:0pt;margin-bottom:0pt"><span style=3D"background-color:transp=
arent"><span style=3D"color:rgb(0,0,0)"><span style=3D"font-family:Arial"><=
span style=3D"font-size:11pt">Let=E2=80=99s say that Alice locks her 10 BTC=
, but creates two outputs: 6 BTC to she and 5 BTC to Bob, if she spends fro=
m this output, now Bob have no way to spend from this, because if he broadc=
ast his 5 BTC he will=C2=A0 exceed the total value, and the evaluation will=
 fall. The 5 BTC will be locked up forever, and he can=E2=80=99t create an =
alternative transaction, because it will never mech with the Merkle path an=
d hence the root. To prevent this, some kind of verification of the values =
may be made by the wallets, all wallets must verify the values.</span></spa=
n></span></span><br></p><p dir=3D"ltr" style=3D"box-sizing:inherit;line-hei=
ght:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style=3D"=
background-color:transparent"><span style=3D"color:rgb(0,0,0)"><span style=
=3D"font-family:Arial"><span style=3D"font-size:11pt">To one wallet verify =
all the outputs, without revealing the sigscript, we can hash the other 2 f=
ields and exchange the hashes, the leafs of the tree are made by the hash(s=
igscript || scriptSize) || amount. Only the amounts are disclosed, keeping =
the privacy, after verifying the process of hashing can be done by all the =
parties, reaching the same root, at the end.</span></span></span></span><br=
></p><div style=3D"box-sizing:inherit"><br></div><p dir=3D"ltr" style=3D"bo=
x-sizing:inherit;line-height:1.38;margin-left:180pt;text-indent:36pt;margin=
-top:0pt;margin-bottom:0pt"><span style=3D"background-color:transparent"><s=
pan style=3D"color:rgb(0,0,0)"><b style=3D"box-sizing:inherit;font-weight:b=
older"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt">Pro=
s</span></span></b></span></span><br></p><p dir=3D"ltr" style=3D"box-sizing=
:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt=
"><span style=3D"background-color:transparent"><span style=3D"color:rgb(0,0=
,0)"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt">Using=
 the p2mos, one keeps private the information about the outputs until it ha=
s been spent, as well saving space into the block and makes the transaction=
s (without taking in account the witness data) </span></span></span></span>=
smaller<span style=3D"background-color:transparent"><span style=3D"color:rg=
b(0,0,0)"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt">=
, decreasing the data used for SPV nodes. We still have an input and an out=
put with explicit given values, that is useful for verifying the state of t=
he chain.=C2=A0</span></span></span></span></p><p dir=3D"ltr" style=3D"box-=
sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bott=
om:0pt"><span style=3D"background-color:transparent"><span style=3D"color:r=
gb(0,0,0)"><b style=3D"box-sizing:inherit;font-weight:bolder"><span style=
=3D"font-family:Arial"><span style=3D"font-size:11pt">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cons</span></span></b></span></span><br>=
</p><p dir=3D"ltr" style=3D"box-sizing:inherit;line-height:1.38;text-indent=
:36pt;margin-top:0pt;margin-bottom:0pt"><span style=3D"background-color:tra=
nsparent"><span style=3D"color:rgb(0,0,0)"><span style=3D"font-family:Arial=
"><span style=3D"font-size:11pt">Needs more coordination between the wallet=
s (this is a problem, especially with scenarios that one part is offline), =
is a bit more hard to compute for a validator, and would require some extra=
 bandwidth for downloading the witness data.</span></span></span></span><br=
></p><p dir=3D"ltr" style=3D"box-sizing:inherit;line-height:1.38;text-inden=
t:36pt;text-align:center;margin-top:0pt;margin-bottom:0pt"><span style=3D"b=
ackground-color:transparent"><span style=3D"color:rgb(0,0,0)"><b style=3D"b=
ox-sizing:inherit;font-weight:bolder"><span style=3D"font-family:Arial"><sp=
an style=3D"font-size:11pt">Retro Compatibility</span></span></b></span></s=
pan><br></p><p dir=3D"ltr" style=3D"box-sizing:inherit;line-height:1.38;tex=
t-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style=3D"background-c=
olor:transparent"><span style=3D"color:rgb(0,0,0)"><span style=3D"font-fami=
ly:Arial"><span style=3D"font-size:11pt">On one hand, old nodes that don=E2=
=80=99t follow the new consensus rule can accept this kind of transaction i=
f it=E2=80=99s made as a anyone can spend in the current consensus, but wit=
h other meanings in the new one(as segwit), but on the other hand, at a sec=
ond spend, the node will interpret it as double spend, hence invalidating i=
t. So the main problem with this approach is to implement it as a soft-fork=
.</span></span></span></span><br></p><p dir=3D"ltr" style=3D"box-sizing:inh=
erit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><s=
pan style=3D"background-color:transparent"><span style=3D"color:rgb(0,0,0)"=
><span style=3D"font-family:Arial"><span style=3D"font-size:11pt">I would l=
ike to receive any thoughts and considerations about this proposal. At the =
most, thank you very much. Sincerely, Jule Adka (<a href=3D"mailto:Jule.Adk=
a@protonmail.com" rel=3D"noreferrer nofollow noopener noreferrer" style=3D"=
box-sizing:inherit;background-color:transparent;color:rgb(147,151,205)" tar=
get=3D"_blank">Jule.Adka@protonmail.com</a>)</span></span></span></span><br=
></p><div style=3D"box-sizing:inherit"><br></div><p dir=3D"ltr" style=3D"bo=
x-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bo=
ttom:0pt"><span style=3D"background-color:transparent"><span style=3D"color=
:rgb(0,0,0)"><span style=3D"font-family:Arial"><span style=3D"font-size:11p=
t">[1]<span>=C2=A0</span></span></span></span></span><a href=3D"https://git=
hub.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel=3D"noreferrer nofo=
llow noopener noreferrer" style=3D"box-sizing:inherit;background-color:tran=
sparent;color:rgb(147,151,205);text-decoration:none" target=3D"_blank"><spa=
n style=3D"background-color:transparent"><span style=3D"color:rgb(17,85,204=
)"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt"><u styl=
e=3D"box-sizing:inherit">BIP141</u></span></span></span></span></a><span st=
yle=3D"background-color:transparent"><span style=3D"color:rgb(0,0,0)"><span=
 style=3D"font-family:Arial"><span style=3D"font-size:11pt">,=C2=A0 Segrega=
ted Witness</span></span></span></span><br></p><p dir=3D"ltr" style=3D"box-=
sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bott=
om:0pt">[2] ANTONOPOLOS, Andres. Mastering Bitcoin<br></p><div dir=3D"ltr" =
style=3D"box-sizing:inherit"><span style=3D"background-color:transparent"><=
span style=3D"color:rgb(0,0,0)"><span style=3D"font-family:Arial"><span sty=
le=3D"font-size:11pt">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [3] A 12-ou=
tput transaction in<span>=C2=A0</span></span></span></span></span><a href=
=3D"https://blockstream.info/tx/1bdde4ec3486ac67018727cfb4aa7fd84011db29bc0=
fdb525a810ad2ab1eb24d" rel=3D"noreferrer nofollow noopener noreferrer" styl=
e=3D"box-sizing:inherit;background-color:transparent;text-decoration:none" =
target=3D"_blank"><span style=3D"background-color:transparent"><span style=
=3D"color:rgb(17,85,204)"><span style=3D"font-family:Arial"><span style=3D"=
font-size:11pt"><u style=3D"box-sizing:inherit">blockstream.info</u></span>=
</span></span></span></a><span style=3D"background-color:transparent"><span=
 style=3D"color:rgb(0,0,0)"><span style=3D"font-family:Arial"><span style=
=3D"font-size:11pt">.</span></span></span></span><br></div><p dir=3D"ltr" s=
tyle=3D"box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt=
;margin-bottom:0pt"><span style=3D"background-color:transparent"><span styl=
e=3D"color:rgb(0,0,0)"><span style=3D"font-family:Arial"><span style=3D"fon=
t-size:11pt">[4] Privacy on<span>=C2=A0</span></span></span></span></span><=
a href=3D"https://en.bitcoin.it/wiki/Privacy" rel=3D"noreferrer nofollow no=
opener noreferrer" style=3D"box-sizing:inherit;background-color:transparent=
;color:rgb(147,151,205);text-decoration:none" target=3D"_blank"><span style=
=3D"background-color:transparent"><span style=3D"color:rgb(17,85,204)"><spa=
n style=3D"font-family:Arial"><span style=3D"font-size:11pt"><u style=3D"bo=
x-sizing:inherit">Bitcoin wiki</u></span></span></span></span></a><br></p><=
div style=3D"box-sizing:inherit"><br></div>________________________________=
_______________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000005dd2a605adb54e3b--