wallet – Multisig Setup – Pruned Bitcoin Core on Computer vs. Dedicated Hardware

Both a full Bitcoin and pruned node can be run from Bitcoin Core with the same level of security.

Pruned nodes have the following differences:

  • Does not keep the full blockchain on disk
  • Size limit is defined by the user
  • Will discard unnecessary block data as it synchronizes

As a user on the Bitcoin Talk forum explains, most “dedicated hardware” Bitcoin Nodes are software wrappers around Bitcoin Core which may be less secure than running Bitcoin Core directly.

See Multisig Setup – Pruned Bitcoin Core on Computer vs. Dedicated Hardware – bitcointalk.org

multi signature – Is this scheme for multisig audit of Trezor + Coldcard ok?

My plan is to make a multisig between coldcard and trezor. I want to audit and verify that I indeed own the 2 keys of these wallets, using a raspberry pi zero (no wifi/bluetooth by definition) on a very old HDMI tv with no internet either, and using a virtual keyboard and simply a mouse on the pi zero.

These are the possible risks I want to mitigate:

To eliminate the risk of the trezor generating a private key I don’t own, I’m gonna put its key on the raspberry pi zero and see that it generates the same master pubkey and shown in trezor. This proves I own this key, but it might be a kew that someone already owns. No problem, that’s why I’m doing multisig.

On the coldcard, I’ll generate a seed using dices, and then verify on the raspberry pi that those dice rolls indeed generate the private key shown by coldcard. This proves that I own a private key that no one owns, because it was generated using dices.

Now that I have 2 private keys that I own, and at least one of them I’m the only owner, I can create a multisig wallet on Ethereum or maybe BlueWallet. I’ll annotate the first 10 addresses generated by the software wallet, and verify if they match on the coldcard and on the trezor. If the 3 show the same 10 set of addresses, I can consider these addresses safe for receiving Bitcoin.

I’ll then receive some Bitcoin on one address, erase both wallets, restore them with the private keys, and then try to spend this Bitcoin, just to make sure I really owned the coins.

What are the possible problems I can encounter? Am I forgetting something important?

PS: I know that if the trezor has a malicious random number generator and it creates a private key that not only myself own, this is a privacy leak, but not a problem. And it’s a privacy leak only when I spend from this address, revealing the public key on the blockchain.

I also plan to use just PBST air-gapped transactions on Coldcard, and a trusted computer to broadcast.

multi signature – Bitcoin 2 of 4 Multisig script with one required

Hi I am to write a bitcoin locking script with property that 2 out of 4 signatures should be verified, but among those verified 2 there is a specific signature that should be verified.

I.e only 1 manager combined with 1 employee in a 4 employee company(including manager) can unlock the script, but the order of the signatures in unlocking script should not be important.
I have given a lot of thought to it, but was unable to satisfy the property that order doesnt matter in unlocking script. Could you please help me?
Thanks in advance!

multi signature – Trade-offs in 2 of 3 multisig release transaction

What are the trade-offs involved in:

  1. Buyer and seller signing the transaction. HodlHodl signs the transaction only in case of dispute.


  1. Seller and HodlHodl signs the transaction. Buyer signs the transaction only when dispute.

According to https://gitlab.com/hodlhodl-public/hodl-client-js/-/blob/master/multisig-spec.md

Server generates release transaction with output address taken from user’s trading settings.
Server signs it’s part of the release transaction input with it’s private key.

Server signature is always goes first expecting client signature as next chunk.
Client decrypts it’s seed with payment password.
Client signs the transaction with it’s private key derived with index and sends back to server.
Service broadcasts provided transaction.

NOTE: In both examples below transaction is signed by seller.
Buyer has to sign transaction only if contract is disputed and resloved in favor of buyer.

Will the trade-offs remain same for any other similar bitcoin projects using 2 of 3 multisig?

multi signature – Recovering 2 of 2 multisig HD Wallet with bip38 encrypted private key

I have been trying to figure out if it is possible to restore my wallet with the current information I have.

  • The wallet is a 2 of 2 multisignature HD wallet
  • The first key is Bip38 and requires a password to decrypt private key
  • The second key has a 24 word seed

I currently have both xpub’s, and the 24 word seed of the second key. Unfortunately I do not have the password for the bip38 encrypted private key. I created the wallet a while ago and cannot remember the password but I have some ideas of what the password might have been. Given this information, I believe it might be worthwhile to try to brute force the password.

