MIME-Version: 1.0
Date: Fri, 19 Aug 2022 08:53:39 -1000
From: "David A. Harding" <dave@dtrt.org>
To: James O'Beirne <james.obeirne@gmail.com>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAPfvXfLvYbKWSWatkunwdcOYN_YTCayr=B_Rm90R+1nUW_zFCg@mail.gmail.com>
References: <CAPfvXfLvYbKWSWatkunwdcOYN_YTCayr=B_Rm90R+1nUW_zFCg@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <813858beca9d1d033fbb0a26921162d6@dtrt.org>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] More uses for CTV
Precedence: list

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