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.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to