Date: Tue, 30 Jan 2024 15:55:09 +1000
From: Anthony Towns <aj@erisian.com.au>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZbiPPSz9vvIxtJSU@erisian.com.au>
References: <ZbFle6n0Zu3yUV8o@petertodd.org>
 <4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com>
 <9tVZA3A4x-GZB5wQ1kMUoyyYXqvGS4MP4iDrLx1FCFHly-MU--II8evpgdcf2Xb9JZWDsY0kEB8r9dClzPrOk_V8EiWtHms8fvlunZQNGrA=@protonmail.com>
 <Zbh9Qqk2jK0tqKgp@petertodd.org>
 <FPf9XHCyxV96ABG154D8WapYmEE8XVFWqpQXBXz7p21xjdOk1Ho_lC4IpUznFbhleS7g_kKhUqsU0gtMT06_zo6B9heKyHfp1P1zfMWkjmA=@protonmail.com>
 <pohquEzgZZA_d4N8NGyF0RNOYNQUn1mEoYLsawgmKL1r_oWXfK2Y4D7VfaK47b2RQ9KNvdsv_pIKahSXyJpWHTHshv_0XJi-jgMo6paN0mI=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <pohquEzgZZA_d4N8NGyF0RNOYNQUn1mEoYLsawgmKL1r_oWXfK2Y4D7VfaK47b2RQ9KNvdsv_pIKahSXyJpWHTHshv_0XJi-jgMo6paN0mI=@protonmail.com>
X-Spam_score: -0.0
X-Spam_bar: /
Cc: Lightning Dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] CheckTemplateVerify Does Not
 Scale Due to UTXO's Required For Fee Payment
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jan 2024 05:55:19 -0000

On Tue, Jan 30, 2024 at 05:17:04AM +0000, ZmnSCPxj via bitcoin-dev wrote:
> 
> > I should note that under Decker-Russell-Osuntokun the expectation is that both counterparties hold the same offchain transactions (hence why it is sometimes called "LN-symmetry").
> > However, there are two ways to get around this:
> > 
> > 1. Split the fee between them in some "fair" way.
> > Definition of "fair" wen?
> > 2. Create an artificial asymmetry: flip a bit of `nSequence` for the update+state txes of one counterparty, and have each side provide signatures for the tx held by its counterparty (as in Poon-Dryja).
> > This lets you force that the party that holds a particular update+state tx is the one that pays fees.
> 
> No, wait, #2 does not actually work as stated.
> Decker-Russell-Osuntokun uses `SIGHASH_NOINPUT` meaning the `nSequence` is not committed in the signature and can be malleated.

BIP 118 as at March 2021 (when it defined NOINPUT rather than APO):

] The transaction digest algorithm from BIP 143 is used when verifying a
] SIGHASH_NOINPUT signature, with the following modifications:
]
]     2. hashPrevouts (32-byte hash) is 32 0x00 bytes
]     3. hashSequence (32-byte hash) is 32 0x00 bytes
]     4. outpoint (32-byte hash + 4-byte little endian) is
]        set to 36 0x00 bytes
]     5. scriptCode of the input is set to an empty script
]        0x00

BIP 143:

] A new transaction digest algorithm is defined, but only applicable to sigops in version 0 witness program:
]
]   Double SHA256 of the serialization of:
] ...
]      2. hashPrevouts (32-byte hash)
]      3. hashSequence (32-byte hash)
]      4. outpoint (32-byte hash + 4-byte little endian) 
]      5. scriptCode of the input (serialized as scripts inside CTxOuts)
] ...
]      7. nSequence of the input (4-byte little endian)

So nSequence would still have been committed to per that proposal.
Dropping hashSequence just removes the commitment to the other inputs
being spent by the tx.

Cheers,
aj