4

I've grabbed "Abe" and have started processing the blockchain into a database, but I can't really find documentation on what the various tables mean / are / contain.

Here's the list:

abe_lock        
block           
block_next      
block_tx        
block_txin      
chain           
chain_candidate 
configvar       
datadir         
magic           
orphan_block    
policy          
pubkey          
tx              
txin            
txout           
unlinked_txin

I can make some guesses, but documentation would be better. Can anyone explain what's in each of these, or point me to some documentation?

Thank you, if you can help!

Improve this question

1 Answer 1

Reset to default
3

I've worked with Abe for some time; I'll try to have a run at it... I'm using the latest table list from Database version Abe39 on MySQL.

Utility tables:

  • abe_lock:

    Used for locking while performing DDL

  • configvar:

    Configuration and results of some auto-detected SQL features.

Blockchain tables:

  • block:

    Block hash and related statistic/infos.

  • block_next:

    Forward-linking of blocks (blocks references only the previous block; this table links to the next one).

  • block_tx:

    Links blocks to all their transactions in tx.

  • block_txin:

    I believe this is merely a "shortcut" table that contains information accessible elsewhere: somewhat links together block_id, txin and the block it's spent on.

  • orphan_block:

    Used to link orphan block (for eventual out of order/multi-threaded indexing?) References the previous block hash (since we do not have pref block_id yet).

  • tx:

    A transaction: links to inputs (txin) and outputs (txout)

  • txin:

    A single transaction input.

  • unlinked_txin:

    As for orphan_block, links to txin we do not have loaded yet. References the txout_hash as we do not have yet the txout_id.

  • txout:

    A single tx output

  • pubkey:

    A bitcoin address (pubkey)

  • multisig_pubkey:

    A multisig pubkey

  • chain:

    Chain name and properties (one per cryptocoin)

  • magic

    Per-chain magic number

  • chain_candidate:

    Identifies each block height and whenever it's part of the longest chain or not.

  • datadir:

    Information relative to blockfile indexer

Sequences:

This is pretty much DB-specific; on MySQL these are tables that have a single AUTO_INCREMENT column and are used to create unique keys for their respective tables:

  • block_seq
  • chain_seq
  • datadir_seq
  • pubkey_seq
  • tx_seq
  • txin_seq
  • txout_seq
Improve this answer
2
  • Do you know how to parse the data content of tx-hash, after a MySQL query in python ?
    – pratiklodha
    Commented Sep 4, 2017 at 16:31
  • I'm not sure I understand your question... There is no information you can get out of the tx hash itself, it's merely a unique 32bytes cryptographic hash that identifies this transaction. If your storage engine is configured to use the binary format, you can get a readable hash with SELECT HEX(tx_hash) .... The actual TX informations is contained within all txin's txin_scriptSig and txout's txout_scriptPubKey fields for the transaction, if enabled. Those may be binary too, and are parseable according to Bitcoin's own pseudo language specifications.
    – Thomas Guyot-Sionnest
    Commented Sep 6, 2017 at 5:16

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.