[bitcoin-dev] New tipe of outputs that saves space and give more privacy

["Jule.Adka" <Jule.Adka@protonmail.com>]

[-- Attachment #1: Type: text/plain, Size: 8014 bytes --]

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 toMerkelized 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 and32 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](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/1bdde4ec3486ac67018727cfb4aa7fd84011db29bc0fdb525a810ad2ab1eb24d).

[4] Privacy on[Bitcoin wiki](https://en.bitcoin.it/wiki/Privacy)

[-- Attachment #2: Type: text/html, Size: 18995 bytes --]