mimblewimble team mailing list archive

[Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx>]

By limiting the total number of UTXOs at every height, the fee market will
naturally make it costly to add extra UTXOs, which are the lingering burden
on historical block validators (it would be good to have a name for this;
it is not "pruning" because that word implies throwing away necessary data
and it is not necessarily "historical" because nodes can use this mode to
sync periodically, it's not just good for IBD).

It would be desirable to have only one parameter which is limited, "block
weight", which makes optimal transaction selection very easy for miners.
Unfortunately historical validators will see a different UTXO delta than
will real-time validators.

In particular, historical validators will see:
  - no inputs
  - some outputs, possibly all of them
  - all kernels

We require that any real-time valid blocks are also historically valid,
but not the other way around. It's clear that a blocksize limit is compatible
with this because the historical blocks have strictly lower size than do
real-time blocks. But the UTXO delta (#outputs - #inputs) will probably
increase.

A simple solution is for out input and output trees to be sumtrees over
the _counts_ of inputs and outputs. Real-time validators would check
these counts, historical ones would (partially) take them at face value,
and the block limit would be computed from that.


Then it's easy to define block weight as

  blocksize + W * (#outputs - #inputs)

where W is some number we haggle over. Importantly I think it needs to be
less than 32 because otherwise adding inputs would be free and would open
us up to DoS attacks. I propose 16 as a compromise.


Cheers
Andrew


On Sat, Sep 30, 2017 at 10:47:19PM -0400, Seamus Finnigan wrote:
> Hi,
> 
> Burning fees is in interesting idea. It's important to consider that fees help with miners sorting txs only if fees go (at least in part) to miners. A progressive burn rate, where the more transactions the higher the burned fees would make for an interesting fee market, somewhat like Monero's block reward penalty if you squint just right. That could allow sorting while preventing Garrick's concern about miners flooding blocks with their own superfluous transactions. I like the point that burning fees is an indirect way to reward holders, but I saw mention somewhere that it rewards full nodes, which I would argue is not true. There is no need to run a node to benefit from holding.
> 
> In any event, I thought one of the great breakthroughs of Mimblewimble was that there could in fact be transactions that effectively **reduce** the size of the blockchain by consuming more utxos than they create. I don't see any mention of this in this fee proposal, but it seems highly relevant. When fees are determined, are they based off their burden on an archival node or their burden on a fully validating node using MW's pruning? The second would seem more prudent, as archival nodes will archive for their own personal reasons, and that doesn't really have anything to do with the transaction's burden on the system. Perhaps it effects bandwidth as transactions are relayed, but that's not as big of a deal with Mimblewimble either given that transactions can be effectively folded into one another by any relay node in the network, meaning bandwidth is much less stressed (and truly complete archival nodes are much more difficult, if not impossible).
> 
> Mischief Managed,
> Seamus Finnigan
> 
> Sent with [ProtonMail](https://protonmail.com) Secure Email.

> -- 
> Mailing list: https://launchpad.net/~mimblewimble
> Post to     : mimblewimble@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~mimblewimble
> More help   : https://help.launchpad.net/ListHelp


-- 
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

"A goose alone, I suppose, can know the loneliness of geese
 who can never find their peace,
 whether north or south or west or east"
       --Joanna Newsom

Attachment: signature.asc
Description: PGP signature