Today the Bitcoin (BSV) network allows merchants to receive payments globally from customers at an extremely low cost in fees compared to legacy fiat based financial systems. However during a short period of time these payments are subject to risk of fraud due to double spending. This risk is particularly notable for what is known as unconfirmed transactions. These are transactions that have not yet been included in the accounting ledger the network maintains known as the block chain.
This document outlines two systems that will provide merchants with additional security for BSV transactions, especially unconfirmed transactions. This security is optional and requires payment of an additional fee.
The second, Instant Transaction Insurance system is intended to be an easy to use system for merchants. The first system, Double Spend Detection, acts as a base layer and need not be used by merchants at all, although it could be.
The goal is to give merchants maximum security and convenience. Thus the goal of the DSD/ITI systems are:
Ideally the merchant would request that a transaction be monitored, and then after a short amount of time (< 2 seconds) the system would report if a double spend attempt has occurred or not.
More realistically:
A set of sensor machines distributed throughout the internet will be maintained. These sensors will be used to poll nodes mining on the network to verify that the network that has accepted a transaction with a high level of confidence.
That is transaction malleability will be exploited by sensors as a feature to maintain a map of hash power on the network. Then these same sensors will be used to inspect the mempools of major miners and arbitrary nodes on the network to ensure that no double spend attempts, that is conflicting transactions, have been broadcast.
When a customer initiates a transaction to a merchant the merchant messages an endpoint of the DSD system. This message will list the transaction to be monitored. The DSD system will respond when either:
It is assumed the network will tend to punish nodes that commit fraud via attempted double spends (i.e. clearly violate the first seen rule, or fail to propagate transactions) by orphaning blocks from those nodes, causing them to become unprofitable and thus ostracizing them from the network over time.
Specifically if a miner receives a (new) block from another (attacking) machine, and that block attempts to double spend a transaction that is in the miners mempool, and that transaction has been in the mempool for, say, over 10 seconds, then an effort to orphan (ignore) the block will be made by the miner.
Heroic CoinGeek has stated they will do this, or something similar, by orphaning blocks with clear double-spend transactions.
To avoid denial of service attacks on the network, miners may use double spend attempt detection systems, such as the one outlined above, to filter out obvious double spend attempts.
Insurance business models are well known and mature. The party to be insured, in our case the merchant pays a premium, in our case on an individual unconfirmed bitcoin transaction. Then in the event of damages, in our case fraud, (specifically a successful double spend), the merchant makes a claim, and receives reimbursement for the damages, up to a pre-agreed limit and less a deductible. In our case the damages are funds not received by the merchant due to a fraudulent double spend by the customer/thief.
The pseudonymous and global nature of bitcoin transactions creates some novel challenges. Ideally, to keep things simple for merchants, they would NOT be required to identify themselves, although it would be possible just as today many crypto exchanges and other business have KYC requirements.
Let us assume then that the system makes no KYC requirements.
Ideally a zero deductible would be charged to maximize simplicity for merchants.
Ideally a fixed premium would be charged per transaction, or at least per byte of the transaction, 2 satoshi per byte seems like a good initial price to encourage use.
By holding the deductible constant at 0, and the premium constant at 2 satoshi per byte, the only variable remaining is the limit. That is the maximum amount of damages due to double spend fraud that the system is able cover.
Thus realistically:
A merchant interested in obtaining insurance for a zero confirmation transaction will message an endpoint of the ITI system requesting insurance for a transaction. The ITI system will either not respond indicating risk limits have been (temporarily) exceeded or respond providing payment details in the form of a proposed bitcoin transaction. Finally the merchant will respond with a signed and funded version of the proposed transaction confirming the insurance contract.
Thus a traditional REST API is used for speed, and bitcoin transactions are used for security, and simplicity as the ITI system can reuse bitcoin as an accounts system. The ITI system would monitor for fraud, that is an attempted double spend on the merchant payment transaction to the ITI system, in which case the contract would be cancelled, and funds paid by the merchant (the premium) would be forfeit.
An example merchant software system, probably nodejs/javascript based would be created so that merchants don't need to implement their side of the system from scratch.
The ITI system would impose limits based on funds available to the system (the float) and claim history, and would be block based. For example if the ITI system is funded with say 1000 Bitcoin BSV initially (the float) then say half of that 1000 BSV, that is 500 BSV would be available initially for insurance, and after say 5 blocks are found, if no fraud occurs then that 500 BSV would be available again to insure new transactions.
If fraud occurs and all funds are lost then merchants would be made whole for their damages and only 500 BSV would be available for insurance and half of that, that is 250 BSV would be the limit for the next 5 blocks.
If no fraud occurs then premium payments made by merchants would be added to the float thus increasing system limits accordingly.
Obviously if the entire float is not required to provide insurance coverage in a single block, then remaining funds would be available to provide coverage in subsequent blocks. e.g. a 250 BSV float could be split into 50 BSV per block over 5 blocks.
This system can be rightfully criticized for centralizing risk into a 3rd party, specifically the DSD/ITI systems.
To mitigate this risk merchants will be able to run the ITI system themself. In which case it is no longer an insurance system but instead a risk management system through limiting maximum funds at risk.
If merchants that run the ITI system begin to insure, or reinsure transactions provided by other merchants then the system would be a fully decentralized insurance system, operating as a second layer.
The ITI system does not work in the presence of severe network congestion. If blocks are full and transactions funded with >= 1 satoshi per byte are not being accepted then no new contracts will be offered or agreed to by the system.
The DSD/ITI systems could either rely on callbacks to merchant endpoints or to reduce latency multiple calls to endpoints could be replaced with the use of persistent TCP/IP connections.
Currently there is no support for informing a merchant that a successful double spend has occurred. The merchant would need to use a separate receiving address for each customer transaction, and lookup each transaction on the blockchain to verify if the funds came from the customer address, or another source, which would indicate the ITI system has covered fraud.
In the event of fraud a merchant will have to wait several blocks before they receive funds. This is to handle the case of orphaned blocks.
Chained transactions up to 1000 deep should be handled.
During network upgrades the service may be suspended temporarily.
The highest priority work is to create a set of distributed sensor machines, with support for mapping hash power on the network and polling the mempool of mining nodes to detect double spend attempts. Then perform feasibility testing on the system by automating double spending attempts.
Thus a globally distributed set of sensor machines has been created which runs a modified version of the BSV source code.
Next steps: