Why CLTV was a bad idea
People seem to have a misplaced idea that the SegWit-coin (BTC) Core developers are even adequate developers who understand Bitcoin and seek to make it work. Such ends cannot be logically constructed in the same sentence. They either understood Bitcoin and are seeking to subvert it, or they have no concept of Bitcoin. Such developers cannot simultaneously be adequate and understand the system; the results and outcome of their changes to BTC from Bitcoin preclude such an eventuality.
CLTV or CheckLockTimeVerify was not some new idea and concept discovered by Core and implemented in 2015. It is in fact an OLD rejected proposal that has been resurrected to allow the introduction of a parasitic protocol that has no relationship to Bitcoin (and, in fact, does not work — see the Lightning Network).
OP_BLOCKNUMBER dates to late 2010. It was discussed in both forums and private communications with multiple people.
CLTV is not needed. It was basically declared a bad idea — time and time again. Yet, as soon as the fools that wanted to play took charge, they decided to experiment and break what they did not understand.
CLTV is unnecessary
Simply put, there is no valid use of CLTV that is safe and cannot be achieved using nLockTime. Lightning is not Bitcoin, it is a parasitic side protocol that destroys the security of the system. So even if it worked (it never will), it would not be an appropriate use case.
The creation of a CLTV-locked transaction requires templates and negotiation between the user and the merchant. It is the same when nLockTime is used.
The required “template construction process” and negotiation aren’t supported directly using CLTV, and even if it were to be implemented, it would be clunky on-chain and limit the development of additional protocols within Bitcoin, as we will soon illustrate below.
What is/was the issue?
Why did CLTV come about as a concept? It started from the misplaced concept in OP_BLOCKNUMBER (OBN hereafter). In dissecting CLTV, we need to start from the beginning and ask why it was a bad idea then and why it was never required.
Bitcoin was designed to allow many transactions. The script is rich, and can be used to exchange a vast number of transactions. The system is in effect unbounded.
In exploring why a user called ByteCoin wanted to add additional OP_CODES to Bitcoin, we need to look at the flawed logic behind the request and, for once, to answer in full and not simply by pushing it away, saying “We can’t safely do OP_BLOCKNUMBER.” Whilst it is true it is also unsatisfying, and so has been a source of the contention over the last decade, I often keep it short when I see something I disagree with and when I am annoyed with people not seeing what I think is clear. But in the coming year, I shall endeavour to rectify the lack of clarity (even as I respond shortly to the trolls).
The explanation that I had proffered was correct. It also did not do enough. The answer proffered is like when one is talking to children — it was abrupt and ended. It could even be seen as condescending and without enough substance for many to grasp the system and build it. So it is a decade late, but it can be addressed now. It is too late for BTC, but then with Bitcoin, there can only be one.
So let us analyse Bytecoin’s response as it should have been addressed close to a decade ago.
- At the moment, if you make a payment to someone but they’ve wiped their wallet then the coins are irretrievably lost.
The saying was true to a limited extent, but it is also a non sequitur. I have filed a number of papers for a variety of threshold techniques that will allow users to protect their keys, but they do not follow as a reason for CLTV or any other on-chain time lock.
When it is explained in detail, it is really simple.
The general high-level concept for time locking a transaction using nLockTime is that you can have a transaction that allows for recovery later, where the values are stored on-chain. So using nLockTime, Alice and Bob could create a transaction that is valid only after a set time or block height.
Let us say that Alice and Bob want to do a transaction. In the scenario, Bob is completing some work for Alice, and Alice has agreed to pay Bob for his work. In order to commit the funds to the contract, Alice puts her payment into a 2-of–2 transaction. Most importantly, Alice wants to be assured that if Bob doesn’t do the work, she can get her money back. It means she can redeem the deposit she has made, but only after a contracted time has elapsed. To do so, Alice has Bob sign a return transaction from the 2-of–2 escrow address that has not yet been funded by Alice.
We can thus create a 2-of-2 transaction to fund it and ensure the return of the funds if Bob does not complete his task adequately. Alice can have Bob sign a return transaction. And it can be constructed in a manner that allows Bob to be paid if the task has been completed.
So we can say that if Alice wants to do the typical CLTV idea of a locked transaction, she can always do so using nLockTime, but without all the CLTV hassle. In doing so, Alice wants to send a payment to Bob, but also have a condition such that she can recover her funds if the contract does not go through. She can use a hash puzzle or even have an escrow condition allowing Bob and Alice to set a mediator in advance. When Bob has completed a task, Alice and Bob do an exchange that allows Alice to access her goods and Bob to get paid.
At the same time, what if Bob does not complete his end of the bargain? Well, with a time lock, Alice will be able to recover her input deposit later on. In CLTV, the idea is that a transaction is created where the return value is inside the script. You need to have all of the logic set in advance, and it is public and visible.
The logic in such a system should be in the wallet.
The wallet should save the transaction that has been partly signed by Bob and is now available for Alice to send if the payment is to be reversed for any reason.
What if Alice loses the signed refund transaction?
Such is the typical response for why CTLV and variants needed to be introduced on-chain. As I said, it is a logical fallacy.
- The nTimeLock (and possibly also nSequence-locked) transaction is a file.
- The private key Alice uses is a file.
If Alice can lose the transaction, then she can also lose the private key. Both are files. In the example, CLTV is sold as a requirement as it allows Alice to recover later and she does not need to keep the signed transaction from Bob. Yet, what is glossed over is that Alice must maintain the key that is used to access the CLTV-locked funds, and the key is a file.
So, Alice somehow has to find the means to protect a transaction that is linked to a file she needs to protect…
Alice can easily protect the time-locked transaction from Bob. In the correct use of keys in Bitcoin, Alice and Bob use the public key once. Their identity is firewalled from the world. If Alice posts the transaction that Bob signed on a public forum, it could be done in a manner that does not disclose her identity. It is in fact far simpler to save a file that will in time be public than to have to require script alterations and to lock users into a limited subset of what they can do. For example, the parties can allow script alterations and even negotiate alternative points within the contract. The process can include the amount or terms. In the real world, many issues that cannot be sorted simply arise after the fact. If we want to stop the drift into courts as a means to resolve disputes, we must allow the parties to an agreement to continue to have the opportunity to negotiate. Note here, I have stated the opportunity to negotiate as the parties do not need to do so.
It is a very narrow path to walk when setting how you believe others should trade, and it is one that leads to failure.
Alice also has more freedom than in the CLTV case
Bob and Alice can continue to negotiate where Alice knows she can recover her funds in full at any time. Bob does not have a means to spend the transaction without input from Alice, so after the expiring of the nLockTime value, Alice has all the power. She can co-sign and then spend the transaction recovering her funds or go back to Bob to negotiate.
Alice has to maintain files. Losing access to the key used to redeem the transaction renders it lost, which is not a point of whether the transaction is done on-chain in CLTV or otherwise. Alice needs to have access to a secure file. So, the above is not a valid CLTV argument. It is, as said, a non sequitur.
Much of what seems to be argued comes from a false understanding of what Bitcoin is and how is works. Worse, much of it is tainted on a misaligned comprehension of what some think Bitcoin should be. Bitcoin is not an implementation of Tim May’s anarchist system. It is far from anonymous, and it cannot be made to be anonymous. Bitcoin is private and designed to work inside the existing common-law legal frameworks defining money and trade.
- Similarly, if the network is flooded with 0.01 fee transactions and you make an urgent payment but forget to include a higher fee then you can’t reissue that payment backed by the same coins but with a fee.
Again, we have a logically flawed argument — if the network is flooded, you cannot send an alternative in any case. So it is also a non sequitur. More, it is not even describing how Bitcoin should work, but rather the cap-limited concept that SegWit coin promotes; it is not how Bitcoin is designed.
Here, the CLTV solution has no relationship to the issue posited in the original post.
More importantly, CLTV or the earlier named ideas do not help you here. If you have a transaction and the fees are too low, then setting a block-height time to expire it makes it something no merchant in their right mind would touch. Using nLockTime, a merchant can have a chained transaction, or you wait. The replace-by-fee concept is flawed, and if nSequence was used (in an agreed contractual exchange with a merchant), all the parties could achieve the intended result in the original version of Bitcoin already.
If we lose sleep over the comments in the original post, we may just finally intuit that the mysterious CLTV method with the proposed solution was maybe to send a CLTV transaction that double-spends the original with a much higher fee. But then again, why would one need CLTV — just replace with a higher fee. So the link to CLTV remains unclear. It is another solution seeking a problem.
- If you could cause the current block number to be pushed on the stack and do some maths with it then you could implement a payment that must be spent by the recipient before a certain block number is reached or else the script would allow it to be spent again by the sender for example.
In the original 2010 post, the concern was that people could construct a transaction that sends from a valid input to an invalid transaction output. But, how does CLTV help here? If you do not construct a transaction in a manner that can be recovered, CLTV will not help you.
It is also of no concern. If you are negotiating, then send the signed value allowing the nLockTime transaction to be used as a redeem transaction.
The idea, again, of losing the file is also not a concern in the sense that, if you lose the redeem transaction, it would be the same as losing the key. The false idea that you lose one file but not another, or as a single store, the key is safe, but you lose the transaction is just foolish. Sorry, there is no other way to put it. The redeem transaction could be saved in the same database or file as the keys. Losing the transaction is also losing the key.
So, even having CLTV does not mitigate loss. To say otherwise is disingenuous.
At least Mike Hearn got it.
Bitcoin is not PGP
Bitcoin is not a web of trust, and you do not protect your keys in the same manner in Bitcoin as you would in PGP. In fact, the idea is that you keep the public key private and only create an address and key pair for a single interaction. Identity is not used in Bitcoin. Identity is a separate process outside the Bitcoin protocol.
There are ways to allow the private use of identity, but it will wait for now as the applications for patents need to mature a little more.
Using nLockTime
The process was documented many times, but I will refer to the one here. Simply put, all of the problems that the proponents of CLTV were asking for can be done with nLockTime, and they can be done in a manner that is simpler and far more elegant. It also allows the developer to explore and create without being constrained to the limits of the protocol.
The last line is important. Not all negotiations need to be on-chain — merely the completed and settled transactions must be.
Bitcoin is not peer to peer as in users run nodes; nodes are always miners. Nodes are not a part of the peer process in Bitcoin, users are. nLockTime is and always was superior to CLTV, even taking the security issues of CLTV away, as nLockTime allowed for more interaction between parties. That is, the peers are allowed to act as peers — to negotiate at all points and not to be forced.
Wallets need to have smarter logic.
A wallet that saves the transaction that is yet to be broadcast and to secure, it would offer far more value than CLTV ever could. Bitcoin is designed to be simple at the centre; the logic can then, as with the Internet, be created on the periphery. Building unnecessary complexity diminishes the system.
CLTV and the former variants are all a combination of anarchist folly and foolishness, added back to allow an attack against Bitcoin, aka Lightning. It is all they allow. The ability of Bitcoin to operate was diminished. Effort was expended creating a system so a few individuals who would never be hired in the real world could say they “fixed” Bitcoin.
Miners are not peers
It is a major fallacy that needs to end.
Miners are not the ones in Bitcoin that determine what occurs in a transaction, the users do. Miners validate and settle the system, and maintain the security ensuring that transactions are ordered correctly and that double spending does not occur. The miners ensure that the base protocol does not change, that it is set and immutable.
Miners are not the ones that decide what is and is not to be contracted. As long as the protocol rules are followed and the required fee is paid, miners incorporate the transactions. The miners do not have any idea who the individuals are, and do not have a means to link public keys and identity. It is something that Core allowed, when it started the false myth of keeping keys.
Users need to have access to the keys that are associated with unspent coins. They do not need to have access to all keys they have ever used, and nor should they have to.
My article is already longer than had been planned, so the issue will be relegated to a later topic. For instance, the concept of an exchange sending your withdrawal coins to an old address leaves you in the possible scenario where you can’t prove to the probity of the transaction or that you don’t have the keys anymore. The whole ‘paying to an address on file’ model needs to be revisited and changed.
Users can and do maintain files. They need to do so whether they have CLTV or simply a private key. So, the fallacious argument that holding a signed transaction that is locked for later broadcast using nLockTime in any way reduces the functionality in Bitcoin is flawed; CLTV reduces the level of control in an erroneous nanny-state form of contempt for the user that is utterly misplaced. As the user has to maintain a file (the private key) securely, saying that the user could lose the transaction or not be able to send it is simply misleading.
- If the user cannot access the key, they cannot access the funds in a CLTV-locked transaction.
- If the user cannot send a signed transaction to the blockchain, then they cannot redeem the funds in a CLTV-based transaction.
- So, if you can send a file, a transaction to the blockchain to redeem CLTV, you can also redeem using nLockTime.
With CLTV, once the transaction is incorporated into the blockchain, the contract is set. Both Alice’s and Bob’s hands are tied. They can add a separate transaction, after the fact, if they want to renegotiate, but doing so also introduces aspects of trust.
If Alice has a signed transaction from Bob, Bob cannot stop her sending it by force, nor does he need to do anything. Bob can negotiate with Alice, and try and convince her to not send the transaction while they are negotiating. Whilst the negotiation is occurring, Alice can end it at any time sending the signed transaction from Bob.
Bob now knows that Alice can do so and that he cannot stop her short of offering something of value to her.
nLockTime, other than being more secure, is also more fair and just, and follows the standard contract negotiation process that is used in the common-law world.
Privacy… CLTV loses it
In CLTV, the conditions are published in the script in advance. With nLockTime, the parties to a transaction have various redeem script options that are not published in advance. Alice can have several possible transactions signed by Bob. Merely the ones that are then used ever become public.
As a consequence, an exchange that is done as a peer process between Alice and Bob is far more private than CLTV can ever hope to be. With CLTV, all of the conditions are there to be seen to the world. Forever.
CLTV is less powerful than nLockTime
nLockTime is both more secure, more private, and more powerful than CLTV.
In our example, we have a limited set of conditions that can be used in a CLTV-based transaction, and all are always set in advance. But, nLockTime allows Alice and Bob to change their minds and engage in a renegotiation right up until a transaction is settled on the blockchain.
For instance, in the example of the 2-of-2 contract above, say we have Alice in possession of a redeem script that Bob has signed and where the nLockTime value is set for 10 days from now. Alice can return to Bob and negotiate in any time up to the final process with knowledge that she can recover at day 10.
Alice can also go to Bob after day 10 and negotiate, knowing she has a fall back to recover funds.
But, in our current scenario, Alice can go to Bob at day 7, 8, and then 9 and attempt to make a new deal. The signed redeem script that was set to ripen at day 10 need now never to be known. If Bob and Alice conclude a negotiation on day 9, it is what is published. Nothing of what Bob and Alice would have done need ever be public.
In such a scenario, both Alice and Bob have the ability to negotiate with each other, and the right is maintained up until the transaction is finalised and encoded into a block.
It is a good thing. I do understand that those wanting socialism and anarchy do not like the concept of free contracting, but it is at the heart of trade.
MORE POWER!
Imagine that there are more options in the script. Alice, Bob, and Charlie are all negotiating. Each can set a variety of nLockTime-satisfied conditions that cannot be sent prior to a predefined time.
Alice can have a script signed by Bob at 10 minutes and one by Charlie at 15 minutes with a later one signed by both Bob and Charlie at 17.5 minutes.
Bob could have a script signed by Alice that is valid with conditions from 11 minutes on and another signed by Alice and Charlie at 20 minutes.
In allowing the wallet to control a level of the processing and to hand the control of the system back to the users, it becomes more powerful and flexible than CLTV could ever hope to achieve.
Conclusion
There were many areas of the original Bitcoin code and system that needed improvement. The code quality was a long way from being desirable, and the system was not complete, with many stubs needing to be finalised. But Bitcoin as a protocol was complete, and the changes to it by the Core developers have not helped at all.
It is time to return Bitcoin to what it was, and with the SV client, we shall be doing just so.
In addition to a new idea that can be used to create a new business, I shall be detailing the errors in ideas surrounding Bitcoin each week. I should have done so a long time ago. For not doing it earlier, I am sorry.
