public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <lf-lists@mattcorallo•com>
To: Richard Myers <rich@gotenna•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
Date: Mon, 10 Aug 2020 20:14:29 -0400	[thread overview]
Message-ID: <e3b1d9a0-df1d-38e0-02cb-306020ab7240@mattcorallo.com> (raw)
In-Reply-To: <CACJVCgLtt=SBLeA=JWPhzU7EdbJUy2AfPTGbs-pRn0fuwGmZsQ@mail.gmail.com>

I was assuming, largely, that Bitcoin Core will eventually get what you describe here (which is generally termed 
"package relay", implying we relay, and process, groups of transactions as one).

What we'd need for SIGHASH_ANYPREVOUT is a relay network that isn't just smart about fee calculation, but can actually 
rewrite the transactions themselves before passing them on to a local bitcoind.

eg such a network would need to be able to relay
"I have transaction A, with one input, which is valid for any output-idx-0 in a transaction spending output B".
and then have the receiver go look up which transaction in its mempool/chain spends output B, then fill in the input 
with that outpoint and hand the now-fully-formed transaction to their local bitcoind for processing.

Matt

On 8/7/20 11:34 AM, Richard Myers wrote:
> 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 
> <mailto: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. 
> 
> 


      reply	other threads:[~2020-08-11  0:14 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
2020-08-11  0:14             ` Matt Corallo [this message]

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=e3b1d9a0-df1d-38e0-02cb-306020ab7240@mattcorallo.com \
    --to=lf-lists@mattcorallo$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=rich@gotenna$(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