From: "David A. Harding" <dave@dtrt•org>
To: James O'Beirne <james.obeirne@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] More uses for CTV
Date: Fri, 19 Aug 2022 08:53:39 -1000 [thread overview]
Message-ID: <813858beca9d1d033fbb0a26921162d6@dtrt.org> (raw)
In-Reply-To: <CAPfvXfLvYbKWSWatkunwdcOYN_YTCayr=B_Rm90R+1nUW_zFCg@mail.gmail.com>
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
next prev parent reply other threads:[~2022-08-19 18:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-19 16:33 James O'Beirne
2022-08-19 17:20 ` Greg Sanders
2022-08-20 3:03 ` ZmnSCPxj
2022-08-19 18:53 ` David A. Harding [this message]
2022-08-19 21:01 ` Jeremy Rubin
2022-09-19 1:22 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=813858beca9d1d033fbb0a26921162d6@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=james.obeirne@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox