Great discussion!
What are the differences/similarities between MW & Lightning Network (LN)? I run a full BTC node and have been testing LN on Ubuntu/Windows/Docker. Is it just me, but I am totally dissatisfied with the way LN is so clunky and quite difficult to work with. I have experienced errors every time I try to do something. You would think that the amt of dev time devoted to this project, they would have arrived @ something more productive.... Tony C ________________________________ From: Mimblewimble <mimblewimble-bounces+ac89=buffalo....@lists.launchpad.net> on behalf of Philbert Wallace <philbertwalla...@gmail.com> Sent: Wednesday, December 20, 2017 4:58 PM To: Andrew Bellenie Cc: mimblewimble@lists.launchpad.net Subject: Re: [Mimblewimble] block weight decay for old inputs Apologies. I did not mean it to come off so opinionated. Ultimately a (collective) opinion is what the block weight concept itself enforces though isn't it? I don't see the harm in at least proposing slight modifications, if nothing else, as fodder for resolving future situations we (collectively) may find ourselves in. That being said, it's been brought to my attention that there are a number of costs that this concept adds to the complexity side of things and it is clear that (at least for now and the foreseeable future) that the perceived benefits, if there be any at all, may not outweigh the upfront complexity cost of a consensus level change like this. Thank you each for your thoughtful feedback. Grin is already on such a great path! On Dec 20, 2017 1:45 PM, "Andrew Bellenie" <andybelle...@gmail.com<mailto:andybelle...@gmail.com>> wrote: 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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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
