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’s scalability, while > helping privacy. > > *Motivation* > > 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. > > 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 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. > > 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… > > 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. > > *An example* > > 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 > expendable 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. > > 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. > > 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. > > 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 of > 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 “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. > > 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. > > 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. > > *Pros* > > 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) 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, 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’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. > > 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 >