mimblewimble team mailing list archive

[Philbert Wallace <philbertwallace4@xxxxxxxxx>]

Greg,
Thank you for your quick reply. However, I do not see how that invalidates
anything I proposed. Spending IS still encouraged, even in what I proposed
since the discount of inputs versus outputs is still preserved (and thereby
putting some downward pressure on the UTXO set).

Either I'm missing something, or you're subtly suggesting that next-layer
solutions on top of grin should be avoided and literally everything should
be on-chain? Aren't there still some fundamental throughput transaction
limits and/or micropayment use cases that we would prefer to have in
channels/offchain?

On Wed, Dec 20, 2017 at 12:39 PM, Greg Sanders <gsanders87@xxxxxxxxx> wrote:

> 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
>>
>>
>