From: "David A. Harding" <dave@dtrt•org>
To: Antoine Riard <antoine.riard@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring
Date: Mon, 21 Sep 2020 10:52:21 -0400 [thread overview]
Message-ID: <20200921145221.76bg5rnw7ohkm3ck@ganymede> (raw)
In-Reply-To: <CALZpt+HtuVC6YmZvABaZUWmN9c3pV1FnX1UUJgGbd_iLuuU8hg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]
On Sun, Sep 20, 2020 at 07:10:23PM -0400, Antoine Riard via bitcoin-dev wrote:
> As you mentioned, if the goal of the sponsor mechanism is to let any party
> drive a state N's first tx to completion, you still have the issue of
> concurrent states being pinned and thus non-observable for sponsoring by an
> honest party.
>
> E.g, Bob can broadcast a thousand of revoked LN states and pin them with
> low-feerate sponsors such as these malicious packages absolute fee are
> higher than the honest state N. Alice can't fee-sponsor
> them as we can assume she hasn't a global view of network mempools. Due to
> the proposed policy rule "The Sponsor Vector's entry must be present in the
> mempool", Alice's sponsors won't propagate.
Would it make sense that, instead of sponsor vectors
pointing to txids, they point to input outpoints? E.g.:
1. Alice and Bob open a channel with funding transaction 0123...cdef,
output 0.
2. After a bunch of state updates, Alice unilaterally broadcasts a
commitment transaction, which has a minimal fee.
3. Bob doesn't immediately care whether or not Alice tried to close the
channel in the latest state---he just wants the commitment
transaction confirmed so that he either gets his money directly or he
can send any necessary penalty transactions. So Bob broadcasts a
sponsor transaction with a vector of 0123...cdef:0
4. Miners can include that sponsor transaction in any block that has a
transaction with an input of 0123...cdef:0. Otherwise the sponsor
transaction is consensus invalid.
(Note: alternatively, sponsor vectors could point to either txids OR
input outpoints. This complicates the serialization of the vector but
seems otherwise fine to me.)
> If we want to solve the hard cases of pinning, I still think mempool
> acceptance of a whole package only on the merits of feerate is the easiest
> solution to reason on.
I don't think package relay based only on feerate solves RBF transaction
pinning (and maybe also doesn't solve ancestor/dependent limit pinning).
Though, certainly, package relay has the major advantage over this
proposal (IMO) in that it doesn't require any consensus changes.
Package relay is also very nice for fixing other protocol rough edges
that are needed anyway.
-Dave
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-09-21 14:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-19 0:51 Jeremy
2020-09-19 1:39 ` Cory Fields
2020-09-19 16:16 ` Jeremy
2020-09-19 13:37 ` David A. Harding
2020-09-19 15:01 ` nopara73
2020-09-19 16:30 ` Jeremy
2020-09-19 17:24 ` David A. Harding
2020-09-19 18:39 ` Antoine Riard
2020-09-19 19:13 ` Antoine Riard
2020-09-19 19:46 ` Jeremy
2020-09-20 23:10 ` Antoine Riard
2020-09-21 14:52 ` David A. Harding [this message]
2020-09-21 16:27 ` Jeremy
2020-09-21 23:40 ` Antoine Riard
2020-09-22 18:05 ` Suhas Daftuar
2020-09-23 22:10 ` Jeremy
2020-09-24 4:22 ` Dmitry Petukhov
2020-09-22 6:24 ArmchairCryptologist
2020-09-22 13:52 ` 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=20200921145221.76bg5rnw7ohkm3ck@ganymede \
--to=dave@dtrt$(echo .)org \
--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