3

My dev environment is quite limited in terms of bandwidth and storage. I need to make a database out of transactions containing opcode 0x6a since a given epoch.

[Scan blocks, going backwards from the latest, until a given blockheight]
[If the transaction outputs contain OP_RETURN, save it with associated metadata]

Is there a way I can do this with bitcoind without having to store the entire chain?

3 Answers 3

1

You could use the pruning mode to only store blocks after the height you are interested in. I think you'll still have to download it to verify the past history, but you won't have to store it all on disk.

See this RPC call for more information.

1

Currently-released version of Bitcoin Core will only process blocks sequentially starting from the beginning of the chain. If that happens to be the beginning of your epoch, you can start recent versions of bitcoind with the -stopatheight parameter to specify the end of your epoch and bitcoind will stop downloading blocks at that point.

Alternatively, a pending Bitcoin Core pull request (PR) provides the behavior you want where you can tell Bitcoin Core not to download any blocks automatically and then manually specify which blocks you want. See PR#10794 for details.

Note that if you operate in this mode connected directly to the peer-to-peer network, your node will only have SPV-level security, meaning someone could theoretically give your node an invalid block with a valid amount of proof of work. If you require a high degree of security, it would be recommend that you exclusively connect your bitcoind running PR#10794 to one of your own fully-validating (regular) bitcoind nodes so that will ensure you only receive valid blocks. To do that, see the -connect option to bitcoind.

0

This is implemented with pull request "rpc: getblockfrompeer" #20295, merged into master on Dec 8, 2021:

getblockfrompeer "blockhash" peer_id

Attempt to fetch block from a given peer.

We must have the header for this block, e.g. using submitheader. Subsequent calls for the same block may cause the response from the previous peer to be ignored. Peers generally ignore requests for a stale block that they never fully verified, or one that is more than a month old. When a peer does not respond with a block, we will disconnect. Note: The block could be re-pruned as soon as it is received.

Returns an empty JSON object if the request was successfully scheduled.

Arguments:

  1. blockhash (string, required) The block hash to try to fetch
  2. peer_id (numeric, required) The peer to fetch it from (see getpeerinfo for peer IDs)

Result: {} (empty JSON object)

Examples:

> bitcoin-cli getblockfrompeer "00000000c937983704a73af28acdec37b049d214adbda81d7e2a3dd146f6ed09" 0

> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "getblockfrompeer", "params": ["00000000c937983704a73af28acdec37b049d214adbda81d7e2a3dd146f6ed09" 0]}' -H 'content-type: text/plain;' http://127.0.0.1:8332/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.