📅 Original date posted:2022-04-25
📝 Original message:Good morning Peter,
>
> On April 22, 2022 11:03:51 AM GMT+02:00, Zac Greenwood via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>
> > I like the maxim of Peter Todd: any change of Bitcoin must benefit all
> > users. This means that every change must have well-defined and transparent
> > benefits. Personally I believe that the only additions to the protocol that
> > would still be acceptable are those that clearly benefit layer 2 solutions
> > such as LN and do not carry the dangerous potential of getting abused by
> > freeloaders selling commercial services on top of “free” eternal storage on
> > the blockchain.
>
>
> To strengthen your point: benefiting "all users" can only be done by benefiting layer 2 solutions in some way, because it's inevitable that the vast majority of users will use layer 2 because that's the only known way that Bitcoin can scale.
I would like to point out that CTV is usable in LN.
In particular, instead of hosting all outputs (remote, local, and all the HTLCs) directly on the commitment transaction, the commitment transaction instead outputs to a CTV-guarded SCRIPT that defers the "real" outputs.
This is beneficial since a common cause of unilateral closes is that one of the HTLCs on the channel has timed out.
However, only *that* particular HTLC has to be exposed onchain *right now*, and the use of CTV allows only that failing HTLC, plus O(log N) other txes, to be published.
The CTV-tree can even be rearranged so that HTLCs with closer timeouts are nearer to the root of the CTV-tree.
This allows the rest of the unilateral close to be resolved later, if right now there is block space congestion (we only really need to deal with the sole HTLC that is timing out right now, the rest can be done later when block space is less tight).
This is arguably minimal (unilateral closes are rare, though they *do* have massive effects on the network, since a single timed-out channel can, during short-term block congestion, cause other channels to also time out, which worsen the block congestion and leading to cascades of channel closures).
So this objection seems, to me, at least mitigated: CTV *can* benefit layer 2 users, which is why I switched from vaguely apathetic to CTV, to vaguely supportive of it.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-07 23:07:52
in reply to nevent1q…33h0
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-07 23:07:52Event JSON
{
"id": "a8c2e1d611a2415fa90f659e8cd86d7ae265938cc139f1567433b5edafa021eb",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686179272,
"kind": 1,
"tags": [
[
"e",
"2ad3d3403e1d63b96ae96eb1c1f2ba31d1c1dccbc5720a099543ffc26240da8b",
"",
"root"
],
[
"e",
"f34d527a11e82a77e15a6ea085d496721e588b6994e97cff73a1dede0b5674ef",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2022-04-25\n📝 Original message:Good morning Peter,\n\n\u003e\n\u003e On April 22, 2022 11:03:51 AM GMT+02:00, Zac Greenwood via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:\n\u003e\n\u003e \u003e I like the maxim of Peter Todd: any change of Bitcoin must benefit all\n\u003e \u003e users. This means that every change must have well-defined and transparent\n\u003e \u003e benefits. Personally I believe that the only additions to the protocol that\n\u003e \u003e would still be acceptable are those that clearly benefit layer 2 solutions\n\u003e \u003e such as LN and do not carry the dangerous potential of getting abused by\n\u003e \u003e freeloaders selling commercial services on top of “free” eternal storage on\n\u003e \u003e the blockchain.\n\u003e\n\u003e\n\u003e To strengthen your point: benefiting \"all users\" can only be done by benefiting layer 2 solutions in some way, because it's inevitable that the vast majority of users will use layer 2 because that's the only known way that Bitcoin can scale.\n\nI would like to point out that CTV is usable in LN.\nIn particular, instead of hosting all outputs (remote, local, and all the HTLCs) directly on the commitment transaction, the commitment transaction instead outputs to a CTV-guarded SCRIPT that defers the \"real\" outputs.\n\nThis is beneficial since a common cause of unilateral closes is that one of the HTLCs on the channel has timed out.\nHowever, only *that* particular HTLC has to be exposed onchain *right now*, and the use of CTV allows only that failing HTLC, plus O(log N) other txes, to be published.\nThe CTV-tree can even be rearranged so that HTLCs with closer timeouts are nearer to the root of the CTV-tree.\nThis allows the rest of the unilateral close to be resolved later, if right now there is block space congestion (we only really need to deal with the sole HTLC that is timing out right now, the rest can be done later when block space is less tight).\n\nThis is arguably minimal (unilateral closes are rare, though they *do* have massive effects on the network, since a single timed-out channel can, during short-term block congestion, cause other channels to also time out, which worsen the block congestion and leading to cascades of channel closures).\n\nSo this objection seems, to me, at least mitigated: CTV *can* benefit layer 2 users, which is why I switched from vaguely apathetic to CTV, to vaguely supportive of it.\n\nRegards,\nZmnSCPxj",
"sig": "83bc16d78d32607eb4ba8932f86b6f34c7b9e7416825d706cc163739c32006ab88f024985553d7a7356a358b8b01fa873508bb57eaa99cdc3fe3c246b0745903"
}