|
May 09, 2014, 08:24:03 AM |
|
That is certainly a nice API, but doesn't quite do what I'd like. If my goal were to keep an updated list of all OP_RETURNs with a certain property, your suggestion would be perfect, but what I really want is the ability to search OP_RETURNs without having to store an updated list (for example, I might want to ask for the first ten OP_RETURNs matching PATTERN).
In a perfect world, someone will have the blockchain as a searchable database somewhere, so that I could simply send an SQL request like SELECT TX_ID FROM OUTPUTS WHERE SCRIPT = REGEX and it would return me the answers (or, given that there are likely to be a lot of matches to many requests, a block of matching records and a cursor to get the next block). In JSON-RPC, one might imagine the api works similar to:
{ "method" : "query", "params" : ["SELECT TX_ID, SCRIPT FROM OUTPUTS WHERE SCRIPT = REGEX ORDER BY TIMESTAMP ASC"], "id" : 1 }
and getting a response like
{ "result" : {"cursor-id" : CURSOR, "response" : [{"TXID" : ..., "SCRIPT" : ...}, {"TXID" : ..., "SCRIPT" : ...}, ... k responses ... , {"TXID" : ..., "SCRIPT" : ...}] }, "error" : null, "id" : 1 }
The next responses can then be got by sending something like
{ "method" : "nextmatches", "params" : [CURSOR], "id" : 1 }
which gets a response like that to the query.
A very concrete application would be to find the first appearance or a particular transaction type, or an op_return with data matching whatever. Perhaps this is even more interesting for testnet: after all, people can try out all sorts of funny transactions there. It seems rather inefficient that if one is interested in querying the blockchain generally, one has to build (and maintain) a database locally.
|