> How do i unsubscribe from this email list? Could someone help me please.
There’s a link in the footer to the linux list, there you can enter your email to unsubscribe Cheers, Conner -- Sent from my Spaceship On Fri, Nov 9, 2018 at 17:19 alexis petropoulos <akexis...@hotmail.com> wrote: > How do i unsubscribe from this email list? Could someone help me please. > > Kindly, > > Alex > ------------------------------ > *From:* lightning-dev-boun...@lists.linuxfoundation.org < > lightning-dev-boun...@lists.linuxfoundation.org> on behalf of Gert-Jaap > Glasbergen <gertj...@gertjaap.nl> > *Sent:* Monday, November 5, 2018 3:48:56 PM > *To:* lightning-dev@lists.linuxfoundation.org; Rusty Russell > *Subject:* Re: [Lightning-dev] RFC: simplifications and suggestions on > open/accept limits. > > > Op 1 nov. 2018 om 03:38 heeft Rusty Russell <ru...@rustcorp.com.au> het > volgende geschreven: > > > I believe this would render you inoperable in practice; fees are > frequently sub-satoshi, so you would fail everything. The entire > network would have to drop millisatoshis, and the bitcoin maximalist in > me thinks that's unwise :) > > > I can see how not wanting to use millisatoshis makes you less compatible > with other people that do prefer using that unit of account. But in this > case I think it's important to allow the freedom to choose. > > I essentially feel we should be allowed to respect the confines of the layer > we're building upon. There's already a lot of benefits to achieve from second > layer scaling whilst still respecting the limits of the base layer. Staying > within those limits means optimally benefit form the security it offers. > > Essentially by allowing to keep satoshi as the smallest fraction, you ensure > that everything you do off-chain is also valid and enforced by the chain when > you need it to. It comes at trade offs though: it would mean that if someone > routes your payment, you can only pay fees in whole satoshis - essentially > meaning if someone wants to charge a (small) fee, you will be overpaying to > stay within your chosen security parameters. Which is a consequence of your > choice. > > I would be happy to make a further analysis on what consequences allowing this > choice would have for the specification, and come up with a proposal on how to > add support for this. But I guess this discussion is meant to "test the > waters" > to see how much potential such a proposal would have to eventually be > included. > > I guess what I'm searching for is a way to achieve the freedom of choice, > without negatively impacting other clients or users that decide to accept some > level of trust. In my view, this would be possible - but I think working it > out > in a concrete proposal/RFC to the spec would be a logical next step. > > Gert-Jaap > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
