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 ...
A multi-signature address is an address that is associated with more than one ECDSA private key. The simplest type is an m-of-n address - it is associated with n private keys, and sending bitcoins from this address requires signatures from at least m keys. A multi-signature transaction is one that sends funds from a multi-signature address.
The primary use ...
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 ...
Bitcoin version 0.6.1 doesn't have useful multisignature support yet, either in the GUI or via the RPC interface, because there is no support for partially signing a multisignature transaction.
What is supported: creating a multisignature transaction (using addmultisigaddress), and sending to a multisignature address (either your own or somebody else's).
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 ...
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 ...
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.
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 ...
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.
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 ...
There are some m-of-n transactions in the blockchain (blockchain.info - block explorer) but they have only been recently added to the standard transaction types.
However the reason why they are probably not in wide spread use yet is there is no gui based client that can construct one. My Wallet will be able to construct them soon, I don't know how much ...
"Bitcoin Faucet Hacked"
How a future version of the Faucet will work to prevent a similar incident:
"BIP 16 / 17 in layman's terms"
"The Truth behind BIP 16 and 17"
TxID is just a SHA256 hash of binary transation data, so it changes upon any modification of transaction.
Therefore, one cannot include verification of TxID in the script in same transaction (if I correctly understood what you want to achieve).
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:
Electrum is ordering the pubkeys lexicographically, ie
Note they're all 03, so it's 72=>f5=>f9
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
After a lot of struggle, I found out that Electrum uses following root derivation for normal and multisig wallets. For example:
root/0/0 for each cosigner. Example:
m/44'/0'/0' ==> shared root key (x)
x/0/0 ==> address for first receiving multisig (derive in all cosigners shared keys. all 3 keys must be lexicographically ordered).
some semi-compatible ...
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.
Transcation in bitcoin are actually scripts, where normaly it states one input and one output address. But there are other op code such as CHECKMULTISIGVERIFY script. Each signing party will have their own public key hence their own address. The way it works is as shown:
N K1 K2 K3 M CHECKMULTISIGVERIFY
-N is the number of signature to continue
Almost all nodes on the network will not relay multisignature transactions because they are not "standard," and almost all miners will not include them in the blocks that they create (for the same reason).
The notion of a "standard" transaction was implemented after Bitcoin started getting popular and had to deal with various denial-of-service attacks that ...