📅 Original date posted:2021-06-15
📝 Original message:On Tue, 15 Jun 2021 at 10:59, Lloyd Fournier <lloyd.fourn at gmail.com> wrote:
>
>
> On Tue, 15 Jun 2021 at 02:47, Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> > This makes a lot of sense as it matches the semantics of what we are
>> trying
>> to achieve: allow the owner of an output (whether an individual or group)
>> to reduce that output's value to pay a higher fee.
>>
>> Note, I think you're still struggling with some trust issue that anchor
>> upgrade is at least eliminating for LN, namely the pre-agreement among a
>> group of signers about the effective feerate to use at some unknown time
>> point in the future. If you authorize your counterparty for a broadcast at
>> feerate X, how do you prevent a broadcast at feerate Y, where Y is far
>> under X, thus maliciously burning a lot of your fee-bumping reserve ?
>>
>> Of course, one mitigation is to make a contribution to a common
>> fee-bumping output reserve proportional to what has been contributed as a
>> funding collateral. Thus disincentivizing misuse of the common fee-bumping
>> reserve in a game-theoretical way. But if you take the example of a LN
>> channel, you're now running into another issue. Off-chain balances might
>> fluctuate in a way that most of the time, your fee-bumping reserve
>> contribution is out-of-proportion with your balance amounts to protect ?
>> And as such enduring some significant timevalue bleeding on your
>> fee-bumping reserve.
>>
>> Single-party managed fee-bumping reserve doesn't seem to suffer from this
>> drawback ?
>>
>
> I claim that what I am suggesting is a single-party managed fee-bumping
> system that solves all fee-bumping requirements of lightning without
> needing external utxos and without additional interaction or fee
> pre-agreement between parties. On the commit tx you have your balance going
> exclusively towards you which you can unilaterally reduce to increase the
> fee up to whatever threshold you want. With a HTLC or PTLC you also always
> have a tx with an output that you can unilaterally drain to bump fee
> (either the hltc-success or htlc-timeout). Are you saying that there are
> protocols where this would require pre-arrangement or are you saying that
> it would require pre-arrangement in lightning for some reason I don't see?
>
Ok now I see what I am missing: We don't really know who owns certain
outputs in lightning until the most-recent-state-enforcement mechanism has
done its job. i.e. the outputs are 2-of-2s up until that has been resolved.
I was operating on some simplified imaginary lightning. Indeed this makes
the proposal far less attractive and does require interaction and
pre-agreement. This complexity here makes it worse than just keeping
external fee-bumping utxos around (as undesirable as this is). Thanks for
helping me figure this out.
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210615/d94f53c0/attachment-0001.html>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-07 22:54:32
in reply to nevent1q…qk7e
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-07 22:54:32Event JSON
{
"id": "bb339431e3da85df2dbe968ef1fec1964fd5b33d22e3fc917557161903a180d7",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686178472,
"kind": 1,
"tags": [
[
"e",
"1359d1037bcc333641858d12ecffe27a5d9f5a125da659af5141f32fc40d20c9",
"",
"root"
],
[
"e",
"9f14347b5badc6794499b03af1f54a7fd21660be09f0407836eaaeb3b6047e87",
"",
"reply"
],
[
"p",
"b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e"
]
],
"content": "📅 Original date posted:2021-06-15\n📝 Original message:On Tue, 15 Jun 2021 at 10:59, Lloyd Fournier \u003clloyd.fourn at gmail.com\u003e wrote:\n\n\u003e\n\u003e\n\u003e On Tue, 15 Jun 2021 at 02:47, Antoine Riard \u003cantoine.riard at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e \u003e This makes a lot of sense as it matches the semantics of what we are\n\u003e\u003e trying\n\u003e\u003e to achieve: allow the owner of an output (whether an individual or group)\n\u003e\u003e to reduce that output's value to pay a higher fee.\n\u003e\u003e\n\u003e\u003e Note, I think you're still struggling with some trust issue that anchor\n\u003e\u003e upgrade is at least eliminating for LN, namely the pre-agreement among a\n\u003e\u003e group of signers about the effective feerate to use at some unknown time\n\u003e\u003e point in the future. If you authorize your counterparty for a broadcast at\n\u003e\u003e feerate X, how do you prevent a broadcast at feerate Y, where Y is far\n\u003e\u003e under X, thus maliciously burning a lot of your fee-bumping reserve ?\n\u003e\u003e\n\u003e\u003e Of course, one mitigation is to make a contribution to a common\n\u003e\u003e fee-bumping output reserve proportional to what has been contributed as a\n\u003e\u003e funding collateral. Thus disincentivizing misuse of the common fee-bumping\n\u003e\u003e reserve in a game-theoretical way. But if you take the example of a LN\n\u003e\u003e channel, you're now running into another issue. Off-chain balances might\n\u003e\u003e fluctuate in a way that most of the time, your fee-bumping reserve\n\u003e\u003e contribution is out-of-proportion with your balance amounts to protect ?\n\u003e\u003e And as such enduring some significant timevalue bleeding on your\n\u003e\u003e fee-bumping reserve.\n\u003e\u003e\n\u003e\u003e Single-party managed fee-bumping reserve doesn't seem to suffer from this\n\u003e\u003e drawback ?\n\u003e\u003e\n\u003e\n\u003e I claim that what I am suggesting is a single-party managed fee-bumping\n\u003e system that solves all fee-bumping requirements of lightning without\n\u003e needing external utxos and without additional interaction or fee\n\u003e pre-agreement between parties. On the commit tx you have your balance going\n\u003e exclusively towards you which you can unilaterally reduce to increase the\n\u003e fee up to whatever threshold you want. With a HTLC or PTLC you also always\n\u003e have a tx with an output that you can unilaterally drain to bump fee\n\u003e (either the hltc-success or htlc-timeout). Are you saying that there are\n\u003e protocols where this would require pre-arrangement or are you saying that\n\u003e it would require pre-arrangement in lightning for some reason I don't see?\n\u003e\n\nOk now I see what I am missing: We don't really know who owns certain\noutputs in lightning until the most-recent-state-enforcement mechanism has\ndone its job. i.e. the outputs are 2-of-2s up until that has been resolved.\nI was operating on some simplified imaginary lightning. Indeed this makes\nthe proposal far less attractive and does require interaction and\npre-agreement. This complexity here makes it worse than just keeping\nexternal fee-bumping utxos around (as undesirable as this is). Thanks for\nhelping me figure this out.\n\nLL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210615/d94f53c0/attachment-0001.html\u003e",
"sig": "c5ad8073832500cc428baf00d2cde8e70be15b5597590ee7c3d8e79125df83feac1a14fcf74e9b276406791f0f820ff7cc0535942ee60a945b492a1fb952d425"
}