DEV Community: sCrypt

Bitcoin OP_CAT Use Cases Series #2: Merkle Trees

sCrypt — Sun, 23 Jun 2024 07:25:35 +0000

Following our series #1, we demonstrate how to construct and verify Merkle trees using OP_CAT.

In Bitcoin, Merkle trees are utilized as the data structure for verifying data, synchronization, and effectively linking the blockchain’s transactions and blocks together. The OP_CAT opcode, which allows for the concatenation of two stack variables, can be used with SHA256 hashes of public keys to streamline the Merkle tree verification process within Bitcoin Script. OP_CAT uniquely allows for the creation and opening of entries in Merkle trees, as the fundamental operation for building and verifying Merkle trees involves concatenating two values and then hashing them.

There are numerous applications for Merkle trees. We list a few prominent examples below.

Merkle proof
A Merkle proof is a cryptographic method used to verify that a specific transaction is included in a Merkle tree without needing to download the entire blockchain. This is particularly useful for lightweight clients and enhancing the efficiency of data verification.

Tree signature
A tree signature is a cryptographic method that enhances the security and efficiency of digital signatures using tree structures, particularly Merkle trees. Compared to regular Multisig, this approach is used to generate a more compact and private proof that a message or a set of messages has been signed by a specific key.

Zero-Knowledge Proof
STARK (Succinct Transparent Arguments of Knowledge) is a type of zero-knowledge proof system. STARKs are designed to allow a prover to demonstrate the validity of a computation to a verifier without revealing any sensitive information about the computation itself. If OP_CAT were to be added to Bitcoin, it could potentially enable the implementation of a STARK verifier in Bitcoin Script, with work already ongoing. This would allow for secure and private transactions on the Bitcoin network. Compared to pairing-based proof systems such as SNARK, STARK is considered to be more Bitcoin-friendly.

Implementation
The implementation of the merkle tree using sCrypt is trivial. The following code calculates the root hash of a merkle tree, given a leaf and its merkle path, commonly used in verifying a merkle proof.

/**
 * According to the given leaf node and merkle path, calculate the hash of the root node of the merkle tree.
*/
@method()
static calcMerkleRoot(
    leaf: Sha256,
    merkleProof: MerkleProof
): Sha256 {
    let root = leaf

    for (let i = 0; i < MERKLE_PROOF_MAX_DEPTH; i++) {
        const node = merkleProof[i]
        if (node.pos != NodePos.Invalid) {
            // s is valid
            root =
                node.pos == NodePos.Left
                    ? Sha256(hash256(node.hash + root))
                    : Sha256(hash256(root + node.hash))
        }
    }

    return root
}

Full code is at https://github.com/sCrypt-Inc/scrypt-btc-merkle.

A single run results in the following transactions:

Script versions
There are alternative implementations in bare scripts, like the one below. One significant advantage of using sCrypt for implementing merkle trees is its readability and maintainability. Scripts are often extremely hard to read and work on.

OP_TOALTSTACK
OP_CAT
OP_CAT
OP_TOALTSTACK
OP_CAT
OP_TOALTSTACK

<0x8743daaedb34ef07d3296d279003603c45af71018431fd26e4957e772df122cb>
OP_CAT
OP_CAT
OP_HASH256

OP_DEPTH
OP_1SUB
OP_NOT
OP_NOTIF
OP_SWAP
OP_CAT
OP_CAT
OP_HASH256

OP_DEPTH
OP_1SUB
OP_NOT
OP_NOTIF
OP_SWAP
OP_CAT
OP_CAT
OP_HASH256

OP_DEPTH
OP_1SUB
OP_NOT
OP_NOTIF
OP_SWAP
OP_CAT
OP_CAT
OP_HASH256

OP_DEPTH
OP_1SUB
OP_NOT
OP_NOTIF
OP_SWAP
OP_CAT
OP_CAT
OP_HASH256

OP_DEPTH
OP_1SUB
OP_NOT
OP_NOTIF
OP_SWAP
OP_CAT
OP_CAT
OP_HASH256

...

Stay tuned for more OP_CAT use cases.

Smart Contract Programming Languages: sCrypt vs. Solidity

sCrypt — Fri, 05 Apr 2024 21:17:23 +0000

This article offers a comparison between two Web3 smart contract programming languages, sCrypt and Solidity, to help you decide which one you should use for building smart contracts in the Bitcoin or Ethereum Virtual Machine ecosystems, respectively.

