Any news on multisig support? Are you working on it or waiting for donations?
i would contribute to a multisig bounty.
Like a zero-fee transaction, eventually it'll get in. Probably.
In the absence of a business model, my priorities are driven by my personal needs, which lately are about space efficiency, bitcoind 0.8.x compatibility, and integrating contributions from other developers. Donations do encourage me to work, at roughly $40/hour for features that I want to add anyway, up to $100 for site-specific things that don't improve Abe for most users. (I'd quote a price in BTC, but BTC/USD is too volatile, as I have ranted in other threads, for reasons that led me to create Abe in the first place.)
I'd like to get clear what "multisig support" means. Now that I have a full database, I can search for new transaction types. There have been a few hundred transaction outputs that use OP_CHECKMULTISIG as specified in BIP 11 M-of-N Standard Transactions
. Blockchain.info calls these "escrow" outputs. Examples: 1 2
. Given an address that redeemed an M-of-N output, Blockchain.info lists the transaction, as in this example
. But if the address did not sign it, its page does not list the transaction: example
. Mapping from addresses back to these transactions will take some extra work.
There have also been a few hundred outputs as in BIP 16 Pay to Script Hash
(P2SH). These have receiving addresses that start with "3" as per BIP 13
. Example: 1
. These output scripts are opaque, but the redeeming input reveals one or more addresses. As far as I know, Blockchain.info does not correlate an address so revealed with the original P2SH transaction. Perhaps it would be useful to do so, and this would require some extra work.
There have also been a few thousand regular pubkey outputs as in this example
that Abe can not parse because the public key is shorter than usual. This has nothing to do with multisig and is really a bug in Abe, but it would be nice to fix. There are also a thousand or so outputs of miscellaneous types unrecognized by Abe. They may all be nonstandard, but it would be nice to make sense of any that are frequent or demonstrably redeemable.
ThomasV sent me this:
it would be nice if Abe could support multisig addresses. For this I think you only need to update deserialize.py.
I did it in Electrum, so you can lookup Electrum's deserialize.py file:https://github.com/spesmilo/electrum/blob/master/lib/deserialize.py
(you don't want to use that file as is, it probably has other differences)
see at the end, the function called get_address_from_input_script.
It is not directly usable: Abe would have to pass the script to the function where currently it passes pubkey_hash to another function. But this would be very easy and would add at least some value regarding P2SH.
A full implementation of M-of-N, P2SH, and mapping from address back to M-of-N transaction would take me about 20 hours, so figure 11 BTC at current rates.