Is there a listing of strange or unusual scripts found in transactions?

I’m studying scripts and am looking for strange or unusual scripts that have appeared in any of the *coin networks..(outside the standard ones listed on this page)

  • Is any one person, or website listing non-standard transactions that are not generated by the default client?

Ideally there would be an analysis of the script and what’s going on, but I’m not picky. I’d even settle for a command line method to extract this data and discover it myself.

My goal is to learn what contracts are occurring in each network and determine the frequency of each. (How popular is multi-sig tx over time)

Alternatively, I can use this as a tool to learn how people are using the scripting language.

What are orphaned and stale blocks?

If I understand it right, a stale block is a block for which an earlier confirmation has been found and was accepted by majority of people. This block is considered invalid and is later never used.

But what is a orphaned block. How is it created? How is it verified that it is orphaned and what is done to the orphaned block?

How do I optimize my usage of oclvanitygen?

I’d like to extract the most performance possible from oclvanitygen. Can anyone tell me what the best practices are with this tool?

Examples may include:

  • Use operating system X, or video card Y
  • Ensure that the file specified with the -F option has more than 7 characters per row
  • Ensure that there are no more than Z quantity of lines in the file
  • Set a custom grid size with the -g option (what is this?)
  • How many work items per thread ( -w option)
  • What custom options should I use (-d option)

How do you perform double-SHA-256 encoding?

The Bitcoin Protocol-specification gives an example of double-SHA-256 encoding.

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)

I’ve tried various SHA256 calculators and the first encoding matches no problem, but the second always resolves to

d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9

I’ve also tried UPPERCASE and swapping the byte endianness.