[Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

Conner Fromknecht conner at lightning.engineering
Fri Nov 9 06:53:56 UTC 2018

> 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


-- Sent from my Spaceship

On Fri, Nov 9, 2018 at 17:19 alexis petropoulos <akexis823 at hotmail.com>

> How do i unsubscribe from this email list? Could someone help me please.
> Kindly,
> Alex
> ------------------------------
> *From:* lightning-dev-bounces at lists.linuxfoundation.org <
> lightning-dev-bounces at lists.linuxfoundation.org> on behalf of Gert-Jaap
> Glasbergen <gertjaap at gertjaap.nl>
> *Sent:* Monday, November 5, 2018 3:48:56 PM
> *To:* lightning-dev at 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 <rusty at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181109/c820dd77/attachment-0001.html>

More information about the Lightning-dev mailing list