Transaction d97cc408618ebaf018307860bdf8aaf571df61d70d29882ad5de83f0472704b0

1 Input
  • 1e77fe5a7cee6a04ad036b9424d254638a6aa05d3f532c0cbc383c37151ea77f:1
    OP_DATA_32(32) 78868edb03840799e38b95855ffe1cae2b515f430fe2af453f078f24710edb7d
    OP_CHECKSIG(172)
    OP_0(0)
    OP_IF(99)
    OP_DATA_3(3) ord
    OP_DATA_1(1) 
    OP_DATA_24(24) text/plain;charset=utf-8
    OP_0(0)
    OP_PUSHDATA2(77) the tests, or in your shell configuration. We also try to follow a TDD (Test-Driven-Development) approach, which means we use tests as a way to get visibility into the code. Tests have to run fast for that reason so that the feedback loop between making a change, running the test and seeing the result is small. To facilitate that we created a mocked Bitcoin Core instance in [test-bitcoincore-rpc](./test-bitcoincore-rpc). Syncing ------- `ord` requires a synced `bitcoind` node with `-txindex` to build the index o
    OP_PUSHDATA2(77) f satoshi locations. `ord` communicates with `bitcoind` via RPC. If `bitcoind` is run locally by the same user, without additional configuration, `ord` should find it automatically by reading the `.cookie` file from `bitcoind`'s datadir, and connecting using the default RPC port. If `bitcoind` is not on mainnet, is not run by the same user, has a non-default datadir, or a non-default port, you'll need to pass additional flags to `ord`. See `ord --help` for details. `bitcoind` RPC Authentication -----------------
    OP_DATA_13(13) ------------
    OP_ENDIF(104)
1 Outputs
  • d97cc408618ebaf018307860bdf8aaf571df61d70d29882ad5de83f0472704b0:0
  • value  546
    address  bc1p6semdnghyuvrlkratjdhkqhxzhujgqn76aqmtcf25y6t05ng44jsp9gr8t