mimblewimble team mailing list archive

[praxeology_guy <praxeology_guy@xxxxxxxxxxxxxx>]

Questions on Transaction Size

Transaction size is important because network bandwidth is considered the most costly part of Bitcoin full verifying node operating costs. Hence Bitcoin's primary scaling problem for on-chain transactions is network bandwidth.

Given that block space must be limited to prevent complete centralization of mining (internet bandwidth is expensive): transaction size is inversely proportional to maximum transaction throughput.

I'm looking for some numbers on transaction size in MimbleWimble. It looks to me like MimbleWimble bandwidth requirements can probably be reduced if a user synchronizes with a less frequent period instead of live synchronization. But for now I'd like to focus on live synchronization bandwidth, which is what miners and some other important infrastructure will do.

Here:
https://www.reddit.com/r/Bitcoin/comments/4vub3y/mimblewimble_noninteractive_coinjoin_and_better/d64fd7n/
Andrew Poelstra said that a MimbleWimble transaction w/ CT style range proofs would have a size of 2.5kB.

I asked Andrew about it, and he replied that they are out of date, he needs to recompute, but the actual answer is of the same order of magnitude.

But... I don't want to make any assumptions about these numbers. I'd like to know specifically:

1. How many bytes must be transmitted in order to relay an unconfirmed transaction?
2. How many bytes must be transmitted in order to relay a confirmed transaction? (that doesn't benefit from the size reduction of a chain of unconfirmed tx being included in the same block)
3. What what would these sizes be if mimblewimble didn't use range proofs, instead let the amounts be public/anyone-can-read (like bitcoin transactions)?

I realize that #3 results in more privacy leak. But potentially there is a market need for a ledger that has this privacy leak, but is able to have significantly lower transaction fees. So I would like to know unconfirmed/confirmed tx relay size in this case as well.

Thanks,
Praxeology Guy

P.S. Merope07/Merope Riddle: Andrew asked me to forward this Bitcoin utxo merkle tree snapshot structure to you:
Bitcoin's utxo set can be pruned with a committed MMR data structure like:
https://petertodd.org/2016/delayed-txo-commitments
I later suggested a way it could be pruned without requiring wallets record adjacent utxos and either watching for their spend or brute force guessing which was spent (including spentness bits in the last non-pruned MMR node):
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013957.html