ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-25 📝 Original message:Good morning Peter, > > On ...
📅 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
📝 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