🏬Bitcoin SPV Library

SPV(Simplified Payment Verification)

SPV

It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.

As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network. One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency. Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.

Verifying the Legitimacy of BTC Transactions through Oracle

The Merlin Protocol development team independently verifies and collaborates with the Chainlink oracle to achieve dual-security verification of transactions on the Bitcoin Network. This involves the oracle providing SPV query services, which require storing the hash of all Bitcoin block headers. Each block headers typically occupy about 80 bytes of storage, and currently, all block headers collectively take up approximately 60 bytes of storage. To alleviate the burden on the oracle, Merlin Protocol protocol opts to conduct SPV query services at specific heights (expected to be at height 750,000). After this particular height, the validity of all transactions can be verified using the Merkle algorithm to ensure the security and efficiency of the protocol.

Reference code:

// Solidity code
function checkWork(bytes29 _header, uint256 _target) internal view typeAssert(_header, Header) returns (bool) {
        return _header.work() < _target;
}


function checkParent(bytes29 _header, bytes32 _prevHeaderDigest) internal pure typeAssert(_header, Header) returns (bool) {
        return _header.parent() == _prevHeaderDigest;
}


function merkleRoot(bytes29 _header) internal pure typeAssert(_header, Header) returns (bytes32) {
        return _header.index(36, 32);
}


function target(bytes29  _header) internal pure typeAssert(_header, Header) returns (uint256) {
        uint256 _mantissa = _header.indexLEUint(72, 3);
        uint256 _exponent = _header.indexUint(75, 1).sub(3);
        return _mantissa.mul(256 ** _exponent);
}


function work(bytes29 _header) internal view typeAssert(_header, Header) returns (uint256) {
        return reverseUint256(uint256(workHash(_header)));
}

function publishHeader(uint32 _height, bytes29 _header) public {
        require(heights[_height] == 0, "HeaderPublisher: height exist");
        uint32 prevHeight = _height - 1;
        bytes29 prevBlockHeader = headers[prevHeight];
        require(_header.work(prevBlockHeader.target()), "HeaderPublisher: invalid work")
        require(blockHashes[_merkleRoot] == bytes32(0), "HeaderPublisher: header exist");
        blockHeaders[_merkleRoot] = _header;
}

Aligned with the algorithmic structure of the blockchain, the oracle internally stores block header data in the form of a chain list. Prior to submitting a new block to the oracle, smart contracts undergo Proof of Work (PoW) verification to ensure the validity of the data. This validation process ensures the legitimacy of new blocks and utilizes the PoW mechanism to prevent malicious submission of false data or tampering with information.

To mint mBTC, an attacker must invoke the smart contract's “mint” interface. In an attempt to circumvent genuine BTC transaction transfers, the attacker may try to compromise the oracle by submitting falsified BTC block header data. Upon receiving and on-chain confirmation, the oracle invokes the “work” interface to calculate the PoW for the block header data, which the attacker cannot forge.

Through this mechanism, the system effectively prevents Sybil attacks, ensuring that only requests based on authentic transaction data receive approval.