Spending the simple way in Bitcoin cash.
It seems to be that many people believe that we require a malleability fix in Bitcoin cash. When pushed for a real reason, one with business use, they at best come up with the concept that we need to be able to spend change in under 10 minutes. What is overlooked is that a chained payment is a second-class transaction and any merchant without knowledge of the parties would be foolish to accept such a transaction built without external trust links.
Why is this?
The reason is that no system, not even Schnorr solves first party malleability. Until a transaction is included within a Block, it is open to change. This is in effect a double spend. In Bitcoin cash, this is a low probability event, but the risk always increases as transactions are chained. Each link in the chain is an increased chance to have a double spend.
Complexity when simple is needed
Before we address any more complex or convoluted methods, I will state that the simple answer is often the best. Bitcoin was designed with the idea of splitting and re-combining in mind. This concept is incorporated into the Bitcoin whitepaper in section 9. This part of the paper notes the use of re-combinatorics. That is, splitting and re-joining transactions. As this section states:
“It should be noted that fan-out, where a transaction depends on several transactions, and those transactions depend on many more, is not a problem here. There is never the need to extract a complete standalone copy of a transaction’s history.”
This is displayed in the image from the paper below:
Bitcoin was designed to be split and recombined. This concept is old. It is how we handle cash now. We compile notes and coins to make up the payment. We can collect many small coins or just hand over a large note and seek change.
The trouble with this concept only comes about if an artificial cap is placed on Bitcoin through a block limit. In limiting the number of signature operations and the size of the blocks, the ability to split and combine coins becomes prohibitively expensive. The end result is the very nature of Bitcoin starts to be altered. In allowing this to have become the status quo, we have forgotten how Bitcoin derives a basic level of fungibility.
In maintaining a variable set of unspent outputs rather than a single large address, you increase both your security and privacy automatically. A single address is always more of a target than many small addresses that may or may not be related. Even the simple action of division into new addresses makes it more difficult to trace ownership.
Yes, when coins are recombined, you can link some of the information from this event, but if this is done as a matter of course and not as the outlier event, then it becomes more difficult to correlate unspent outputs (coins).
In fact, only those coins can be linked. If you want to ensure privacy, then when having “random” payments come into your wallet, you could also send these separately to be mixed. This then removes the ability to have these used in the way that a tracking cookie is used on the web.
A good, privacy-focused wallet would allow the user to separate and isolate inputs as well as to divide these. This has been one of the most insidious consequences of limiting the block size. In doing this, the limits that come from trying to combine unspent coins into fewer inputs have led to a system with far less privacy. When there are only one or two inputs to all payments, it becomes really easy to trace the movement of coins.
When we start making wallets split coins and not use the same address (that is, to avoid address reuse), we find that we have more and not less control of our money. It becomes more fungible and more difficult to trace all we do. That is what we have had slowly eroded away from Bitcoin, the privacy and usability of simple cash. We have the fallacies about how difficult it will be to use and the lies that say that monetary sovereignty require checking all transactions in the blockchain separately.
The truth is that maintaining control of our private keys and allowing the system to split and recombine inputs creates fungibility and adds privacy.
Optimal Cash Denominations
When we start to think of Bitcoin as cash, we can start to link existing spending and purchasing habits of consumers. When we want to spend, we do not generally walk out the door carrying a large pile of 500 Euro notes. If we were to do so, we might find spending that sum difficult. We would need to curtail some of our day seeking vendors will to accept and provide change for these notes. Many will not.
It is the same with Bitcoin, if we expect to walk into a store and spend 100 BCH in a single TX and then have the transaction used as a chain in a second store in under 10 minutes and maybe even a third, we are not taking the time to understand how Bitcoin was designed.
A spending wallet could be created with automatic allocation rules based on existing cash allocation systems. Such a wallet would allow a consumer to load value onto their phone or mobile wallet before shopping. The result is that they would not need to take all of their Bitcoin with them, allowing the consumer to limit the amount that they are willing to carry. This could even be linked to automated rules that can be used to top-up the wallet remotely on determined events or limits or when a remotely located person is involved.
This is also a well known scenario in the Gaming industry. There are limits to the opportunities to exchange chips at the table in a casino. So, in order to be able to raise and play well, the mix of chips is also important. This is not just a concept that comes from using cash, it is also linked to the concept of putting together a functional poker chip set.
Vaulting and saving
In the physical world, we have vaults, safes and cash boxes. In societies such as those in Japan and Switzerland, this will be an easier concept. In Japan the idea of saving cash remains the norm. This society has not been suppressed in a manner like that in Spain. This concept has been slowly eroded away with the freedoms that people once enjoyed. I say suppressed as in Spain it is illegal to withdraw or spend even moderate amounts of cash. This limit was 2,500 Euro in 2016 and has been decreased to only 1,000 Euro.
If we start to think of Bitcoin as a cash system again, we can start to think of using it as cash would have been used and how cash is still used in countries like Japan where it is common and remains un-suppressed.
When we use cash, we take money out of a cash box and place what we expect into a wallet. This is how Bitcoin was designed as well. We can lock up a large amount of funds in a safe place. Think of this more secure warm storage as a cash box or safe that you may have at home.
As section 9 of the whitepaper states:
Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.
In this way, we send the stored value into our wallets that we can use for shopping. From this point, we can spend when we are at a merchant or have our wallets topped up (even remotely).
A further example of not thinking the issue through and understanding Bitcoin is that of what if you want to buy goods for another person. This is also touted as a reason to fix malleability. In this (contrived) scenario, you are at a store and a friend calls saying can you buy X for me as well (maybe they saw a social media post of w=something you just purchased…)
The claim is that you need to receive your friend’s funds to your wallet and then spend this on the purchase (in under 10 minutes again).
I say that this is contrived for a reason. In this scenario, it is clear that those making this claim do not understand the nature and power of Bitcoin.
We see that this was never how Bitcoin was designed in a reading of section 10 from the whitepaper.
If we step back and think of the scenario, we know that our friend can see and interact with us. This means that they do not require that we act as a trusted third party in this transaction. How? Easy, the friend pays directly.
If the friend is already willing to have us collect the goods for them, they could also do this when the friend pays directly and in fact, they would not need to place as much trust in us for this.
Rather than chaining a transaction, Bitcoin allows us to pay the store / merchant directly. We can act as a proxy for our friend and send them a payment request. This could be something like that proposed in BIP 70 by Gavin and Mike.
In this way, the merchant is paid instantly and there is no chaining required. The friend could even be on the other side of the globe and the payment would reach the merchant in a couple seconds to be verified as a standard 0-conf (zero confirmation) while you wait (and this would be in the order of 1–3 seconds.
So, I need to inquire, why are we seeking to make more difficult “solutions” when a far superior method exists right now and was incorporated from the start into Bitcoin?
This is not a real scenario. Malleability does not need a fix to stop this occurring. The nature of Bitcoin is to not require the use of third parties, so why are so many people doing their utmost to make third parties a part of Bitcoin?
The clear argument that I would expect from this concept other than Block-size would be the false need to limit the UTXO size.
In splitting bitcoin, we increase the UTXO size. This has been falsely sold as a problem. This is how Bitcoin was designed. The people who are trying to limit block-size are in effect selling you the idea of privacy as they make your privacy easier to subvert and remove.
Once you accept that mining will become a corporate activity, managed and secured economically and through competition, the faster that you start to see that this is an economic system and that it is secured economically. It was destined to scale.
The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don’t generate.
There was never really a long-term issue with the growth of a UTXO set outside the false idea that all people need to run a node. Once we accept that this is not how Bitcoin was designed, we can start to grow the system and start to make it valuable to billions of people.
Once we move past the unfounded FUD that has been oversold as a scaling issue (and seems more to be a method to extract value from Bitcoin into Alt-Coins) we start to see that Bitcoin was designed to work as cash and when it is used this way, it works best.
So, as for the idea that we need to fix malleability so we can chain transactions, well, that is a straw-man in any event. We would never have merchants trusting chains of unconfirmed transactions to the same level as they would a single 0-conf that they can monitor and know the risk of in under a second.
Chained transactions have a purpose. When you are dealing with payment channels, a series of transactions can be linked. For this scenario, there are solutions that can be introduced to allow this with a very low level of risk.
Using multiple TXID exchanges based on both the (R,S) and (R,-S) pairs coupled with SIGHASH_NONE/SIGHASH_ANYONECANPAY (and related) options, we can create complex scripts that can be chained.
This will be covered in a later post to this.
Returning money to a Vault
At the end of our shopping, we can of course return our money for later use. We could recombine this if we are less concerned with privacy or we could split and separate it further. This is where opportunities for the development of good wallets exist. Using nLocktime, this can even be automated.
Transactions based on nLocktime are not valid before the time that was set when the transaction was created and signed. We can use this as a feature. Any transaction that is now invalid as it has been spend cannot be seen to be valid by the network.
As such, when we fund our wallet before we go shopping, we can also create the transaction that will return the funds safely into storage. As an example, we could move funds into a mobile wallet in the morning. Say for ease of explaining that we create 10 coins valued at 5 mBit each.
At the same time, we would have also created a set of signed transactions that have an nLocktime value set to say 21:00 (9pm) local time. This would be a set of 10 separate signed transactions that become valid only after 9pm.
During the day, we spend the following amounts:
· 5 mBits — Coffee.
· 27 mBits — Lunch.
· 13 mBits — Flower for wife.
After this we have the following remaining in our mobile wallet.
· 5 mBits change from a Coffee
· 3 mBits change from Lunch
· 1 mBit change if we used the two previous change amounts on the flowers (A), or
· 7 mBits change from the flowers using a 10 mBit coin (B).
And either (respectively), 60 mBits in 6 x 10 mBit coins (A) or 40 mBits in 4 x 10 mBit coins (B).
In either instance, the unspent coins would be automatically returned to out wallet from the vault application at 9 PM. This would send a broadcast for all of the coins (or could even monitor the spent ones to no longer hold signed transactions for). Any attempt of the wallet to try and send a signed Transaction for the spent coin is rejected.
The effect is that we are left (respectively) with either 1 mBit or 15 mBits of change in our mobile wallet (depending on our personally spending preferences.
At no time did we need to ask the merchant to trust us. They can validate that the 0-conf transaction they have is the only one on the network in seconds and we can move to the next store and spend in moments.
The trouble with many people in the Bitcoin world right now is that they look for complicated solutions to simple issues.
In this, we have not needed to concern ourselves with malleability at all. It has had no impact despite the touted need. When we start to look at this, we see that many of the “so-called” issues with Bitcoin are not issues at all, but really come to problems created by “experts” to defend and solidify a position that they hold and not from reality.