I publish the translation of the article “ Have you Cryptocurrency?” »Ray Patterson (Ray Patterson) from the site Bytecoin.org .There is no "best" cryptocurrency
Bitcoin is beautiful, Bytecoin is beautiful, Doge is beautiful.
All cryptocurrencies are beautiful (well, or let's imagine for a moment that this is so).
You can pay Bitcoin for Subway sandwiches, use Bytecoin for private shopping, send Dogecoin to your friends as gifts, and so on. That is, you can use the features of each of the cryptocurrencies for the appropriate case. But - that's a shame - you would not like to hang around with a dozen wallets for each of these coins.
')
Naturally, you can simply collect another cryptocurrency, which will combine all the best features. Something like a standard for cryptocurrency. Wait ... This reminds me of something.
Of course, such an approach is possible ... theoretically. But in practice this becomes impracticable.
First, the idea of the “best” is extremely subjective. It does not seem to everyone that the “demurrage” function (payment for a simple coin in a wallet) in a Freicoin is a rather useful function. The selection of a standard from all sorts of variations of Proof of Work was also a tremendous test.
Secondly, some things simply cannot be combined in principle: imagine yourself at the place of service, which should take into account the million functions of only ONE cryptocurrency. Would you accept it? In the end, it is simply extremely difficult from a technical point of view - to contain all the introduced innovations and updates of various projects.
Multiplying Alt-Coins
Here's a different point of view. Imagine yourself a happy cryptocurrency developer. You have invented a new function and now you want to test it in real conditions. You cannot whip up everything and throw it on the market (your project is extremely important for you), but you cannot test a new feature without real users. What to do?
You want your cryptocurrency to receive this function (and people would use it) and at the same time doubt it, because in case of a critical error, people will lose their money.
Alternative 1 is the creation of Altkoyn with its own blockchain (something like a testnet for the main project).
Counter-argument: this alternative project will be forcibly terminated if successful, so as not to become a competitor to the main currency (which, as we remember, the new function should eventually enter). In any case, users will have to put these altcoins somewhere.
Alternative 2 was described by a person you (hopefully) known, by Adam Beck, two years ago: the so-called 2-way pegging (the author claims in his work that the concept belongs to Gregory Maxwell). The idea is that you can start a parallel blockchain with an experimental feature, in which there will be no coins (for now). The user can “block” coins in the main blockchain (sending them to a special address script), and the same number of coins will appear in a parallel chain. Naturally, we are talking about the same coins available to the user. The elegance of this concept is that the second blockchain should not contain the main one: to release N-altcoins, the user only has to provide concise evidence of the fact that the N-altcoins were blocked in the main chain. After that, he can use them inside the second blockchain with all available functions.
How to get the coin back? In the same way! Hence the "2-way pegging". The user must block the coins in the test chain, and they will be unlocked in the main one. The ratio for such transitions is always 1: 1, so the total number of coins in two chains will be constant. Thus, the exchange rate and other purchasing criteria will not change. Technically, these are the same coins, only now they have branches in the second blockchain. If something happens to them, due to their experimental kind, the coins will simply fall back into the main chain. And if you decide to inject the tested function into the main circuit, there will simply be no need for an alternative circuit (until it again rises to you to test another revolutionary function).
Let's talk about Bitcoin (again)
What should these “blocking” address scripts look like? If you want to know the details, then there is nothing easier - let's look at them on the example of Bitcoin. As you know, transactions include
inputs (inputs) and
outputs (outputs), which, formally, are a set of script commands. What do they describe?
Output: Address of the recipient of the coins and what he or she must do to spend them.
Login: Information about exiting a previously performed transaction.
That is, a transaction can be obtained when some input refers to some output of an earlier transaction. The money received is distributed among the various exits in the current transaction.
The most common way out (simplified) is the “PUBLIC KEY 'A' + SIGNATURE OF THE CONFIRMATION TEAM” and the entry “SUBSCRIBE WITH THIS KEY”. If the signature is successfully confirmed with a key, this part of the transaction is recognized as valid and everything is in order.
In this case, the scripts for our case with 2-way pegging will include the following characters:
- Transaction TX1, which blocks money in the main chain to transfer it to an alternative.
- TX2, which implements these coins in an alternative chain and translates them further inside the chain.
- TX3, which blocks money in an alternative chain and returns it back to the main
- TX4, which unlocks money in the main blockchain.
So, the following actions:
- TX1 output. OUT: “PUBLIC KEY 'A' + BLOCKING COMMAND FOR CHAIN 2 + PUBLIC KEY 'B' + SIGNATURE CONFIRMATION TEAM”. Now money is locked, and can not be spent without data blocking.
- Input TX2. IN implements TX1: “SPV-PROOF OUT1 + SIGNED BY KEY 'A'”. Inside an alternative chain, this script is not conducted as a regular input, which spends coins of the same chain, namely, a transfer from the main chain.
What is SPV-PROOF OUT1?This is a TX1 transaction (containing OUT1) and hashes of other transactions from the same block that contains TX1. That is, we can restore the hash tree for all transactions and check if they really come from chain 1 (yes, we need to know the hashes of the blocks from chain 1, but this is not so much). This kind of scheme is suitable for “light” wallets, including when we have to check if a transaction exists without checking the entire blockchain. This is called the Simplified Payment Verification, and this method can even be found in Satoshi Nakamoto's article.

- Now we have a valid entry for the N-coins that we received from chain 1 to TX2. They can be used in chain 2 until it is time to bring them back. Thus, the movement of coins to the TX3 transaction does not interest us: they can change the owner or not.
- TX3 output. OUT in an alternative circuit: "LOCK COMMAND IN CHAIN 2". What does the lock command look like? For example, money can simply be sent to a public key of the form "000000", or a hash of something. No one should know the correct private key. From now on, TX3. The OUT in the secondary circuit becomes almost unrecoverable. Technically, we did something that is analogous to the Proof of Burn.
- Input TX4.IN in the main circuit: “LINK TO TX1.OUT + SPV-BLOCK-PROOF + SIGNATURE WITH KEY 'B'”
We turn to TX1.OUT, since the main circuit has no idea about the existence of an alternative. It should look as if the money never disappeared: it was sent to the output of TX1.OUT, and now it has been spent at the entrance of TX4.IN. The circuit compares the confirmation commands from the TX1.OUT script with the contents in the TX4.IN, and they converge! We just have to train the script for a couple of new commands, and that's all.
Beauty sidechains
Now we are ready to deal with all altcoins. You should have already guessed what we should do: implement 2-way pegging in each alt-coin and update the script in the main chain. Then we will be able to translate bitcoins into altcoins and vice versa.
To do this, we need to name this idea Sidechains, assemble a team of Bitcoin developers and other volunteers, create a Blockstream company and receive $ 21 million of funds from investors. It sounds easy.
The company focuses on the implementation of the described mechanism and the creation of a number of sidechains for testing experimental ideas. You can read these ideas on
this site .
- Confidential Transactions: transactions that hide the amount of payments. For each transaction, you can only make sure that the sum of the exits does not exceed the sum of the entries (that is, that the money is not taken from the air)
- Segregated Witness: transaction restructuring so that you can “throw out” unnecessary data from old data: such as signatures. After all, if a transaction has long been in the blockchain, it is definitely valid. Why do we need her signature then, right?
- Relative Lock Time: new ways to date transactions. It will allow, for example, to send money that "can be spent through N blocks after inclusion in the block."
- Schnorr Signature Validation: a different signature algorithm, more efficient than the current Bitcoin ECDSA. By the way, it is precisely the signatures of Schnorr that underlie CryptoNote.
- New opcodes: testing in the wild of new commands of the scripting language is a dangerous thing, it must be done with extreme caution. Now it can be done "in the sandbox."
The main thing to understand about Sidechains is that in practice, coins from the main chain are used, not newly released ones.
That is, if DigitalNote (XDN) is tied to Bitcoin, then you will receive a new type of input that recognizes a “foreign coin” in the system. You can turn Bitcoins into XDN and use XDN functionality (send anonymous messages, receive interest, etc.) using bitcoins. Exchange rate and XDN quality will not be affected. Later, you block (destroy) bitcoins inside the XDN, and this gives you the right to unlock them inside the BTC blockchain.
Blockstream Achievements
In the spring of 2014, a year after the description of the 2-way pegging Blockstream released an article. A year later, recently, the guys announced their first Sidechain, called "Liquid". Its purpose is to make sure that fast transactions are possible between large financial hubs (exchanges and online wallets).
Instead of withdrawing funds from Kraken and transferring them to a BTCC account, the user simply clicks a button in his profile. His bitcoins are sent to the Kraken address in Liquid-blockchain, which instantly transfers them to the BTCC address, and the BTCC already sends them back to the Bitcoin blockchain, to their own Bitcoin wallet. Technically, it is a living analogue of bank clearing.
Why is this sequence of actions faster than just a direct transaction from the Kraken Bitcoin address to the BTCC Bitcoin address?
In this case, you would have to wait for six standard confirmations, which would take about an hour. But Liquid-chain is not exactly a public blockchain. Transactions in it occur faster, because it operates between the participants who trust each other. That is, if Kraken possesses a certain amount of funds in Liquid in advance, Liquid simply sends the user's coins through its own blockchain, instead of the Bitcoin network. The only requirement is the presence of a certain amount of funds in both blockchains (Bitcoin and Liquid) in order to satisfy both applications for inter-exchange Liquid transfers and applications for ordinary withdrawals.
Obviously, something simpler could have been invented for such purposes, but in our case Liquid is a more important entity.
Really existing functioning sidechain.
The first, but hopefully not the last.