David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2022-08-19 📝 Original message:On 2022-08-19 06:33, James ...
📅 Original date posted:2022-08-19
📝 Original message: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
📝 Original message: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