Instant transactions
The “FUD” around Bitcoin is deep, but we shall start to clear it up.
The truth is, most things in Bitcoin are simple. This is why many in the industry try to tell you otherwise. They seek to gain a falsely earnt place as the “High Priests of crypto”. They also seek to manipulate markets with false claims of vulnerabilities that do not exist—a form of fraud.
We had the lie and scam claim of Selfish Mining for years. That was the lie of the land for a long time. It was claimed that Bitcoin needed to be fixed by these disingenuous scammers, who really wanted nothing more than to ensure Bitcoin would not scale. Now, the false narrative, the lie, is the “0-conf-is-not-safe” mantra.
The latest is the fraudulent and unscientific claim of being able to double spend Bitcoin, that they could get away with a fraud and steal from a merchant that has taken an unconfirmed transaction and walk out with the ill-gotten goods. As always, they do a test in a lab with no relation to reality, but that is not even the start of it.
What is “0-conf” or an instant transaction?
To start to define any so-called attack, we need to start by defining what a 0-conf or an instant transaction is. The so-called attack is only of concern in a scenario where a merchant and client seek to complete and exchange in moments. This is, the client seeks to pay and then to “bounce” a transaction in seconds by fraudulently replacing it with another transaction that spends the same input transaction to a separate output.
The claim is that this can defraud the merchant, and thus a double spend means that the merchant is not safe.
The truth is this is an equivocation, made by those seeking to falsely manipulate markets; it is a form of fraud. The fraud is the claim of a double spend. The truth is, these do not exist. This is why anonymous accounts are always used in making these claims. This is basically a form of fraud. The key point is to appear valid and scientific to those without the skills to see the truth, and really, to deliver a message:
- including false or deceptive messages, and
- leaving out important information.
The reality is that all transactions have risk, but to minimise risk, you need to act in a certain way.
For a merchant, this means not assuming that you can send a transaction without a suitable mining fee. Note that, again, the merchant sends. This is the first and most critical part of all this. Bitcoin is a peer-to-peer system. It is the exchange of messages (transactions) that forms the peer component of the system, not mining. Mining is there to ensure the creation of a competitive system to stop double spending.
- Users exchange peer-to-peer with the ability to have messages sent to another party (through the miners) to be collected later when they log into their wallet.
- Miners are paid to not only verify transactions, but to find errors in the efforts of other miners, and to invalidate these.
So for a merchant, a vending machine even, to take a risk and accept a transaction from a client, they need to do this in a manner that makes the risk worthwhile. This is just a fact of life. It is nothing to be concerned with, like all other aspects of life; it means doing things correctly.
The following process is how a merchant process should be handled; this is what a 0-conf attack will need to overcome to be a real attack and not a marketing fraud.
Step 1. The client makes an offer to the merchant. This can be a request for a coffee in a café or selecting a product in a vending machine, whatever.
Step 2. The merchant sets the value and exchange rate, and hands a template to the client. This is a Bitcoin-transaction template with an output address, any conditions and the required scripts, and payment terms. An example of this is displayed in the image below.
Step 3. The reality is that the merchant sets the invoice up, and exchanges this with the client. We are also not talking about complex redemption systems.
Rather, we are allowing the merchant and client to exchange a transaction template using an SPV wallet (we will explain how this works in the coming weeks, and there is no SPV wallet — none has yet existed. More, they are simple).
The part that few seem to have understood is that keys should not be reused.
If we take the linked process (see URL) we can start with a known or determinable public key (even one on a CA on a PKI system) that is never used. From this, there are methods to create a series of output addresses that are designed to be used once and only once.
In the case of the merchant, we can have a system that allows all output addresses to be linked from a privacy-based scenario and yet to also be verifiably demonstrable from an audit and business scenario. That is, shareholders and even tax officials could determine that the invoice was not split or padded and that the correct amounts had been allocated to the correct addresses.
So, you can prove a private ledger created as a sub-set of the Bitcoin blockchain and still remain private.
This seems to be a difficult concept for some people. In the real world, a merchant or vendor gives you an invoice to pay. This does not change in the Bitcoin world. You send what is requested. The crypto-anarchist set seems to have this idea of what Bitcoin is, where a user can dictate how a merchant does business. Sorry, this is reality.
The merchant creates a template that is handed to the user.
Step 4. With the merchant’s template, the user can now decide on what input coins they want to use and where their outputs (if any) will go.
The user accepts the template, adds the input coins and sets the change address. Output 3 is not a “real” output as it is a miner fee. It is the MINIMUM amount that the user needs to send such that the total fees are paid to the miner and that there is a sufficient additional amount (not specified in output) that is now set as a fee for miners.
We can see a signed example above. It can even be compressed into a human-displayable format (one of the many aspects of what we have as Metanet) that is signed. To make this more private (in certain legal industries), a merchant could add inputs, and the client could add outputs to themselves (to make tracing more private).
The signed transaction is handed to the merchant. In this example, the merchant has set a requirement for 0.50 units in mining fees. If the client hands the merchant a transaction using less than this, they will reject it. It is the merchant and not the user who sets the terms used here, and the merchant can simply not allow the sale, if it is under the offer price.
In this example of a template, the merchant has a minimum output of 12.5 units with an optional field for tips. The merchant could automate the fees used in the template so that the client pays more as they add more input transactions, if this was desired. With SV, we do not see input transactions as a concern. These inputs lower the UTXO size, so miners should be willing to accept large input sets and charge based on the outputs (which was in the initial template exchange). It is one thing we want to push in SV.
The fees cover mining and VAT, and leave enough to pay the mining fee. If the client sends a lower value transaction to the miner, then the merchant will not have to accept it. Even if the user was a particularly stupid one, and thought they can do something to fool the merchant, such as sending the signed template, rather than returning it to the merchant, well, then they have legally made a donation to the merchant and not engaged in a legal contractual supply.
The merchant can (at their leisure) return funds to the client (with a handling fee), or have the client sit in a corner and wait until the fee has cleared (one confirm or multiple confirmations), or require that the client pay again and state that they (the merchant) will return funds (minus a mining fee and any handling charge) to the client AFTER the transaction has cleared with 6 confirmations AND the initial invoice is paid.
It is how the real world works. Bitcoin is not about allowing users to tell businesses how to operate. If you have such an idea, you are deluded.
Step 5. With the signed transaction returned from the client, the merchant now starts by sending a request to the mempool of the miners (or their own, if they are large enough to warrant having one; and for a franchise or group, this could be a company system) to check the inputs.
- The merchant checks the input TXs (transactions), and makes certain that these have not been spent. They do this by randomly polling miners (remember, ONLY miners are nodes in Bitcoin).
- The merchant ensures that the transaction from the user matches the template and that it includes sufficient fees and the total is at least the minimum (if the user wants to donate more to miners, who are we to stop them…).
- The merchant sends the transaction to multiple mining nodes, and relays simultaneously (I will detail how SPV should work in Jan 2019, and it is rather simple).
- The merchant rechecks the transaction inputs with miners, after sending their signed payment.
If the merchant detects a double spend, it is a fraud. The merchant has the legal right to detain the client in many countries and have the authorities take them off, just as is the case with shop lifters right now. This is before the client even received the goods. They can at this point be legally arrested for a larceny, and it is the same as when a person has attempted to pass a bad cheque.
The definition and use of cheques are covered by The Bills of Exchange Act 1882, and the Cheques Acts of 1957 and 1992. The most recent amendment to the Bills of Exchange Act occurred via the Small Business, Enterprise and Employment Act, which gained Royal Assent in 2015, eliminating the need for cheques to be physically transported around the country (and this definition incorporates a Bitcoin transaction that has not been confirmed).
In the U.S., there are state laws for this — these vary, but are generally similar to this one. For the UK, you will find page 214 of the attached offers some details of the offence (This is a clearer explanation of the UK laws, even if US based.).
Step 6. The merchant now provides the goods to the client. They have checked twice, made certain that the inputs had not been spent, and then they are safe in the assumption that the miners have received the transaction and no fraud has been attempted.
That is all there is. It is not some technical system of fraud proofs and the anarchist utopia that no state will exist. Bitcoin works inside and with the law.
If the merchant sets the template, pays the mining fees, and sends the transaction, there is no measurable risk of a double spend. Just as merchants will not allow customers to set payment terms and require a cheque from a strange country to just be used in consideration, they will not allow payment under strange terms.
The reality is that in 2 seconds (or less) the merchant has checked the transaction, and the reality is that you do not get to send a double spend. A double-spend attack is not about replacing your own transaction, it is about defrauding a merchant who allows small-value instant transactions. If the merchant sends, the chance of sending to all miners and getting a system that has a probabilistic chance of a free coffee are small. If the miners are polled after the send, the reality is that you will be caught double spending and get away with this fraud less than once in 100 billion times. In checking more miners, the merchant can be even more well assured.
The truth is, if you try and double spend, you will see a set of flashing lights and not even have the chance to smell the coffee.
0-conf and the online merchant
If you are Amazon, even this is not needed. The online merchant simply stops delivery as soon as they find the fraud attempt. Say you send an order with Amazon; then, the store starts to process the order. It is likely going to be hours before the invoice is touched, and if the transaction was “double-spent”, you have signed evidence of fraud and simply do not pack the goods.
Not reusing keys is important
One problem that I see all around is the re-use of keys. Bitcoin keys and addresses should be changed on every use. You should not receive funds to the same address twice, and you should not need to keep keys.
The biggest privacy failure in Bitcoin is the re-use of addresses. If users simply did not use the same address more than once (ever), the idea of tracking “spam” payments would not exist at all.
The truth is, if configured correctly, you should never ever have a re-use of Bitcoin addresses ever.
The false claims
There is a reason these people use anonymous accounts. They are frauds seeking to manipulate markets using false information.
My answer…
I will cover any loss that occurs on a REAL double-spend fraud. Oh… I do not expect to even have to spend a cent. I will also help ensure that the person who does it ends spending a long time in a small cell.
