mimblewimble team mailing list archive

[Greg Sanders <gsanders87@xxxxxxxxx>]

With MW(and even mostly with Bitcoin), the cost of UTXO storage(and
rangeproof thereof) are likely the constraining resource factor in the long
run for use. Making sure users pay their way for that storage seems more
pertinent. Spending should be encouraged, as it literally makes MW
chainstate smaller.

On Wed, Dec 20, 2017 at 3:36 PM, Philbert Wallace <
philbertwallace4@xxxxxxxxx> wrote:

> So I see that grin also uses the concept of "block weight" similar to
> bitcoin. I'm curious though, has there been any thought into (further)
> reducing input weight according to how old the input is? Right now,
> regardless of the age of an input it has the same weight. *However, isn't
> it more reasonable, for example, that an input that is 1 day old would
> weigh much more than an input that is 1 year old?*
>
> The underlying motivation is: crypto networks, including grin, are new and
> they are going to take time to develop/adopt. We want patient and
> resourceful participants. Furthermore, on-chain transactions are akin to a
> global state changes and should be viewed as extremely precious/scarce. If
> a local state change is possible instead, people should prefer that method
> over a globally impactful one. We want to be attracting people that are in
> it for the "long haul" rather than just a "quick fix." If you're impatient
> and don't plan ahead it is/should be the most-expensive way to interact
> with the network. If, on the other hand, you're patient and/or plan a head
> (ie: use other layers whenever possible so as to not burden the main chain)
> you're rewarded with a lesser impact on blockweight (and thereby,
> essentially, cheaper fees) when you do need to utilize that input. To be
> clear, of course we would never prevent on-chain txs, this is merely about
> encouraging one type of behavior over another and keeping grin's mainchain
> clean and respected.
>
> There are a number of advantages I can think of if we did this:
>
> 1) This would encourage on-chain txs as a last resort (rather than a first
> resort) and rewards patience and forward thinking (ie: if you do an onchain
> transaction to someone and that someone turns right around and does another
> on-chain tx ... there is a chance that was the ONLY option, in which case
> fine, but there may also have been a way for the parties to cooperate to
> achieve the same end off-chain and perhaps it should always be cheaper for
> all parties to at least first investigate if it's possible to accomplish
> the goal off-chain and/or in another layer, such as lightning).
>
> 2) If inputs get cheaper to spend over time, this might provide a natural
> mechanism for at least some dust cleanup. Similarly, it gives some piece of
> mind to the hodlrs and rewards them for their patience and/or conversely
> punishes them (with more expensive fees) for being finicky. While it is a
> somewhat silly meme, I believe a growing cohort of hodlers are crucial to
> the success of any crypto network (in addition to all the other great
> features that grin brings to the table!).
>
> 3) One of the unknown issues with lightning, as far as I can tell, is that
> if channels are expensive to both open (and presumably also expensive to
> close), it's tough to justify the initial opening expense. However, this
> mechanism would encourage long-lived channels (nothing prevents short lived
> channels) since the longer a channel is open, the cheaper it would be to
> close. This is also a nice peace-of-mind aspect for channel participants.
> It allows them to feel more comfortable investing in the upfront cost of a)
> opening the channel and b) the due-diligence cost in determining whether
> the channel partner is someone/thing you'll likely transact with for a
> while.
>
> As far as implementation (ie: at what rate should inputs decay?), it seems
> reasonable to me that an input that is over a year old should "cost" (in
> block weight) a small fraction of an input which is only a couple minutes
> old. A smooth decay function may not even be necessary. If there is a
> particular threshold that we think is healthy, a simple stepwise function
> could do:
>
> input_weight = if( age > 1 year) then "1 unit" else "3 units"
> output_weight = "10 units"
>
> Though, of course, I prefer the cleanness of a more smooth decay :-)
>
> Thoughts?
>
> P.S. There are probably some downsides to this that I have not yet thought
> of, but wanted to at least get a discussion going and some feedback before
> investigating further.
>
> --
> Mailing list: https://launchpad.net/~mimblewimble
> Post to     : mimblewimble@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~mimblewimble
> More help   : https://help.launchpad.net/ListHelp
>
>