You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When calling chain.address_type_txes() with a block range that has 0 transactions of the specified address type, the script hangs and eventually throws a "std::bad_alloc" error.
Huh interesting. I've never hit that before, but I can recreate it. If it's the same problem you're hitting, it looks a like a bug that occurs in the segmentChain method which address_type_txes depends on which occurs whenever the range of blocks contains fewer transactions than your machine has CPUs. I'm working on a fix now.
Incidentally in the just released BlockSci v0.5, chain.address_type_txes() has been replaced by chain.blocks.txes.including_output_of_type(blocksci.address_type.nulldata) which returns a blocksci.TxIterator object which is an iterator over the matching transactions and also allows vectorized operations.
When calling chain.address_type_txes() with a block range that has 0 transactions of the specified address type, the script hangs and eventually throws a "std::bad_alloc" error.
Example:
txes_protocol = chain.address_type_txes(511645, 511646, blocksci.address_type.nulldata)`
Error:
MemoryError: std::bad_alloc
I've also reproduced this behavior with address type of multisig, eg. block 170.
The text was updated successfully, but these errors were encountered: