TXO 2.0

A New transaction data format for the Bitcoin Genesis Update

Much of the innovation with systems developed by Planaria corp has been around how it represents Bitcoin transactions. BitDB was the first system to extract data from a bitcoin transaction into a generic structured database. To turn raw transactions into a queryable structured format, TXO serialization format was created.

Then as developers started using OP_RETURN scripts in various creative ways by piping one into another (through Bitcom pipeline scheme), it became important to invent a new serialization format: BOB.

With Genesis update however, TXO may be all we need since all restrictions are gone. All bitcoin script limits are lifted therefore developers will be able to finally use Bitcoin script as a legitimate programming language. With various flexible Bitcoin script patterns emerging, it will be important to be able to easily query bitcoin scripts by opcodes, as well as other powerful attributes enabled by the Genesis update.

And that’s the goal of TXO 2.0: It is a simple, consistent, and mostly backwards-compatible Bitcoin transaction serialization format for querying the Bitcoin universe, post Genesis.

Here are the highlights:

1. “b” is for base64: Now the “b” attribute is ONLY used for base64. Previously, the “b” prefixed attributes had somewhat of an ambiguous meaning: it could be a base64 representation, but could also mean an Opcode. Now “b” attributes are only used for base64. This brings up a question: How do we represent opcodes?
2. “o” is for opcode: The Genesis update will remove all opcode usage limitations. This means there will be an explosion of different bitcoin transaction types, and being able to query based on opcodes will become very important going forward. We need an easy, human readable way to filter by opcode patterns. Therefore it is best to use human readable opcode names instead of numbers. This means, instead of indexing { “b0": { “op": 106 } } we use { “o0": “OP_RETURN" } for example.
3. “len” is for script sequence size: Each input or output script is a sequence of chunks (either a buffer chunk or an opcode chunk). There has been no native way to get how many chunks are in a script. With TXO2.0, now we have a “len” attribute.
4. “seq” is for nSequence: Enabled with the Genesis update.
5. “lock” is for nLocktime: Enabled with the Genesis update.
6. “str” removed: The “str” attribute was simply an ASM representation of a Bitcoin script. Technically this was a redundant feature and waste of storage space, because everything in the “str” attribute was already supported by other attributes such as “b”, “h”, and “s” attributes. But many people have been using “str” just to get opcode names because previously the “o” attribute didn’t exist. Now you can use the “o” attribute for this purpose.

And here’s an example:

{
  "tx": {
    "h": "153d56a57db213777d3dac3459a40fe62036b762163f2563066f8a67a3cba014"
  },
  "blk": {
   "i": 620415,
   "h": "0000000000000000025a5aeaed281a198979f44c1492432505858c7603b33133",
   "t": 1580715685
  },
  "in": [
    {
      "i": 0,
      "seq": 4294967295,
      "e": {
        "h": "f51596ab84f5219d470b3e73229533997c4ffd32579bb7c350bf235b57aac063",
        "i": 1,
        "a": "184UFRtgg8BR2Uebt3BVBvqBLoj81ZwDK1"
      },
      "s0": "0E\u0002!\u0000��(�su�\u0014�\u0018AU���=ܦE�\u0003��P(7к��{\u0002 /�\u0007�O�30_ټ�J�\t\u0003�O�ް��\u001c�\u0015Ղg���A",
      "b0": "MEUCIQCbxSiAc3XurhTDGEFVwOvWPdymRcUDj5pQKDfQuuCMewIgL/oH10/pMzBf2bzSSo0JA+xPyt6wtKgciRXVgmeFjfJB",
      "h0": "30450221009bc528807375eeae14c3184155c0ebd63ddca645c5038f9a502837d0bae08c7b02202ffa07d74fe933305fd9bcd24a8d0903ec4fcadeb0b4a81c8915d58267858df241",
      "s1": "\u0003�;�d\f�G��/T��0\u001b�<��w5���y�\u0003��\\ I",
      "b1": "A/w7smQM2Ee18i9U2cYwG+48vKt3NfmWv3nkA6TcXCBJ",
      "h1": "03fc3bb2640cd847b5f22f54d9c6301bee3cbcab7735f996bf79e403a4dc5c2049",
      "len": 2
    }
  ],
  "out": [
    {
      "i": 0,
      "e": {
        "v": 0,
        "i": 0,
        "a": "false"
      },
      "o0": "OP_RETURN",
      "s1": "19dbzMDDg4jZ4pvYzLb291nT8uCqDa61zH",
      "b1": "MTlkYnpNRERnNGpaNHB2WXpMYjI5MW5UOHVDcURhNjF6SA==",
      "h1": "313964627a4d444467346a5a347076597a4c623239316e5438754371446136317a48",
      "s2": "\u0001",
      "b2": "AQ==",
      "h2": "01",
      "s3": "{\"bitvavo\":{\"l\":256.96,\"v\":62906}}",
      "b3": "eyJiaXR2YXZvIjp7ImwiOjI1Ni45NiwidiI6NjI5MDZ9fQ==",
      "h3": "7b226269747661766f223a7b226c223a3235362e39362c2276223a36323930367d7d",
      "s4": "184UFRtgg8BR2Uebt3BVBvqBLoj81ZwDK1",
      "b4": "MTg0VUZSdGdnOEJSMlVlYnQzQlZCdnFCTG9qODFad0RLMQ==",
      "h4": "3138345546527467673842523255656274334256427671424c6f6a38315a77444b31",
      "s5": "1580715600",
      "b5": "MTU4MDcxNTYwMA==",
      "h5": "31353830373135363030",
      "len": 6
    },
    {
      "i": 1,
      "e": {
        "v": 606891,
        "i": 1,
        "a": "184UFRtgg8BR2Uebt3BVBvqBLoj81ZwDK1"
      },
      "o0": "OP_DUP",
      "o1": "OP_HASH160",
      "s2": "Mp�߫W��2w�|�r刂��\u0012",
      "b2": "TXDf36tXmocyd9x893LliIK4ihI=",
      "h2": "4d70dfdfab579a873277dc7cf772e58882b88a12",
      "o3": "OP_EQUALVERIFY",
      "o4": "OP_CHECKSIG",
      "len": 5
    }
  ],
  "lock": 0,
  "timestamp": 1580715617612
}

TXO is not THE final transaction data representation format. There are some more feature additions coming up as well, and there may be other transaction serialization formats in the future. But for now, this shall be the minimal skeleton we start from, which should cover most use cases.

The TXO 2.0 format will be supported by all the new Planaria API systems to be launched going forward.

Learn more about the TXO 2.0 spec, and please provide your feedback here (feature addition requests or suggestions welcome):

TXO 2.0 · Issue #3 · interplanaria/txo