Andrea RASPITZU [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-13 📝 Original message: Good morning John-John, ...
📅 Original date posted:2019-03-13
📝 Original message:
Good morning John-John,
The current version of the spec uses source routing and that requires the
sending node to attach the fees to the payment when is sent out, if the
onion carries the wrong amount of fees for a channel the intermediate node
should reply with a channel_update message containing the actual fees. It
seems to me that you are binding the fees of a channel to its actual state
but that would require to re-broadcast a channel_update for every payment
that traverse the channel, so in short for every payment there would be an
update being gossiped on the network and that's unpractical.
Cheers, Andrea.
Le mer. 13 mars 2019 à 15:55, John-John Markstedt <john-john at markstedts.org>
a écrit :
> I’ve been thinking about the current fee structure I believe it may be
> problematic
> as there is no inherent way to incentive balanced channels.
>
> This may be a bit far down the road as there are more direct problems
> that need to be addressed first. However if you all believe there might be
> some
> merit in this line of thinking I can spend some more time formalizing a
> more proper
> implementable proposal and run some simulations to verify it’s impact on
> throughput
> and robustness.
>
> Although there are methods to balance channels it would be beneficial if
> the
> fee could reflect the state in which the channel is left.
>
> Currently the fee is only proportional to the liquidity used, not the
> state of the channel.
>
> Suppose there exists a channel between Alice and Bob with 10 million
> satoshis in it.
> Two payments, [image: P_{1}] and [image: P_{2}] are routed through the
> channel from Bob to Alice.
> Both use the same amount of liquidity, 3,500,000 satoshis each, but they
> start from
> two different initial states [image: B_{1}] and [image: B_3].
>
> [image: protocol_upgrade.png]
>
> The two payments would incur the same fee,
>
> [image: F_{P_1 P_2} = F_B + (3,500,000 * F_R / 1,000,000)]
>
> but leave the channels in completely different states.[image: P_1] at [image:
> B_2] and [image: P_2] at [image: B_4].
> It is of course possible to reset the channel price after [image: P_1] to
> be more expensive,
> but suppose a third larger payment [image: P_3] going from [image: B_1]
> to [image: B_4] would still run
> into this problem.
>
> It is possible to limit the maximum allowed payment, to say 1/5 of the
> total channel
> capacity, so a fee could be broadcast between payments. However
> that would reduce possible transacting parties in the network, limiting
> connectivity.
>
> If the price structure was a scheme of brackets instead, where the cost
> depend on the channel position, these issues may be resolved.
> Each satoshi in the channel may be seen as a different bracket, with a
> different price for each
> satoshi moved. The channels would then broadcast a cost function instead
> of the fixed fee.
>
> [image: fee_scheme.png]
>
> From the cost function the fee may be retrieved by calculating the area
> under the graphs.
> Some deterministic way to round the fee to whole satoshis and some way to
> verify the
> function is formulated correctly must be defined.
>
> The fees for [image: P_1], [image: P_2] would be very different with this
> brackets method.
>
> [image: F_{P_1} = F_{B} + \int_{B_1}^{B_2} f(x) dx = F_B + 13,502,153,930
> \mu S]
>
> [image: F_{P_2} = F_{B} + \int_{B_3}^{B_4} f(x) dx = F_B + 88,984,850,361
> \mu S]
>
> Here the fees are much larger for the payment that unbalances the channel
> than the
> payment that balances it.
>
> Brackets would incentivize payments to route in such a way to keep channels
> balanced which may lead to higher throughput.
>
> This method clearly has some headaches accompanying it. It may be
> unnecessarily complex and
> would requires deterministic ways to calculate integrals over multiple
> systems. There might be better
> ways to solve this problem and there might be problems with this approach
> I’m unaware of.
> Anyway, some small tweaks in the protocol may lead to a much healthier
> network which
> may be worthy of exploration.
>
> Best regards,
> John-John Markstedt
> _______________________________________________
> 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/20190313/2062da41/attachment.html>;
📝 Original message:
Good morning John-John,
The current version of the spec uses source routing and that requires the
sending node to attach the fees to the payment when is sent out, if the
onion carries the wrong amount of fees for a channel the intermediate node
should reply with a channel_update message containing the actual fees. It
seems to me that you are binding the fees of a channel to its actual state
but that would require to re-broadcast a channel_update for every payment
that traverse the channel, so in short for every payment there would be an
update being gossiped on the network and that's unpractical.
Cheers, Andrea.
Le mer. 13 mars 2019 à 15:55, John-John Markstedt <john-john at markstedts.org>
a écrit :
> I’ve been thinking about the current fee structure I believe it may be
> problematic
> as there is no inherent way to incentive balanced channels.
>
> This may be a bit far down the road as there are more direct problems
> that need to be addressed first. However if you all believe there might be
> some
> merit in this line of thinking I can spend some more time formalizing a
> more proper
> implementable proposal and run some simulations to verify it’s impact on
> throughput
> and robustness.
>
> Although there are methods to balance channels it would be beneficial if
> the
> fee could reflect the state in which the channel is left.
>
> Currently the fee is only proportional to the liquidity used, not the
> state of the channel.
>
> Suppose there exists a channel between Alice and Bob with 10 million
> satoshis in it.
> Two payments, [image: P_{1}] and [image: P_{2}] are routed through the
> channel from Bob to Alice.
> Both use the same amount of liquidity, 3,500,000 satoshis each, but they
> start from
> two different initial states [image: B_{1}] and [image: B_3].
>
> [image: protocol_upgrade.png]
>
> The two payments would incur the same fee,
>
> [image: F_{P_1 P_2} = F_B + (3,500,000 * F_R / 1,000,000)]
>
> but leave the channels in completely different states.[image: P_1] at [image:
> B_2] and [image: P_2] at [image: B_4].
> It is of course possible to reset the channel price after [image: P_1] to
> be more expensive,
> but suppose a third larger payment [image: P_3] going from [image: B_1]
> to [image: B_4] would still run
> into this problem.
>
> It is possible to limit the maximum allowed payment, to say 1/5 of the
> total channel
> capacity, so a fee could be broadcast between payments. However
> that would reduce possible transacting parties in the network, limiting
> connectivity.
>
> If the price structure was a scheme of brackets instead, where the cost
> depend on the channel position, these issues may be resolved.
> Each satoshi in the channel may be seen as a different bracket, with a
> different price for each
> satoshi moved. The channels would then broadcast a cost function instead
> of the fixed fee.
>
> [image: fee_scheme.png]
>
> From the cost function the fee may be retrieved by calculating the area
> under the graphs.
> Some deterministic way to round the fee to whole satoshis and some way to
> verify the
> function is formulated correctly must be defined.
>
> The fees for [image: P_1], [image: P_2] would be very different with this
> brackets method.
>
> [image: F_{P_1} = F_{B} + \int_{B_1}^{B_2} f(x) dx = F_B + 13,502,153,930
> \mu S]
>
> [image: F_{P_2} = F_{B} + \int_{B_3}^{B_4} f(x) dx = F_B + 88,984,850,361
> \mu S]
>
> Here the fees are much larger for the payment that unbalances the channel
> than the
> payment that balances it.
>
> Brackets would incentivize payments to route in such a way to keep channels
> balanced which may lead to higher throughput.
>
> This method clearly has some headaches accompanying it. It may be
> unnecessarily complex and
> would requires deterministic ways to calculate integrals over multiple
> systems. There might be better
> ways to solve this problem and there might be problems with this approach
> I’m unaware of.
> Anyway, some small tweaks in the protocol may lead to a much healthier
> network which
> may be worthy of exploration.
>
> Best regards,
> John-John Markstedt
> _______________________________________________
> 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/20190313/2062da41/attachment.html>;