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
<[email protected]> 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 <[email protected]> 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 <[email protected]> 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
> > > [email protected]
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > [email protected]
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
