📅 Original date posted:2015-09-24
📝 Original message:
Hi all,
So as was discussed last month [0] there's a potential incentive problem
if fees are only paid on success: you can lock up someone else's funds for
"TIMEOUT" and pay them nothing, just by routing a payment to someone who
won't either collect it, or redeem it. As an alternative to fines [1]
I think it's possible to offer fees directly for forwarding a transaction.
Suppose you have an onion wrapped routing message, and want to send N
bitcoins to Dave via Alice, Bob and Carol. Alice receives message MA,
Bob receives MB, etc. Alice wants "a" in fees, Bob wants "b" in fees,
etc. Then you setup HTLCs paying A as follows:
"c/2+n" bitcoins payable on receipt of R
"c/2+b/2" bitcoins payable on receipt of #(MD)
"b/2+a/2" bitcoins payable on receipt of #(MC)
"a/2" bitcoins payable on receipt of #(MB)
Alice forwards MB to Bob (encrypted), and asks if Bob is able to determine
what hashes to #(#(MB)). Bob calculates #(MB) and #(#(MB)) and gives an
ack or nak -- if there's a nak, Alice aborts the transaction. If it's
an ack, Bob begins updating the commitments to add (c/2+n), (c/2+b/2),
(b/2) HTLCs with Alice payable to Bob, and provides #(#(MB)) to Alice,
allowing her to collect the first half of her fee.
This then repeats for Bob/Carol and Carol/Dave.
This lets nodes get paid upfront (when they forward the transaction,
rather than when the transaction eventually completes), including for
failing transactions, but requires them to actually do 90% of the work
forwarding the transaction (Alice can abort accepting the HTLCs with
Bob, but Alice will miss out on half her fee, and Bob will know Alice
is cheating him out of "b" bitcoins at that point, and can close the
channel as punishment). It also gives the payer some progress information
on how the transaction is doing (the "a" transaction should be finished
shortly after the transaction has made it to Bob, etc).
Downsides: it's complicated and multiplies the number of HTLCs you have
to deal with, and it (at least somewhat) reveals the length of the route.
(If incremental fines work out, I think they're probably a better way
of dealing with delayed acceptance of transactions. Still, maybe this
turns out to be useful/interesting anyway...)
Cheers,
aj
[0] http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html
[1]
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000158.html
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-09 12:44:42
in reply to nevent1q…0a9u
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-09 12:44:42Event JSON
{
"id": "cf6d14df9c32efda3c71bfc9ea284610a21b8fa066f4f620b364da58818532e5",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686314682,
"kind": 1,
"tags": [
[
"e",
"4afdcc472a884961c57cb1478e7b0853d7fdcb0a633ba510a1d758ea7caaa293",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2015-09-24\n📝 Original message:\nHi all,\n\nSo as was discussed last month [0] there's a potential incentive problem\nif fees are only paid on success: you can lock up someone else's funds for\n\"TIMEOUT\" and pay them nothing, just by routing a payment to someone who\nwon't either collect it, or redeem it. As an alternative to fines [1]\nI think it's possible to offer fees directly for forwarding a transaction.\n\nSuppose you have an onion wrapped routing message, and want to send N\nbitcoins to Dave via Alice, Bob and Carol. Alice receives message MA,\nBob receives MB, etc. Alice wants \"a\" in fees, Bob wants \"b\" in fees,\netc. Then you setup HTLCs paying A as follows:\n\n \"c/2+n\" bitcoins payable on receipt of R\n \"c/2+b/2\" bitcoins payable on receipt of #(MD)\n \"b/2+a/2\" bitcoins payable on receipt of #(MC)\n \"a/2\" bitcoins payable on receipt of #(MB)\n\nAlice forwards MB to Bob (encrypted), and asks if Bob is able to determine\nwhat hashes to #(#(MB)). Bob calculates #(MB) and #(#(MB)) and gives an\nack or nak -- if there's a nak, Alice aborts the transaction. If it's\nan ack, Bob begins updating the commitments to add (c/2+n), (c/2+b/2),\n(b/2) HTLCs with Alice payable to Bob, and provides #(#(MB)) to Alice,\nallowing her to collect the first half of her fee.\n\nThis then repeats for Bob/Carol and Carol/Dave.\n\nThis lets nodes get paid upfront (when they forward the transaction,\nrather than when the transaction eventually completes), including for\nfailing transactions, but requires them to actually do 90% of the work\nforwarding the transaction (Alice can abort accepting the HTLCs with\nBob, but Alice will miss out on half her fee, and Bob will know Alice\nis cheating him out of \"b\" bitcoins at that point, and can close the\nchannel as punishment). It also gives the payer some progress information\non how the transaction is doing (the \"a\" transaction should be finished\nshortly after the transaction has made it to Bob, etc).\n\nDownsides: it's complicated and multiplies the number of HTLCs you have\nto deal with, and it (at least somewhat) reveals the length of the route.\n\n(If incremental fines work out, I think they're probably a better way\nof dealing with delayed acceptance of transactions. Still, maybe this\nturns out to be useful/interesting anyway...)\n\nCheers,\naj\n\n[0] http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html\n\n[1]\nhttp://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000158.html",
"sig": "06846ee1a48e9965d6cb1495991c1ccd36a02b4e30539807393c33ee6befd5fe8144a2a0615564ee0d1d7d64454941f228e90c54650a973fe21a4445f68521cd"
}