# Nested BlockchainBlockData fail

New 11.3 functions to query blockchains. In trying to build a block link by iterative lookup, this function works for several iterations then fails:

NestList[Query[BlockchainBlockData[#,BlockchainBase->"Bitcoin"]&]/* Query["PreviousBlockHash"],"00000000000000000038f324c04b678c85b5ee25ca8b36d8eef313e7e733293f",10]


{00000000000000000038f324c04b678c85b5ee25ca8b36d8eef313e7e733293f,000000000000000000428a173468966d068f08f63f11c2d8db47d95ab861a32a,0000000000000000003b3bab092183a0fe6c33b6656f360c4118564478126a5b,00000000000000000004b9e238f822a7bdf4104ffcc8ef44c22bef468a47facd,Missing[Failed],Missing[Failed],Missing[Failed],Missing[Failed],Missing[Failed],Missing[Failed],Missing[Failed]}

even though individual queries work:

 BlockchainBlockData[
"00000000000000000004b9e238f822a7bdf4104ffcc8ef44c22bef468a47facd",
BlockchainBase -> "Bitcoin"] // Query["PreviousBlockHash"]


"0000000000000000003b6b67cb4c5db2edae01a630c3ff795148f2abce9dc223"

Similarly, plugging the result in gives a valid previous block hash etc.

Is it a resource bottleneck? I can't believe a Nest 10 levels deep would be a problem.

The example accesses the blockchain too rapidly. If we add the option FailureAction->None to the first query, we see the error message:

BlockchainBlockData::btcrate: Rate limit exceeded for Bitcoin blockchain access.

Sniffing the network traffic, it would appear at time of writing that the service used is blockcypher.com. The API documentation states that the rate limit for an unregistered account is 5 requests/second and 600 requests/hour.

Accordingly, I was able to obtain a full result by inserting a 200ms delay before each request:

NestList[
( Pause[0.2]
; BlockchainBlockData[#, BlockchainBase -> "Bitcoin"]["PreviousBlockHash"]
) &
, "00000000000000000038f324c04b678c85b5ee25ca8b36d8eef313e7e733293f"
, 10
]

(*
{00000000000000000038f324c04b678c85b5ee25ca8b36d8eef313e7e733293f,
000000000000000000428a173468966d068f08f63f11c2d8db47d95ab861a32a,
0000000000000000003b3bab092183a0fe6c33b6656f360c4118564478126a5b,
00000000000000000004b9e238f822a7bdf4104ffcc8ef44c22bef468a47facd,
0000000000000000003b6b67cb4c5db2edae01a630c3ff795148f2abce9dc223,
0000000000000000000506c50e99c65b74f2d00ef2344f8139a831fdb6f0be30,
0000000000000000002f1d23de38e9a20f90f52524bbdb4451f0dbc49897ba22,
000000000000000000190ac64c8c5a1a9acbf338d8435c0dcd74d41c0b031535,
000000000000000000429f5fec52afdc16540ef5eda2d5a711a988db8041da46,
0000000000000000003e0453ef04d9e17818ec3718d1811f1c0b295887828870,
000000000000000000175173c6fe40dd7cd74612e7b844be0419d8eac86c8375}
*)

• Thanks for the legwork. – alancalvitti Apr 9 '18 at 14:27
• That is correct. The functions introduced in v11.3 used an external API. The updated functions in v12 now use Wolfram resources and have a higher rate limit. – xtian777x Oct 18 '19 at 0:22