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
Source: YenPoint's Python SDK User Test Report. All credit to Ken Sato of YenPoint
The ASM (Assembly) format is valuable for programming Bitcoin Script. However, there are ambiguities in the ASM format of Bitcoin opcodes between the different SDKs (TypeScript, Python, GO). A standardized ASM format across all infrastructure, libraries, SDKs, etc. is required
The Go SDK, with its apparently comprehensive list of ASM might serve as the baseline for an ASM standard.
Example
The conversion between bytecodes, ASM, and higher-level languages should be seamless and consistent. This will empower developers to program in ASM, creating complex script templates using higher-level languages like Scrypt, and precisely define script templates for NFTs, FTs, and smart contracts. Historically, the ASM format has been poorly defined due to limited use cases and Bitcoin Core's disabling of most opcodes. BSV has re-enabled most opcodes and plans to restore all opcodes in the near future.Consequently, developers will craft increasingly complex smart contract scripts, heightening the need for a well-defined ASM format. This will elevate ASM from an ambiguous pseudo-language to a genuine programming language and foundational tool. This shift will usher in a renaissance for Bitcoin smart contracts
Create a super-script which includes all possible OP codes for full coverage, including those which will soon be "reactivated" within "Chronicle" release.
Add new unit tests to each of the ts-sdk go-sdk and py-sdk to check conversion of this test-script back and forth between the formats. SV Node, I wouldn't worry about as it will not change but will be obsolete soon enough as Teranode replaces it. Teranode will use go-sdk so we should be covered.
Write some sort of formal language spec (how you do that I don't know but we can look into it).
Update all the SDKs to ensure there is 1:1 conversion in both directions across all languages.
Summary
Source: YenPoint's Python SDK User Test Report. All credit to Ken Sato of YenPoint
The ASM (Assembly) format is valuable for programming Bitcoin Script. However, there are ambiguities in the ASM format of Bitcoin opcodes between the different SDKs (TypeScript, Python, GO). A standardized ASM format across all infrastructure, libraries, SDKs, etc. is required
The Go SDK, with its apparently comprehensive list of ASM might serve as the baseline for an ASM standard.
Example
The conversion between bytecodes, ASM, and higher-level languages should be seamless and consistent. This will empower developers to program in ASM, creating complex script templates using higher-level languages like Scrypt, and precisely define script templates for NFTs, FTs, and smart contracts. Historically, the ASM format has been poorly defined due to limited use cases and Bitcoin Core's disabling of most opcodes. BSV has re-enabled most opcodes and plans to restore all opcodes in the near future.Consequently, developers will craft increasingly complex smart contract scripts, heightening the need for a well-defined ASM format. This will elevate ASM from an ambiguous pseudo-language to a genuine programming language and foundational tool. This shift will usher in a renaissance for Bitcoin smart contracts
Other information
Examples of the Different ASM formats for each repositories
SVNode
Py-sdk
Typescript SDK
Go SDK
Relevance to BSV
The text was updated successfully, but these errors were encountered: