Suppose you want to bet on the outcome of the future bitcoin Bitcoin, how would you do it? This question arose last spring, when Roger Ver, an investor and supporter of Bitcoin Unlimited, accepted the call from the user under the name Loaded. The bet was which of the blockboys after the hard-core network would dominate.
The dispute arose when the Bitcoin Unlimited project (now Emergent Consensus, EC), whose vocal supporter is Ver, proposed removing the limit on the maximum block size. This was long before the SegWit2x proposal appeared.
The essence of the dispute was as follows. The user, under the name of Loaded in the message left on the Bitcointalk forum, suggested that Roger Vera be exchanged at a rate of one to one BTC for BTU (the alleged name of Bitcoin's second blockbuster) in the case of hard-core. The user indicated in the message the address of the purse containing 40 000 BTC and proof of possession.
"Roger Ver, I'm offering you a deal - an exchange of 1 to 1. I'm ready to change from 60,000 to 130,000 of my BTUs to your BTC," the report said. Ver replied that he agreed to discuss the details of the exchange.
Intrigued by the bet and the amount Ver was willing to bet (about $ 120 million in bitcoins at the time), researchers Patrick McCorry of University College London and Ethan Heilman of the University of Boston, along with Andrew Miller, assistant professor Illinois University, began to look for a way to realize this bet.
As a result, they issued a document outlining the technical details necessary for the implementation of the bet.
Technical difficulties
To better understand the problem that McCorry, Heilman and Miller tried to solve, it is worthwhile to carefully consider the terms of the deal that Loaded and Ver want to conclude.
First, each of the parties will need to postpone 60,000 BTC to the hard-core. After the branching of the network and the appearance of two blockhouses, each of the parties will have coins in both lockers - 60,000 BTC and 60,000 BTU. Then Loaded exchanges its 60,000 BTCs in one network for Roger's 60,000 BTUs in the other. After the exchange will be done at Loaded there will be 120 000 BTC, and at Vera - 120 000 BTU.
The main question is who will be richer on the whole.
However, such a scheme is not easy to implement. Despite the fact that fast inter-network transactions seem to be the most obvious solution to the problem, this method can only work after a hard-core, when two networks appear. Until then, there will be only one network. Thus, the trick is to find a way for each side to make an exchange before fork, and then after it. And since SegWit is not yet activated, the solution must also take into account the transaction malleability, a problem that only complicates things.
However, Heilman and McCorry noted that they had a great time, searching for solutions and considering the plasticity problem.
"It's much more complicated, but it only makes it more fun," Heilman said.
How it works
The solution offered by the researchers is a modified version of the fast data exchange protocol, which is based on two transaction burdens: CheckTimeLockVerify (CTLV) and hatchets. CTLV establishes transactions at a point in time in the future, and the users require a "secret" (a hash of the hash) to unlock the output of the transaction.
It is also worth noting that the protocol will work not only in the case of BU hardback, but also of any other fork that has the so-called "repetition protection" - something that makes it possible to be sure that the transactions appearing in the block after the branching are not Duplicate each other.
As a result, the transaction will look something like this.
Transaction Fund
To complete the transaction, Ver and Loaded pay 60,000 BTC per transaction fund. This transaction has three exits. One is associated with Vera coins, the other is with Loaded coins and the third acts as an error insurance, allowing Loaded to cancel the transaction if Ver refuses to sign any off-net transactions necessary to complete the transaction. To save money in security until the fork, each exit has a lock with a lock at a certain time.
Now that the money for the transaction is safe, both parties can proceed to add their digital signatures to two more transactions. This will determine how the money in the fund of the transaction will be spent after the fork.
First, Ver calculates the "secret" (prototype) and hashes it. Then three transactions must be created and signed by both parties prior to the fork. Thus, when the block is split, Ver and Loaded will only need to make transactions to receive their deposits.
Barter transaction
The "barter transaction" (swap transaction), in fact - a couple of transactions. When activated, one transaction picks up 120,000 BTUs from the BU network and sends them to the Faith, while the other transaction sends 120,000 BTC from the BTC network to the Loaded user. To ensure that each transaction only works on the network in which it should, the protocol uses repetition protection, which is already included in its update. Thus, each of the participants will not be able to receive coins in both networks.
When the time comes, Ver will be responsible for activating the transaction. To demand his funds from the BU fork, he will have to reveal the secret created at the very beginning. With this secret, Loaded will be able to automatically and quickly get all of its funds from the BTC fork. But there is a catch. Ver can first decide to wait and see what will happen to the market. If the BU network does not look good, he may change his mind and do not want to make a deal. Another transaction acts as a protection against such behavior.
Penalty Transaction
To encourage Vera to make a timely transaction, there is a third "penalty transaction", which is also created in advance. By signing the penalty transaction, Ver agrees to give away all Coins Loaded, in case he decides not to make a deal. If Ver does not sign the transaction in advance, then Loaded uses an error protection in the transaction fund to cancel the entire transaction.
It should be noted once again that all the transactions mentioned must be created and signed before the fork.
Place your bets
In the case of the implementation of the EC EC, Wer, which has long been promoting the idea of larger blocks, believes that the EC network will benefit. But is he ready to fulfill the terms of the deal that Loaded suggested to him? If he agrees, then as they say McCorry and Heilman they will be just happy to help carry out the deal. They also believe that other developers will also join their efforts. Now it remains only to wait for the final decision of Vera.
Heilman notes: "I do not live by the hope for bitcoin Bitcoin, however, if it does happen, we will be able to observe the outcome of an interesting bet."
On the other hand, there is a high probability that there will be no conditions for betting. This will happen in the event that the SegWit2X agreement is triggered and the hardware will be performed after SegWit is activated and supported by the vast majority of the community members. In this case, the change in the block size will occur not according to the BU (EC) consensus rules, but according to SegWit2X rules, which formally and actually allows the participants to abandon it. In addition, the second block with no significant portion of nodes and / or hashtrait simply does not appear, and Bitcoin's network will remain unified. For such an option, uncontested, all reasonable users will vote. A network with tens of billions of capitalization is not the best field for games.