In preparation for this year's edition of Bitcoin SV Developers Week, or Bitcoin SV DevCon 2021, we are making the most popular presentations of 2020 available in written format.

In this top presentation, nChain R&D software engineer Jad Wahab talks about Merchant API (mAPI), a recently introduced tool unique to the Bitcoin SV network. mAPI is an interface between nodes and miners, allowing anyone to easily interface with a node, in order to, for example, get policy limits and fees, submit transactions, obtain Merkle Proofs or receive double-spend alerts.

(If you’d rather watch, head over here. )

Bitcoin miner fee calculation and Merchant API (mAPI)

What is mAPI?

mAPI is an interface that lets merchants connect directly with Bitcoin nodes or miners.

Merchant API makes it easy for nodes to offer tailored services to merchants (or users), making peer-to-peer transactions easier in the process. 

Why is mAPI important?

To understand the importance of this tool, consider the background of Bitcoin scaling , peer-to-peer transactions, and the peer-to-peer network. 

The image above shows a 2009 email from Satoshi Nakamoto, the inventor of Bitcoin, to Mike Hearn, an early Bitcoin developer. 

In this email thread, Satoshi explains that the existing Visa credit card network processes about 15 million Internet purchases per day worldwide and that Bitcoin could already scale much larger than that with existing hardware, at a fraction of the cost, without ever hitting a scale ceiling. 

A lot has happened since 2009, but with Bitcoin SV, we are finally back to the scale Satoshi envisioned. On the Bitcoin SV Mainnet, transaction throughput of 3,987 transactions per second has been demonstrated over a sustained period (at height 656003 ) - and it keeps growing.

In this same email thread, Satoshi talks about transactions - which were effectively free at that time - and the future importance of fees and how they would develop on the network. He expressly referred to the need for implementing transaction fees once running a node became more burdensome, just as the case is today. 

He says that the node’s owner would decide the minimum fee they were willing to accept and users would get faster acceptance if they included a fee.

When Bitcoin was in its infancy, the way that a customer would send a transaction to a merchant was completely unscalable. The legacy method of sending a transaction worked like this: if a customer wanted to send a transaction to a merchant, they would first have to send it to the Bitcoin network. The merchant would then need to listen to all transactions on the network, scanning them to find the single transaction they were looking for, then drop all the rest. Why should a merchant need to process every single transaction on the network if they are only interested in one? As the Bitcoin network grows, it does not make sense for merchants to listen to all transactions across the world to verify a single one. 

Rather, it became increasingly evident that transactions should be conducted directly between users, that is, peer-to-peer. Using this model, a customer would send the transaction to a merchant directly and then the merchant would then send that to the network. 

Therefore, the merchant, or the recipient of the funds, is the party responsible for settling the transaction on the blockchain. It is a similar concept to cashing a cheque. If you want to send someone a cheque, you hand them the cheque and they must cash it. You don't send the cheque to the bank on their behalf.

This updated process allows the merchant who needs to settle that transaction to do it in the way they find most suitable. For example, if they needed to settle the transaction quickly, they would broadcast it immediately with a higher fee. If they were an online retailer that only ships in a few days or weeks, they would not have the same urgency and could choose to pay a lower fee. 

The Merchant API is one of many tools that makes these peer-to-peer transactions easier and more secure. It puts the merchant in charge of settling the transactions addressed to it. 

The role of nodes in preventing double-spends

In the past, there has been a lot of controversy around the double-spending of funds. The misunderstanding starts with the way the Bitcoin network was modelled, which was originally as a mesh network. 

But as time progressed it became evident that the Bitcoin network is not a mesh network, but rather a small-world network with a highly connected graph . In this network type, miners or nodes are densely connected to speed up the finding of hash solutions and propagation of new blocks. Block propagation happens every 10 minutes, on average, which is why every second counts.

It is not enough to find a valid block - as a miner, you must ensure that your block gets to everyone else on the network before it is usurped by a competing block. If you are not first, you fail to win your reward. In the GIF above, you can see an example of how a wallet sends a transaction to the network. 

Because Bitcoin miners are so densely connected, there are always fewer than three hops before a transaction reaches the entire Bitcoin mining network. Unlike in a mesh network structure, this process is fast and highly interconnected.

In the example below, someone is trying to spend the same funds twice by sending a transaction addressed to one recipient and another transaction sending the same funds back to themself via a different miner, both at the same time. 

This is like sending Amazon a cheque and then withdrawing all of the money from your account before they can cash it. But with Bitcoin, doing so leaves evidence that you attempted to defraud the merchant.

