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 ...
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
Changed op code behavior: we will need an op code to check
Schnorr signatures. With a hard fork, we can redefine
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 ...
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 ...
It seems some partial implementation exists. Quoting Gavin:
Generate a multisig address:
Gather (or generate) 3 bitcoin addresses, on whichever machines will be participating, using getnewaddress or getaccountaddress RPC commands (or copy and paste from the GUI).
Get their public keys using the validateaddress RPC command 3 times.
Then create a 2-of-3 ...
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.
Here's the high-level description of ...
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.
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 ...
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.
According to the glossary
the possible prefixes for bitcoin addresses are 1,3 or 5:
I'm quoting here:
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 ...
Yes you can do public key recovery with EC Schnorr. Consider
R = kG, [r = R.x, s = k + H(r, m)d], Q = dG
sG = ?R + H(r, m)Q
sG = kG + H(r, m) dG = R + H(r, m)Q
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 ...
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 ...
Electrum is ordering the pubkeys lexicographically, ie
Note they're all 03, so it's 72=>f5=>f9
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 ...
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 ...
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.
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:
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?
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
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)
That's because a P2SH address is still a hash of the script, regardless of whether the script is an embedded ...
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.
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 ...
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 ...
from 0-of-0 upto 20-of-20
is 0-of-0 p2sh redeemption
if 20-of-20 bare multisig redeemption
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 ...
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 ...