{
  "txid": "cd531a572f5247a055f2249d3398356848cb5624f2ad4fdec20eb66bd0e97c9c",
  "block_height": 802762,
  "time": null,
  "app": "pow.co",
  "type": "post",
  "map_content": "## Scrypt Design Considerations\n\n[From the Scrypt Discord Channel](https://discord.com/channels/953808129043333140/954737352713064518)\n\nMany design decisions I have made without reference to anyone else in scrypt and would like to coordinate on some concepts going forward for better cross-app compatability of objects.\n\nFor instance when assigning ownership to an object (instance) what should be the standard name of the prop for ownership? \n\nWhen using a PubKeyHash to assign ownership the simple demo from the website names that prop p2pkh but I have gone back and forth and have decided to name that owner instead.\n\nSimilarly for when ownership is indicated by a PubKey I still am using the prop name owner that way anyone indexing the objects can create a database of objects owned by a given player, irrespective of the contract class because there is a standard owner property. \n\nAlso are people using PubKeyHash or PubKey more to assign ownership? It seems unnecessary to use PubKeyHash for objects that are called multiple times since the public key is going to be exposed anyway whenever you sign. Plus most known wallets only allow a single public key anyway for use with scrypt so re-use is an issue. Certainly for simplicity it is easier to use PubKey but should PubKeyHash be the standard approach? I am not clear. Of course using PubKeyHash would allow for people to securely mint, receive, and store objects with a unique address generated for each object by and extended (HD) private key, therefore never exposing any public keys until the contract was called.\n\nLooking for pros and cons and perhaps most importantly any approach others are taking and what success, barriers you are facing.\n\n**VERSIONING**: Another rather unresolved engineering challenge we are facing is how to version contracts. Has anyone approached trying to explicitly version their objects? Once deployed into a production-ready app it seems like these contracts are set in stone, so up-front design becomes incredibly critical. Versioning could help improve the release and feedback cycle on software development.\n\n**FEES**: How is the most correct way to set sats/kb fees ? TAAL recently announced 0.001 sat/byte or 1sat/kb but scrypt-ts still charges 50 sat/kb by default!\n\n**REGISTRY**: Has there been consideration for registering SmartContract classes on the blockchain so that the entire network may discover, download, and interact with all objects? A standard approach that embeds both the contract source code plus ABI metadata into a known data structure will enable us to create indexes on top and construct a library of known contract artifacts that can be consumed at one's leisure. Currently the whatsonchain contract verification tool does something like this but it is unclear if they are indexed the contracts, and that database is certainly not published on chain.",
  "media_type": "text/markdown",
  "filename": "|",
  "author": "1HuTvn11gcxYkjoz3QjmWbArrnRfp3Kd8j",
  "display_name": null,
  "channel": null,
  "parent_txid": null,
  "ref_txid": null,
  "tags": null,
  "reply_count": 0,
  "like_count": 0,
  "timestamp": "2023-07-29T12:50:47.000Z",
  "media_url": null,
  "aip_verified": true,
  "thread_root_tx": null,
  "engagement_score": 0,
  "token_ref": null,
  "token_type": null,
  "kind": null,
  "lat": null,
  "lng": null,
  "category": null,
  "locked_sats": "0",
  "pow_bits": 0,
  "has_access": true,
  "attachments": [],
  "ui_name": "1HuTvn\u2026Kd8j",
  "ui_display_name": "1HuTvn\u2026Kd8j",
  "ui_handle": null,
  "ui_display_raw": null,
  "ui_signer": "1HuTvn\u2026Kd8j",
  "ref_ui_name": "unknown",
  "ref_ui_signer": "unknown"
}