48
I know this question is old, but I stumbled upon it looking how to teach myself how multisig addresses work, and I imagine others will to. So I’m going to try to explain the typical flow for creating, adding bitcoins to, and eventually spending a multisig address. This explanation is aimed at beginners, so please excuse my lack of brevity. First off, some ...
36
Warning: I've never actually worked with the Schnorr signature scheme. The
following is my analysis based on reading the Wikipedia
article, the ed25519
page, and some discussions between devs in
#bitcoin-dev.
Likely Changes
Changed op code behavior: we will need an op code to check
Schnorr signatures. With a hard fork, we can redefine
op_checksig and
...
31
We need to distinguish the limitations for validity and standardness. The first is determined by the consensus rules (which cannot change without a hard fork). The second ones are determined by local relay and mining policies implemented in the reference client, and can change from version to version.
In addition, we need to distinguish raw multisig (a ...
19
Your question seems to assume that the only goal is minimizing on-chain transaction size. Reducing size and related costs is certainly something that can be improved upon, but it's far from the only thing. The primary advantages of the Schnorr proposal are:
Better privacy, by making different multisig spending policies indistinguishable on chain. When ...
13
I expect that CHECKMULTISIG will call the CHECKSIG function and manipulate the stack to run CHECKSIG in a loop until it terminates and either has its M-out-of-N valid sigs or not?
That's not really how it's implemented internally, so there are a couple of pitfalls if you imagine it operating like that.
OP_CHECKMULTISIG
Here's the high-level description of ...
12
By reading this answer, I understand that in m-of-n multisig addresses, m and n are limited by the maximum size allowed by the P2SH redeemScript (i.e. 520 bytes).
That's correct. Even though the OP_CHECKMULTISIG script opcode supports more keys, more than 15 public keys simply don't fit in a P2SH redeemscript, so that becomes the limiting factor.
However,...
11
The most fundamental difference is that Shamir Secret Shares shares... well, a secret. Multisig shares the ability to sign, but does not share the private keys directly.
You could use SSS to implement a sort-of multisig scheme. Multiple people come up jointly with a single key, split it into pieces, and then separate them. Now they want to produce a ...
10
There are two basic templates for using multisig for "escrow", 2-of-2 and 2-of-3. In both cases, you can currently use bitcoin-qt's raw transaction API to create the addresses and transactions.
In 2-of-2 you do the following:
Create a multisig address which requires signatures from both the buyer and seller.
The buyer sends funds to this address.
Seller ...
9
According to the glossary
the possible prefixes for bitcoin addresses are 1,3 or 5:
I'm quoting here:
Address
Bitcoin address is a Base58Check representation of a Hash160 of a
public key with a version byte 0x00 which maps to a prefix "1".
Typically represented as text (ex. 1CBtcGivXmHQ8ZqdPgeMfcpQNJrqTrSAcG)
or as a QR code.
A variant ...
9
Yes you can do public key recovery with EC Schnorr. Consider
R = kG, [r = R.x, s = k + H(r, m)d], Q = dG
verify:
sG = ?R + H(r, m)Q
recovery:
sG = kG + H(r, m) dG = R + H(r, m)Q
so
Q = 1 / H(r, m) * (sG - R).
(And to compute R from r if R is point-compressed, R = (r,f(r)) R' = (r,-f(r)) and try both R and R' by checking if the signature is valid with ...
9
If you are comfortable with a command line, I have used ssss-split and ssss-combine for sharding encryption keys in a n-of-m scheme. These utilities use Shamir's Secret Sharing Scheme to safely break up secrets for later reassembly.
For example, you could create a 4-of-7 scheme, where you would hide shards in 7 different locations (personal safe, safety ...
8
Advantages of OP_CHECKMULTISIG over Shamir Secret Sharing for k-of-n:
There is no need to reconstruct the actual secret key on one specific machine. With SSS, you're inherently relying on that one machine being able to verify that what it's going to sign is what is intended - otherwise you may e.g. be sending your entire balance instead of just the payment ...
7
You do not need private keys at all to generate multisig m-of-n address!
You do need public keys. Yes, three for m-of-3 and eleven for 5-of-11 (for example)
7
See BIP45.
Electrum is ordering the pubkeys lexicographically, ie
03722ef79a70b43843c642f3495d2b9b8a6403189d52a04ecac652c133f7940fed
03f5ce19296793c6695bfefd7ead459a3f88ef776d8fc08b470dbc749d266d5
03f9652bfbbfb426eb2011db774c97866e00effdf954cc225807f89b23150dda3a
Note they're all 03, so it's 72=>f5=>f9
7
OP_CHECKMULTISIG contains a bug which consumes one extra element from the stack. Due to this, an additional OP_FALSE (0x00) is pushed for multisig scripts to make the script evaluation valid.
7
Taproot generally has two ways of spending. The default way is to spend the output using the key path: pay-to-taproot then behaves like a p2pk output except that it is using a schnorr signature and the corresponding address being encoded using bech32.
The alternative is to reveal that the inner key was tweaked with the root of a Merkle tree, the Merkle path ...
6
A public key in Bitcoin is a pair of 256-bit numbers used as part of the ECDSA scheme. A Bitcoin address is a Base58-encoding of the 160-bit hash of the public key (the hash function in question being RIPEMD160 of SHA256).
From the public key you can easily and deterministically compute the address, but from the address alone you cannot deduce the public ...
6
I calculated it here summarized per month:
month btc count
201201 0.010000 1
201202 1.150000 5
201203 0.015000 2
201209 0.010000 1
201212 137.737103 46
201301 9.781411 9
201302 0.100000 2
201303 527.570925 724
201304 385.334698 1137
201305 300.712263 991
...
6
No. A "multisig address" is really a hash of a redeem script encoded as a P2SH address. Redeem scripts can't be nested, which means you can't include one redeem script inside another redeem script, so it is impossible to implement the feature you describe under current Bitcoin consensus rules.
6
Yes, it's called HDM (Hierarchical-Deterministic-Multisig).
There's no standard, per se, and the main proponent (to the best of my knowledge) is/has been Vitalik Buterin, of Ethereum/Bitcoin Magazine fame.
There's code in the Python pybitcointools library which allows one to implement this on a low level. The functions are called:
bip32_hdm_script and
...
6
No, but instead you can make a 3-of-4 multisig where you hold both keys A and B, then you give key C to a family member, and D to someone else(just as an example). This way you are certain that you are involved in all transactions. I presume this is the end result you are after?
6
Electrum uses BIP45.
m / purpose' / cosigner_index / change / address_index
Example for non-change of the first cosigner and first address: m / 45' / 0 / 0 / 0
See: https://bitcointalk.org/index.php?topic=1634517.15
and
https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki
6
Until a P2SH-P2WPKH UTXO is spent and the redeemScript is exposed, a P2SH-P2WPKH address is indistinguishable from a non-segwit P2SH address (such as a non-segwit multi-signature address)
Reference: https://bitcoincore.org/en/segwit_wallet_dev/
That's because a P2SH address is still a hash of the script, regardless of whether the script is an embedded ...
6
validateaddress has changed to be separate from the wallet, so it cannot look up the public key information for an address. Use getaddressinfo instead in order to get all of the wallet information for an address, including the public key.
6
The number of signers with MuSig (and MuSig2) is practically infinite. For example, creating a MuSig signature with 1 million signers takes about 130 seconds on my laptop (see https://github.com/jonasnick/musig-benchmark).
However, MuSig(2) does not have the same functionality as OP_CHECKMULTISIG. MuSig only supports m = n which is the definition of "...
5
This is the new issue, the one that's causing all the trouble. You basically have two choices:
Don't spend any of your own outputs until you're quite confident they're fully confirmed. For example, you could wait for three confirmations.
Be prepared to deal with this problem by monitoring your outstanding transaction chains and re-issuing any orphaned ...
5
from 0-of-0 upto 20-of-20
https://blockchain.info/tx/970b435253b69cde8207b3245d7723bb24861fd7ab3cfe361f45ae8de085ac52
is 0-of-0 p2sh redeemption
https://blockchain.info/tx/da738e29f64e90ae46dcc3e6b4154041d6324abbe7919e722d486a4a3148b7dc
if 20-of-20 bare multisig redeemption
https://blockchain.info/tx/...
5
My understanding is that one needs the private keys of Adres1 and Adres2 to be able to spend from MultiSigAddress. Is this correct?
Yes that is correct
What if one of the addresses belonged to someone else? How could I use the funds on MultiSigAddres using Bitcoin Core in that case?
You will need the private key for both addresses (public keys) in order ...
5
I tested it by creating a secure wallet on BitGo.
They gave a multisig address for deposits. 2/3 of keys are needed to withdraw Bitcoins. BitGo holds one key, you get private key and backup key.
You don't need to printed private key to withdraw Bitcoins. the passphrase is enough (apparently the key is derived form the passphrase).
BitGo cannot do Bitcoin ...
5
You're correct that Gavin has all three private keys available to him at the start, but you're missing that he only uses the public keys to create the P2SH multisig address. Specifically, this line from the example is listing only public keys,
./bitcoind createmultisig 2 '["...
Only top voted, non community-wiki answers of a minimum length are eligible