The GIF above illustrates what would happen in a small-world network if a customer tried to send a transaction to the merchant and then back to themselves at the same time. Because the network is so densely connected, it will be clear that there is another competing transaction on the network as soon as the merchant tries to settle that transaction. 

For the customer to defraud the merchant, they would need to get their double-spent transaction into the network within an incredibly small timeframe. Because of network delays, it is almost impossible to time this correctly. And even if timed correctly, the network can still foil the scam by notifying the merchant, who can then withhold the goods and take legal action.

Security vs usability

There is no such thing as 100% security – it is always a matter of risk and costs. And very often, it is the human element that foils even the best security measures.

There is always a trade-off between security and usability. The more security protocols implemented - two-factor authentication, extra layers of encryption and similar - the bigger the penalty on usability. 

These trade-offs must therefore be weighed to meet the required security threshold without over-engineering and sacrificing usability. 

With the Bitcoin network, we know that there is always only going to be one transaction that is written to the blockchain – that is how the technology works. You cannot have double-spends written to the blockchain. And as soon as one of the nodes finds a new block, the block will include one transaction or the other, or be orphaned (dropped). 

Based on that assumption, we do not need to have nodes settle the conflict between double-spends. It is sufficient to notify the merchant that a double-spend has occurred - and this is one of the functions that mAPI provides.

It is not the node’s job to be the arbiter of truth: nodes settle transactions.

It is the merchant or receiver of funds’ responsibility to settle the transaction properly, just like it is your responsibility to cash a cheque addressed to yourself. If you try to cash it in by mail and it gets lost, you won’t be able to hold the bank responsible.

Double-spends - theory vs practice

Double-spend attacks are always talked about theoretically, as there has never been a successful double-spend attack . In theory, one could pay a miner to process a double-spend transaction or reverse a transaction, but it is not at all practical. If you consider the hundreds of millions of dollars miners invest in their businesses, they are not going to risk all of that for your double-spend transaction so you can defraud Starbucks - especially one that is bound to be detected and thus be ultimately ineffective and inconsequential.  

The second element that prevents a double-spend relates to miner identity. If you tried to pay a miner to reverse your payment for a car purchase, for example, they would be attaching their identity to this fraudulent act. Miners are spending millions of dollars to remain competitive in the Bitcoin network. If they participate in fraud, they would commit a crime and risk their entire business model by harming the Bitcoin network they depend on. 

Additional security via mAPI 

Double-spend alerts

For even more security, companies like GAP 600 offer services that insures businesses that handle many quick payments. 

But mAPI already increases security, as it lets miners offer services like providing double-spend alerts that make transactions more secure. Think of mAPI as an ATM that allows you to cash your cheque directly with miners. 

'A system is secure if an adversary within a specific threat model cannot violate the security policy

,' - Dr George Danezis, Principles of Computer Security

Merkle proofs

Outside of double-spend alerts, mAPI provides additional security through Merkle proofs . Merkle proofs, also known as inclusion proofs, provide evidence of the exact time the network mined a transaction. As described in the white paper, the SPV header chain makes this possible, and because it is so small and grows at such a small rate (about 4MB per year), a low-cost device can generate it cheaply and easily.

Real-time notifications

Another service that miners can offer via mAPI is real-time notifications. If you are waiting for a type of transaction to be mined onto the blockchain - for example, Twetch posts - you can employ a miner to send you notifications. 

These are only a few services that miners are offering. mAPI allows them to be creative with their service offerings and enable clients to interface with them directly.

nLockTime transaction storage

The Genesis upgrade to the Bitcoin SV protocol restored nLockTime and the sequence fields of a transaction, many more use cases have become possible. nLockTime allows you to send someone a transaction and only permit them to spend it after a certain period of time has passed. 

When developing the Bitcoin software, the question came up as to whether all miners should have to store nLockTIme transactions that are essentially dated in the future. The consensus was that it depends on which services the miner is offering. It will cost the transaction processor money to store such a transaction, so they should be allowed to offer it as a paid service if they so choose. 

Miners and nodes vs transaction processors

You might have noticed that companies like TAAL are moving away from using the word ‘miner’ and refer to ‘transaction processors’ instead. Over the years, people have used the terms miner and nodes to refer to anything from hobbyists running Raspberry Pis right through to sophisticated mining pools using specialised ASIC machines.

By instead calling them transaction processors, we are in a way, professionalising the industry. The Bitcoin incentive system reduces the set block rewards over time to encourage miners to create other profitable business strategies around the blockchain. It is already a much more reliable long-term strategy to depend on transaction fees, but we expect to see more processors diversifying their service offerings in the future.

mAPI to enable Teranode scaling

