If we talk about the already existing banking system, then a transaction inside an Alfa Bank is simply editing the balance sheet, where the number decreases opposite one name and increases opposite another. In the case of interbank transfers, some third-party organizations are connected, for example, SWIFT, but, in fact, everything works in approximately the same way.
When we deal with the blockchain-based financial system, the money transfer process looks completely different. In Bitcoin, there is no general table of the form <address, balance>, exactly as there is no regulator that would edit this table. In this article, I will show what a transaction in Bitcoin is, how it is built, and explain why Bitcoin has its own programming language added about which everyone has heard, but no one has seen it.
As I said above, in Bitcoin there is no single structure in which each address would have its current balance. Instead, the same notorious blockchain is used, that is, all transactions are stored at all. For simplicity, for now you can assume that these are messages of the form
<address 1> sent <amount> BTC to <address 2>
So, if you go around the blockchain, you can count how many coins "belong" to a specific address.
The actual transaction on the Bitcoin network is actually a bit more complicated than the one described above. In fact, this is some cumbersome structure, the main components of which are inputs (inputs) and outputs (outputs).
Inputs are transactions that you refer to. Imagine that three transactions were once sent to your X address:
If you need to spend, for example, 45 BTC, then you can refer to transaction 888888 , or directly to two transactions: 123456 and 6453795 . If you wish, you can even refer to all three transactions, although it is not clear why.
Outputs - literally "outputs". So far, you can assume that these are addresses (although this is not the case) to which funds will be “sent” as a result of the transaction. There can also be several exits, and each of them has its own amount.
In the picture below, a new transaction C is created , which refers to two outputs, A and B. As a result, at the entrance to the transaction, 0.008 BTC is obtained, which are then divided into two outputs — 0.003 BTC is sent to the first address, and 0.004 BTC to the second address.
The ability to specify several outputs at once is a very important feature, because a transaction (or, more precisely, its output) can be used as an input only once and only as a whole. That is, if you have an incoming transaction at 10 BTC, and you need to spend 8 of them in some Starbucks, you simply create a transaction with one input and two exits: 8 BTC to the store and 2 BTC back to your address. If you create a transaction in which the sum of the outputs is less than the sum of the inputs (as in the picture), the difference is sent to the address of the miner who recorded your transaction in the block.
It is this difference between the sum of the inputs and the sum of the outputs that is called the transaction fee , that is, the transaction fee. It is the second most important source of income for miners and it depends on it when the transaction is included in the blockchain. This is due to the fact that every miner has a pool of unverified transactions that claim to be in the block, and, as a rule, the miner simply sorts them in descending order of commission, thereby maximizing their profits. Therefore, the greater the commission, the higher you will be in the queue and the faster your payment will pass.
In the image below you can see a photofit of a miner who received a transaction with a commission of $ 135,000.
As soon as a new transaction is entered into the blockchain, its outputs can be used as inputs. For such, as yet unused, exits, there is a special name - UTXO ( unspent transaction output ). As I have already said, each output can be used as an input only once, therefore, in practice, it is of unspent exits that are of interest, while those already used are stored as a tribute to the security of the system.
BTWs under UTXO often mean the whole array of unspent exits, although well-educated young people should write UTXO pool well, or at least UTXO set .
Returning to the beginning of the article, now you should be clear that to calculate the balance of the address you don’t need to go through the whole blockchain, and you just have to do without going over the UTXO pool , which is obviously faster.
The general view of the transaction is described in the official specification of the protocol , but here I will give a live example, taken from the blog Ken Shirriff .
For some mysterious reason , value and previous output hash should be presented in little endian form, that is, in our case, the hash of the transaction to which we refer is generally 81 b4 c8 32 ... , although it is recorded in the transaction in the form of ... 32 c8 b4 81 . In the same way, the transaction amount is 0.00091234 BTC or 0x016462 in hex, but in the protocol it is written as 62 64 01 00 00 00 00 00 .
BTW transaction hash is considered extremely simple - take the entire transaction as a sequence of bytes (in the example above, you get a string of the form 010000000148 .... 00 ), count the SHA-256 hash from it twice and present the result in little endian form.
previous output index - we refer not to the transaction itself, the hash of which is specified in the previous output hash , but to one of its outputs. In this parameter, we indicate exactly which way we are interested, the numbering starts from zero. By the way, in the text I will often speak about the “reference to the transaction”, but this is only for the sake of expressiveness of the language.
block lock time - this parameter is rarely used in practice. If it is not equal to 0 and less than 500 million, then this is the number of the block from which this transaction can be used as an input. Since on average, blocks appear every 10 minutes, it is easy to estimate the time when the transaction "opens".
If the lock time is more than 500 million, then it means the UNIX timestamp, starting from which the transaction will become available. In our case there is 0, that is, the transaction is available immediately.
sequence - this feature is no longer used, you can read about it here .
Parameters with the word script in the title are much more complicated, they will be described below.
Most likely, you have already heard that there is a mechanism in the Bitcoin network based on crypto-resistant algorithms + a private / public key pair that allows you to create a system in which only the owner of the private key can use the coins associated with the address obtained from this key. Now I will show how this is implemented "under the hood."
To begin with, Bitcoin has its own programming language inside, called Script. Here is what the Bitcoin wiki writes about it:
Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.
The bottom line is that the language is simple as cork, stack-based, and turing-incomplete. Here is an example of a typical program:
1 OP_DUP OP_DUP 5 OP_HASH160
Each instruction is called opcode - there are about 80 of them , so the language is really quite primitive. The picture below shows the program execution process 2 3 OP_ADD 5 OP_EQUAL
:
Let us return to the language a little later, but first let's find out why it is needed here at all.
To do this, we recall the transaction structure and two parameters: scriptSig and scriptPubKey . Unlike other parameters, the purpose of these two is not at all obvious, and IMHO is the most difficult thing in Bitcoin.
I have seen many attempts to explain (as a rule, unsuccessful ones) what the scripts are in Bitcoin and how to perceive them on an intuitive level. Nevertheless, I take the risk and try to give another analogy. To do this, let's look at a will , like this:
$ 1,000,000 go to Alice only after she turns 18
In this case, the text of the will itself is a condition in which you can use money (read, you can use the transaction for $ 1,000,000 as an entrance ), and a photocopy of your passport at the age of 19 is proof that the condition is met and it's time to get the money .
It is in order to set the condition under which it will be possible to spend the output, and to be able to confirm that the condition is met and you need the SCRIPT, private / public keys and other difficulties.
In the case of Bitcoin, a will is a locking script , which is indicated in the transaction inside the pk_script field. It is also often called scriptPubKey due to the fact that most often it is a program containing a public key or address, although, generally speaking, it may not have anything to do with cryptography.
A kind of "proof" that the condition from locking script is fulfilled is called unlocking script , is written in the signature script field and is often called scriptSig , guess why.
The script validation mechanism for validity is very simple - to do this, you need to connect the unlocking script + locking script and run the resulting program as one unit. If, after execution, the stack remains TRUE
, then the transaction is valid and invalid in any other case.
Most likely, you did not understand anything, so let's write some as simple as possible script to finally understand everything. The idea is to block money with a number, for example 370
. Locking script will look like OP_MUL 370 OP_EQUAL
and in order to unlock a transaction, you will need to specify two numbers, giving 370 in the product.
To experiment with Script, we will use the online platform to run and debug Bitcoin scripts. In the unlocking script we write for example 10 37
. Checking :
P2PKH is probably used in 99 transactions out of 100, so it’s worth understanding how it works. Here is its general view:
This script has been known since the very beginning of Bitcoin and, probably, coined by Satoshi himself. It is he who performs the task about which I wrote above: to make it so that only the owner of the private key can use the coins associated with the address obtained from this key .
On fingers it looks like this: Let your friend B own the private key P. He receives from it the public key K , address A, and reports the address to you. Next, you send to the address A 1 BTC and in the locking script field write something like the following:
Only those who own the private key for address A will be able to spend this transaction. As a proof, write in the unlocking script, firstly, the public key K , and secondly, sign your transaction signature with the private key P.
When B decides to use your transaction as an input, he will create his own, for example, at 0.5 BTC, and in the unlocking script field insert the signature of his transaction with the private key P - <sig>
and the public key K - <PubK>
.
OP_DUP
takes the top element of the stack and duplicates it; now there are two public keys on top of the stackOP_HASH160
replaces the top stack item with its RIPEMD160(SHA256(x))
hash RIPEMD160(SHA256(x))
RIPEMD160(SHA256(public_key))
and the address is basically the same thing.OP_EQUALVERIFY
removes the top two stack elements, and if they are not equal, the program execution is interrupted with an errorOP_CHECKSIG
verifies the signature for a matching transaction. If everything is correct, it deletes the signature, deletes the public key and adds TRUE
One of the most interesting properties of Bitcoin, and the blockchain technology in general, is immutability and a hypothetical "eternity" of everything that goes there. It is not surprising that over time there were people who wanted to use it for their own purposes. And the first thing that occurred to them was to try to save some third-party data to the blockchain and get P2P dropbox.
I think you already understand how this is done. Take the line Make America great again
and just write it in the locking script . It will still be a completely valid script, another thing is that it will not be possible for him to come up with such an unlocking script to unlock the funds. But if you send to the exit with such a script, conditionally speaking, 0.0000001 BTC, then in principle it is not a pity. The only limit is the size of your transaction. Consider that it can not be more than 100 KB, although in reality everything is a bit more complicated there; you can read it here .
It is clear that this situation is not for everyone. Bitcoin already has big scalability problems, and the blockchain, which is no small, starts to get littered with all sorts of left-handed data. Moreover, we remember that such transactions cannot be spent, which means they will always remain in the UTXO pool , which is no better .
In order to reach a compromise, OP_RETURN
was added, which allows you to "legally" store up to 40 bytes of data in the blockchain.
OP_RETURN is a script opcode used to mark a transaction output as invalid. Since the data has been made to the Bitcoin payments, it can be added to the bitcoin wiki
Here is the simplest locking script with his participation: OP_RETURN <40kb data>
. Remarkably, the output with such a script acquires the status of provably unspendable , that is, provably non-tradable . Because of this, it does not even fall into the UTXO pool , thereby saving precious space. Other reasons to use OP_RETURN <data>
instead of <data>
you can find here .
Spoiler - they are not, unless of course you are not convinced altruist.
Source: https://habr.com/ru/post/319860/
All Articles