Solidity
Solidity emerged as the first-ever programming language for smart contracts and remains the most extensively utilized language in the Web3 space due to its first-mover advantage. It serves as the primary language for developing applications today on Ethereum and
Ethereum Virtual Machine (EVM) compatible blockchains, including Binance Smart Chain and Tron.

sCrypt
sCrypt was developed with the aim of ensuring the utmost safety, security, and predictability in managing blockchain assets, while also equipping developers with the tools to create cutting-edge blockchain applications. Introduced 8 years following Solidity, sCrypt incorporated many lessons learned from the early years of Web3 application development, emphasizing the critical need for secure and reliable smart contracts. It is the primary smart contract language for Bitcoin Virtual Machine (BVM) based blockchains such as BTC, BSV, and MVC.

Overview: sCrypt vs. Solidity
Smart contracts control and manage billions of dollars’ worth of cryptocurrency and digital assets. Security flaws can lead to direct financial losses, particularly due to irreversible transactions and immutable code. Losses from hacks involving Solidity smart contracts have amounted to hundreds of millions of dollars over the years. These losses stem from a variety of vulnerabilities and attack vectors.

The Ethereum community has made significant efforts to enable developers to create secure smart contracts by providing security guidelines and compiling information on known attacks and vulnerabilities. However, despite these efforts, security issues persist, largely because the Solidity language inherently permits these vulnerabilities. In contrast, sCrypt effectively eliminates many of these security flaws right from the start.

sCrypt, being a modern language, learns from Solidity’s flaws. It adopts a distinctive approach in its design, focusing primarily on security and ensuring predictable behavior. The foundational principles of sCrypt were significantly influenced by analyzing prevalent Solidity vulnerabilities, leading to the development of a language specifically engineered with predictability and security as its primary objectives. sCrypt prioritizes security from the ground up. Its design was informed by a thorough review of the typical errors, vulnerabilities, and challenges encountered in smart contract development. The philosophy behind sCrypt emphasizes that if it’s possible to maintain functionality and expressiveness while greatly reducing the likelihood of human mistakes, such measures should be implemented at the language level.

Establishing the right mental frameworks for smart contracts and blockchain systems is crucial: complexity introduces a higher likelihood of bugs, leading to further complexity in attempts to fix those bugs. This cycle can trap us in a continuously escalating complexity spiral, as witnessed in Solidity. Tackling these challenges at the programming language level can prevent this compounding complexity.

Below is a high-level comparison between these two languages:

Decidability
sCrypt is considered decidable, since an sCrypt smart contract always terminates and halts in a finite number of steps, for any given input. Put simply: it is guaranteed that sCrypt contract execution will end.

Solidity supports unbounded loops, recursion, and dynamic function calls, which makes it impossible to decide if a Solidity smart contract will halt or not.

sCrypt disallows unbounded loops and recursion at language level. Surprisingly, this is achieved without sacrificing expressivity, meaning Bitcoin smart contracts are still Turing-Complete.

The fact that sCrypt is decidable ensures that developers (and their tools) can more straightforwardly understand and accurately predict how sCrypt contracts will behave, no matter what the input is. In many situations, particularly with high-stakes transactions or critical systems, this predictability is highly valued.

Decidability also allows for formal verification by complete static analysis of the entire call graph of a given smart contract. Formal verification is a popular method in security testing and auditing, using mathematical proofs to verify that specific properties of the contracts will consistently hold true or false under all conditions. Doing so to Solidity is incredibly difficult, due to the explosion of available paths.

Reentrancy
Reentrancy occurs when a smart contract makes a call to another contract, which then makes a call back to the original contract, effectively re-entering the initial logic. For instance, Contract A calls Contract B, waiting for a specific condition to be fulfilled before it updates its state. Meanwhile, Contract B calls back into Contract A. If your contract design isn’t meticulously crafted, reentrancy can cause your code to behave in unintended ways, whether due to a bug or as an exploit by a malicious entity. It could enable an attacker to execute multiple withdrawals before the contract updates its internal ledger, exposing the contract to various risks, including the potential for the total token balance to be siphoned off, as was infamously the case with the DAO hack.

Solidity permits reentrancy and has recently introduced an optional [noReentrancy] guard that developers can choose to implement or not. Ultimately, the responsibility is on the developers to use this feature.

In contrast, sCrypt does not permit reentrancy at all, eliminating this risk by design.

