{"type":"rich","version":"1.0","author_name":"npub1sprhp66c693av0c0n9had046hcdcckp2th25fnmphwstc5e4wg9qxs64t2","author_url":"https://nostr.ae/npub1sprhp66c693av0c0n9had046hcdcckp2th25fnmphwstc5e4wg9qxs64t2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-08-15\n📝 Original message:\nThe field of economics has done much work over the past few decades\ndemonstrating that “Free” is problematic in practice because humans will go\nout of their way to externalize costs elsewhere (e.g. time, in the case of\nlightning), given the promise of freedom. In other words, actors often act\nirrationally to get a free deal.\n\nAs protocol designers, it would be remiss to ignore this (repeatedly\ndemonstrated) truth.\n\nTo avoid this, we’ve been suggesting setting a min_htlc_value requirement.\nThe problem with zbf + a min_htlc size requirement is that it makes tiny\npayments impossible over lightning, which was one of the original design\ngoals of the system, and is an important feature to keep/support as\nlightning grows into poorer economic bases and the bitcoin market price\ncontinues to rise.\n\nMy suggestion would be that, as a compromise, we set a network wide minimum\nfee at the protocol level of 1msat. Naively, this seems it should be easy\nto add to calculations using single-dimension optimization (or trivial\nenough to ignore entirely), it removes the “free lunch” irrationality\nhoneypot zbf opens, and it provides a way forward for the continued use of\nmicropayments.\n\nThe result is that micropayments have a different payment regime than\n“non-micropayments”, (which may still incentive almost irrational behavior)\nbut at least there’s no *loss* felt by node operators for\nhandling/supporting low value payments. 10k micropayments is worth 10sats.\n\nIt’s also simple to implement and seems rather obvious in retrospect.\n\nThe only confounding future change that I can see us making would be the\nintroduction of negative fees, which are useful as a way to induce payments\nto rebalance channels passively. This seems like something we can revisit\nonce a proposal for negative fees is being seriously considered, however.\n\nOn Sun, Aug 15, 2021 at 05:59 ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning aj, et al.\n\u003e\n\u003e \u003e Hey *,\n\u003e \u003e\n\u003e \u003e There's been discussions on twitter and elsewhere advocating for\n\u003e \u003e setting the BOLT#7 fee_base_msat value [0] to zero. I'm just writing\n\u003e \u003e this to summarise my understanding in a place that's able to easily be\n\u003e \u003e referenced later.\n\u003e \u003e\n\u003e \u003e Setting the base fee to zero has a couple of benefits:\n\u003e \u003e\n\u003e \u003e -   it means you only have one value to optimise when trying to collect\n\u003e \u003e     the most fees, and one-dimensional optimisation problems are\n\u003e \u003e     obviously easier to write code for than two-dimensional optimisation\n\u003e \u003e     problems\n\u003e\n\u003e Indeed, this is a good point regarding this.\n\u003e\n\u003e\n\u003e \u003e -   when finding a route, if all the fees on all the channels are\n\u003e \u003e     proportional only, you'll never have to worry about paying more fees\n\u003e \u003e     just as a result of splitting a payment; that makes routing easier\n\u003e \u003e     (see [1])\n\u003e\n\u003e If we neglect roundoff errors.\n\u003e\n\u003e On the other hand, roundoff errors involved are \u003c1msat per split, so it\n\u003e probably will not matter to most people.\n\u003e\n\u003e \u003e     So what's the cost? The cost is that there's no longer a fixed\n\u003e minimum\n\u003e \u003e     fee -- so if you try sending a 1sat payment you'll pay 0.1% of the\n\u003e fee\n\u003e \u003e     to send a 1000sat payment, and there may be fixed costs that you have\n\u003e \u003e     in routing payments that you'd like to be compensated for (eg, the\n\u003e \u003e     computational work to update channel state, the bandwith to forward\n\u003e the\n\u003e \u003e     tx, or the opportunity cost for not being able to accept another\n\u003e htlc if\n\u003e \u003e     you've hit your max htlcs per channel limit).\n\u003e \u003e\n\u003e \u003e     But there's no need to explicitly separate those costs the way we do\n\u003e \u003e     now; instead of charging 1sat base fee and 0.02% proportional fee,\n\u003e \u003e     you can instead just set the 0.02% proportional fee and have a\n\u003e minimum\n\u003e \u003e     payment size of 5000 sats (htlc_minimum_msat=5e6, ~$2), since 0.02%\n\u003e \u003e     of that is 1sat. Nobody will be asking you to route without offering\n\u003e a\n\u003e \u003e     fee of at least 1sat, but all the optimisation steps are easier.\n\u003e\n\u003e Should this minimum a node will be willing to forward be part of gossip,\n\u003e and how does this affect routing algorithms?\n\u003e\n\u003e \u003e     You could go a step further, and have the node side accept smaller\n\u003e \u003e     payments despite the htlc minimum setting: eg, accept a 3000 sat\n\u003e payment\n\u003e \u003e     provided it pays the same fee that a 5000 sat payment would have.\n\u003e That is,\n\u003e \u003e     treat the setting as minimum_fee=1sat, rather than\n\u003e minimum_amount=5000sat;\n\u003e \u003e     so the advertised value is just calculated from the real settings,\n\u003e \u003e     and that nodes that want to send very small values despite having to\n\u003e \u003e     pay high rates can just invert the calculation.\n\u003e\n\u003e I like this idea, as I think it matches more what the incentives are.\n\u003e But it requires a change in gossip and in routing algorithms, and more\n\u003e importantly it requires routing algorithms to support two different fee\n\u003e schemes (base + proportional vs min + proportional).\n\u003e\n\u003e On the other hand, this still is a two-dimensional optimization algorithm,\n\u003e with `minimum_fee` and `proportional_fee_millionths` as the two dimensions.\n\u003e So maybe just have a single proportional-fee mechanism...\n\u003e\n\u003e \u003e\n\u003e \u003e     I think something like this approach also makes sense when your\n\u003e channel\n\u003e \u003e     becomes overloaded; eg if you have x HTLC slots available, and y\n\u003e channel\n\u003e \u003e     capacity available, setting a minimum payment size of something like\n\u003e \u003e     y/2/x**2 allows you to accept small payments (good for the network)\n\u003e \u003e     when you're channel is not busy, but reserves the last slots for\n\u003e larger\n\u003e \u003e     payments so that you don't end up missing out on profits because you\n\u003e \u003e     ran out of capacity due to low value spam.\n\u003e \u003e\n\u003e \u003e     Two other aspects related to this:\n\u003e \u003e\n\u003e \u003e     At present, I think all the fixed costs are also incurred even when\n\u003e \u003e     a htlc fails, so until we have some way of charging failing txs for\n\u003e \u003e     incurring those costs, it seems a bit backwards to penalise\n\u003e successful\n\u003e \u003e     txs who at least pay a proportional fee for the same thing. Until\n\u003e we've\n\u003e \u003e     got a way of handling that, having zero base fee seems at least fair.\n\u003e\n\u003e Yes, the dreaded mechanism against payment lockup, which as far as I\n\u003e understand has a lot of thought already sunk into it without any\n\u003e widely-accepted solution, sigh.\n\u003e\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210815/cb1c33c6/attachment.html\u003e"}