mimblewimble team mailing list archive

[Andrew Bellenie <andybellenie@xxxxxxxxx>]

I don't agree with opinionated approaches dictating how people 'should' use
a blockchain. What you are proposing is effectively a transaction tax which
will discourage use of the blockchain for its primary purpose, transacting.

A fee market already incentivises people to use off-chain transactions
wherever it is economically appropriate.

Unless I'm mistaken, grin will do dust cleanup easily with cut-through. A
properly designed wallet should do this by default.

Andrew B


On 20 December 2017 at 20:54, Philbert Wallace <philbertwallace4@xxxxxxxxx>
wrote:

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