Why `TxRef`?

[AngusP]

The spec uses only TxRefs (from BIP-136) to refer to did:btcs, but these have a few drawbacks:

1. They include the block height, meaning a did:btc's TxRef cannot be known or shared until, at minimum it has 1 confirmation, but conservatively may need 6 to 100 for surity
2. In the case of a reorg, it it highly likely that the TxRef will point to a new transaction rather than be invalid, and although it is highly unlikely but not impossible that that transaction could be a different DID. This is a (admittedly incredibly expensive and hard to pull-off) attack vector. The more common case is that it is not a DID transaction, but still there.

A couple of alternatives come to mind:

1. Why not just the txid? You could encode it more compactly that just hex. Using txid has the advantage that it is knowable before te transaction has been broadcast (potentially useful if someone wants to commit to an unpublished DID, and the txid itself is sort-of a commitment to the DID)
   • This would also allow Proof-of-Work in DID creation, as with some nonce space to provide entropy you can grind the txid to have some number of leading 0s, which could also be used to shorten the did:btc:... depending on the encoding chosen.
   • AFAIK for any Bitcoin Node that has txindex on, this is easy to fetch. However, given the ubiquity of Electrum servers on-top-of Core and the difficulty of doing much useful without it, I'd wager most core nodes do have this enabled. (Opinon) SPV and 'light' nodes seem to be near-dead as a concept, with stuff like Neutrino replacing it.
2. You could use (cue screeching) one of the Ordinal theory methods of referring to a specific sat, e.g. the ordinal number encoded with Bech32m/B58/whatever, or the ordinal 'name'. These have the advantage of being a lot shorter than txids, some shorter than TxRefs whilst still being unmalleable to reorgs.
   • Using Ordinal theory does have the big downside of needing an index that Bitcoin Core itself doesn't maintain

[garyrob]

It appears that the index adds about 20%-25% to the space taken up. Given the ongoing reduction in SSD cost, it seems arguable that a motivation did:btcr had for using TxRef is less and less relevant and will continue to be so, whereas the benefits of using txid will remain.

I'm not sure that the shortness of ordinal numbers is much of an advantage. People aren't going to be typing them in, in normal cases. And if shorter versions are desirable, perhaps that could be accomplished with a registry that maps short names to TxIds, which might live on Stacks or some equivalent; but that would be the subject of another issue!

[AngusP]

I'm not sure that the shortness of ordinal numbers is much of an advantage

I'd tend to agree, I'd prefer just the txid because it also has the potentially useful property of pre-commitment to an unbroadcasted/unconfirmed did

[garyrob]

I'd tend to agree, I'd prefer just the txid because it also has the potentially useful property of pre-commitment to an unbroadcasted/unconfirmed did

The BIP-136 spec for TxRef says: "We recommend that TxRefs should be not used for positions within the blockchain having a maturity less than 100 blocks."

Still, for practical purposes, waiting 1000 minutes (a little less than 17 hours) for public use of a new DID may not be an excessive barrier, given that from then on, we have a short, human-transcribable DID...

[garyrob]

A usage idea: When did:btc DIDs are shared, include the transaction ID with the data. When the DID Document is retrieved, the resolver add the TxId associated with the TxRef location to the presented information. The receiver could verify the TxId against the one that was shared with them when the DID was shared. This would be analogous to downloading a file and checking the checksum against one that is presented with the link.

This seems like it could eliminate the (extremely small) risk of an attack by replacing the transaction at the TxRef location.

[AngusP]

the receiver could verify the TxId against the one that was shared with them when the DID was shared

You could, but that's starting to feel hacky. Also would mean a did:btc has an additional verification step that's special/unique, or that a did:btc looks valid except the TxRef and txid within the document don't match -- so it's there, you could use it, but it broke a rule (but still will live on the chain forever 😆)

[garyrob]

> the receiver could verify the TxId against the one that was shared with them when the DID was shared

You could, but that's starting to feel hacky. Also would mean a did:btc has an additional verification step

You're right.

The DID specification allows for DIDs with more than 2 semicolons. In example of such a DID is:

did:pkh:eip155:1:0xb9c5714089478a327f09197987f16f9e5d936e8a

How about 2 forms of DID for this spec. Perhaps:

did:btc:id:F4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 and

did:btc:xg4x-ay5y-q5zq-232

Both valid, and both resolvable to the same DID Document. The preferred way of presenting a DID would be giving both forms. If it's a context where the user can copy and paste it, or it's part of some kind of digital communication, the did:btc:id format would be preferred. Otherwise the short one would be used when a human is going to type something in. If the ID is very old, it can be trusted. If not, the user can look at the did:btc:id that would be presented in the DID Document and confirm that it's the one presented alongside the did:btc DID he typed in.

(Actually, the id: piece may not be necessary, since the two forms of DID would be easily distinguishable.)

Of course, normally DIDs are unique and this approach is superficially inconsistent with that. But with such different forms, I don't think it is necessarily a real-world problem.

There is at least a degree of precedent for two different forms of DID leading to the same DID Document:

did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a and

did:ethr:1:0xb9c5714089478a327f09197987f16f9e5d936e8a

both point to the same DID Document because "1:" specificies Ethereum mainnet, which is also the default. See https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md.

[garyrob]

Following up on my previous post. Section 5.1.3 of the Decentralized Identifiers (DIDs) v1.0 spec has an alsoKnownAs property that would be exactly what we want for an alternative URI for the DID Document. So I suggest supporting both TxRex and TxId, to get the best of both worlds. The DID Document could show the DID using TxRef for the "id" property and a version of the DID using the TxId for the "alsoKnownAs" property.