[bitcoin-dev] Miniscript support in hardware wallets/signing devices
Hi Assessing what should be sent to this mailing list is difficult. We don't want to be bombarded with full on company promotional materials obviously but then at the same time only focusing on contentious consensus changes at the expense of everything else just gives a warped view to readers of this list of what is happening in the community and what 99 percent of Bitcoin devs are working on. One example of many is Miniscript. In this excellent blog post [1] by Salvatore Ingala he explains the work he is doing to get Miniscript support in the Ledger hardware wallet (or "signing device" [2], hat tip nvk). Miniscript has been in the works for a number of years now and the first of multiple Miniscript related pull requests was recently merged into the Bitcoin Core wallet [3]. This wasn't included in the recent Bitcoin Core 23.0 release [4] but one would expect it to be included in the next major release (24.0). Salvatore explains that to start enabling Miniscript support in Ledger only requires ~20 lines of code but there is additional complexity that isn't covered by the included code snippet. And of course the Policy to Miniscript compiler(s) don't (yet) support Taproot trees of scripts so we are talking primarily Bitcoin scripts pre-Taproot. He also includes a short video of what the Policy/Miniscript user experience might look like on a Ledger Nano. For those who are interested in learning more about Miniscript stickies-v is hosting a Bitcoin Core PR review club on Miniscript on May 18th [5]. Disclaimer: I have personal views on hardware wallets/signing devices as anyone does but I do not receive funding from any particular company or product in the space. [1]: https://blog.ledger.com/miniscript-is-coming/ [2]: https://signingdevice.com/ [3]: https://github.com/bitcoin/bitcoin/pull/24147 [4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020321.html [5]: https://bitcoincore.reviews/24148 -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Miniscript
Good morning David, > Today, new Bitcoin applications such as JoinMarket, Wasabi wallet, and Arwen > all > suffer from a problem of having novel bitcoin scripts. For CoinJoin (JoinMarket, Wasabi) at least, I believe there is no need of novel Bitcoin SCRIPTs. Indeed, from what I can tell they use only P2WPKH `SIGHASH_ALL` signatures and P2WPKH outputs: there seems to be nothing to analyze there. I do not believe Miniscript would benefit those in particular. (though miniscript does have other benefits as well: in particular sufficiently-advanced miniscript compilers will be able to write shorter SCRIPTs than mere unaided humans can) I have not investigated much of Arwen yet but it seems to me to be a sort of exchange-specific payment-channel implementation. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Miniscript
Glad to see this post. I have been following Miniscript for some time, and the static analysis that is possible with Miniscript is particularly interesting to me. Today, new Bitcoin applications such as JoinMarket, Wasabi wallet, and Arwen all suffer from a problem of having novel bitcoin scripts. Bitcoin script is not easy to analyze, and historically it has been difficult for me to get comfortable using these applications because I have been unable to convince myself to have complete confidence in the integrity of the transactions these applications want me to sign. Well established applications can eventually overcome this issue for users by getting sufficient expert review and commentary, however this proves as a substantial barrier to entry in an ecosystem that is ideally as open as possible. Miniscript can make a huge difference here. With Miniscript, it possible to create hardware wallets that can perform static analysis on novel miniscripts and provide the user with assurances about the nature of the transactions. A hardware wallet with a Miniscript analyzer may not be able to tell you that a transaction is a CoinJoin transaction, but it will be able to tell you that under all possible scenarios, you end up with just as many coins in your addresses that you started with, modulo some transaction fee. This is a big deal for novel application writers, as it significantly reduces the barrier for them to convince both themselves and others that the code they wrote does not risk user funds being lost, especially if all transactions are being externally analyzed and signed. Miniscript is not of course a complete solution, for example it cannot solve all of the high-risk edge cases that are present in the lightning network, but it is a big step forward and I believe that widespread use of Miniscript would be a huge boon to the Bitcoin ecosystem. On Mon, Aug 19, 2019 at 7:18 PM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi all, > > Miniscript is a project we've been working on for the past year or so, > and is now at a stage where I'd like to get it some more attention. It is > joint > work with Andrew Poelstra and Sanket Sanjalkar. > > It's a language for writing (a subset of) Bitcoin Scripts in a structured > way, > enabling analysis, composition, generic signing and more. > > For example the script > >OP_CHECKSIG OP_IFDUP OP_NOTIF OP_DUP OP_HASH160 > OP_EQUALVERIFY OP_CHECKSIGVERIFY <144> OP_CSV OP_ENDIF > > in Miniscript notation would be > > or_d(c:pk(A),and_v(vc:pk_h(B),older(144))) > > making it human (engineer?) readable that this is a script that permits A > to > take the coins at any time, and B after 1 day. A full description of the > language can be found on the project website > http://bitcoin.sipa.be/miniscript > > Using Miniscript it's possible to: > * Write descriptors for addresses for scripts that implement things more > complicated than multisig. > * Make software that can deal with composition of policies (e.g. have funds > in a 2-of-3 setup where one of the 3 "keys" is itself a policy that > involves > perhaps multiple devices and timeouts). > * Compile complex spending policies to efficient scripts. > * Figure out under what necessary and/or sufficient conditions a script > can be > satisfied. > * Given signatures for a sufficient set of keys (and hash preimages, if > needed), > generically construct a witness for arbitrary scripts, without metadata > apart from the script itself and public keys appearing in it. This means > generic PSBT signers are possible for this class of scripts. > * Compute the bounds on the size of a witness for arbitrary scripts. > * Perform static analysis to see if any of Script's resource limitations > (ops limit, stack size, ...) might interfere with the ability to spend. > * Who knows what else... > > We have two implementations: > * a C++ one (https://github.com/sipa/miniscript) > * a Rust library (https://github.com/apoelstra/rust-miniscript). > > The implementations are a work in progress, but through large scale > randomized > tests we have confidence that the language design and associated witnesses > are > compatible with the existing consensus and standardness rules. > > To be clear: Miniscript is designed for Bitcoin as it exists today > (primarily > P2WSH), and does not need any consensus changes. That said, we plan to > extend > the design to support future script changes Bitcoin may include. > > Cheers, > > -- > Pieter > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Miniscript
Hi all, Miniscript is a project we've been working on for the past year or so, and is now at a stage where I'd like to get it some more attention. It is joint work with Andrew Poelstra and Sanket Sanjalkar. It's a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing and more. For example the script OP_CHECKSIG OP_IFDUP OP_NOTIF OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIGVERIFY <144> OP_CSV OP_ENDIF in Miniscript notation would be or_d(c:pk(A),and_v(vc:pk_h(B),older(144))) making it human (engineer?) readable that this is a script that permits A to take the coins at any time, and B after 1 day. A full description of the language can be found on the project website http://bitcoin.sipa.be/miniscript Using Miniscript it's possible to: * Write descriptors for addresses for scripts that implement things more complicated than multisig. * Make software that can deal with composition of policies (e.g. have funds in a 2-of-3 setup where one of the 3 "keys" is itself a policy that involves perhaps multiple devices and timeouts). * Compile complex spending policies to efficient scripts. * Figure out under what necessary and/or sufficient conditions a script can be satisfied. * Given signatures for a sufficient set of keys (and hash preimages, if needed), generically construct a witness for arbitrary scripts, without metadata apart from the script itself and public keys appearing in it. This means generic PSBT signers are possible for this class of scripts. * Compute the bounds on the size of a witness for arbitrary scripts. * Perform static analysis to see if any of Script's resource limitations (ops limit, stack size, ...) might interfere with the ability to spend. * Who knows what else... We have two implementations: * a C++ one (https://github.com/sipa/miniscript) * a Rust library (https://github.com/apoelstra/rust-miniscript). The implementations are a work in progress, but through large scale randomized tests we have confidence that the language design and associated witnesses are compatible with the existing consensus and standardness rules. To be clear: Miniscript is designed for Bitcoin as it exists today (primarily P2WSH), and does not need any consensus changes. That said, we plan to extend the design to support future script changes Bitcoin may include. Cheers, -- Pieter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
