From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id F1597C0051 for ; 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 ; 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 ; 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 ; 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 ; Tue, 25 Aug 2020 11:25:00 -0400 Received: by mail-ed1-f53.google.com with SMTP id f24so9291646edw.10 for ; 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 Date: Tue, 25 Aug 2020 08:24:46 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "Jule.Adka" , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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* > , > Segregated Witness > > [2] ANTONOPOLOS, Andres. Mastering Bitcoin > [3] A 12-output transaction in *blockstream.info* > > . > > [4] Privacy on *Bitcoin wiki* > > _______________________________________________ > 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
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.o= rg> wrote:
Hey, there! I have a new proposal to help Bitcoin=E2=80=99s sca= lability, while helping privacy.

Motivation

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.=

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.<= br>

<= span style=3D"font-size:11pt">Description

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.

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.

=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 <20-bytes-hash>), 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<= br>

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.=

An example

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 expendable 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 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.

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.

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=C2=A0= 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=C2=A032 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't change.=

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 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.

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.


Pro= s

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) = smaller= , 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

=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
=

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.

Retro Compatibility

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= .

I would l= ike to receive any thoughts and considerations about this proposal. At the = most, thank you very much. Sincerely, Jule Adka (Jule.Adka@protonmail.com)


[1]=C2=A0BIP141,=C2=A0 Segrega= ted Witness

[2] ANTONOPOLOS, Andres. Mastering Bitcoin

<= span style=3D"color:rgb(0,0,0)">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [3] A 12-ou= tput transaction in=C2=A0blockstream.info= .

[4] Privacy on=C2=A0<= 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">Bitcoin wiki

<= div style=3D"box-sizing:inherit">
________________________________= _______________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--0000000000005dd2a605adb54e3b--