ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-09-05 📝 Original message: Good morning list, I do ...
📅 Original date posted:2019-09-05
📝 Original message:
Good morning list,
I do not see much point in using miniscript for Lightning unless we decide to support transporting arbitrary contracts, as here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html
Otherwise, it would be far easier implementation-wise, to just have carefully-coded SCRIPT to transport HTLCs.
It would even be possible, to write it in miniscript and compile it once, then debate endlessly on how to improve the output of the miniscript compiler, on the principle that all that a human-level or higher intelligence needs, to beat a compiler, is to make a single improvement to the compiled output.
On the other hand, if we *were* to support arbitrary contracts over payment channels, we should note:
* Very few contracts are "routable" (only HTLCs and DLCs come to mind, and various HTLCs-yielding-HTLCs constructions) over the network.
* Supporting arbitrary routing would be a massive massive massive headache as forwarding nodes need to have some assurance they can claim the incoming if the outgoing is claimed, or similar.
* While miniscript is more amenable to programmatic analysis, I do not know what property needs to be actually proven in order to prove that contracts can be forwarded somehow.
* Any absolute timelocks on the contract will imply that the hosting payment channel (and channel factory, for that matter) has a lifetime up to the timelock.
* This should be easy to extract from the miniscript.
* This is needed as the payment channel cannot actually enforce time, only the blockchain layer can, thus enforcement of the timelock can only be done onchain.
* For Decker-Russell-Osuntokun, the channel unilateral close needs to be started *before* the absolute timelock, with the channel security parameter of the CSV-delay before the absolute timelock.
For Poon-Dryja the channel unilateral close can be done on the block before the absolute timelock (or some more blocks before that as a safety margin).
* Any contract will automatically get a `|| (A && B)` appended to it, where `A` and `B` are the channel counterparties.
* This is simply the right of all participants to agree to ignore the contract and settle it by other means, as in Smart Contracts Unchained: https://zmnscpxj.github.io/bitcoin/unchained.html
* Consider how `update_fail_htlc` works: the HTLC does not explicitly contain a clause by which it can simply be "failed" other than by the timelock branch.
Yet `update_fail_htlc` does not require waiting for the timelock to arrive.
* This is simply the fact that the payment channel can be updated such that the contrract is deleted outright, with the contract funds reallocated in any way that both participants agree.
Of note is that a miniscript compiler would be quite useful if we were to support arbitrary contracts over Poon-Dryja channels.
This is because, as I pointed out in the linked post, there is a need to add the condition `&& (A && B) || (revoke)` to the contract in order to ensure that the transaction first pays out to a revocable output with an `nSequence` restriction.
The addition of these extra conditions would be trivial with miniscript, and the miniscript-to-SCRIPT compiler could potentially optimize away the extra conditions, if a Sufficiently Smart Compiler (TM) for miniscript is developed.
Of course, under Decker-Russell-Osuntokun (which is what triggered this thread initially anyway), the additional conditions on the arbitrary contract are unnecessary and all that is needed is to analyze the contract for absolute timelocks.
Forwardability of arbitrary contracts is more difficult to prove; I cannot imagine how it can be done.
But surely it would be possible, my untrained intuition subroutine reports.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, September 5, 2019 12:04 AM, Antoine Riard <antoine.riard at gmail.com> wrote:
> Hello all,
> Didn't listen to Pieter Wuille interview, so don't know how he was thinking to use miniscript for lightning.
> But currently in lightning all our scripts are templates, a use of a miniscript compiler would be to find optimized bitcoin scripts for a given policy which model the channel and then hardcode them in lightning backend.
> The other use I can see would be to use miniscript to write customizable conditional-payment than our basic HTLCs, real hurdle would be to implement on-chain monitoring and resolution right.
> Not sure how Eltoo fit into it as it's a sighash extension to get a new update mechanism, miniscript seems more tailored for the transfer layer.
>
> Regards,
> Antoine
>
> Le mer. 4 sept. 2019 à 08:53, Bastien TEINTURIER <bastien at acinq.fr> a écrit :
>
> > Good morning Richard,
> >
> > This is an interesting initiative, I'm curious to see the results!
> > I know we haven't worked on any Eltoo implementation yet at Acinq and I don't know if others have attempted it.
> >
> > However I have a very open question that may impact your project.
> > I'm starting to look at miniscript [1] (still a total noob though) and listened to an interview where Pieter Wuille briefly mentioned that using miniscript for lightning may be more future-proof and extensible than directly using bitcoin script.
> > Have you considered first re-writing the Eltoo scripts with miniscript? Or did someone else on this list attempt this already?
> > Do people on this list have opinions on whether that is the right direction for Eltoo scripts (and maybe even for Bolt 1.x scripts if any_prevout never makes it to Bitcoin scripts)?
> >
> > Cheers,
> > Bastien
> >
> > [1] http://bitcoin.sipa.be/miniscript/
> >
> > Le mer. 4 sept. 2019 à 13:20, Richard Myers <rich at gotenna.com> a écrit :
> >
> > > Hi All,
> > >
> > > To better understand how the eltoo update scheme ( https://blockstream.com/eltoo.pdf ) works in practice I implemented eltoo in the Bitcoin functional test framework. These simulations exercise a concrete implementation of the eltoo Bitcoin scripts and explore the data flow between nodes that use eltoo to update their channel state.
> > >
> > > My motivation for creating these tests is to have a framework for both understanding and refining the Bitcoin scripts and message passing protocol for eltoo. I’d love to hear what people think of my initial implementation.
> > >
> > > This simulation uses a fork of Bitcoin with cdecker’s SIGHASH_NOINPUT patch applied to the signet2 fork fjahr created with patches applied for signet (kallewoof), taproot (sipa) and anyprevout* (ajtowns).
> > >
> > > https://github.com/remyers/signet2/blob/eltoo/test/functional/simulate_eltoo.py
> > >
> > > Next steps:
> > >
> > > - add bidirectional channel updates
> > >
> > > - derive public keys for settle transactions from a pre-shared basepoint
> > >
> > >
> > > Does anyone know of any other eltoo implementations? I’d love to compare notes and get the ball rolling on a detailed specification.
> > >
> > > Special thanks to the Chaincode Summer Residency and Christian Decker for their helpful advice and encouragement while I worked on this project.
> > >
> > > -- Richard
> > >
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
Good morning list,
I do not see much point in using miniscript for Lightning unless we decide to support transporting arbitrary contracts, as here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html
Otherwise, it would be far easier implementation-wise, to just have carefully-coded SCRIPT to transport HTLCs.
It would even be possible, to write it in miniscript and compile it once, then debate endlessly on how to improve the output of the miniscript compiler, on the principle that all that a human-level or higher intelligence needs, to beat a compiler, is to make a single improvement to the compiled output.
On the other hand, if we *were* to support arbitrary contracts over payment channels, we should note:
* Very few contracts are "routable" (only HTLCs and DLCs come to mind, and various HTLCs-yielding-HTLCs constructions) over the network.
* Supporting arbitrary routing would be a massive massive massive headache as forwarding nodes need to have some assurance they can claim the incoming if the outgoing is claimed, or similar.
* While miniscript is more amenable to programmatic analysis, I do not know what property needs to be actually proven in order to prove that contracts can be forwarded somehow.
* Any absolute timelocks on the contract will imply that the hosting payment channel (and channel factory, for that matter) has a lifetime up to the timelock.
* This should be easy to extract from the miniscript.
* This is needed as the payment channel cannot actually enforce time, only the blockchain layer can, thus enforcement of the timelock can only be done onchain.
* For Decker-Russell-Osuntokun, the channel unilateral close needs to be started *before* the absolute timelock, with the channel security parameter of the CSV-delay before the absolute timelock.
For Poon-Dryja the channel unilateral close can be done on the block before the absolute timelock (or some more blocks before that as a safety margin).
* Any contract will automatically get a `|| (A && B)` appended to it, where `A` and `B` are the channel counterparties.
* This is simply the right of all participants to agree to ignore the contract and settle it by other means, as in Smart Contracts Unchained: https://zmnscpxj.github.io/bitcoin/unchained.html
* Consider how `update_fail_htlc` works: the HTLC does not explicitly contain a clause by which it can simply be "failed" other than by the timelock branch.
Yet `update_fail_htlc` does not require waiting for the timelock to arrive.
* This is simply the fact that the payment channel can be updated such that the contrract is deleted outright, with the contract funds reallocated in any way that both participants agree.
Of note is that a miniscript compiler would be quite useful if we were to support arbitrary contracts over Poon-Dryja channels.
This is because, as I pointed out in the linked post, there is a need to add the condition `&& (A && B) || (revoke)` to the contract in order to ensure that the transaction first pays out to a revocable output with an `nSequence` restriction.
The addition of these extra conditions would be trivial with miniscript, and the miniscript-to-SCRIPT compiler could potentially optimize away the extra conditions, if a Sufficiently Smart Compiler (TM) for miniscript is developed.
Of course, under Decker-Russell-Osuntokun (which is what triggered this thread initially anyway), the additional conditions on the arbitrary contract are unnecessary and all that is needed is to analyze the contract for absolute timelocks.
Forwardability of arbitrary contracts is more difficult to prove; I cannot imagine how it can be done.
But surely it would be possible, my untrained intuition subroutine reports.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, September 5, 2019 12:04 AM, Antoine Riard <antoine.riard at gmail.com> wrote:
> Hello all,
> Didn't listen to Pieter Wuille interview, so don't know how he was thinking to use miniscript for lightning.
> But currently in lightning all our scripts are templates, a use of a miniscript compiler would be to find optimized bitcoin scripts for a given policy which model the channel and then hardcode them in lightning backend.
> The other use I can see would be to use miniscript to write customizable conditional-payment than our basic HTLCs, real hurdle would be to implement on-chain monitoring and resolution right.
> Not sure how Eltoo fit into it as it's a sighash extension to get a new update mechanism, miniscript seems more tailored for the transfer layer.
>
> Regards,
> Antoine
>
> Le mer. 4 sept. 2019 à 08:53, Bastien TEINTURIER <bastien at acinq.fr> a écrit :
>
> > Good morning Richard,
> >
> > This is an interesting initiative, I'm curious to see the results!
> > I know we haven't worked on any Eltoo implementation yet at Acinq and I don't know if others have attempted it.
> >
> > However I have a very open question that may impact your project.
> > I'm starting to look at miniscript [1] (still a total noob though) and listened to an interview where Pieter Wuille briefly mentioned that using miniscript for lightning may be more future-proof and extensible than directly using bitcoin script.
> > Have you considered first re-writing the Eltoo scripts with miniscript? Or did someone else on this list attempt this already?
> > Do people on this list have opinions on whether that is the right direction for Eltoo scripts (and maybe even for Bolt 1.x scripts if any_prevout never makes it to Bitcoin scripts)?
> >
> > Cheers,
> > Bastien
> >
> > [1] http://bitcoin.sipa.be/miniscript/
> >
> > Le mer. 4 sept. 2019 à 13:20, Richard Myers <rich at gotenna.com> a écrit :
> >
> > > Hi All,
> > >
> > > To better understand how the eltoo update scheme ( https://blockstream.com/eltoo.pdf ) works in practice I implemented eltoo in the Bitcoin functional test framework. These simulations exercise a concrete implementation of the eltoo Bitcoin scripts and explore the data flow between nodes that use eltoo to update their channel state.
> > >
> > > My motivation for creating these tests is to have a framework for both understanding and refining the Bitcoin scripts and message passing protocol for eltoo. I’d love to hear what people think of my initial implementation.
> > >
> > > This simulation uses a fork of Bitcoin with cdecker’s SIGHASH_NOINPUT patch applied to the signet2 fork fjahr created with patches applied for signet (kallewoof), taproot (sipa) and anyprevout* (ajtowns).
> > >
> > > https://github.com/remyers/signet2/blob/eltoo/test/functional/simulate_eltoo.py
> > >
> > > Next steps:
> > >
> > > - add bidirectional channel updates
> > >
> > > - derive public keys for settle transactions from a pre-shared basepoint
> > >
> > >
> > > Does anyone know of any other eltoo implementations? I’d love to compare notes and get the ball rolling on a detailed specification.
> > >
> > > Special thanks to the Chaincode Summer Residency and Christian Decker for their helpful advice and encouragement while I worked on this project.
> > >
> > > -- Richard
> > >
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev