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!

headpoobah
  • 41
  • 3

1 Answers1

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
Thomas Guyot-Sionnest
  • 341
  • 1
  • 4
  • Do you know how to parse the data content of tx-hash, after a MySQL query in python ? – pratiklodha Sep 04 '17 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 Sep 06 '17 at 05:16