Transaction ID as Position in Block?

[kimdhamilton]

From @ChristopherA on June 30, 2017 6:34

Blockstack was the first to suggest that the DID an index of the transaction within a confirmed block, rather than the transaction ID. The advantage of this is that it is possible to have a transaction id that isn't confirmed, as it is only the hash of the transaction. The disadvantage of it is all of the bitcoin explorer APIs search on transaction id.

The most secure method of confirming a DID:BTCR will be to have a full node with -txindex on, but ideallly we do want to support lighter clients being able to confirm via a online explorer.

We should investigate if any explorer APIs allow us to search for a transaction index within a block, or announce support of @veleslavs & @jonasschnelli proposal for a bech32 transaction id.

cc: @muneeb-ali @shea256 @jcnelson

Copied from original issue: WebOfTrustInfo/btcr-hackathon-2017#1

[kimdhamilton]

From @jonasschnelli on June 30, 2017 7:59

Ideally block explorer support it. But I guess that will take a while.

Much better is, that you actually don't need a tx-indexed blockchain or blockexplorer to grab a Tx-Ref according to the txref BIP.

You can do it on the client side within seconds (by SPV check the block-headers and download a single block).

I'm currently adding support for TxRef's after the BIP above in libbtc.

The power lies in the fact that everyone can fetch a TxRef TX with SPV within seconds from the p2p network (== not trusting anyone). No bloom filters are involved.

[kimdhamilton]

From @ChristopherA on June 30, 2017 8:28

@jonasschnelli Very cool ! I didn't quite connect that you didn't need a tx-indexed full node to grab one of your tx-refs!

I look forward to seeing your libbtc implementation of it. If you have it functioning by the start of our virtual hackathon on the week of July 10th, we'll likely base the C-version of our prototype code for DIDs using libbtc.

[kimdhamilton]

From @jonasschnelli on June 30, 2017 17:21

I can add some things to give you a C toolset to worth with txref as well as with the block fetching... most things are already there. Should be done before July 10th.

[kimdhamilton]

From @ChristopherA on June 30, 2017 18:8

@jonasschnelli — Thanks! That will be extremely helpful.

BTW, do you have any recommendations for a C library to aid in using JSON-RPC calls to bitcoind? @shannona and I have been using libbitcoinrpc for our tutorial (see drafts at https://github.com/ChristopherA/Learning-Bitcoin-from-the-Command-Line/blob/master/12_2_Accessing_Bitcoind_with_C.md & https://github.com/ChristopherA/Learning-Bitcoin-from-the-Command-Line/blob/master/12_3_Programming_Bitcoind_with_C.md ) and it has been quite painful.

[kimdhamilton]

From @jonasschnelli on June 30, 2017 18:20

Yeah. RPC / JSON is painful in plain C.
I came to the conclusion to only do the core stuff in C (hash / tx / blocks / bip32 / keys / ecdsa / ser-/deser / AES / CPRNG), things that can be use on embedded devices. JSON/RPC as well as the network layer make probably much more sense to do in C++(11).
C++11 is fully portable IMO (all modern smartphone operating system as well as all widely used desktop systems support it).

However, libbtc has a network layer based on libevent written in pure C which is useful for low-memory environments (I guess the same would have been possible with C++).
Doing concurrency (somehow required with p2p networking) is hard in C (or say much simpler in C++).

I if would have to do JSON-PRC against bitcoind, I would probably use UniValue (https://github.com/bitcoin-core/univalue?files=1) and some libevent based http client (see bitcoin-cores bitcoin-cli or an alternative would be using libcurl).

If you want pure C, try libevent & YAJL (or look for a complete JSON RPC C library).

[kimdhamilton]

We've decided this is a good approach. Close with summary/topic paper. Add links

Point to BIP PR, etc -- note final format may change

[kimdhamilton]

Move to RWoT. Some elements not part of BIP may be suitable for W3C

[kimdhamilton]

From @ChristopherA on August 11, 2017 18:32

A BIP number has been assigned, BIP 136, but the PR has not been accepted yet — they have asked non-bitcoin references to be deleted.