📅 Original date posted:2015-09-24
📝 Original message:
On Thu, Sep 24, 2015 at 03:17:41PM +0930, Rusty Russell wrote:
> 4) HTLC precision increase, ceiling drop.
> As a secondary effect, 32 bits places a ceiling of 0.04 satoshi
> (currently about $10USD) on each HTLC.
This means keeping the channel balances in 64 bit counters, right?
I was thinking along the following lines:
- bitcoin txns have absolute fees (currently f = 0.1 mBTC)
- lightning has percentage fees (call it p)
- so breakeven point is a transaction amount A, where
A * p = f; ie A = f/p
- p should be less than 2%, putting a lower limit on A of 5 mBTC,
but 0.04 BTC = 40 mBTC, which is well above that.
- if A = 0.04 BTC, p = f/A = 0.25%, putting a lower limit on lightning
fees (that's for the entire path, individual hops could be lower)
I probably would have preferred capping out at about 0.1 BTC (~$23),
corresponding to lightning fees of 0.1% matching bitcoin fees of 0.1 mBTC,
but that's quibbling.
Anyway, if you want to send more than $10 via lightning you just do
multiple transactions with different R values [0], the same way you
might use two $20 notes to pay someone $40. Even $1000 would just be
100 transactions, which doesn't seem like too big a deal?
Having a small maximum is probably also useful for routing -- if you want
to send two $10 notes, send them along different routes to avoid draining
any particular channel. That also helps obscure how much is being spent.
A maximum seems pretty helpful for planning how to fund a node too --
if you know no individual transaction will be more than 0.04 BTC, you
can setup your fee schedule in 0.04 BTC increments (or greater), and
not have to worry about "if i got 30 mBTC I'd raise my fee before the
next 30 mBTC came in; but here's 60 mBTC in one hop with just 2x the
lower fee! do I accept it or reject it?"
So, hey, turns out I totally endorse this change. +1.
Cheers,
aj
[0] or just rely on the different S values the R/S method for avoiding
onion probing would automatically use
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-09 12:44:41
in reply to nevent1q…t8aa
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-09 12:44:41Event JSON
{
"id": "78a5e70caabda9b131ed54cfd3637aaa5fd814a2518094b32df65512e3cdf722",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686314681,
"kind": 1,
"tags": [
[
"e",
"9128208f979ba16b9ae0be51d665e61e4d39f4748bd35992d09bb44edfaa05bc",
"",
"root"
],
[
"e",
"7c9634b943bcc6c94fab845e43b127ad900f3c0ed781d61522312d68fbe6892e",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-09-24\n📝 Original message:\nOn Thu, Sep 24, 2015 at 03:17:41PM +0930, Rusty Russell wrote:\n\u003e 4) HTLC precision increase, ceiling drop.\n\u003e As a secondary effect, 32 bits places a ceiling of 0.04 satoshi\n\u003e (currently about $10USD) on each HTLC.\n\nThis means keeping the channel balances in 64 bit counters, right?\n\nI was thinking along the following lines:\n\n - bitcoin txns have absolute fees (currently f = 0.1 mBTC)\n - lightning has percentage fees (call it p)\n - so breakeven point is a transaction amount A, where\n A * p = f; ie A = f/p\n - p should be less than 2%, putting a lower limit on A of 5 mBTC,\n but 0.04 BTC = 40 mBTC, which is well above that.\n - if A = 0.04 BTC, p = f/A = 0.25%, putting a lower limit on lightning\n fees (that's for the entire path, individual hops could be lower)\n\nI probably would have preferred capping out at about 0.1 BTC (~$23),\ncorresponding to lightning fees of 0.1% matching bitcoin fees of 0.1 mBTC,\nbut that's quibbling.\n\nAnyway, if you want to send more than $10 via lightning you just do\nmultiple transactions with different R values [0], the same way you\nmight use two $20 notes to pay someone $40. Even $1000 would just be\n100 transactions, which doesn't seem like too big a deal?\n\nHaving a small maximum is probably also useful for routing -- if you want\nto send two $10 notes, send them along different routes to avoid draining\nany particular channel. That also helps obscure how much is being spent.\n\nA maximum seems pretty helpful for planning how to fund a node too --\nif you know no individual transaction will be more than 0.04 BTC, you\ncan setup your fee schedule in 0.04 BTC increments (or greater), and\nnot have to worry about \"if i got 30 mBTC I'd raise my fee before the\nnext 30 mBTC came in; but here's 60 mBTC in one hop with just 2x the\nlower fee! do I accept it or reject it?\"\n\nSo, hey, turns out I totally endorse this change. +1.\n\nCheers,\naj\n\n[0] or just rely on the different S values the R/S method for avoiding\n onion probing would automatically use",
"sig": "a36351ffbff699ae2d73ba626672c8cde7871d4f763aa7101558a8d5dce0d917aaa163ae473c3c7e645a3f7d4412d2e5669f5b4684a20cc82813831b89fbf031"
}