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 ([email protected])
[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
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
