So, as I'm researching all of the output scripts that I cannot successfully decode the bitcoin address for, I realize I may going about this the wrong way.
I looked for common patterns in the scripts, which normally 99.999% of all output scripts conform to.
In the early days of bitcoin people used the full 65 byte public key, then later switched to the 20 byte RIPEMD160 format nearly everywhere.
However, there are a number of other formats, including things like multi-sig, script hashes, and others, which create a lot of permutations.
I guess what I'm looking for is the following:
I want a routine which can accept a transaction output script as raw hex binary data and provide as output the public bitcoin addresses (*exactly* what would show up in blockchain.info as the output address).
something like:
struct BitcoinAddress
{
uint32_t key[25]; // the 25 bitcoin public key address
};
uint32_t findOutputAddresses(const uint8_t *scriptData, // The raw output script data
uint32_t scriptLength, // The length of the output script.
BitcoinAddress *keys, // The array of keys to return
uint32_t maxOutputKeys); // The maximum number of output keys allowed
If someone could implement this in C++ with absolutely *no* external dependencies on any other code of any code (except stdint.h) that would be ideal. I have a routine already that does this, however that routine clearly doesn't take every possible permutation into account and I gather having the magic knowledge to know how to parse the output scripts in every flavor is time consuming.
If anyone thinks they can write such a routine and has an interest, I would gladly pay a reasonable bitcoin bounty for the code snippet. It could also be very educational.
Again, the requirements are that it accepts the raw binary blob of an output script and returns one, or more, bitcoin addresses which when printed in BASE58 ASCII exactly matches what would show up in blockchain.info. It must be a single source file, C++, and have zero external dependencies on anything other than
Anyone up for that challenge?
Up until now the number of keys I failed to parse were fairly statistically insignificant, but that is no longer the case due to recent changes in how people are forming their transactions. I want to finalize my 'end of the year' statistics on the blockchain but, to do so, I cannot let any more public keys slip by unaccounted for.
Thanks,
John