Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT

[Matt Corallo <lf-lists@mattcorallo.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. 
> 
>