Overflows and underflows
In Solidity, overflows occur when a calculation exceeds the maximum value that can be stored, while underflows happen when a calculation falls below the minimum value. Such events can throw smart contracts into chaos, and attackers may deliberately trigger them in contracts that are poorly coded. Typically, this results in the contract becoming inoperable or being depleted of its tokens.

sCrypt guards against overflows and underflows by using only big numbers called bigint, a data type that can store integers with an arbitrarily large number of digits.

Learning Curve and Developer Tooling
sCrypt is an embedded Domain Specific Language (eDSL) based on TypeScript. It is strictly a subset of TypeScript, so all sCrypt code is valid TypeScript. TypeScript is chosen as the host language because it provides an easy, familiar language (JavaScript), but with type safety. There’s an abundance of learning materials available for TypeScript and thus sCrypt, including online tutorials, courses, documentation, and community support. This makes it relatively easy for beginners to start learning. It also has a vast ecosystem with numerous libraries and frameworks (e.g., React, Angular, Vue) that can simplify development and integration with Web2 applications.

Solidity presents a steeper learning curve, especially for those new to blockchain concepts. It requires a solid understanding of specific security practices and the Ethereum ecosystem. While there are growing resources for learning Solidity, including official documentation, tutorials, and courses, the pool is orders of magnitudes smaller compared to TypeScript.

Debugging Solidity code can prove to be difficult because of the limited availability of advanced debugging tools. This limitation hampers the ability to diagnose and fix issues, particularly in the case of complex contracts. sCrypt, being TypeScript, enjoys many modern debuggers such as in Visual Studio Code. It is supported by any TypeScript IDEs, including Visual Studio Code, WebStorm, Vim and Atom.

Pure
A pure function is a specific type of function that has the following characteristics:

_Deterministic Output: _The output of a pure function is solely determined by its input values. Given the same input, a pure function will always return the same output.
Stateless: A pure function does not maintain or require any internal state to compute their output.
_No Side Effects: _A pure function does not cause any observable side effects in the outside world. This means it does not modify any external state, global variables, or data outside its scope, nor does it depend on any external state. Pure functions align closely with mathematical functions like quadratic (y=ax²+bx+c) or trigonometric (y=sin(x)). They allow for greater predictability, easier testing, and more efficient code optimization by compilers.

All sCrypt functions declared as public are pure and boolean, evaluating to true or false. A function returning true will always return true, regardless of where, when, and how it is run. Its return is only determined by the calling transaction and arguments, which are both local. This means if a function is true when tested locally, it will be deemed true by miners when the enclosing transaction is broadcast. We do not even need to run a local node (e.g., regtest) to test it, since it can be evaluated without accessing a miner network.

In Solidity, functions are impure and capable of interacting with the blockchain through various actions, including reading from and altering the contract’s state, transferring ether, and invoking other contracts. The only exception is functions marked as pure. This impurity and unpredictability can make the code harder to test, debug, and reason about. Impure functions that alter contract states or perform transactions can be exploitable points for attackers.

Postconditions
Postconditions in programming are conditions or predicates that must hold true immediately after the execution of a program or a specific block of code, such as a function or method. They are a key concept in the design by contract methodology, where they are used to specify and document the expected state of a system after a piece of code executes. Postconditions help in ensuring that a program behaves as expected and can be used for debugging, testing, and formal verification purposes.

Let’s consider a function that increments a given number by one. To illustrate postconditions in JavaScript, a simple check is included after the function’s execution to ensure the postcondition holds true.

function incrementByOne(number) {
  const result = number + 1;
  return result;
}

// Function to check postcondition
function checkPostcondition(input, output) {
  if (output !== input + 1) {
    throw new Error('Postcondition failed: The output is not one greater than the input.');
  }
}

// Example usage
const inputNumber = 5;
const incrementedNumber = incrementByOne(inputNumber);

// Check the postcondition
checkPostcondition(inputNumber, incrementedNumber);

console.log('Incremented number:', incrementedNumber);

In the context smart contract, postconditions protect developers and users from bugs and abuse.

In sCrypt contracts with state update, the new state has to be passed in when the calling transaction is constructed off chain, which is verified in the smart contract on chain. We are guaranteed the contract enters the expected and correct new state after the call.

In Solidity, only the action of how a state is updated is specified. The new state is generally not passed in and one could only hope the contract is updated to the new expected state, making it unpredictable and error-prone.

sCrypt verifies, while Solidity computes. The former is more secure and reliable.

