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

[Jeremy <jlrubin@mit.edu>]

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

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*
> <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>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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