Gert-Jaap Glasbergen [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-10-30 to 2018-11-07
💬 Posted a total of 4 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:51:57

- reply

📅 Original date posted:2018-11-06
📝 Original message:
> On 6 Nov 2018, at 14:10, Christian Decker <decker.christian at gmail.com> wrote:
>
> It should be pointed out here that the dust rules actually prevent us
> from creating an output that is smaller than the dust limit (546
> satoshis on Bitcoin). By the same logic we would be forced to treat the
> dust limit as our atomic unit, and have transferred values and fees
> always be multiples of that dust limit.
I don’t follow the logic behind this. I can see how you can’t make outputs below dust, but not how every transferred value must be multiples of that. My minimum HTLC should be 546 - sure - but then I can also make HTLCs worth 547, 548? I don’t see how the next possible value transfer has to be 2*546. On single hop transfers it can be even possible to make a trustless payment of 1 satoshi, provided the protocol would allow to do this without an HTLC.
> 546 satoshis is by no means a tiny amount anymore, i.e., 546'000 times
> the current minimum fee and value transferred. I think we will have to
> deal with values that are not representable / enforceable on-chain
> anyway, so we might as well make things more flexible by keeping
> msatoshis.
I can see how this makes sense. If you deviate from the realms of what is possible to enforce on chain, you may as well take as much advantage as possible for the tradeoff you’ve chosen. So in that scenario (you are already departing from on-chain enforcement) msatoshi makes for much broader applicability. However, my argument would be that this departure should be a conscious choice.
Again, I am not advocating mandatory limitations to stay within base layer enforcement, I am advocating _not_ making it mandatory to depart from it.
> With a lot of choice comes great power, with great power comes great
> responsibility... uh I mean complexity :-) I'm all for giving users the
> freedom to chose what they feel comfortable with, but this freedom comes
> at a high cost and the protocol is very complex as it is. So we need to
> find the right configuration options, and I think not too many users
> will care about their unit of transfer, especially when it's handled
> automatically for them.
I would not envision this to be even configurable by end users. I am just advocating the options in the protocol so that an implementation can choose what security level it prefers.
Gert-Jaap

2023-06-09 12:51:57

- reply

📅 Original date posted:2018-11-07
📝 Original message:
> On 7 Nov 2018, at 12:01, Anthony Towns <aj at erisian.com.au> wrote:
>
> I don't think it quite makes sense either fwiw.
Glad it’s not just me :)
> What's enforcable on chain will vary though -- as fees rise, even if the
> network will still relay your 546 satoshi output, it may no longer be
> economical to claim it, so you might as well save fees by not including
> it in the first place.
I agree here, but there’s a provision in place to cope with this. People can define the minimum size of payments / channel balances they are willing to accept, in order to prevent producing dust or trimmed outputs. They can adhere to certain limits within their own control. If fees vary you can accept it’s current temporary nature and leave the channel in place for low tides, or if fees rise more structurally close channels and reopen them with higher limits. The key is that it’s in your control.
> Otherwise, if you're happy accepting 652 satoshis, I don't see why you
> wouldn't be happy accepting an off-chain balance of 652.003 satoshis;
> you're no worse off, in any event.
I wouldn’t be worse off when accepting the payment, I agree. I can safely ignore whatever fraction was sent if I don’t care about it anyway. The protocol is however expecting (if not demanding) me to also route payments with fractions, provided they are above the set minimum. In that case I’m also expected to send out fractions. Even though they don’t exist on-chain, if I send a fraction of a satoshi my new balance will be 1 satoshi lower on-chain since everything is rounded down.
If forwarding the payment is optional, then that technically gives me an out to implement my desired behaviour. But, I think it would be highly harmful to the reliability of the network if a client were to simply not route payments that don’t adhere to their (undocumented) requirements. It would be much more sensible for nodes to be made aware of those requirements, to prevent them from trying to route through channels in vain. That’s why I would prefer this to be part of the channel’s properties so everyone is aware.
> Everything in open source is configurable by end users: at worst, either
> by them changing the code, or by choosing which implementation to use…
Well, yes, in that sense it is. But the argument was made that it’s too complex for average users to understand: I agree there, but that’s no reason to not make the protocol support this choice. The fact that the end user shouldn’t be bothered with the choice doesn’t prohibit the protocol from supporting it.
Gert-Jaap.

2023-06-09 12:51:56

- reply

📅 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>