From: Richard Myers <rich@gotenna•com>
To: Matt Corallo <lf-lists@mattcorallo•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
Date: Fri, 7 Aug 2020 17:34:43 +0200 [thread overview]
Message-ID: <CACJVCgLtt=SBLeA=JWPhzU7EdbJUy2AfPTGbs-pRn0fuwGmZsQ@mail.gmail.com> (raw)
In-Reply-To: <94bb2092-6d53-0e46-45ac-a1f8e04dafba@mattcorallo.com>
[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]
When you say that a special relay network might be more "smart about
replacement" in the context of ANYPREVOUT*, do you mean these nodes could
RBF parts of a package like this:
Given:
- Package A = UpdateTx_A(n=1): txin: AnchorTx, txout: SettlementTx_A(n=1)
-> HtlcTxs(n=1)_A -> .chain of transactions that pin UpdateTx_A(n=1) with
high total fee, etc.
And a new package with higher fee rate versions of ANYPREVOUT* transactions
in the package, but otherwise lower total fee:
- Package B = UpdateTx_B(n=1): txin: AnchorTx, txout: SettlementTx_B(n=1)
-> HtlcTxs(n=1)_B -> low total fee package
Relay just the higher up-front fee-rate transactions from package B which
get spent by the high absolute fee child transactions from package A:
- Package A' = UpdateTx_B(n=1): txin: AnchorTx, txout: SettlementTx_B(n=1)
-> HtlcTxs(n=1)_A -> ...chain of up to 25 txs that pin UpdateTx(n=1) with
high total fee, etc.
On Thu, Aug 6, 2020 at 5:59 PM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> In general, SIGHASH_NOINPUT makes these issues much, much simpler to
> address, but only if we assume that nodes can
> somehow be "smart" about replacement when they see a SIGHASH_NOINPUT spend
> which can spend an output that something else
> in the mempool already spends (potentially a different input than the
> relaying node thinks the transaction should
> spend). While ideally we'd be able to shove that (significant) complexity
> into the Bitcoin P2P network, that may not be
> feasible, but we could imagine a relay network of lightning nodes doing
> that calculation and then passing the
> transactions to their local full nodes.
[-- Attachment #2: Type: text/html, Size: 2488 bytes --]
next prev parent reply other threads:[~2020-08-07 15:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-09 21:40 Anthony Towns
2020-07-09 22:30 ` Anthony Towns
2020-07-10 7:46 ` Christian Decker
2020-07-10 3:29 ` ZmnSCPxj
2020-08-03 19:27 ` Richard Myers
2020-08-04 1:38 ` ZmnSCPxj
2020-08-04 4:02 ` lf-lists
2020-08-04 4:23 ` ZmnSCPxj
2020-08-04 10:38 ` Christian Decker
2020-08-04 13:10 ` Matt Corallo
2020-08-04 14:59 ` ZmnSCPxj
2020-08-06 15:58 ` Matt Corallo
2020-08-07 15:34 ` Richard Myers [this message]
2020-08-11 0:14 ` Matt Corallo
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='CACJVCgLtt=SBLeA=JWPhzU7EdbJUy2AfPTGbs-pRn0fuwGmZsQ@mail.gmail.com' \
--to=rich@gotenna$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lf-lists@mattcorallo$(echo .)com \
/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