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 <bast...@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 <r...@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@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
