{
  "txid": "a2ce13de341a6650ccf936992ee155b904c0cb67219a725d1cfd13528c9779cd",
  "block_height": 780822,
  "time": null,
  "app": "relayclub",
  "type": "post",
  "map_content": "Developer Journal February 26, 2023\n\nHaving chosen to come down here to the office this morning rather than head up the bus to the slopes of Soldeu I discover that my computer cannot connect to the internet here so I have decided to write my thoughts for preparation on this Sunday. The reason I came here to work is because I feel a sort of anxiety about the state of powco.dev and that it does not currently work for anyone. Also I feel like my vision for onchain developer contracts would make me a lot more money more quickly if I go all the way to fully scrypt-based contracts and skip the RUN token infrastructure altogether or simply use it to augment the scrypt programs. Step one for RUN or script is sitll simply creating the transaction such that org, repo, issue number, title, and description are embedded in to token script outputs. There would then need to be no interactivity whatsoever and the satoshis can become locked in the issue for all of time given the issue is non-interactive.\n\nA first step toward making the issue contract interactive is by providing a bail out mechanism like Daniel described for all games. In this case the bailout mechanism would allow one to spend the satoshis contained within the issue, thus destroying the issue from the blockchain unspent outputs. That is to say in another style that the bits on which the issue was residing are freed up to host another tenant on the blockchain data registry. By default the bailout or eject method shall allow the creators of the contract to eject the satoshis, for now since there are no additional players in the system. Once other players have deposited bits into the contract the eject method may become in-operable, or perhaps it allows for ejection of only the satoshis that were originally deposited and no more.\n\nIn order to skip RUN and go directly to scrypt I must create a single function that accepts a github issue record and outputs a txid of a new transaction, ultimately saving that txid in the github issue database record. At that point the powco dev api will return a txid correctly for every issue known. However there must also be a second function that detects this type of powcodev contract and can properly parse the contract metadata. That way any application upon discovering the Dev Issue Contract can parse it and index it properly, a primary example being the pow.co feed displaying details of the Issue simply by parsing its raw transaction hex. Additionally the real time stream processor will be upgraded to include this Dev Issue filter-detector and output a reliable real time even stream to message exchanges, the database indexes, and end user apps.\n\nTo attain maximum increase in my smart contract programming skills through this exercise I may elect to write automated end to end tests that actually use the blockchain live to transact using the smart contract. By calling its methods with all reasonable cases of valid and invalid parameters and then asserting the correctness of the results, my contracts' user base and paying customers will have the highest confidence. On Circle CI there shall be configured an environment variable for the private keys needed to operate the end to end tests. That key may be a hierarchical key from which the test program derives all of the accounts required to operate the multi-party contract. Each sub-account will have access to a certain set of bits in unspent outputs so that they may uniquely operate their portion.\n\nRather than requiring the test operation to know all of the sub-accounts and their addresses, having to pre-fund the correct amount for each participant, instead automate all of that. There shall be rules set out in a declarative fashion such that the system is able to allocate all the right bits to all the right keys upon startup of the program. Declaratively describing the account balance requirements means users of the module describe the desired end state and let the program decide how to transition to that state. That method is opposed to an imperative syntax where each developer would have to determine which operations are needed to get the correct coins to the correct addresses, and then write them into a step-by-step program. The way this declarative smart contract test setup language will work is you say how many satoshis or specific outputs you want for any number of various locking scripts, and then the program creates them all in a single setup transaction.\n\nThroughout the tests all satoshis should be used by locking and unlocking the smart contract with different methods under certain conditions. At the end of the test suite a global teardown method shall return (or attempt to return) all satoshis back to the original addresses assuming they are still under pay-to-pubkey-hash scripts available to the original private keys. This same style of test suite for interactive multiplayer smart contracts can be super valuable for all scrypt developers so it shall be made into a template so that many more developers, especially myself now and in the future, will be able to deploy powerfully valuable programs on bitcoin at a tiny fraction of the current cost of development.",
  "media_type": "text/plain",
  "filename": "|",
  "author": "14JHZkFXsF3cTt6pdYUkZnjbosNT4n55Ks",
  "display_name": null,
  "channel": "club",
  "parent_txid": null,
  "ref_txid": null,
  "tags": null,
  "reply_count": 2,
  "like_count": 1,
  "timestamp": "2023-02-26T10:54:29.000Z",
  "media_url": null,
  "aip_verified": true,
  "has_access": true,
  "attachments": [],
  "ui_name": "14JHZk\u202655Ks",
  "ui_display_name": "14JHZk\u202655Ks",
  "ui_handle": null,
  "ui_display_raw": null,
  "ui_signer": "14JHZkFXsF3cTt6pdYUkZnjbosNT4n55Ks",
  "ref_ui_name": "unknown",
  "ref_ui_signer": "unknown"
}