📅 Original date posted:2018-05-12
📝 Original message:
Hi,
Maybe this is a stupid question, and it is late so maybe I'm
overlooking something, but I don't want to lose a potentially good
idea, so here it goes:
Right now, BOLT#3 imposes a certain algorithm for fee estimation. This
algorithm is likely to be sub-optimal: fee estimation is a difficult
subject, and may involve subjective situation-specific considerations
of participants. I guess it's only there to achieve some kind of
consensus between the peers.
But why do we need consensus at all? There are two versions of each
commitment transaction: one to be used for unilateral close by one peer
(A), and one to be used by the other (B). Peer A has an interest in
"commit transaction A", so I'd consider it fair to let peer A pay the
transaction fee for that commit tx (subtracted from its part of the
channel funds), and also to let peer A determine the amount of that
fee. If A wants a different fee for whatever reason, it should simply
be able to ask B for a signature on an updated "commit transaction A".
B shouldn't care about that fee, as long as its own funds, HTLCs etc.
are OK.
I guess, when only changing the fee, you don't even need to use a new
revocation secret. Your peer may have different versions which only
differ in how much fees your peer pays, and you 'll never care which of
them will be used by your peer. Not using a new revocation secret may
or may not be a premature optimization though.
If a peer doesn't have enough funds to pay a reasonably effective tx
fee, normally that shouldn't be a problem, because then it doesn't have
a significant financial interest in having a usable commit tx either.
The only exception is if there are significant HTLCs. Is this where the
idea breaks down? As far as I can see, this is an exceptional (but
important) case, but during normal operation, peers should be free to
choose the fee for their own commit tx.
You'd have to deal with any follow-up transactions as well: changing a
fee changes the txID, so you need to update follow-up transactions.
regards,
CJP
CJP [ARCHIVE] /
npub13q…cuzdm
2023-06-09 12:50:44
in reply to nevent1q…qtty
Author Public Key
npub13q863scgpsaanrjhfn7dd4h48lgnupgkcs828arzj4pckrq8hh6s4cuzdmPublished at
2023-06-09 12:50:44Event JSON
{
"id": "61c7e113c9ebb92e534b580798e24ac46fdd75302a6b7a8cca9065db156ab9eb",
"pubkey": "880fa8c3080c3bd98e574cfcd6d6f53fd13e0516c40ea3f46295438b0c07bdf5",
"created_at": 1686315044,
"kind": 1,
"tags": [
[
"e",
"629fcd5747647daa51d31f12b98ad8b5a7bfbf628448e9f5550a111a84baf829",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2018-05-12\n📝 Original message:\nHi,\n\nMaybe this is a stupid question, and it is late so maybe I'm\noverlooking something, but I don't want to lose a potentially good\nidea, so here it goes:\n\nRight now, BOLT#3 imposes a certain algorithm for fee estimation. This\nalgorithm is likely to be sub-optimal: fee estimation is a difficult\nsubject, and may involve subjective situation-specific considerations\nof participants. I guess it's only there to achieve some kind of\nconsensus between the peers.\n\nBut why do we need consensus at all? There are two versions of each\ncommitment transaction: one to be used for unilateral close by one peer\n(A), and one to be used by the other (B). Peer A has an interest in\n\"commit transaction A\", so I'd consider it fair to let peer A pay the\ntransaction fee for that commit tx (subtracted from its part of the\nchannel funds), and also to let peer A determine the amount of that\nfee. If A wants a different fee for whatever reason, it should simply\nbe able to ask B for a signature on an updated \"commit transaction A\".\nB shouldn't care about that fee, as long as its own funds, HTLCs etc.\nare OK.\n\nI guess, when only changing the fee, you don't even need to use a new\nrevocation secret. Your peer may have different versions which only\ndiffer in how much fees your peer pays, and you 'll never care which of\nthem will be used by your peer. Not using a new revocation secret may\nor may not be a premature optimization though.\n\nIf a peer doesn't have enough funds to pay a reasonably effective tx\nfee, normally that shouldn't be a problem, because then it doesn't have\na significant financial interest in having a usable commit tx either.\nThe only exception is if there are significant HTLCs. Is this where the\nidea breaks down? As far as I can see, this is an exceptional (but\nimportant) case, but during normal operation, peers should be free to\nchoose the fee for their own commit tx.\n\nYou'd have to deal with any follow-up transactions as well: changing a\nfee changes the txID, so you need to update follow-up transactions.\n\nregards,\nCJP",
"sig": "10e751d26c090cb0567c405d4627fe11acc89e570c30f224783b141a8de4d31be4eecc560ddd74ca4e7c71d1db904c1d7c41193153d090f3e6baace32ed7488d"
}