offline / multisig UX #56

issue fanquake openend this issue on August 14, 2020
  1. fanquake commented at 10:04 am on August 14, 2020: member

    Moved from https://github.com/bitcoin/bitcoin/issues/16954.

    Continued discussion from https://github.com/bitcoin/bitcoin/pull/16944#issuecomment-534538035, based on @gwillen’s offline signing branch: https://github.com/gwillen/bitcoin/tree/feature-offline-v2

    If we make the entire Send experience a modal, things might get a bit simpler.

    IMG_4970

    Sorry for the handwriting :-) There’s 3 stages to a transaction:

    1. Draft / compose: enter recipient, amount, fees, etc. (the current Send screen).

    This step is skipped when loading a PSBT (e.g. via menu: Transaction -> Load, or a smart clipboard).

    1. Sign: currently a popup which confirms the details. With hardware wallets (e.g. #16549) this should enumerate connected wallets and let you sign one by one. In a multisig situation it should detect if any signatures are missing, and rename the 3rd step to “Export”.

    2. Finish / Export: once again repeat the importantant details. For basic wallets with private keys in it, this should just show that the transaction has been broadcast. With a completed PSBT it should let the user choose between broadcasting or exporting (clipboard, save to disk).

  2. fanquake added the label Brainstorming on Aug 14, 2020
  3. Rspigler commented at 0:47 am on August 23, 2020: contributor

    Why does this start with, ‘On your ONLINE computer: Click ‘Save to file…’to save your unsigned transaction to a file and transport it to your offline computer’

    Shouldn’t the online computer only be used for broadcasting the transaction? This would be more secure

  4. gwillen commented at 1:29 am on August 23, 2020: contributor

    @Rspigler The offline computer, inherently due to being offline, does not have a copy of the blockchain. That means it can’t create transactions, because of Bitcoin’s UTXO model. Every transaction must spend some coins, but you need the blockchain in order to know what coins you have.

    I copied this basic workflow from Armory, and from BIP 174 PSBT, but in principle there are other workflows possible, and you could push more work onto the offline machine – you could have the online machine merely provide a list of coins in the wallet, and let the offline machine perform all coin selection and transaction creation. I don’t have a sense of what the benefits / drawbacks of such a setup might be. (In the Bitcoin setting, where all transaction contents are public, there can be no privacy benefit that I can see; everything will eventually have to pass through the online machine anyway. Any security benefit from having the offline machine build the transaction SHOULD also be available from using the offline machine to review the transaction before signing it, which is the current workflow that I think everybody uses.)

    (One could imagine a privacy-coin setting, unlike Bitcoin, where the online machine need not even know which coins were spent. But I don’t know enough to speculate about what information the offline machine would need for transaction creation in that case, and it’s not directly relevant to Bitcoin Core at any rate.)

  5. Rspigler commented at 2:49 am on August 23, 2020: contributor

    ‘Facepalm’. Duh.

    My concern was that if the workflow was going online->offline and back to online, that that wouldn’t be a secure airgap, and would be an avenue for malware transfer.

    If more work was pushed onto the offline machine, it would still need some data input, like you alluded to. Unless that data could be manually input on the offline machine (probably not recommended due to user error), qr codes would be a good solution because they have a small attack surface and are verifiable (unlike USB’s).

  6. gwillen commented at 2:57 am on August 23, 2020: contributor
    Unfortunately yes, there is always the online-offline-online information flow somewhat inherent in this workflow. USB sticks are popular for this but obviously have a certain amount of attack surface. QR codes are definitely the most popular proposed alternative I’m aware of (but for large transactions you end up needing more than one, which has its own issues.)
  7. Rspigler commented at 9:26 pm on August 23, 2020: contributor

    This probably is no longer the place for this discussion then, as I don’t want to crowd or slow the implementation of better UX for current offline/multisig design.

    Core produces QR codes currently, but doesn’t have the ability to scan them: https://github.com/bitcoin/bitcoin/issues/9913 This discussion can probably be continued after that is merged.

    Is there still a plan for a general ‘Wallet Composer File’ like discussed here: https://github.com/bitcoin/bitcoin/issues/18142

  8. Rspigler commented at 7:21 am on May 13, 2021: contributor

    There is now a proposed BIP standardizing a process for setting up multisignature wallets - https://github.com/bitcoin/bips/pull/1097 Also a proposed BIP for an updated hierarchy for cosigners in multisignature wallets - https://github.com/bitcoin/bips/pull/1089

    This would include descriptor wallets, PSBTs, and (hopefully) QR codes.

  9. fanquake referenced this in commit 9b49ed656f on Oct 20, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin-core/gui. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-03 17:20 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me