Composition over inheritance
sCrypt emphasizes using composition instead of inheritance. This approach implies that sCrypt smart contracts do not engage in inheritance as observed in languages such as Solidity. Consequently, there’s no need to navigate through intricate class hierarchies or deal with contracts that carry implicit behaviors from their ancestors. sCrypt mandates explicitness and deliberate composition in its design. Without the concept of inheritance, developers are required to clearly define the actions of their code. This characteristic enhances the predictability and transparency of contracts and simplifies the audit process.

The Complete Guide to Full Stack Bitcoin SV Development

sCrypt — Thu, 28 Mar 2024 17:09:25 +0000

In this guide, you’ll learn a web3 tech stack that will allow you to build full stack decentralized apps on the Bitcoin SV blockchain. We will walk through the entire process of building a full stack decentralized Tic-Tac-Toe, including:

Write a smart contract.
Deploy the contract
Add a front-end (React)
Integrate Yours wallet

By the end, you will have a fully functional Tic-Tac-Toe App running on Bitcoin.

What we will use

Let’s go over the main pieces we will be using and how they fit into the stack.

1 - sCrypt Framework

sCrypt is a TypeScript framework to develop smart contracts on Bitcoin. It offers a complete tech stack:

the sCrypt language: an embedded
Domain Specific Language
(eDSL) based on TypeScript, which allows developers to write
smart contracts directly in TypeScript. Developers don’t have
to learn a new Web3 programming language like Solidity, and can
reuse their favorite tools, like IDEs and NPM.
library (scrypt-ts):
a comprehensive and concise library
designed for client-side JavaScript applications, such as
React, Vue, Angular, or Svelte, to interact with the Bitcoin SV
Blockchain and its ecosystem.
sCrypt CLI: CLI to
easily create, compile and publish sCrypt
projects. The CLI provides best practice project scaffolding.

2. Yours Wallet

Yours Wallet is an open-source digital wallet for BSV and 1Sat Ordinals that enables access to decentralized applications developed on Bitcoin SV. Yours Wallet generates and manages private keys for its users in a non-custodial manner, ensuring that the users have full control over their funds and transactions. These keys can be utilized within the wallet to securely store funds and authorize transactions.

3. React

React.js, often simply referred to as React, is a JavaScript library developed by Facebook. It’s primarily used for building user interfaces (UIs) for web applications. It simplifies the process of building dynamic and interactive web applications and continues to be seemingly dominating the front-end space.

What we will Build

We will build a very simple Tic-Tac-Toe game on chain. It uses the Bitcoin addresses of two players (Alice and Bob respectively) to initialize a smart contract. They each bet the same amount and lock it into the contract. The winner takes all bitcoins locked in the contract. If no one wins and there is a draw, the two players can each withdraw half of the money. Tic-Tac-Toe, the age-old game of strategy and skill, has now found its way onto the blockchain thanks to the power of sCrypt.

Prerequisites

1 - Install node.js and npm (node.js ≥ version 16)
2 - Install Git
3 - Yours wallet Chrome extension installed in your browser
4 - Install sCrypt CLI
npm install -g scrypt-cli

Getting Started

Let’s simply create a new React project.

Firstly let’s create a new React project with TypeScript template.

npx create-react-app tic-tac-toe --template typescript

Then, change the directory to the tic-tac-toe project directory and also run the init command of the CLI to add sCrypt support in your project.

cd tic-tac-toe npx scrypt-cli@latest init

Tic-tac-toe Contract
Next, let’s create a contract at src/contracts/tictactoe.ts:

import {
    prop, method, SmartContract, PubKey, FixedArray, assert, Sig, Utils, toByteString, hash160,
    hash256,
    fill,
    ContractTransaction,
    MethodCallOptions,
    bsv
} from "scrypt-ts";

export class TicTacToe extends SmartContract {
    @prop()
    alice: PubKey;
    @prop()
    bob: PubKey;
    @prop(true)
    isAliceTurn: boolean;
    @prop(true)
    board: FixedArray<bigint, 9>;
    static readonly EMPTY: bigint = 0n;
    static readonly ALICE: bigint = 1n;
    static readonly BOB: bigint = 2n;

    constructor(alice: PubKey, bob: PubKey) {
        super(...arguments)
        this.alice = alice;
        this.bob = bob;
        this.isAliceTurn = true;
        this.board = fill(TicTacToe.EMPTY, 9);
    }

