📅 Original date posted:2015-07-14
📝 Original message:
>I like to think of fees in the same way as we pay for Internet access.
>Every physical hop in the Internet has related costs, e.g. in placing
>the cables and upgrading the cables when new technology becomes
>available and when demand grows.
What sort of fee would this be? A percentage fee? A per-transaction fee? Both?
I can see a compelling case for any of the three.
On Tue, Jul 14, 2015 at 12:54 PM, CJP <cjp at ultimatestunts.nl> wrote:
>
>> Fees are a real issue. Without source routing the client is guessing
>> how much fees will be, and there'll be a lot of gaming to decide how
>> much of the pie to take (take too much, you get none as payment fails to
>> route). I think you'll end up asking your provider how you should to
>> pay, and that's a pretty horrible model for privacy.
>>
>> With source routing and onion it's a little better; you can explicitly
>> state what each hop gets. Of course, if your route/payment information
>> is out of date you lose, too.
>
> I like to think of fees in the same way as we pay for Internet access.
> Every physical hop in the Internet has related costs, e.g. in placing
> the cables and upgrading the cables when new technology becomes
> available and when demand grows. Yet it doesn't matter for your Internet
> bill how many hops your packets make, or which route they follow. Your
> ISP will just average out all the costs it has to make on its
> interfaces, and present a fraction of that to each customer. At some
> points in the middle between providers, there are places where both
> sides have an equal interest in maintaining their link, and no fees are
> charged.
>
> One major difference with the Internet is that we already have a
> micro-transaction infrastructure in place, which is something the
> Internet has never had (until now). This means it is possible to do
> instant per-transaction payment of transaction fees. The fact that we
> CAN do it doesn't mean we SHOULD, but I think there are advantages:
> non-immediate payment models always require some form of trust from at
> least one of the sides. Immediate payment of a transaction fee is as
> simple as updating the micro-transaction channel with a slightly larger
> amount than the to-be-forwarded transaction amount.
>
> An interesting question is whether nodes will be prepared to forward
> payments at a net loss (the to-be-paid fee is higher than the
> to-be-received fee); maybe they will, if they can compensate the losses
> with higher profits on other transactions. Fee differences could play a
> role in routing decisions.
>
> That brings me to another point: fees could be used as a way to
> incentivize people to bring channels back to equilibrium. When a
> channel's funds are almost fully assigned to one of its sides, further
> payments towards that side become nearly impossible. Increasing fees in
> that direction and decreasing fees in the opposite direction should
> incentivize people to perform more transactions that bring the channel
> back to equilibrium, and to perform less transactions that bring it
> further out of equilibrium, or find alternative routes for those
> transactions.
>
> You could even offer negative fees for transactions that bring a channel
> back to equilibrium. There could be a market for people making money
> from bringing other peoples' channels back to equilibrium. This would
> require either to step away from "net neutrality" (so, not the same fee
> for every route / destination), or it would require some form of source
> routing and explicitly setting the fees of intermediate nodes.
>
> My "neutral meeting point" routing design, which is effectively a
> two-hop source routing, is already good enough: a node in the middle of
> the network is advertising that it can benefit from a negative fee, and
> it invites people to perform transactions and to share the profit. It
> creates two routable addresses (one for the negative-fee interface (A)
> and one for all other interfaces (B)). Other people can then perform a
> payment-to-self, with payee side routing to A and payer-side routing to
> B. Payee-side can then have a larger payment amount than payer-side, as
> agreed with the meeting point, to transfer a part of the profit to the
> person performing the transaction.
>
> CJP
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Nick ODell [ARCHIVE] /
npub192…qwur0
2023-06-09 12:43:33
in reply to nevent1q…jhwz
Author Public Key
npub192dh6dprqsvsrdeche436s9xunwnlyzpu7jl5j3d83nz62tgznrsnqwur0Published at
2023-06-09 12:43:33Event JSON
{
"id": "91dbc00024f8d7c97bf43ae978cfdc6a8a302ab172daf917b363f8c3e89d14f6",
"pubkey": "2a9b7d3423041901b738be6b1d40a6e4dd3f9041e7a5fa4a2d3c662d296814c7",
"created_at": 1686314613,
"kind": 1,
"tags": [
[
"e",
"b051b897d36d9747c0a2ead17e2be0eb4114a547258d74b54d7d8da5c672c214",
"",
"root"
],
[
"e",
"7ae00265e7b7721504a45cc5f0416d7e1ffee58e972dbfd020b2f6671bc2ba91",
"",
"reply"
],
[
"p",
"880fa8c3080c3bd98e574cfcd6d6f53fd13e0516c40ea3f46295438b0c07bdf5"
]
],
"content": "📅 Original date posted:2015-07-14\n📝 Original message:\n\u003eI like to think of fees in the same way as we pay for Internet access.\n\u003eEvery physical hop in the Internet has related costs, e.g. in placing\n\u003ethe cables and upgrading the cables when new technology becomes\n\u003eavailable and when demand grows.\n\nWhat sort of fee would this be? A percentage fee? A per-transaction fee? Both?\n\nI can see a compelling case for any of the three.\n\nOn Tue, Jul 14, 2015 at 12:54 PM, CJP \u003ccjp at ultimatestunts.nl\u003e wrote:\n\u003e\n\u003e\u003e Fees are a real issue. Without source routing the client is guessing\n\u003e\u003e how much fees will be, and there'll be a lot of gaming to decide how\n\u003e\u003e much of the pie to take (take too much, you get none as payment fails to\n\u003e\u003e route). I think you'll end up asking your provider how you should to\n\u003e\u003e pay, and that's a pretty horrible model for privacy.\n\u003e\u003e\n\u003e\u003e With source routing and onion it's a little better; you can explicitly\n\u003e\u003e state what each hop gets. Of course, if your route/payment information\n\u003e\u003e is out of date you lose, too.\n\u003e\n\u003e I like to think of fees in the same way as we pay for Internet access.\n\u003e Every physical hop in the Internet has related costs, e.g. in placing\n\u003e the cables and upgrading the cables when new technology becomes\n\u003e available and when demand grows. Yet it doesn't matter for your Internet\n\u003e bill how many hops your packets make, or which route they follow. Your\n\u003e ISP will just average out all the costs it has to make on its\n\u003e interfaces, and present a fraction of that to each customer. At some\n\u003e points in the middle between providers, there are places where both\n\u003e sides have an equal interest in maintaining their link, and no fees are\n\u003e charged.\n\u003e\n\u003e One major difference with the Internet is that we already have a\n\u003e micro-transaction infrastructure in place, which is something the\n\u003e Internet has never had (until now). This means it is possible to do\n\u003e instant per-transaction payment of transaction fees. The fact that we\n\u003e CAN do it doesn't mean we SHOULD, but I think there are advantages:\n\u003e non-immediate payment models always require some form of trust from at\n\u003e least one of the sides. Immediate payment of a transaction fee is as\n\u003e simple as updating the micro-transaction channel with a slightly larger\n\u003e amount than the to-be-forwarded transaction amount.\n\u003e\n\u003e An interesting question is whether nodes will be prepared to forward\n\u003e payments at a net loss (the to-be-paid fee is higher than the\n\u003e to-be-received fee); maybe they will, if they can compensate the losses\n\u003e with higher profits on other transactions. Fee differences could play a\n\u003e role in routing decisions.\n\u003e\n\u003e That brings me to another point: fees could be used as a way to\n\u003e incentivize people to bring channels back to equilibrium. When a\n\u003e channel's funds are almost fully assigned to one of its sides, further\n\u003e payments towards that side become nearly impossible. Increasing fees in\n\u003e that direction and decreasing fees in the opposite direction should\n\u003e incentivize people to perform more transactions that bring the channel\n\u003e back to equilibrium, and to perform less transactions that bring it\n\u003e further out of equilibrium, or find alternative routes for those\n\u003e transactions.\n\u003e\n\u003e You could even offer negative fees for transactions that bring a channel\n\u003e back to equilibrium. There could be a market for people making money\n\u003e from bringing other peoples' channels back to equilibrium. This would\n\u003e require either to step away from \"net neutrality\" (so, not the same fee\n\u003e for every route / destination), or it would require some form of source\n\u003e routing and explicitly setting the fees of intermediate nodes.\n\u003e\n\u003e My \"neutral meeting point\" routing design, which is effectively a\n\u003e two-hop source routing, is already good enough: a node in the middle of\n\u003e the network is advertising that it can benefit from a negative fee, and\n\u003e it invites people to perform transactions and to share the profit. It\n\u003e creates two routable addresses (one for the negative-fee interface (A)\n\u003e and one for all other interfaces (B)). Other people can then perform a\n\u003e payment-to-self, with payee side routing to A and payer-side routing to\n\u003e B. Payee-side can then have a larger payment amount than payer-side, as\n\u003e agreed with the meeting point, to transfer a part of the profit to the\n\u003e person performing the transaction.\n\u003e\n\u003e CJP\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "633b73fd344179b7c96cef2d956f75b0a8b92bf36d2bbef274736f44cd5db155f013da549ad8778da6e40bd933e2f6ddc2670f642e67517ffd5427435c249440"
}