Another reason why mAPI is crucial for the Bitcoin node software is that it has always been a huge monolithic structure. mAPI is the first step to compartmentalising the node by taking out the fee module. Instead of submitting transactions directly to the node, the mAPI fee module instead calculates the fee. Through this extension to the sendrawtransaction RPC call, a transaction can be sent without first checking with a node about the fee, enabling it to stand alone. It is the first step towards turning the Bitcoin node software into a micro-services architecture as part of the Teranode project, which will allow Bitcoin nodes to run at tremendous scale.

How does mAPI work?

In April 2020, the mAPI public beta was released on the Bitcoin SV GitHub with BRFC (Bitcoin request for comments), a reference implementation and a goal line. You can head over there to see the items currently on the repository. If you have any feedback, you can create issues on the repo or join the Telegram support group.

The mAPI interface

Currently, the mAPI interface is very simple. There are only three calls. You can get a fee quote that lets you discover the fees miners are charging other merchants to determine what fee you need to pay to have your transactions settled quickly. 

Once you have created your transaction, there is a 'post' option to submit your transaction and a 'get' option to query the transaction status so you can track when it's been mined. 

Data Flow - BIP270/PayMail

The data flow above gives a more in-depth view of how Merchant API fits in with the bigger picture of peer-to-peer transactions. BIP270 and PayMail work together as a mechanism for peers to discover each other and send transactions peer-to-peer to each other. 

Once the merchant knows where they need to request the payment from and what script they need to use, they would get the fees from mAPI and request the payment from the customer's wallet. Once they authorise it, the payment is sent back to the merchant. The merchant would then post and submit the transaction directly to the miner to settle it. Afterwards, they can query the transaction status. 

Miner ID

Using mAPI calls, miners can also sign their responses to make them even more secure. Miner ID is a way for miners to identify themselves through the coinbase transaction cryptographically. In the past, miners could put any data in the input of the coinbase transaction, which is the transaction that pays them ‘newly-minted’ satoshis for mining a block. This meant that anyone could impersonate someone else. By implementing Miner ID, miners identify themselves cryptographically by using a signature and a public key - which represents the Miner ID. 

Once miners put their public key into the block, identifying themselves, they can use the private key associated with that public key to sign data. They can also sign their mAPI responses with this private key. 

JSON envelopes

Using JSON for the mAPI system makes it tough to sign data, as it is not deterministic. To resolve the issue, the Bitcoin SV Node Team developed JSON Envelopes.

The problem with JSON’s lack of determinism is this: if you have a JSON with two fields, 'name' and 'colour', you can flip the name and the colour. You could even add spaces in their carriage returns. Although they would all be equivalent, to sign something cryptographically using the Elliptic Curve Digital Signature Algorithm ( ECDSA ), it must be deterministic. If you change one bit in what you're trying to sign, the whole signature will change and you won't be able to verify it. You thus need a way of making the JSON object deterministic to sign it properly. 

Enter JSON Envelopes, which are a way of 'enveloping' the JSON object inside another JSON object. The JSON object is stringified and then put as a payload of another JSON object, with the signature as another field on this piece of data and the public key. 

Fee specifications

In the past, Bitcoin did not have different fee specifications. Everyone would simply charge a single satoshi per byte. But when we start reducing fees to less than one Satoshi per byte, we get into decimals that make things a bit harder. 

Deterministic transaction fee calculation

To make things simpler, the Bitcoin SV Infrastructure Team developed a deterministic transaction fee calculation that uses integer amounts. Floating-point numbers are not the most accurate, so instead of setting the price at 0.5 satoshis per byte, it is set at 5 satoshis per 10 bytes.

Integer amounts are used, with a floor established, to ensure that a customer never underpays by one Satoshi. To establish proper convention, it is recommended that the bytes be set at a power of 10.

Bitcoin miner fee types

While merchants would use the above calculation to determine fees, miners could offer different services for different fee types. As Bitcoin SV lets you encode data in Bitcoin transactions through OP_RETURN outputs, there are also data fees that miners could price more cheaply.

How do I use mAPI?

You might be wondering how you can use mAPI. There are a few services that are connected to mAPI, as well as several miners, along with their nodes, that are already implementing it. 

The first is TAAL, which is leading the way with mAPI and Bitcoin services . Not only were they the first mining company to implement mAPI, but they have also added some extra services too. With their user-based fee policies, they have made deals with businesses to lower their fees for particular transactions or set volumes of transactions. 

Other services that offer mAPI include Mempool, DotWallet, Matterpool, whatsonchain, and Unwriter’s Minercraft . 

Bitcoin SV DevCon 2021

Bitcoin SV DevCon 2021 is set to kick off on May 15, 2021.

If you found this presentation valuable, you are sure to benefit from attending. Secure your spot by registering here .