A txid is calculated as sha256d(tx). When a txid is presented as a string for a human or a text based api, it is first reversed, then hex encoded. This reversing step can be a source of bugs and confusion. Unfortunately, this convention also sees use with block ids, merkle roots, merkle tree nodes, etc.
This lib is currently using reverse order everywhere. As the lib is for low level manipulation of bitcoin primitives, I believe txid should always be in normal order. A txid string in reverse order, should be considered a different construct.
This could be achieved by having separate methods on every object using this bitcoin id convention, or with functions for explicit conversion.
tx.get_id()
tx.get_id_string()
txin.set_prev_tx_id(id)
txin.set_prev_tx_id_string(id)
// or
tx.get_id()
bitidtos(tx.get_id())
txin.set_prev_tx_id(id)
txin.set_prev_tx_id(stobitid(id))
Another thing to consider is the get_id_hex methods. For new users of the lib, it is not clear from the method name what this actually returns. It may be best to remove them entirely.
A txid is calculated as
sha256d(tx). When a txid is presented as a string for a human or a text based api, it is first reversed, then hex encoded. This reversing step can be a source of bugs and confusion. Unfortunately, this convention also sees use with block ids, merkle roots, merkle tree nodes, etc.This lib is currently using reverse order everywhere. As the lib is for low level manipulation of bitcoin primitives, I believe
txidshould always be in normal order. Atxid stringin reverse order, should be considered a different construct.This could be achieved by having separate methods on every object using this bitcoin id convention, or with functions for explicit conversion.
Another thing to consider is the
get_id_hexmethods. For new users of the lib, it is not clear from the method name what this actually returns. It may be best to remove them entirely.