Date: Tue, 30 Jan 2024 05:17:04 +0000
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <pohquEzgZZA_d4N8NGyF0RNOYNQUn1mEoYLsawgmKL1r_oWXfK2Y4D7VfaK47b2RQ9KNvdsv_pIKahSXyJpWHTHshv_0XJi-jgMo6paN0mI=@protonmail.com>
In-Reply-To: <FPf9XHCyxV96ABG154D8WapYmEE8XVFWqpQXBXz7p21xjdOk1Ho_lC4IpUznFbhleS7g_kKhUqsU0gtMT06_zo6B9heKyHfp1P1zfMWkjmA=@protonmail.com>
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>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org,
 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
Precedence: list


> I should note that under Decker-Russell-Osuntokun the expectation is that=
 both counterparties hold the same offchain transactions (hence why it is s=
ometimes called "LN-symmetry").
> However, there are two ways to get around this:
>=20
> 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 upda=
te+state txes of one counterparty, and have each side provide signatures fo=
r the tx held by its counterparty (as in Poon-Dryja).
> This lets you force that the party that holds a particular update+state t=
x 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.

Further, in order for update transactions to be able to replace one another=
, the amount output of the update transaction needs to be the same value as=
 the input of the update transaction --- meaning cannot deduct the fee from=
 the channel, at least for the update tx.
This forces the update transaction to be paid for by bringing in an externa=
l UTXO owned by whoever constructed the update transaction (=3D=3D whoever =
started the closing).


Regards,
ZmnSCPxj