<div dir="auto">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 <a href="https://utxos.org">https://utxos.org</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 25, 2020, 6:48 AM Jule.Adka via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="box-sizing:inherit"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">Hey, there! I have a new proposal to help Bitcoin’s scalability, while helping privacy.</span></span></span></span><br></div><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;text-align:center;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><b style="box-sizing:inherit;font-weight:bolder"><span style="font-family:Arial"><span style="font-size:11pt">Motivation</span></span></b></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">All transactions in the Bitcoin’s 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 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 data 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="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">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.</span></span></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;text-align:center;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><b style="box-sizing:inherit;font-weight:bolder"><span style="font-family:Arial"><span style="font-size:11pt">Description</span></span></b></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">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.</span></span></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">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 for transactions in a unique block, without increasing it’s actual size. As well, decrease the UTXO’s size, taking less resource from validators node.</span></span></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt"> An ordinary(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_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 script data, 49 in the total. 10 bytes more than an ordinary transaction with one output. But usually the transactions have 2 outputs (the actual payment and 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…</span></span></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">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 the 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 the privacy troubles associated with outputs, like Equal-output CoinJoin and different outputs types[4] are solved.</span></span></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;text-align:center;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt"><b>An example</b></span></span></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">When Alice’s wallet create a transaction, sending 5 bitcoins to Bob 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’s wallet create the invoice to be paid by Alice, he gives an output to Alice and she adds it together into a Merkle Tree, takes the root and build a transaction paying to this hash. Alice’s wallet then sends a path into the tree to prove to Bob that his output is really into a transaction and is fully </span></span></span></span>expendable<span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt"> from Bob’s wallet. Bob now looks for the mempool (and the chain, of course) to find transactions that pay to the given Markle Root.</span></span></span></span></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">Now let’s 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 “actual output” means the output that keeps hidden from the world until Bob spends it). After checking if Bob’s output really exists, an node can evaluate it exactly in the same way as ordinary transactions, the output will look like any other.</span></span></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">Alice’s 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 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></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">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<span> </span></span></span></span></span><span style="background-color:rgb(255,255,255)"><span style="color:rgb(34,34,34)"><span style="font-family:Arial"><span style="font-size:10.5pt">Merkelized output set), instructing the node to look at the witness data in order to find the actual output. So, we have 1 byte of opcode and<span> </span></span></span></span></span><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">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.</span></span></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">The amount also is helpful to determine whether the UTXO still have any locked coins, if the total “removed” 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’s set. If one tries to retrieve more than it’s actually locked in, it fails.</span></span></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">Let’s 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’t 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 wallets must verify the values.</span></span></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">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 tree are made by the hash(sigscript || 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="box-sizing:inherit"><br></div><p dir="ltr" style="box-sizing:inherit;line-height:1.38;margin-left:180pt;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><b style="box-sizing:inherit;font-weight:bolder"><span style="font-family:Arial"><span style="font-size:11pt">Pros</span></span></b></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">Using the p2mos, one keeps private the information about the outputs until it has been spent, as well saving space into the block and makes the transactions (without taking in account the witness data) </span></span></span></span>smaller<span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">, 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. </span></span></span></span></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><b style="box-sizing:inherit;font-weight:bolder"><span style="font-family:Arial"><span style="font-size:11pt"> Cons</span></span></b></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">Needs more coordination between the wallets (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="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;text-align:center;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><b style="box-sizing:inherit;font-weight:bolder"><span style="font-family:Arial"><span style="font-size:11pt">Retro Compatibility</span></span></b></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">On one hand, old nodes that don’t follow the new consensus rule can accept this kind of transaction if it’s made as a anyone can spend in the 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.</span></span></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">I would like to receive any thoughts and considerations about this proposal. At the most, thank you very much. Sincerely, Jule Adka (<a href="mailto:Jule.Adka@protonmail.com" rel="noreferrer nofollow noopener noreferrer" style="box-sizing:inherit;background-color:transparent;color:rgb(147,151,205)" target="_blank">Jule.Adka@protonmail.com</a>)</span></span></span></span><br></p><div style="box-sizing:inherit"><br></div><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">[1]<span> </span></span></span></span></span><a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="noreferrer nofollow noopener noreferrer" style="box-sizing:inherit;background-color:transparent;color:rgb(147,151,205);text-decoration:none" target="_blank"><span style="background-color:transparent"><span style="color:rgb(17,85,204)"><span style="font-family:Arial"><span style="font-size:11pt"><u style="box-sizing:inherit">BIP141</u></span></span></span></span></a><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">, Segregated Witness</span></span></span></span><br></p><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt">[2] ANTONOPOLOS, Andres. Mastering Bitcoin<br></p><div dir="ltr" style="box-sizing:inherit"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt"> [3] A 12-output transaction in<span> </span></span></span></span></span><a href="https://blockstream.info/tx/1bdde4ec3486ac67018727cfb4aa7fd84011db29bc0fdb525a810ad2ab1eb24d" rel="noreferrer nofollow noopener noreferrer" style="box-sizing:inherit;background-color:transparent;text-decoration:none" target="_blank"><span style="background-color:transparent"><span style="color:rgb(17,85,204)"><span style="font-family:Arial"><span style="font-size:11pt"><u style="box-sizing:inherit">blockstream.info</u></span></span></span></span></a><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">.</span></span></span></span><br></div><p dir="ltr" style="box-sizing:inherit;line-height:1.38;text-indent:36pt;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent"><span style="color:rgb(0,0,0)"><span style="font-family:Arial"><span style="font-size:11pt">[4] Privacy on<span> </span></span></span></span></span><a href="https://en.bitcoin.it/wiki/Privacy" rel="noreferrer nofollow noopener noreferrer" style="box-sizing:inherit;background-color:transparent;color:rgb(147,151,205);text-decoration:none" target="_blank"><span style="background-color:transparent"><span style="color:rgb(17,85,204)"><span style="font-family:Arial"><span style="font-size:11pt"><u style="box-sizing:inherit">Bitcoin wiki</u></span></span></span></span></a><br></p><div style="box-sizing:inherit"><br></div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" rel="noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>