I am unsure the best method of brute forcing a multisig wallet. If it was a non-multisig wallet, I could just do something like this:

const decryptedKey = bip38.decrypt(encryptedPrivateKey, password);
const privateKeyWif = wif.encode(
const coinkey = CoinKey.fromWif(privateKeyWif);
console.log('address with btc im trying to recover' === coinkey.publicAddress, password) // Found password

The address I am trying to recover starts with a 3 as it is a P2SH address (multisig). When I run the code above I get an address that starts with a 1 (not multisig). With all this being said, what is the best way (if there is any) to validate the “correctness” of a password during brute forcing one key of a multisig wallet?

bitcoind – Multisig synchronization – Bitcoin Stack Exchange

In order to set up a multisig transaction, your bitcoind needs to know the public keys that make up that multisig address, and the order that those public keys are listed in. The address itself doesn’t contain this information. If you already have 1 bitcoind set up with this information, you can use this script to copy that information to a second bitcoind.

Then, once you do that, you can craft a multisig transaction, then distribute that transaction to each of the signers.

multi signature – import multisig wallet into bitcoin core, Vpub keys are not valid. how to?

I’m trying to import an HD multisig wallet created with Electrum into Bitcoin core v0.21.0.0.

I managed to do so with the fantastic cryptoadvance.specter server, but I also would like to import it using the standard bitcoin-cli commands.

This is what I managed to do so far, and it only works if I convert the pub keys Vpub Multi-signature P2WSH to tpub P2PKH, so for example:




then I can run this program and it seems to be working fine, unless it’s not because the resulting addresses are very different. (the wallet created with Specter matches perfectly the one in Electrum, it finds the correct transactions as well)



echo "Making wallet '${wallet}' from ${pub1} ${pub2}"

descriptor=$(bitcoin-cli getdescriptorinfo $rawdescriptor | jq -r '.descriptor')
bitcoin-cli deriveaddresses  ${descriptor} "(0,0)"

bitcoin-cli createwallet $wallet true
bitcoin-cli -rpcwallet=$1  importmulti '({"desc": "'$descriptor'", "internal": false, "range": (0, 1000), "timestamp": 1609459200, "keypool": true, "watchonly": true, "label": "lol"})' '{ "rescan": true}'
# bitcoin-cli -rpcwallet=$1 rescanblockchain

I can’t use the Vpub keys because bitcoin-cli (v0.21.0.0) throws this message:

key 'vpub5UXsYa6RJKsn5DYT52PanEWhidjBRpt11vx7Y3MP4ShSRnEH9TZrGN2Cg4KjK2GVJNg2ynpZzq8YC1Jr1m3cnTfV8wsNT7EwTaYMy4PCDAg' is not valid.

At this stage i’m only interested into a watch only wallet, so i don’t need to use private keys.

Also, I’m in testnet and I have testnet=1 on my bitcoin.conf

I’ve tried reading as much as I could but I think i hit a wall now and I don’t know how to continue.
Any help would be greatly appreciated

bitcoin core – Is Sharding a Good Alternative to MultiSig?

For security reasons, we require that each withdrawal be “approved” by multiple servers so that in the event that a single server is compromised the attacker won’t be able to siphon funds from the entire wallet. The typical approach used to execute this concept is a MultiSig address where the transaction is only approved after it is signed by multiple entities.

However, the fees for a 2/3 MultiSig transactions are nearly twice as high as fees for a regular transaction. If we wanted 3/4 (or higher) MultiSig the fees would be even costlier. This got me thinking of a way to take advantage of the security benefits offered by MultiSig transactions without suffering from excessive fee consumption in the process.

The immediate solution that comes to mind is sharding. In short, instead of using MultiSig we can safely break up the PK using Shamir’s Secret Sharing Scheme with unlimited schemes (such as 4-of-7 or 3-of-4 etc) and store the shards on separate servers thereby requiring multiple servers to “sign” a withdrawal request.

Does MultiSig provide any (security) benefit over sharding? Is sharding a viable alternative to MultiSig?


Perhaps the only problem with this proposal is that each server cannot independently “authorize” the transaction using its “shard”. At some point, all shards would need to be known to “reassemble” the PK so the attacker could still use this as the “weakest point of attack”? Is this correct?