    @method()
    public move(n: bigint, sig: Sig) {
        // check position `n`
        assert(n >= 0n && n < 9n);
        // check signature `sig`
        let player: PubKey = this.isAliceTurn ? this.alice : this.bob;
        assert(this.checkSig(sig, player), `checkSig failed, pubkey: ${player}`);
        // update stateful properties to make the move
        assert(this.board[Number(n)] === TicTacToe.EMPTY, `board at position ${n} is not empty: ${this.board[Number(n)]}`);
        let play = this.isAliceTurn ? TicTacToe.ALICE : TicTacToe.BOB;
        this.board[Number(n)] = play;
        this.isAliceTurn = !this.isAliceTurn;

        // build the transation outputs
        let outputs = toByteString('');
        if (this.won(play)) {
            outputs = Utils.buildPublicKeyHashOutput(hash160(player), this.ctx.utxo.value);
        }
        else if (this.full()) {
            const halfAmount = this.ctx.utxo.value / 2n;
            const aliceOutput = Utils.buildPublicKeyHashOutput(hash160(this.alice), halfAmount);
            const bobOutput = Utils.buildPublicKeyHashOutput(hash160(this.bob), halfAmount);
            outputs = aliceOutput + bobOutput;
        }
        else {
            // build a output that contains latest contract state.
            outputs = this.buildStateOutput(this.ctx.utxo.value);
        }
        if (this.changeAmount > 0n) {
            outputs += this.buildChangeOutput();
        }
        // make sure the transaction contains the expected outputs built above
        assert(this.ctx.hashOutputs === hash256(outputs), "check hashOutputs failed");
    }

    @method()
    won(play: bigint): boolean {
        let lines: FixedArray<FixedArray<bigint, 3>, 8> = [
            [0n, 1n, 2n],
            [3n, 4n, 5n],
            [6n, 7n, 8n],
            [0n, 3n, 6n],
            [1n, 4n, 7n],
            [2n, 5n, 8n],
            [0n, 4n, 8n],
            [2n, 4n, 6n]
        ];
        let anyLine = false;
        for (let i = 0; i < 8; i++) {
            let line = true;
            for (let j = 0; j < 3; j++) {
                line = line && this.board[Number(lines[i][j])] === play;
            }
            anyLine = anyLine || line;
        }
        return anyLine;
    }

    @method()
    full(): boolean {
        let full = true;
        for (let i = 0; i < 9; i++) {
            full = full && this.board[i] !== TicTacToe.EMPTY;
        }
        return full;
    }

}

Properties
The Tic-Tac-Toe contract features several essential properties that define its functionality:

1 - Alice and Bob: Public keys of the two players.
2 - is_alice_turn: A boolean flag indicating whose turn it is
to play.
3 - board: A representation of the game board, stored as a
fixed-size array.
4 - Constants: Three static properties defining game symbols
and empty squares.

Constructor

constructor(alice: PubKey, bob: PubKey) {
        super(...arguments)
        this.alice = alice;
        this.bob = bob;
        this.isAliceTurn = true;
        this.board = fill(TicTacToe.EMPTY, 9);
    }

Upon deployment, the constructor initializes the contract with the public keys of Alice and Bob. Additionally, it sets up an empty game board to kickstart the game play.

Public methods
Each contract must have at least one public @method. It is denoted with the public modifier and does not return any value. It is visible outside the contract and acts as the main method into the contract (like main in C and Java).

The public method in the contract is move(), which allows players to make their moves on the board. This method validates the moves, checks the player's signature, updates the game state, and determines the outcome of the game.

Signature verification

Once the game contract is deployed, anyone can view and potentially interact with it. We need an authentication mechanism to ensure only the desired player can update the contract if it’s their turn. This is achieved using ditigal signatures.

Only the authorized player can make a move during their turn, validated through their respective public key stored in the contract.

// check signature `sig`
let player: PubKey = this.isAliceTurn ? this.alice : this.bob;
assert(this.checkSig(sig, player), `checkSig failed, pubkey: ${player}`);

Non-Public methods

The contract includes two non-public methods, won() and full(), responsible for determining whether a player has won the game and if the board is full, leading to a draw.

Tx Builder: buildTxForMove

Bitcoin transaction can have multiple inputs and outputs. We need to build a transaction when calling a contract.

Here, we have implement a customize transaction builder for the move() method as below:

