Awesome multisig PR labyrinth guide #24861

issue Sjors openend this issue on April 15, 2022
  1. Sjors commented at 11:17 am on April 15, 2022: member

    @ryanofsky recently suggested that I should write an overview of how the various pull requests spread over different repositories relate to some bigger picture view.

    See the multisig tutorial for how things currently work.

    I typically have the following future multisig wallet in mind to guide my thinking:

    1. a computer running Bitcoin Core holding one master key (key 1)
    2. one or more hardware wallets with additional keys, via HWI (keys 2 … n)
    3. taproot keypath using n-of-n MuSig2
    4. a fallback with fewer keys after some time elapsed
    5. a GUI wizard to set this up (simple Python command line tool until then)

    The descriptors for this could be hand crafted, but it would be nice to have: 6. Miniscript compiler that can generate this

    What’s Missing?

    • Taproot support for external signers:
    • Timelock support for descriptors: this will be added along with full MiniScript support in #24148 & #24149 (@darosior).
    • Ability to handle descriptors for which we have 1-of-N keys. Descriptor wallets currently expect the wallet to be either watch-only and have no keys, or to have all the keys.
      • #25907 makes it possible to create a wallet with a seed, but without any descriptors.
      • The user would grab an xpub from it (#22341 ) to construct a multisig descriptor and then import that.
      • PR’s to move in the right direction: #26728 and #23544 (up for grabs)
    • MuSig2 setup and signing support, which requires:
      • a BIP to specify new PSBT fields (tracked in #23326)
      • Bitcoin Core changes; no PR yet afaik, (tracked in #23326)
      • At least one other (hardware) wallet to support it
        • I’m not aware of any hardware wallet working on this yet
        • testing with two Bitcoin Core nodes is good start
      • HWI changes: additional commands for:
        • initial setup
        • signing (although perhaps calling signtx multiple times with the right PSBT will “just work”)
    • a simple Python setup wizard
      • right now Specter Desktop is by far the easiest way to setup a multisig wallet. But it’s a huge dependency (including a bunch of NPM packages for their web interface). A simple Python script in contrib/ could call HWI to get a list of signers, ask what threshold to use, call createwallet to generate a blank wallet, fetch an xpub from it, and then call importdescriptors.
      • the script could use BIP 129 / BSMS (perhaps initially without encryption)
      • Specter doesn’t set the external_signer wallet flag, so I have a trivial PR to do that manually: #21928
    • a GUI setup wizard: once we have an established work flow, we would implement that in the GUI

    Misc

    I have a PR that improves address display handling on the device:

    Even better would be if we had a feature to ask the wallet for a signature to prove it has the private key (without passing that information to the outside world of course, see #24186). This requires BIP-322 support on our end (#24058), at least one hardware wallet to support it, and a new HWI signmessage command. Perhaps this can later be expanded to allow your device to prove that it (still) has the keys it needs as a co-signer.

    Miniscript compilers currently doesn’t support Taproot (e.g. to find the optimal tree structure), but I’m assuming you can still hand craft a leaf containing MiniScript.

  2. jonatack commented at 11:21 am on April 15, 2022: contributor
    Thanks @Sjors, this is very helpful.
  3. laanwj commented at 11:44 am on April 15, 2022: member
    Thanks! It’s definitely good to have an umbrella issue here, how to get to the point where it’s more or less easy to do multisig with bitcoin core.
  4. fanquake commented at 12:10 pm on April 17, 2022: member

    we would just add support new commands in the external signer command interface

    Can you elaborate on your longer term plans for external signing / Boost Process.

    Process is currently relatively poorly maintained; bugs are remaining unfixed for multiple Boost releases, the code and issue tracking is confusingly spread across multiple repositories (which have different versions of the code), no recent “modernization” (i.e no option use std::filesystme over boost::filesystem, like other Boost modules, which is why we no-longer support external signing on Windows). It’s inclusion in our project is also a downside to our Boost consolidation / removal, i.e #24742.

    If we continue to use it going forward, I think we need some sort of plan, addressing the above, rather than leaving it ignored while start accumulating workarounds in our own code to support it, and it’s presence potentially blocks other goals.

    Happy to split this out into a separate issue for discussion.

  5. Sjors commented at 12:03 pm on April 18, 2022: member

    Can you elaborate on your longer term plans for external signing / Boost Process.

    Ideally replace it, but I have no idea with what. That hasn’t changed since 2019. In the original PR #15382 (comment) Garzik pointed an alternative from a 2016 blog post. Interesting that repo does have some ongoing development: https://github.com/arun11299/cpp-subprocess

    It doesn’t support Windows (well) at the moment, but that might be acceptable since we already (temporally) Windows support anyway.

    Happy to split this out into a separate issue for discussion.

    Indeed seems better to have a separate issue. Swapping out the implementation of RunCommandParseJSON should have no impact on the rest of the architecture.

  6. Rspigler commented at 4:41 pm on April 18, 2022: contributor

    I too had some concerns with one of the original PRs (https://github.com/bitcoin/bitcoin/pull/21935#issuecomment-840110786) re: external signers. Revisiting this I think could be good. I typically build with ./configure --disable-external-signer

    That being said, my main goal is setting up (offline) multisig with Bitcoin Core, and I think it is many other people’s goals to set up a wallet as you described in the OP - so thank you for setting up this umbrella issue Sjors! We are getting closer and closer to the final goal!

    I think some other PRs that could be good to add to the above tasklist would be:

    For Taproot support for external signers: (Besides the already linked #22558 in the OP):

    Additional Miniscript PRs:

    Descriptors

    The GUI probably should be built with the new QML based fork? (https://github.com/bitcoin-core/gui-qml) @jarolrod @hebasto @Bosch-0

    GUI:

    BIPs to be supported:

    I had set a $1,500 bounty for a GUI in Bitcoin Core that allows for the setting up of an (offline) multisignature wallet (here: #21071). Since then, there’s been further work and standardization on this project. I am raising this bounty to $10,000, to be paid out in bitcoin. Payments will be made in part as individual tasklists are completed; to be divided up to developers who worked on the code and helped review it; at my discretion. This bounty update overrules and succeeds completely the original $1,500 bounty.

    Bounty_Signed.txt

    Also:

    Addition:

    • The GetExternalSigner changes that will be needed as discussed here

    Also, ultimately:

    So that threshold spends can be implemented privately

    Edit: Damn formatting

  7. Bosch-0 commented at 3:27 am on April 20, 2022: none

    Thanks for putting this together Sjors, mulitisg in core would be great.

    As @Rspigler mentioned, the QML project aims to be a more modern, user friendly version of the current GUI. Would be great for the GUI component of this effort was put towards the new QML framework. Imo putting a feature freeze on the widgets GUI and slowly moving towards QML as the project develops would prevent a lot of technical debt - something we don’t have a lot of room for.

    Tagging others on the project for visibility @GBKS @promag @Mogashni.

    If you are looking ahead as to how an app like this would function, Nunchuk is a great example and imo easier to use than Specter. @hugohn

  8. Rspigler commented at 10:36 pm on May 2, 2022: contributor

    Also, ultimately: - [ ] https://github.com/ElementsProject/secp256k1-zkp/pull/138

    So that threshold spends can be implemented privately

    Placed in my original post here

  9. Rspigler commented at 0:55 am on May 4, 2022: contributor
    @Sjors Can you update the title to show the bounty? Thanks.
  10. Bosch-0 commented at 2:19 am on May 4, 2022: none
    Should also add this to https://bitcoinbounties.org/ 👀
  11. Rspigler commented at 2:41 am on May 4, 2022: contributor
    Submitted!
  12. Sjors commented at 1:13 pm on May 10, 2022: member
    Don’t know about changing the title. I’ll add a link to that site to the PR description once its added.
  13. Rspigler commented at 5:53 pm on June 28, 2022: contributor
    @Sjors #22558 can be checked off :partying_face:
  14. Sjors commented at 10:50 am on September 28, 2023: member

    Slightly updated the PR description, mainly: point to #26728 which replaces an earlier attempt, drop mention of potential NthKey MuSig2 support, since I discontinued that app.

    Are any other wallets working on MuSig2?


Sjors jonatack laanwj fanquake Rspigler Bosch-0

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-17 06:12 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me