Some addresses on this page indicate whether the address is a multisig, and what the threshold signature scheme is. How do they detect this?
Add a comment
|
2 Answers
There are different types of addresses in Bitcoin. The simplest format is called pay-to-public-key-hash (p2pkh) which locks funds to a single private key. Another is called pay-to-script-hash (p2sh), which allows to lock funds to a script that encodes the spending conditions.
The recipient(s) of a p2sh output must reveal the redeemscript upon spending and must fulfill the encoded conditions to prove their ownership. P2sh addresses are recognized by having a 3… prefix. The most popular application of p2sh is to encode a payment to multiple co-owners, i.e. multisignature addresses. For example in the case of a 2-of-3 multisig, said redeemscript would be composed from 2 pubkey1 pubkey2 pubkey3 3 OP_CHECKMULTISIG where the "2" is the required signatures and the "3" the number of eligible public keys. The proof of ownership is then provided by two signatures corresponding to two of the listed public keys. In other words, once a p2sh output is spent, all that needs to happen is that you read the m-of-n directly from the redeemscript. ;)
Also, since the p2sh address is derived from a hash of the redeemscript, you cannot tell anything whatsoever about the content of the redeemscript until it is revealed in spending (unless you're part of the recipients that created it in the first place).
For a complete walkthrough, see CHECKMULTISIG a worked out example.
Once an address has been spent from, the script that is used to create the P2SH address will be revealed in the spending transaction. So any addresses that have the 'm-of-n' information listed on that page will be addresses that have been spent from in the past.
Interestingly, a BIP for something called Taproot was just published by @PieterWuille, which would allow for coins held at multi-sig addresses to be spent in a way which does not sacrifice privacy by revealing the full locking script in the spending transaction. Using Taproot construction (which also requires Schnorr signatures), if the key-holders end up spending the funds in a manner that they agreed upon during the time of the script (address) creation, then the data that is published to the blockchain just looks like a normal P2PKH spend, instead of a P2SH spend. This is good for privacy, but can also allow savings on transaction fees, as more complicated and data-intensive scripts can be used without having to pay more fees than a standard P2PKH transaction (assuming the 'best-case spend', of course.).
So if Schnorr and Taproot are adopted, then stats like this will be more difficult to attain.
