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