Presigned transactions have to use a N-of-N (2-2 for ln, more for pools) multisignature which is computed over the network whereas in-script commitments can be done 1 key that is a non-secret point (e.g., just the generator I think works).

For large protocol trees (e.g., of size N) the savings can be substantial! It also reduces the amount of state that needs to be stored since the in-script sigs can be deterministic.

Rene has some nice work demonstrating that latency in generating state transitions has a very substantial cost to the efficiency of routing, maybe he can chime in further.


You can also do a "back-filling" where you get the best of both, by (after you commit to the quick to generate in-script version) lazily backfilling with an equivalent p2wpkh version. If you have a channel, when you are in "burst mode", you can cancel the longer to generate p2wpkh version when newer states come in. (data hazard/ bypass).


With respect to mining pools and size constraints, https://rubin.io/bitcoin/2021/12/12/advent-15/ shows how paying into batches of channels can be used to trustlessly compress payouts without custodial relationship.


--
@JeremyRubin

On Fri, Aug 19, 2022 at 11:53 AM David A. Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On 2022-08-19 06:33, James O'Beirne via bitcoin-dev wrote:
> Multiple parties could
> trustlessly collaborate to settle into a single CTV output using
> SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction
> similar to coinjoins.

Just to make sure I understand, is the reason for SH_ALL|SH_ACP so that
any of the parties can subsequently RBF fee bump the transaction?

> Conceptually, CTV is the most parsimonious way to do such a scheme,
> since you can't really get smaller than a SHA256 commitment

What's the advantage of CTV here compared to presigned transactions?  If
multiple parties need to interact to cooperatively sign a transaction,
no significant overhead is added by having them simultaneously sign a
second transaction that spends from the output of the first transaction.
  Presigned transactions actually have two small benefits I can think of:

1. The payment from the first transaction (containing the spends from
the channel setup transactions) can be sent to a P2WPKH output, which is
actually smaller than a SHA256 commitment.  Though this probably does
require an extra round of communication for commit-and-reveal to prevent
a collision attack on the P2WPKH address.[1]

2. Having the first transaction pay a either a P2WPKH or bech32m output
and the second transaction spend from that UTXO may blend in better with
other transactions, enhancing privacy.  This advantage probably isn't
compatible with SH_ALL|SH_ACP, though, and it would require other
privacy upgrades to LN.

> direct-from-coinbase payouts seem like a
> desirable feature which avoids some trust in pools.
> [...]
> If the payout was instead a single OP_CTV output, an arbitrary number
> of pool participants could be paid out "atomically" within a single
> coinbase.  One limitation is
> the size of the coinbase outputs owed to constituent miners; this
> limits the number of participants in the pool.

I'm confused by this.  What is the size limitation on coinbase outputs,
how does it limit the number of participants in a pool, and how does CTV
fix that?

Thanks,

-Dave

[1]
https://bitcoinops.org/en/newsletters/2020/06/24/#reminder-about-collision-attack-risks-on-two-party-ecdsa
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev