From: Lloyd Fournier <lloyd.fourn@gmail•com>
To: Antoine Riard <antoine.riard@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent
Date: Tue, 15 Jun 2021 10:59:12 +1000 [thread overview]
Message-ID: <CAH5Bsr1NxM6WcpagwpmFC=Nn3tzK+H8n-Vx1_ObMGEejnD4SjA@mail.gmail.com> (raw)
In-Reply-To: <CALZpt+E09jViG0owWpSWBoG5rjk_=HdMgQisp_1DsBEKBq-D2w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2661 bytes --]
On Tue, 15 Jun 2021 at 02:47, Antoine Riard <antoine.riard@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?
To further emphasise the generality of this idea you can easily imagine a
world where this is enabled on all Bitcoin transactions (of course you have
to stomach tx malleability -- a bit more palatable with ANYPREVOUT
everywhere). Even for a normal wallet-to-wallet payment the receiver could
efficiently increase the tx fee by making a signature under the key of
their output and replacing the original tx without interacting with the
sender who actually provided the funds for the payment.
Cheers,
LL
[-- Attachment #2: Type: text/html, Size: 3150 bytes --]
next prev parent reply other threads:[~2021-06-15 0:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-27 20:14 Antoine Riard
2021-05-27 21:45 ` darosior
2021-05-28 4:13 ` Antoine Riard
2021-05-28 22:25 ` darosior
2021-06-10 21:16 ` Antoine Riard
2021-06-10 13:18 ` darosior
2021-06-07 2:27 ` Lloyd Fournier
2021-06-10 21:45 ` Antoine Riard
2021-06-10 22:47 ` darosior
2021-06-13 5:56 ` Lloyd Fournier
2021-06-13 14:16 ` Jeremy
2021-06-14 17:18 ` Antoine Riard
2021-06-14 16:46 ` Antoine Riard
2021-06-15 0:59 ` Lloyd Fournier [this message]
2021-06-15 3:08 ` Lloyd Fournier
2021-07-08 11:17 ` Anthony Towns
2021-07-09 13:19 ` Antoine Riard
2021-07-10 1:47 ` Anthony Towns
2021-07-12 0:02 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAH5Bsr1NxM6WcpagwpmFC=Nn3tzK+H8n-Vx1_ObMGEejnD4SjA@mail.gmail.com' \
--to=lloyd.fourn@gmail$(echo .)com \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox