This is a gross misrepresentation. You can check the original address, the money is still there:

https://live.blockcypher.com/btc/address/12wLQaz26TQxJzRo2RLch6KyQ4uc1VrNuK/
https://blockchain.info/address/12wLQaz26TQxJzRo2RLch6KyQ4uc1VrNuK

You made a mistake when creating the payment forward which resulted in a wrong destination address. Because of a set of security measures we have in place, it's very difficult to unlock the funds to send to a different or corrected address. As we felt we could have caught this particular mistake, we offered a free plan for a month in return (for a $75 value). Not to mention that you had used our services completely for free prior to that.

Now you come back 9 months later, posting FUD online. Needless to say, you have far exceeded the limits of our patience.

Do you want the callbacks to stop at some point or just have a lower number of confirmations than 6? For the latter you can just set enable_confirmations=false and create a webhook yourself with the desired confirmation count.

Not sure what exactly was the issue described above but I'm guessing it was related to decoding the JSON body. The full transaction is sent in the POST body as JSON, make sure you decode that properly with the programming language you're using (for ex in PHP check http://stackoverflow.com/questions/8945879/how-to-get-body-of-a-post-in-php).

Once you can decode the full transaction, the number of confirmations is a property there.

Hey there, co-founder and CTO of BlockCypher here.

Can you clarify what you mean by GET or POST variables? Callbacks are done using POST requests and the details of the payments are in the body of the POST as a JSON document, not as URL parameters if that's what you were expecting.

I really wish I had a better answer to this question but unfortunately it's not possible as-is. The data that gets signed and later checked by the OP_CHECKSIG operation is a hash of the transaction data, and this is how the scripts work, not something we can change. So the details of the transaction can't be extracted and checked anymore after hashed.

What we could do is, provided an option, return you the transaction data. You would have to hash it yourself before signing but at least all the information would still be there. Verification would still be not trivial though as you'd have to Base58 decode the address. Provided all that, I have a function you could get some inspiration from to do the verification (only verifies the output but in practice that's what you really care about):

func Check(txdata []byte, outputAddress string) bool {
  if len(txdata) < 25 { return false }
  decoded := base58Decode(outputAddress)
  // 4 last bytes of tx are the lock time, byte before is OP_CHECKSIG, address is right before that
  // before are the address length, OP_DUP OP_HAS160 and the length of the script
  output := txdata[len(txdata)-34:]
  oneoutput := bytes.Compare([]byte{1, 0, 0, 0}, output[0:4]) == 0
  checksig  := output[4] == 25 && output[5] == 118  && output[6] == 169 && output[7] == 20 &&
                output[28] == 136 && output[29] == 172
  addrmatch := bytes.Compare(output[8:28], decoded[1:21]) == 0
  return oneoutput && addrmatch && checksig
}

I wrote this as a way to explain how Bitcoin scripts are evaluated. Javascript was chosen for as a language the interpreter as a lot of people can read it pretty easily. Thought it'd be useful for others here:

http://www.blockcypher.com/#!Build-a-Bitcoin-Script-Interpreter-in-Javascript/cw46/C1457639-6C3B-4625-942E-C5D93E3AF602

Sorry for the late reply, just noticed this thread. I'm the founder and CTO at BlockCypher, happy to answer any technical question you'd have.

BlockCypher just added gzip payload compression support simply by setting the "Accept-Encoding: gzip" HTTP header. This should greatly improve response times, especially for people using us from Europe or Asia.

Disclosure: I'm the founder and CTO at BlockCypher.

There's a subtle distinction here:

• Invalid transactions are just refused no matter what. They're either badly formatted, use an unsupported opcode (like string manipulation ones), try to double-spend, etc.
• Non-standard transactions are valid and accepted as such but not relayed. They can be included in a block only by mining pools that accept them (like Eligius).

First a caveat: I'm not part a committer in the Bitcoin Core team but I've been following it pretty closely for a few months now.

As I understand it, the process is a fairly standard review-then-commit (abbreviated RTC as opposed to CTR):

• A change is discussed on the mailing list (not necessarily required for small/safe patches)
• Person creates a branch and make their changes there.
• Person creates a pull request and asks for one or two code reviews.
• More discussion occurs on the pull request.
• When the people who cared are good with the patch, it gets applied by a committer.

Whether your patch gets applied depends on how likely you are to attract reviewers and committers. Fairly meritocratic (http://www.apache.org/foundation/how-it-works.html#meritocracy) overall.

There are a few ways to do what you propose. You could use OP_PICK or OP_ROLL. If you want to be more creative, you can do that with the alt stack as well, look at OP_TOALTSTACK and OP_FROMALTSTACK.

I'm not aware of a better documentation source than the wiki unfortunately. You do know that non-standard scripts aren't relayed though, right?

http://www.coindesk.com/blockcypher-update-gyft-litecoin/


In addition to the Bitcoin, you can now support Litecoin using the exact same APIs. Generalizable to any block chain as well.

You can find something similar here:

http://dev.blockcypher.com/#websockets

Those are mostly private APIs but Websockets aren't hard to put in place. You can use socket.io as you mentioned for the websocket server, the difficulty is more getting access to the original event, which won't be websocket.

There's no absolute, it's just degrees of risk, going from 0-confirmation to 100 blocks of confirmation or more. I'm not aware of any theory or paper trying to quantify those risks precisely though, it's actually pretty difficult. I'd be interested if someone knows of a good publication here. If someone gets a good risk profile, I can imagine an insurance business could get structured around it.

I'd love to check you link and see what you guys have done but I don't seem to be very lucky at getting your site to load.

Hey, sorry for the late reply, actually missed yours.

First, we've done some more work trying to get closer to the blockexplorer "standard" (what blockchain.info more or less uses). There's still a little more work left but it's definitely better in terms of JSON format. There's also a few things in the format we will never support just because the design is not scalable. For example:

$ curl http://blockchain.info/rawblock/299994

That's a 310k response. It's silly.

Second, regarding your proposal, I definitely think agreeing on a JSON schema is interesting. Endpoint addresses though... not so much. As long as there's a simple URL mapping, services should be free to pick URLs that match their own API schemes (I think).

This sounds more like external software, even though it's useful. Have someone write a small script doing that for you.

Wouldn't something like that fit your need?

http://dev.blockcypher.com/

You could setup a webhook that will call you for any new block transaction. From there you just need to check the first byte of the transaction script and if it's an OP_RETURN, do whatever you'd like to do to analyze it.

We released a pretty simple transaction API:

http://dev.blockcypher.com/#creating_transactions

We also have a full sample here:

http://dev.blockcypher.com/samples/create-tx.html

It's free to use and if you exceed the rate limits, just ask for a user token.

Your VPS doesn't have enough memory. You'll need to upgrade.