You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We would like multiple approaches in DID:BTCR to point to the DDO.
The first is simple — don't include an op_return at all. A DDO is constructed based on information from the transaction and the block the transaction is confirmed in. These include the control key (from the public key in the P2PKH script), the owner key (the hash of the future key that is the address the first txout has been sent to), and the date from the blockheader. There may be some other useful information that can be assumed.
The second is a short URL, less than 40 or 80 characters, that points to the location of the DDO, which is self-signed by the transactions public key.
The third is a content addressable hash, possibly with URI at beginning. We should consult with @jbenet's IPFS team what the best method is. Some hash encodings with URI may be too large for 40 characters. There is also related to issue #3 — a bare hash value is indistinguishable from any other has, but an hash identifiable as an IPFS hash could be censorable.
Finally, the fourth is pointing to Blockstack's layer two update record. I'm not quite sure if they are planning on updating how they do that anytime soon. Does that need a URI or prefix?
We would like multiple approaches in DID:BTCR to point to the DDO.
The first is simple — don't include an op_return at all. A DDO is constructed based on information from the transaction and the block the transaction is confirmed in. These include the control key (from the public key in the P2PKH script), the owner key (the hash of the future key that is the address the first txout has been sent to), and the date from the blockheader. There may be some other useful information that can be assumed.
The second is a short URL, less than 40 or 80 characters, that points to the location of the DDO, which is self-signed by the transactions public key.
The third is a content addressable hash, possibly with URI at beginning. We should consult with @jbenet's IPFS team what the best method is. Some hash encodings with URI may be too large for 40 characters. There is also related to issue #3 — a bare hash value is indistinguishable from any other has, but an hash identifiable as an IPFS hash could be censorable.
Finally, the fourth is pointing to Blockstack's layer two update record. I'm not quite sure if they are planning on updating how they do that anytime soon. Does that need a URI or prefix?
cc: @muneeb-ali @shea256 @jcnelson
The text was updated successfully, but these errors were encountered: