Gert-Jaap Glasbergen [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-05 📝 Original message: Op 1 nov. 2018 om 03:38 ...
📅 Original date posted:2018-11-05
📝 Original message:
Op 1 nov. 2018 om 03:38 heeft Rusty Russell <rusty at rustcorp.com.au<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181105/c2df9ec6/attachment.html>;
📝 Original message:
Op 1 nov. 2018 om 03:38 heeft Rusty Russell <rusty at rustcorp.com.au<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181105/c2df9ec6/attachment.html>;