static buildTxForMove(
    current: TicTacToe,
    options: MethodCallOptions<TicTacToe>,
    n: bigint
  ): Promise<ContractTransaction> {
    const play = current.isAliceTurn ? TicTacToe.ALICE : TicTacToe.BOB;
    const nextInstance = current.next();
    nextInstance.board[Number(n)] = play;
    nextInstance.isAliceTurn = !current.isAliceTurn;
    const unsignedTx: bsv.Transaction = new bsv.Transaction().addInput(
      current.buildContractInput(options.fromUTXO)
    );
    if (nextInstance.won(play)) {
      const script = Utils.buildPublicKeyHashScript(
        hash160(current.isAliceTurn ? current.alice : current.bob)
      );
      unsignedTx.addOutput(
        new bsv.Transaction.Output({
          script: bsv.Script.fromHex(script),
          satoshis: current.balance,
        })
      );
      if (options.changeAddress) {
        unsignedTx.change(options.changeAddress);
      }
      return Promise.resolve({
        tx: unsignedTx,
        atInputIndex: 0,
        nexts: [],
      });
    }
    if (nextInstance.full()) {
      const halfAmount = current.balance / 2;
      unsignedTx
        .addOutput(
          new bsv.Transaction.Output({
            script: bsv.Script.fromHex(
              Utils.buildPublicKeyHashScript(hash160(current.alice))
            ),
            satoshis: halfAmount,
          })
        )
        .addOutput(
          new bsv.Transaction.Output({
            script: bsv.Script.fromHex(
              Utils.buildPublicKeyHashScript(hash160(current.bob))
            ),
            satoshis: halfAmount,
          })
        );
      if (options.changeAddress) {
        unsignedTx.change(options.changeAddress);
      }
      return Promise.resolve({
        tx: unsignedTx,
        atInputIndex: 0,
        nexts: [],
      });
    }
    unsignedTx.setOutput(0, () => {
      return new bsv.Transaction.Output({
        script: nextInstance.lockingScript,
        satoshis: current.balance,
      });
    });
    if (options.changeAddress) {
      unsignedTx.change(options.changeAddress);
    }
    const nexts = [
      {
        instance: nextInstance,
        atOutputIndex: 0,
        balance: current.balance,
      },
    ];
    return Promise.resolve({
      tx: unsignedTx,
      atInputIndex: 0,
      nexts,
      next: nexts[0],
    });
  }

Integrate Front-end (React)

After we have written/tested our contract, we can integrate it with front-end so that users can play our game.

First, let’s compile the contract and get the contract artifact json file by running the command below :

npx scrypt-cli@latest compile

You should see an artifact file tictactoe.json in the artifacts directory. It can be used to initialize a contract at the front end.

import { TicTacToe } from './contracts/tictactoe';
import artifact from '../artifacts/tictactoe.json';

TicTacToe.loadArtifact(artifact);

Install and Fund Wallet

Before deploying a contract, we need to connect a wallet first. We use Yours Wallet, a MetaMask-like wallet.

After installing the wallet, click the settings button in the upper right corner to switch to testnet. Then copy your wallet address and go to our faucet to fund it.

Connect to wallet

We call requestAuth() to request to connect to the wallet. If the request is approved by the user, we now have full access to the wallet. We can, for example, call getDefaultPubKey() to get its public key.

const walletLogin = async () => {
    try {
      const provider = new DefaultProvider({
          network: bsv.Networks.testnet
      });
      const signer = new PandaSigner(provider);
      signerRef.current = signer;

      const { isAuthenticated, error } = await signer.requestAuth()
      if (!isAuthenticated) {
        throw new Error(error)
      }
      setConnected(true);
      const alicPubkey = await signer.getDefaultPubKey();
      setAlicePubkey(toHex(alicPubkey))
      // Prompt user to switch accounts
    } catch (error) {
      console.error("pandaLogin failed", error);
      alert("pandaLogin failed")
    }
};

Initialize the contract

We have obtained the contract class Tictactoe by loading the contract artifact file. When a user clicks the start button, the contract is initialized with the public keys of two players alice and bob. The public key can be obtained through calling getDefaultPubKey() of Signer.

The following code initializes the contract.

const [alicePubkey, setAlicePubkey] = useState("");
const [bobPubkey, setBobPubkey] = useState("");
...
const startGame = async (amount: number) => {
  try {
    const signer = signerRef.current as PandaSigner;
    const instance = new TicTacToe(
        PubKey(toHex(alicePubkey)),
        PubKey(toHex(bobPubkey))
      );
    await instance.connect(signer);

  } catch(e) {
    console.error('deploy TicTacToe failes', e)
    alert('deploy TicTacToe failes')
  }
};

