cashscript
cashscript copied to clipboard
⚖️ Easily write and interact with Bitcoin Cash smart contracts
We should fix the length of bytes types when using split: `bytes2 firstTwoBytes = test.split(2)[0];` The above does not work, when it should always be possible to type the length...
Right now the artifact contains `"bytecode"`, which has ASM-formatted bytecode. Because there are multiple ways to represent bytecode as ASM (multiple ASM representations), it is probably better to have `"bytecode"`...
Since the upgrade to using bigint in the CashScript compiler, scientific notation has apparently been broken. We can fix this at the same time as implementing #171.
In certain cases, contracts (or collections of contracts) reuse pieces of code. For readability and reusability of complex operations it would be good to allow defining libraries/macros that live outside...
We should consider adding syntactic sugar for "slice" functionality so instead of `bytes stateItem = fullState.split(4)[1].split(10)[0];` it would be `bytes stateItem = fullState.slice(4,10);` suggesting the name `slice` because `substr` could...
`int conversionToBch = 100_000_000;` reads better and is more easily auditable than `int conversionToBch = 100000000;` This feature is also allowed in Javascript & Solidity. https://docs.soliditylang.org/en/latest/types.html#rational-and-integer-literals
Currently some casts will actually call conversion like int() resulting in compiled bytecode using OP_BIN2NUM. In some cases, when the user knows that the hex will be a valid script...
Declare them in contract() statement, but decide their position later, so compiled bytecode can add them later to avoid unnecessary stack juggling