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