Call the contract

Now we can start playing the game. Every move is a call to the contract and triggers a change in the state of the contract.

const { tx: callTx } = await p2pkh.methods.unlock(
    (sigResponses: SignatureResponse[]) => findSig(sigResponses, $publickey),
    $publickey,
    {
        pubKeyOrAddrToSign: $publickey.toAddress()
    } as MethodCallOptions<P2PKH>
);

After finishing with the front-end you can simply run :
npm start

You can now view it at http://localhost:3000/ in your browser.

Conclusion

Congratulations! You have just built your first full stack dApp on Bitcoin. Now you can play tic-tac-toe or build your favorite game on Bitcoin. Now would be a good time to pop some champagne if you haven’t already :).

One session of play can be viewed here:

https://youtu.be/l65Ha5AmKjk

All the code can be found at this github repo.

By default, we deploy the contract on testnet. You can easily change it to mainnet.

How to Become a BSV Blockchain Developer in 2024

sCrypt — Thu, 28 Mar 2024 16:16:59 +0000

In this rapidly growth of blockchain technology, developers play a pivotal role in shaping the future of decentralized systems. Among all the blockchain platforms, Bitcoin SV (BSV) stands out as a powerful Blockchain offering scalability, security, and stability. As we venture into 2024, the demand for skilled BSV blockchain developers continues to surge. If you’re excited and ready to dive into this exciting field, this comprehensive guide will show you the path to become a proficient BSV blockchain developer.

Understanding the BSV Ecosystem:

Before delving into the specifics of BSV development, it’s essential to grasp the fundamentals of the BSV ecosystem. BSV, short for Bitcoin Satoshi Vision, emerged as a result of a contentious hard fork from the Bitcoin Cash (BCH) blockchain. It upholds the original vision outlined in Satoshi Nakamoto’s whitepaper, emphasizing large block sizes and low fees to enable scalable transactions and data storage so that enterprises application can be build on top of blockchain.

Understand Basics :

BSV Academy - Bitcoin Theory Bitcoin Theory covers the design of Bitcoin as a system as prescribed by Satoshi Nakamoto.
BSV Academy - Bitcoin Essentials Bitcoin essentials covers Hash Functions, Merkle tree, Digital Signatures e.t.c.
Learnmeabitcoin - A very useful and comprehensive resources to understand how bitcoin (bsv) actually work.

Smart Contracts

sCrypt : sCrypt is an embedded Domain Specific Language (eDSL) based on TypeScript for writing smart contracts on Bitcoin SV. sCrypt is very powerful as Smart contracts on Bitcoin are based on the UTXO model, which makes bsv blockchain scale.
docs : A comprehensive documentation to learn sCrypt.
Boilerplate : Sample sCrypt Smart Contract codes along with tests with dozens of contract written already.

Developer Resources

A list of resources, tools, libraries, and projects related to the Bitcoin SV can be found here. Below are some of the resources :

sCrypt - ord : 1sat Ordinals library
DartSV : A dart library for interacting with bitcoin network.
JungleBus : is a powerful, low-level indexer to power lightweight Bitcoin data sets.
Bitcoin class with satoshi : A very useful youtube channel to learn sCrypt.

Communities

Telegram
Discord
Slack
X(twitter)
Reddit

Continuous Learning:

The field of blockchain technology evolves at a rapid pace, necessitating a commitment to lifelong learning. Engage with the BSV community through forums, meetups, and online resources to stay updated on industry trends.

Career and Opportunities:

As a BSV blockchain developer, you’ll find a wealth of career opportunities across various sectors in the eco - system. Whether you aspire to work for established enterprises, startups, or embark on entrepreneurial ventures, the demand for BSV expertise continues to grow exponentially.

Bsv blockchain jobs

Conclusion:

Becoming a proficient BSV blockchain developer requires dedication, curiosity, and a willingness to continue learning. By mastering sCrypt, leveraging BSV libraries and frameworks, and staying informed about the latest protocols and tools, you’ll position yourself as a valuable asset in the blockchain industry. As we navigate the transformative landscape of decentralized technology, seize the opportunity to leave your mark as a skilled BSV blockchain developer in 2024 and beyond.

Tag me if you build something great.