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
--
Mailing list: https://launchpad.net/~mimblewimble
Post to : [email protected]
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp
