Hi AJ,
> The idea behind this is that then you can use a signature to link a
> set of inputs and outputs via a signature in a way that's more general
> than SIGHASH_ANYONECANPAY (since you can have many inputs attesting to
> the same subset of outputs), SIGHASH_SINGLE (since you can attest to
> multiple outputs), and SIGHASH_ALL (since you don't have to attest to
> all outputs). This means that (eg) you can have a tx closing a lightning
> channel commit to a dozen outputs that specify where the channel's funds
> end up, but are also able to add additional inputs to cover fees, and
> additional outputs to collect the change from those fees.
To precise more one of the use-case for SIGHASH_GROUP, you can have one LSP with hundreds of Lightning channels opened with as much (mobile) counterparties, of which the majority are probably offline most of their times to aggregate the LN commitment transaction in a single bundle with one pair of input/output. Aggregation should be non-interactive, fee-savings from a L2 viewpoint would be all the saved anchor outputs, blockspace-savings from a full-node viewpoint would be those same anchor outputs.
> To some degree, this provides an alternative way of getting the same
> benefits of SIGHASH_GROUP: if you were constructing a transaction
> consisting of {i1,i2,i3,i4,f} -> {o1,o2,o3,c} with {i1,i2,i3} committing to
> {o1} and {i4} committing to {o2,o3} and f providing the fees with c
> collecting the change, you could instead create three transactions:
>
> {i1,i2,i3} -> {o1, eph1}
> {i4} -> {o2,o3, eph2}
> {eph1, eph2, f} -> {c}
I think here a SIGHASH_GROUP-like would be: {i1, i2, i3, i4 i.f, o1, o2, o3, o.f}. Where `i.f` is the input for feeding external value in the bundle, `o.f` the output for output fees.
Compared to anchors, I believe you're saving 1-input/2-outputs of fees for a construction expressing the same semantics ?
> However, it's likely the only benefit to using SIGHASH_ALL there is to reduce
> malleability risk, and ephemeral anchors probably already achieve that.
If my understanding is correct with ephemeral anchors, we allow third-party malleability (i.e a entity not owning any key in the funding channel output) of the chain of transactions. If nversion=3 is robust against "classic" pinnings at the commitment
transaction-level by a counterparty (scenario 2b in [0] iirc), it should hold against external parties. However, it might introduce issues, where a common CPFP is conflicted on one of its input, e.g in the example above eph1 is replaced by malicious better fee/feerate eph1', cancelling {i4, o2, o3} fee-bumping.
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html> The v3.4b rule unfortunately prevents ephemeral anchors from being used
> to provide fees for multiple input/output groups in the way I suggest
> above
See point above, as providing fees for multiple input/output groups *might* be unsafe, so I think this is a limited downside anyway.
> (I suspect the only way to remove that restriction without reinstating the pinning
> vector is to allow replacements that have a higher fee rate, even though
> they have a lower absolute fee)
From my memory, I think this is correct -- Though now you're introducing the issue where one might be able to downgrade the fee content of your miner mempool in a period of emptiness. However, I believe if we move to a higher fee rate only, it might make
the cost of the replacement issue above.
> Anyway, in theory, I think ephemeral anchors get most of the potential
> benefits of SIGHASH_GROUP, particularly if the (v3.4b) rule can be removed
> or loosened somehow. And it's obviously much less costly to implement:
> it's relay policy only, rather than a consensus change; and it only
> operates at the transaction level, so we don't have to start worrying
> about pinning of inputs vs whole transactions.
Yes I think the only clear benefit of SIGHASH_GROUP over ephemeral anchors is the fee/blockspace savings for some types of LN deployments. Comes at far higher engineering resources as it's a consensus change rather than relay policy only. However, in the future, if it is combined with other changes like malleability of the output amounts, it could unlock use-cases like "dynamic value reallocation" from unknown initial sending.
Best,
Antoine