Как выглядит код криптовалюты

A from-scratch tour of Bitcoin in Python

I find blockchain fascinating because it extends open source software development to open source + state. This seems to be a genuine/exciting innovation in computing paradigms; We don’t just get to share code, we get to share a running computer, and anyone anywhere can use it in an open and permissionless manner. The seeds of this revolution arguably began with Bitcoin, so I became curious to drill into it in some detail to get an intuitive understanding of how it works. And in the spirit of “what I cannot create I do not understand”, what better way to do this than implement it from scratch?

We are going to create, digitally sign, and broadcast a Bitcoin transaction in pure Python, from scratch, and with zero dependencies. In the process we’re going to learn quite a bit about how Bitcoin represents value. Let’s get it.

(btw if the visual format of this post annoys you, see the jupyter notebook version, which has identical content).

Step 1: generating a crypto identity

First we want to generate a brand new cryptographic identity, which is just a private, public keypair. Bitcoin uses Elliptic Curve Cryptography instead of something more common like RSA to secure the transactions. I am not going to do a full introduction to ECC here because others have done a significantly better job, e.g. I found Andrea Corbellini’s blog post series to be an exceptional resource. Here we are just going to write the code but to understand why it works mathematically you’d need to go through the series.

Okay so Bitcoin uses the secp256k1 curve. As a newbie to the area I found this part fascinating — there are entire libraries of different curves you can choose from which offer different pros/cons and properties. NIST publishes recommendations on which ones to use, but people prefer to use other curves (like secp256k1) that are less likely to have backdoors built into them. Anyway, an elliptic curve is a fairly low dimensional mathematical object and takes only 3 integers to define:

In addition to the actual curve we define a Generator point, which is just some fixed “starting point” on the curve’s cycle, which is used to kick off the “random walk” around the curve. The generator is a publicly known and agreed upon constant:

Finally, the order of the generating point G is known, and is effectively the “size of the set” we are working with in terms of the (x,y) integer tuples on the cycle around the curve. I like to organize this information into one more data structure I’ll call Generator:

Notice that we haven’t really done anything so far, it’s all just definition of some data structures, and filling them with the publicly known constants related to the elliptic curves used in Bitcoin. This is about to change, as we are ready to generate our private key. The private key (or “secret key” as I’ll call it going forward) is simply a random integer that satisfies 1 <= key < n (recall n is the order of G):

This is our secret key — it is a a pretty unassuming integer but anyone who knows it can control all of the funds you own on the Bitcoin blockchain, associated with it. In the simplest, most common vanilla use case of Bitcoin it is the single “password” that controls your account. Of course, in the exceedingly unlikely case that some other Andrej manually generated their secret key as I did above, the wallet associated with this secret key most likely has a balance of zero bitcoin :). If it didn’t we’d be very lucky indeed.

We are now going to generate the public key, which is where things start to get interesting. The public key is the point on the curve that results from adding the generator point to itself secret_key times. i.e. we have: public_key = G + G + G + (secret key times) + G = secret_key * G. Notice that both the ‘+’ (add) and the ‘*’ (times) symbol here is very special and slightly confusing. The secret key is an integer, but the generator point G is an (x,y) tuple that is a Point on the Curve, resulting in an (x,y) tuple public key, again a Point on the Curve. This is where we have to actually define the Addition operator on an elliptic curve. It has a very specific definition and a geometric interpretation (see Andrea’s post above), but the actual implementation is relatively simple:

I admit that it may look a bit scary and understanding and re-deriving the above took me a good half of a day. Most of the complexity comes from all of the math being done with modular arithmetic. So even simple operations like division ‘/’ suddenly require algorithms such as the modular multiplicative inverse inv . But the important thing to note is that everything is just a bunch of adds/multiplies over the tuples (x,y) with some modulo p sprinkled everywhere in between. Let’s take it for a spin by generating some trivial (private, public) keypairs:

Okay so we have some keypairs above, but we want the public key associated with our randomly generator secret key above. Using just the code above we’d have to add G to itself a very large number of times, because the secret key is a large integer. So the result would be correct but it would run very slow. Instead, let’s implement the “double and add” algorithm to dramatically speed up the repeated addition. Again, see the post above for why it works, but here it is:

With the private/public key pair we’ve now generated our crypto identity. Now it is time to derive the associated Bitcoin wallet address. The wallet address is not just the public key itself, but it can be deterministically derived from it and has a few extra goodies (such as an embedded checksum). Before we can generate the address though we need to define some hash functions. Bitcoin uses the ubiquitous SHA-256 and also RIPEMD-160. We could just plug and play use the implementations in Python’s hashlib , but this is supposed to be a zero-dependency implementation, so import hashlib is cheating. So first here is the SHA256 implementation I wrote in pure Python following the (relatively readable) NIST FIPS PUB 180-4 doc:

Okay the reason I wanted to implement this from scratch and paste it here is that I want you to note that again there is nothing too scary going on inside. SHA256 takes some bytes message that is to be hashed, it first pads the message, then breaks it up into chunks, and passes these chunks into what can best be described as a fancy “bit mixer”, defined in section 3, that contains a number of bit shifts and binary operations orchestrated in a way that is frankly beyond me, but that results in the beautiful properties that SHA256 offers. In particular, it creates a fixed-sized, random-looking short digest of any variably-sized original message s.t. the scrambling is not invertible and also it is basically computationally impossible to construct a different message that hashes to any given digest.

Bitcoin uses SHA256 everywhere to create hashes, and of course it is the core element in Bitcoin’s Proof of Work, where the goal is to modify the block of transactions until the whole thing hashes to a sufficiently low number (when the bytes of the digest are interpreted as a number). Which, due to the nice properties of SHA256, can only be done via brute force search. So all of the ASICs designed for efficient mining are just incredibly optimized close-to-the-metal implementations of exactly the above code.

Anyway before we can generate our address we also need the RIPEMD160 hash function, which I found on the internet and shortened and cleaned up:

As with SHA256 above, again we see a “bit scrambler” of a lot of binary ops. Pretty cool.

Okay we are finally ready to get our Bitcoin address. We are going to make this nice by creating a subclass of Point called PublicKey which is, again, just a Point on the Curve but now has some additional semantics and interpretation of a Bitcoin public key, together with some methods of encoding/decoding the key into bytes for communication in the Bitcoin protocol.

We are not yet ready to take this class for a spin because you’ll note there is one more necessary dependency here, which is the b58 encoding function b58encode . This is just a Bitcoin-specific encoding of bytes that uses base 58, of characters of the alphabet that are very unambiguous. For example it does not use ‘O’ and ‘0’, because they are very easy to mess up on paper. So we have to take our Bitcoin address (which is 25 bytes in its raw form) and convert it to base 58 and print out the characters. The raw 25 bytes of our address though contain 1 byte for a Version (the Bitcoin “main net” is b’\x00′ , while the Bitcoin “test net” uses b’\x6f’ ), then the 20 bytes from the hash digest, and finally 4 bytes for a checksum so we can throw an error with 1 — 1/2**32 = 99.99999998% probability in case a user messes up typing in their Bitcoin address into some textbox. So here is the b58 encoding:

Let’s now print our Bitcoin address:

Cool, we can now check some block explorer website to verify that this address has never transacted before: https://www.blockchain.com/btc-testnet/address/mnNcaVkC35ezZSgvn8fhXEa9QTHSUtPfzQ. By the end of this tutorial it won’t be, but at the time of writing indeed I saw that this address is “clean”, so noone has generated and used the secret key on the testnet so far like we did up above. Which makes sense because there would have to be some other “Andrej” with a bad sense of humor also tinkering with Bitcoin. But we can also check some super non-secret secret keys, which we expect would have been used be people in the past. For example we can check the address belonging to the lowest valid secret key of 1, where the public key is exactly the generator point :). Here’s how we get it:

Indeed, as we see on the blockchain explorer that this address has transacted 1,812 times at the time of writing and has a balance of $0.00 BTC. This makes sense because if it did have any balance (in the naive case, modulo some subtleties with the scripting language we’ll go into) then anyone would just be able to spend it because they know secret key (1) and can use it to digitally sign transactions that spend it. We’ll see how that works shortly.

Part 1: Summary so far

We are able to generate a crypto identity that consists of a secret key (a random integer) that only we know, and a derived public key by jumping around the Elliptic curve using scalar multiplication of the Generating point on the Bitcoin elliptic curve. We then also derived the associated Bitcoin address which we can share with others to ask for moneys, and doing so involved the introduction of two hash functions (SHA256 and RIPEMD160). Here are the three important quantities summarized and printed out again:

Part 2: Obtaining seed funds + intro to Bitcoin under the hood

It is now time to create a transaction. We are going to be sending some BTC from the address we generated above (mnNcaVkC35ezZSgvn8fhXEa9QTHSUtPfzQ) to some second wallet we control. Let’s create this second “target” wallet now:

Ok great so our goal is to send some BTC from mnNcaVkC35ezZSgvn8fhXEa9QTHSUtPfzQ to mrFF91kpuRbivucowsY512fDnYt6BWrvx9. First, because we just generated these identities from scratch, the first address has no bitcoin on it. Because we are using the “parallel universe” developer-intended Bitcoin test network, we can use one of multiple available faucets to pretty please request some BTC. I did this by Googling “bitcoin testnet faucet”, hitting the first link, and asking the faucet to send some bitcoins to our source address mnNcaVkC35ezZSgvn8fhXEa9QTHSUtPfzQ. A few minutes later, we can go back to the blockchain explorer and see that we received the coins, in this case 0.001 BTC. Faucets are available for the test net, but of course you won’t find them on the main net 🙂 You’d have to e.g. open up a Coinbase account (which generates a wallet) and buy some BTC for USD. In this tutorial we’ll be working on the test net, but everything we do would work just fine on the main net as well.

Now if we click on the exact transaction ID we can see a bunch of additional information that gets to the heart of Bitcoin and how money is represented in it.

Transaction id. First note that every transaction has a distinct id / hash. In this case the faucet transaction has id 46325085c89fb98a4b7ceee44eac9b955f09e1ddc86d8dad3dfdcba46b4d36b2. As we’ll see, this is just a SHA256 double hash (hash of a hash) of the transaction data structure that we’ll see soon serialized into bytes. Double SHA256 hashes are often used in place of a single hash in Bitcoin for added security, to mitigate a few shortcomings of just one round of SHA256, and some related attacks discovered on the older version of SHA (SHA-1).

Inputs and Outputs. We see that the faucet transaction has 1 input and 2 outputs. The 1 input came from address 2MwjXCY7RRpo8MYjtsJtP5erNirzFB9MtnH of value 0.17394181 BTC. There were 2 outputs. The second output was our address and we received exactly 0.001 BTC. The first output is some different, unknown address 2NCorZJ6XfdimrFQuwWjcJhQJDxPqjNgLzG which received 0.17294013 BTC, and is presumably controlled by the faucet owners. Notice that the the inputs don’t exactly add up to the outputs. Indeed we have that 0.17394181 — (0.001 + 0.17294013) = 0.00000168 . This “change” amount is called the fee, and this fee is allowed to claimed by the Bitcoin miner who has included this transaction in their block, which in this case was Block 2005500. You can see that this block had 48 transactions, and the faucet transaction was one of them! Now, the fee acts as a financial incentive for miners to include the transaction in their block, because they get to keep the change. The higher the fee to the miner, the more likely and faster the transaction is to appear in the blockchain. With a high fee we’d expect it to be eagerly taken up by miners and included in the very next block. With a low fee the transaction might never be included, because there are many other transactions broadcasted in the network that are willing to pay a higher fee. So if you’re a miner and you have a finite amount of space to put into your Block — why bother?

When we make our own transaction, we’ll have to make sure to include this tip for the miner, and pay “market rate”, which we’ll look up. In the case of this block, we can see that the total amount of BTC made by the miner of this block was 0.09765625 BTC from the special “Coinbase” transaction, that each miner is allowed to send from a null input to themselves, and then a total of 0.00316119 BTC was the total fee reward, summed up over all of the 47 non-Coinbase transactions in this block.

Size. Also note that this transaction (serialized) was 249 bytes. This is a pretty average size for a simple transaction like this.

Pkscript. Lastly note that the second Output (our 0.001 BTC) when you scroll down to its details has a “Pkscript” field, which shows:

This is where things get a bit crazy with Bitcoin. It has a whole stack-based scripting language, but unless you’re doing crazy multisig smart contract triple escrow backflips (?), the vast majority of transactions use one of very few simple “special case” scripts, just like the one here. By now my eyes just glaze over it as the standard simple thing. This “Pkscript” is the “locking script” for this specific Output, which holds 0.001 BTC in it. We are going to want to spend this Output and turn it into an Input in our upcoming transaction. In order to unlock this output we are going to have to satisfy the conditions of this locking script. In English, this script is saying that any Transaction that aspires to spend this Output must satisfy two conditions. 1) their Public key better hash to 4b3518229b0d3554fe7cd3796ade632aff3069d8. And 2) the digital signature for the aspiring transaction better validate as being generated by this public key’s associated private key. Only the owner of the secret key will be able to both 1) provide the full public key, which will be checked to hash correctly, and 2) create the digital signature, as we’ll soon see.

By the way, we can verify that of course our public key hashes correctly, so we’ll be able to include it in our upcoming transaction, and the all of the mining nodes will be able to verify condition (1). Very early Bitcoin transactions had locking scripts that directly contained the public key (instead of its hash) followed by OP_CHECKSIG, but doing it in this slightly more complex way protects the exact public key behind the hash, until the owner wants to spend the funds, only then do they reveal the public key. (If you’d like to learn more look up p2pk vs p2pkh transactions).

Part 3: Crafting our transaction

Okay, now we’re going to actually craft our transaction. Let’s say that we want to send half of our funds to our second wallet. i.e. we currently have a wallet with 0.001 BTC, and we’d like to send 0.0005 BTC to our second wallet. To achieve this our transaction will have exactly one input (= 2nd output of the faucet transaction), and exactly 2 outputs. One output will go to our 2nd address, and the rest of it we will send back to our own address!

This here is a critical part to understand. It’s a bit funky. Every Input/Output of any bitcoin transaction must always be fully spent. So if we own 0.001 BTC and want to send half of it somewhere else, we actually have to send one half there, and one half back to us.

The Transaction will be considered valid if the sum of all outputs is lower than the sum of all inputs (so we’re not minting money). The remainder will be the “change” (fee) that will be claimed by the winning miner who lucks out on the proof of work, and includes our transaction in their newly mined block.

Let’s begin with the transaction input data structure:

The first two variables ( prev_tx, prev_index ) identify a specific Output that we are going to spend. Note again that nowhere are we specifying how much of the output we want to spend. We must spend the output (or a “UTXO” as it’s often called, short for Unspent Transaction Output) in its entirety. Once we consume this UTXO in its entirety we are free to “chunk up” its value into however many outputs we like, and optionally send some of those chunks back to our own address. Anyway, in this case we are identifying the transaction that sent us the Bitcoins, and we’re saying that the Output we intend to spend is at the 1th index of it. The 0th index went to some other unknown address controlled by the faucet, which we won’t be able to spend because we don’t control it (we don’t have the private key and won’t be able to create the digital signature).

The script_sig field we are going to revisit later. This is where the digital signature will go, cryptographically signing the desired transaction with our private key and effectively saying “I approve this transaction as the possessor of the private key whose public key hashes to 4b3518229b0d3554fe7cd3796ade632aff3069d8”.

sequence was in the original Bitcoin implementation from Satoshi and was intended to provide a type of “high frequency trade” functionality, but has very limited uses today and we’ll mostly ignore.

Calculating the fee. Great, so the above data structure references the Inputs of our transaction (1 input here). Let’s now create the data structures for the two outputs of our transaction. To get a sense of the going “market rate” of transaction fees there are a number of websites available, or we can just scroll through some transactions in a recent block to get a sense. A number of recent transactions (including the one above) were packaged into a block even at <1 satoshi/byte (satoshi is 1e-8 of a bitcoin). So let’s try to go with a very generous fee of maybe 10 sat/B, or a total transaction fee of 0.0000001. In that case we are taking our input of 0.001 BTC = 100,000 sat, the fee will be 2,500 sat (because our transaction will be approx. 250 bytes), we are going to send 50,000 sat to our target wallet, and the rest ( 100,000 — 2,500 — 50,000 = 47,500 ) back to us.

Populating the locking scripts. We’re now going to populate the script_pubkey “locking script” for both of these outputs. Essentially we want to specify the conditions under which each output can be spent by some future transaction. As mentioned, Bitcoin has a rich scripting language with almost 100 instructions that can be sequenced into various locking / unlocking scripts, but here we are going to use the super standard and ubiquitous script we already saw above, and which was also used by the faucet to pay us. To indicate the ownership of both of these outputs we basically want to specify the public key hash of whoever can spend the output. Except we have to dress that up with the “rich scripting language” padding. Ok here we go.

Recall that the locking script in the faucet transaction had this form when we looked at it in the Bitcoin block explorer. The public key hash of the owner of the Output is sandwiched between a few Bitcoin Scripting Language op codes, which we’ll cover in a bit:

We need to create this same structure and encode it into bytes, but we want to swap out the public key hash with the new owner’s hashes. The op codes (like OP_DUP etc.) all get encoded as integers via a fixed schema. Here it is:

Ok we’re now going to effectively declare the owners of both outputs of our transaction by specifying the public key hashes (padded by the Script op codes). We’ll see exactly how these locking scripts work for the Ouputs in a bit when we create the unlocking script for the Input. For now it is important to understand that we are effectively declaring the owner of each output UTXO by identifying a specific public key hash. With the locking script specified as above, only the person who has the original public key (and its associated secret key) will be able to spend the UTXO.

Digital Signature

Now for the important part, we’re looping around to specifying the script_sig of the transaction input tx_in , which we skipped over above. In particular we are going to craft a digital signature that effectively says “I, the owner of the private key associated with the public key hash on the referenced transaction’s output’s locking script approve the spend of this UTXO as an input of this transaction”. Unfortunately this is again where Bitcoin gets pretty fancy because you can actually only sign parts of Transactions, and a number of signatures can be assembled from a number of parties and combined in various ways. As we did above, we will only cover the (by far) most common use case of signing the entire transaction and, and constructing the unlocking script specifically to only satisfy the locking script of the exact form above (OP_DUP, OP_HASH160, <hash>, OP_EQUALVERIFY, OP_CHECKSIG).

First, we need to create a pure bytes “message” that we will be digitally signing. In this case, the message is the encoding of the entire transaction. So this is awkward — the entire transaction can’t be encoded into bytes yet because we haven’t finished it! It is still missing our signature, which we are still trying to construct.

Instead, when we are serializing the transaction input that we wish to sign, the rule is to replace the encoding of the script_sig (which we don’t have, because again we’re just trying to produce it…) with the script_pubkey of the transaction output this input is pointing back to. All other transaction input’s script_sig is also replaced with an empty script, because those inputs can belong to many other owners who can individually and independently contribute their own signatures. Ok I’m not sure if this is making sense any right now. So let’s just see it in code.

We need the final data structure, the actual Transaction, so we can serialize it into the bytes message. It is mostly a thin container for a list of TxIn s and list of TxOut s: the inputs and outputs. We then implement the serialization for the new Tx class, and also the serialization for TxIn and TxOut class, so we can serialize the entire transaction to bytes.

Before we can call .encode on our Transaction object and get its content as bytes so we can sign it, we need to satisfy the Bitcoin rule where we replace the encoding of the script_sig (which we don’t have, because again we’re just trying to produce it…) with the script_pubkey of the transaction output this input is pointing back to. Here is the link once again to the original transaction. We are trying to spend its Output at Index 1, and the script_pubkey is, again,

This particular Block Explorer website does not allow us to get this in the raw (bytes) form, so we will re-create the data structure as a Script:

Что такое исходный код криптовалюты?

Исходный код — текст программы, написанный на определенном языке программирования с возможностью внесения изменений. В чем его особенности? Какие виды бывают? Что такое код криптовалюты?

Исходный код криптовалюты: что это

Термин «исходный код» применяется среди программистов, составляющих ПО на разных языках программирования. В общем понимании это входные сведения для транслятора, который отражает код до запуска программы или сразу выполняет ее с применением интерпретатора. По информации, изложенной в исходных данных, легко понять логику поведения программы или цифровых монет (для криптовалюты). Для обоснования данных применяются комментарии или выпускается документация с пояснениями.

В общей практике исходный код применяют программисты для внесения изменений, изучения или совершенствования ПО. Его также используют специалисты в качестве инструмента для общения. На практике исходный код может разбиваться на блоки и использоваться в различных проектах.

Отвечая на вопрос, что такое код криптовалюты, можно сказать следующее — это наиболее важный элемент (основа) цифровой монеты, обеспечивающая ее работу внутри криптовалютной платформы. Без исходного кода исправление или внесение изменений в работу системы становится невозможным.

Исходный код криптовалюты бывает двух видов:

1. Открытый. Доступ имеют все пользователи.
2. Закрытый. Возможность правки имеют только узкая группа разработчиков.

Организация и требования к исходному коду криптовалюты

Исходный код в зависимости от сложности состоит из одного или группы файлов. Язык написания может быть различным с возможностью «смешивания» разных вариантов. К примеру, допускается написание основной части на C++ с дополнительными вставками на Assembler. Известны случаи составления модулей с помощью разных языков, после чего составляющие элементы собираются в единый документ.

При разработке крупных проектов могут использоваться от 2 и более файлов с исходными кодами. В этом случае создатели выпускают отдельный документ с пояснением принципов работы каждого элемента и пояснением зависимости между ними. В состав файлов могут входить разные показатели для компилятора и программируемой среды. В зависимости от ситуации документы могут выполняться в текстовом виде или поддерживать другие форматы. Разработка и внесение правок в файлы осуществляется с применением особого софта.

Иными словами, исходный код (в том числе криптовалюты) — это набор файлов, в составе которых содержится разная информация. Для упрощения взаимодействия с создателями, как правило, применяют системы управления.

При оценке качества исходного кода криптовалюты не применяются термины плохой или хороший. Здесь учитывается несколько параметров:

Удобство изучения исходного кода (простота). Важно наличие комментариев и пояснений к программе.

Важность открытости исходного кода криптовалюты

Проекты с открытым исходным кодом — разработки, позволяющие другим участникам сети проверять корректность информации, вносить изменения (по желанию) или расширять возможности системы. Открытость исходного кода ценится не только в криптовалютах, но и в мире программного обеспечения. Стоит отметить, что большая часть цифровых монет построена именно на открытом коде.

Некоторые разработчики ПО и криптовалют скрывают исходный код. В этом случае поддержкой, разработкой и устранением ошибок занимается ограниченный круг лиц. К примеру, в криптовалютах NEM, Stellar и ряде других монет доступ посторонних к исходному коду закрыт. Это касается и многих программ, к примеру, Facebook или Adobe. Такое ПО носит название «несвободного», с ограниченным доступом. Внесение правок или изменений доступно авторам, имеющим юридически обоснованное право.

Открытость исходного кода делает его доступным для всех желающих. Любой человек сможет выполнять разные функции с программой — делать копии, смотреть, вносить правки, отправлять друзьям или проходить обучение. Некоторые разработчики открывают доступ к исходнику, но ограничивают его применение. К примеру, смотреть можно, а вот делать копии и использовать в других проектах нельзя.

Открывая код для пользователей, создатели криптовалюты повышают уровень децентрализации сети. К развитию платформы привлекаются опытные программисты и знающие пользователи, способные дать полезные рекомендации, а иногда и самостоятельно внести правки. Кроме того, сообщество держит под контролем открытый код и оперативно выявляет имеющиеся ошибки. Все это повышает надежность сети и ускоряет ее развитие.

Сегодня наиболее крупные криптовалюты, торгуемые на крупных биржах и востребованные на рынке (к примеру, Bitcoin, Ethereum и другие), построены на открытом исходном коде. При этом регулирующие организации и уполномоченные органы, пытающиеся понять сущность виртуальных денег, уверены в разработке таких ПО какой-то одной или группой предприятий. Такое мнение в отношении криптовалют ошибочно.

И правда, исходный код многих программ разрабатывается и поддерживается специальными компаниями. Для открытого ПО работает иной принцип. Здесь ключевую роль играет участие каждого человека в развитии сети. В процессе создания исходного кода криптовалют участвуют сотни тысяч людей. Информация бесплатно распространяется в Сети, скачивается на компьютеры и изучается пользователями. Сведения публичны, поэтому замечания относительно работы кода или его слабых мест появляются в сжатые сроки.

Благодаря такому подходу, исходный код криптовалюты никому не принадлежит, на него нет прав, запрещающих применение другими людьми. К примеру, не существует предприятия, которое бы владело Bitcoin или Monero. Такая децентрализация несет ряд преимуществ для системы, ее продвижения и развития. В программной среде одним из наиболее успешных примеров является операционная система Linux, имеющая открытый исходный код и при этом обладающая много большей надежностью, чем Windows.

Преимущества открытого исходного кода криптовалюты

Открытость исходного кода в криптовалютной сфере и секторе программного обеспечения несет ряд позитивных моментов:

Наличие мотивации, позволяющей создать качественный продукт. Каждый человек, участвующий в создании или оптимизации исходного кода ставит задачей лично использовать проект и получать от этого дивиденды. Такой участник свободен в своих действиях, он не ограничен контрактными обязательствами и требованиями создателя. В результате возникает качественный продукт с минимальным набором проблем.

Преимущества	Недостатки
Высокая вероятность создания качественного продукта.	Доступность исходного кода для злоумышленников, которые могут использовать информацию для поиска багов и возможностей взлома сети.
Тесное взаимодействие основных разработчиков и членов сообщества.
Высокая скорость устранения багов и слабых мест.
Упрощение и оптимизация кода, а, следовательно, повышение надежности криптовалюты.
Отсутствие временных рамок в развитии проекта.

Анализируя, что такое исходный код криптовалюты с позиции открытости, можно сделать вывод о пользе такого подхода. В результате работы сотен тысяч людей появляется надежный и качественный продукт, который постоянно совершенствуется. При появлении малейших багов или проблем в работе опытные программисты с удовольствием берутся за решение проблемы для внесения посильного вклада в развитие проекта.

Остальное сообщество, не участвующее во внесении правок, пользуется качественным продуктом. Бесплатное ПО как бы появляется из воздуха и доступно всем желающим до момента, пока группа экспертов заинтересована в развитии проекта.

Законодательство и исходный код криптовалюты

Позиция многих стран относительно виртуальных денег и возможности их применения находится под вопросом. Одни полностью легализовали криптовалюту (к примеру, Япония, Беларусь), другие разрешили ее применение частично (Китай, Южная Корея, некоторые страны ЕС), третьи запретили (Эквадор, Непал и другие).

Что касается открытости исходного кода, здесь позиция правительств крупных государств в большей части одинаковая. Такой подход поддерживается, ведь это стимулирует создание более совершенного и надежного программного обеспечения. Разработка защищена авторским правом, но пользователи могут использовать и даже изменять код без получения разрешения или внесения платежей.

В ряде лицензий прописываются требования, подразумевающий выпуск ответвлений ПО с учетом аналогичных правил. В результате спрос на программы с открытым кодом увеличивается.

Источник исходного кода криптовалюты — где скачать

Главная страница сайта github.com

Как отмечалось, ярким примером ПО с открытым кодом — Linux, а в сфере криптовалют — Биткоин, Эфир. Сегодня большинство блокчейн-проектов выбирают открытую схему развития, понимая перспективы и возможности таких разработок. В результате на рынок выпускаются сети, взаимодействующие на базе согласия.

ПО, позволяющее пользователю подключиться к сети, носит название клиента, а сама программа имеет открытый код. При создании софта участвует множество людей, которые скачивают программу со специальных сайтов и создают нечто новое. К примеру, в сфере криптовалют это может быть кошелек, биржевая площадка или другое совместимое ПО.

Необходимая информация содержится на сайте github.com. Эта удобная платформа, в основе которой лежит GLt. Сервис контролирует процесс изменения исходных кодов и хранит в базе историю внесения изменений. Здесь же указывается дата внесения правок, человек, который это сделал, и время внесения правок.

Хранилище носит название репозиторий, а правки в исходный код делаются с помощью коммитов. Последние — набор правок в документах, объединенных в один перечень (для каждого предусмотрено индивидуальное обоснование). Изменения вносятся после получения соответствующих запросов.

Принцип действия можно рассмотреть на примере:

1. В 1-й день создана разметка html (делается коммит).
2. На 2-е сутки добавляются цвета, меняются шрифты (для этих правок также пишется коммит) и так далее.

Иными словами, репозиторий контролирует форки для оригинального (первоначального) программного обеспечения. После выставления первичный проект можно усовершенствовать, после чего изменения сохранятся на сайте. К примеру, по ссылке github.com/ethereum можно найти 181 репозиторий для криптовалюты Эфириум. Каждый из них акцентирует внимание на определенном нюансе проекта — умных контрактов, совместимости с сетью и так далее. При этом код Эфириума доступен для просмотра и скачивания в полном объеме.

Что касается Bitcoin Core, здесь актуальна ссылка github.com/bitcoin/bitcoin. На 6 декабря 2018 года в этой сети отражено 18,893 тысячи коммитов и 209 релизов. Для получения доступа к репозиториям криптовалюты можно перейти по ссылке github.com/bitcoin/. По аналогичному принципу легко найти исходный код почти для любой интересующей криптовалюты. К примеру, для Zcash предусмотрено 14 репозиториев, а ссылка для скачивания — github.com/Zcash, для Litecoin — github.com/litecoin-project.

Как исходный код криптовалюты используется при создании новых монет?

В основе любой виртуальной монеты лежит программный код, где прописаны технические параметры коина и функционирования сети. В результате у создателей цифровых денег имеется два пути:

Использовать существующий код криптовалюты и внести интересующие изменения. Это наиболее простой путь, ведь достаточно зайти на github.com и найти интересующие сведения. В дальнейшем придется проделать большую работу — сделать собственные библиотеки, определиться с сетевыми портами и настроить их, установить параметры генерации коинов, сделать ключи и провести другие мероприятия.

Если говорить в общем, создание криптовалюты проходит в несколько этапов:

Выбор подходящего исходного кода, используемого для создания монеты.

Bitcoin in a nutshell — Cryptography

Одна из причин, почему Bitcoin продолжает привлекать столько внимания — это его исключительная «математичность». Сатоши Накамото удалось создать систему, которая способна функционировать при полном отсутствии доверия между ее участниками. Все взаимодействия основаны на строгой математике, никакого человеческого фактора — вот в чем была революционность идеи, а не в одноранговой сети, как многие думают. Поэтому первую главу я решил посвятить именно математическим основам Bitcoin.

Ниже я постараюсь объяснить вам самые базовые вещи — эллиптические кривые, ECC, приватные / публичные ключи и так далее. По возможности я буду иллюстрировать свои слова примерами кода, преимущественно на Python 2.7, если что-то непонятно — спрашивайте в комментариях.

• Bitcoin in a nutshell — Cryptography

Table of content

1. Introduction
2. Elliptic curve
3. Digital signature
4. Private key
5. Public key
6. Formats & address
7. Sign
8. Verify
9. Formats
10. Links

Introduction

Как я уже сказал выше, криптография — это фундаментальная часть Bitcoin. Без нее вообще бы ничего не заработало, поэтому начинать нужно именно отсюда.

В Bitcoin используется так называемая криптография на эллиптических кривых (Elliptic curve cryptography, ECC). Она основана на некоторой особой функции — эллиптической кривой (не путать с эллипсом). Что это за функция и чем она так примечательна я расскажу дальше.

Elliptic curve

Если на пальцах, то эллиптическая кривая — это внешне довольно простая функция, как правило, записываемая в виде так называемой формы Вейерштрасса:

В зависимости от значений параметров и , график данной функции может выглядеть по разному:

Скрипт для отрисовки графика на Python:

Если верить вики, то впервые эта функция засветилась еще в трудах Диофанта, а позже, в 17 веке, ей заинтересовался сам Ньютон. Его исследования во многом привели к формулам сложения точек на эллиптической кривой, с которыми мы сейчас познакомимся. Здесь и в дальнейшем мы будем рассматривать некоторую эллиптическую кривую .

Пусть есть две точки . Их суммой называется точка , которая в простейшем случае определяется следующим образом: проведем прямую через и — она пересечет кривую в единственной точке, назовем ее . Поменяв координату точки на противоположную по знаку, мы получим точку , которую и будем называть суммой и , то есть .

Считаю необходимым отметить, что мы именно вводим такую операцию сложения — если вы будете складывать точки в привычном понимании, то есть складывая соответствующие координаты, то получите совсем другую точку , которая, скорее всего, не имеет ничего общего с или и вообще не лежит на кривой .

Самые сообразительные уже задались вопросом — а что будет, если например провести прямую через две точки, имеющие координаты вида и , то есть прямая, проходящая через них, будет параллельна оси ординат (третий кадр на картинке ниже).

Несложно увидеть, что в этом случае отсутствует третье пересечение с кривой , которое мы называли . Для того, чтобы избежать этого казуса, введем так называемую точку в бесконечности (point of infinity), обозначаемую обычно или просто , как на картинке. И будем говорить, что в случае отсутствия пересечения .

Особый интерес для нас представляет случай, когда мы хотим сложить точку саму с собой (2 кадр, точка ). В этом случае просто проведем касательную к точке и отразим полученную точку пересечения относительно .

Теперь, легким движением руки, можно ввести операцию умножения точки на какое-то число. В результате получим новую точку , то есть раз. С картинкой все должно стать вообще понятно:

Elliptic curve over a finite field

В ECC используется точно такая же кривая, только рассматриваемая над некоторым конечным полем — простое число. То есть

Все названные свойства (сложение, умножение, точка в бесконечности) для такой функции остаются в силе, хотя, если попробовать нарисовать данную функцию, то напоминать привычную эллиптическую кривую она будет лишь отдаленно (в лучшем случае). А понятие «касательной к функции в точке» вообще теряет всякий смысл, но это ничего страшного. Вот пример функции для :

А вот для , тут вообще почти хаотичный набор точек. Единственное, что все еще напоминает о происхождении этого графика, так это симметрия относительно оси .

P. S. Если вам интересно, как в случае с кривой над конечным полем вычислить координаты точки , зная координаты и — можете полистать «An Introduction to Bitcoin, Elliptic Curves and the Mathematics of ECDSA» by N. Mistry, там все подробно расписано, достаточно знать математику на уровне 8 класса.

P.P.S. На случай, если мои примеры не удовлетворили ваш пытливый ум, вот сайт для рисования кривых всех сортов, поэкспериментируйте.

SECP256k1

Возвращаясь к Bitcoin, в нем используется кривая SECP256k1. Она имеет вид и рассматривается над полем , где — очень большое простое число, а именно .

Так же для SECP256k1 определена так называемая base point, она же generator point — это просто точка, как правило, обозначаемая , лежащая на данной кривой. Она нужна для создания публичного ключа, о котором будет рассказано ниже.

Простой пример: используя Python, проверим, принадлежит ли точка кривой SECP256k1

Digital signature

Общая идея такая: Алиса хочет перевести 1 BTC Бобу. Для этого она создает сообщение типа:

Потом Алиса берет свой приватный ключ (пока что можете считать, что это число, известное только Алисе), хэш сообщения и функцию вида . На выходе она получает подпись своего сообщения — в случае ECDSA это будет пара целых чисел, для других алгоритмов подпись может выглядеть по другому. После этого она рассылает всем участникам сети исходное сообщение, подпись и свой публичный ключ.

В результате, каждый Вася при желании сможет взять эту троицу, функцию вида и проверить, действительно ли владелец приватного ключа подписывал это сообщение или нет. А если внутри сети все знают, что принадлежит Алисе, то можно понять, отправила эти деньги она или же кто-то пытается сделать это от ее имени.

Более того, предположим, что нашелся человек, вставший между Алисой и остальной сетью. Пусть он перехватил сообщение Алисы и что-то в нем изменил, буквально 1 бит из миллиарда. Но даже в этом случае проверка подписи на валидность покажет, что сообщение было изменено.

Это очень важная фича для Bitcoin, потому как сеть распределенная. Мы не можем заранее знать, к кому попадет наша транзакция с требованием перевести 1000 BTC. Но изменить ее (например указать свой адрес с качестве получателя) он не сможет, потому как транзакция подписана вашим приватным ключом, и остальные участники сети сразу поймут, что здесь что-то не так.

AHTUNG! В действительности процесс довольно сильно отличается от вышеописанного. Здесь я просто на пальцах показал, что из себя представляет электронно-цифровая подпись и зачем она нужна. Реальный алгоритм описан в главе «Bitcoin in a nutshell — Transactions».

Private key

Приватный ключ — это довольно общий термин и в различных алгоритмах электронной подписи могут использоваться различные типы приватных ключей.

Как вы уже могли заметить, в Bitcoin используется алгоритм ECDSA — в его случае приватный ключ — это некоторое натуральное 256 битное число, то есть самое обычное целое число от до . Технически, даже число 123456 будет являться корректным приватным ключом, но очень скоро вы узнаете, что ваши монеты «принадлежат» вам ровно до того момента, как у злоумышленника окажется ваш приватный ключ, а значения типа 123456 очень легко перебираются.

Важно отметить, на сегодняшний день перебрать все ключи невозможно в силу того, что — это фантастически большое число.

Постараемся его представить: согласно этой статье, на всей Земле немногим меньше песчинок. Воспользуемся тем, что , то есть песчинок. А всего адресов у нас , примерно .

Значит, мы можем взять весь песок на Земле, превратить каждую песчинку в новую Землю, в получившейся куче планет каждую песчинку на каждой планете снова превратить в новую Землю, и суммарное число песчинок все равно будет на порядки меньше числа возможных приватных ключей.

По этой же причине большинство Bitcoin клиентов при создании приватного ключа просто берут 256 случайных бит — вероятность коллизии крайне мала.

Python

Python, ECDSA

Bitcoin-cli

Public key

Пусть — наш приватный ключ, — base point, тогда публичный ключ . То есть, фактически, публичный ключ — это некоторая точка, лежащая на кривой SECP256k1.

Два важных нюанса. Во-первых, несложно видеть, что операция получения публичного ключа определена однозначно, то есть конкретному приватному ключу всегда соответствует один единственный публичный ключ. Во-вторых, обратная операция является вычислительно трудной и, в общем случае, получить приватный ключ из публичного можно только полным перебором первого.

Ниже вы узнаете, что точно такая же связь существует между публичным ключом и адресом, только там все дело в необратимости хэш-функций.

Python, ECDSA

C++, libbitcoin

Для компиляции и запуска используем (предварительно установив libbitcoin):

Вы можете видеть, что форматы публичных ключей в первом и втором примере отличаются (как минимум длиной), об этом я подробнее расскажу ниже.

Formats & address

Base58Check encoding

Эта кодировка будет встречаться нам постоянно на протяжении всей книги, поэтому стоит понимать, как она работает и зачем она вообще нужна.

Ее суть в том, чтобы максимально кратко записать последовательность байт в удобочитаемом формате и при этом сделать вероятность возможных опечаток еще меньше. Я думаю вы сами понимаете, что в случае Bitcoin безопасность лишней не бывает. Один неправильный символ и деньги уйдут на адрес, ключей к которому скорее всего никто никогда не найдет. Вот комментарий к этой кодировке из в base58.h:

Краткость записи проще всего реализовать, используя довольно распространенную кодировку Base64, то есть используя систему счисления с основанием 64, где для записи используются цифры 0,1. 9 , буквы a-z и A-Z — это дает 62 символа, оставшиеся два могут быть чем угодно, в зависимости от реализации.

Первое отличие Base58Check в том, что убраны символы 0,O,l,I на случай, если кто-нибудь решит их перепутать. Получается 58 символов, можете проверить

Второе отличие — это тот самый check. В конец строки снова добавляется checksum — первые 4 байта SHA256(SHA256(str)) . Ну и еще нужно добавить в начало столько единиц, сколько ведущих нулей было до кодировки в base58, это уже дело техники.

Private key formats

Самый очевидный способ хранить приватный ключ — это записать 256 бит в виде кучи нулей и единиц. Но, наверное, любой технически грамотный человек понимает, что будет сильно проще представить ту же самую последовательность в виде 32 байт, где каждому байту соответствует два символа в шестнадцатиричной записи. Напомню, что в этом случае используются цифры 0,1. 9 и буквы A,B,C,D,E,F . Этот формат я использовал в примерах выше, для красоты его еще иногда разделяют пробелами.

1. Берем приватный ключ, например 0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D
2. Записываем его в Base58Check с префиксом 0x80 . Все.

Public key formats

На всякий случай напомню, что публичный ключ — это просто точка на прямой SECP256k1. Первый и самый распространенный вариант его записи — uncompressed формат, по 32 байта для X и Y координат. Чтобы не возникало путаницы, используется префикс 0x04 и того 65 байт.

Однако, как можно догадаться из названия, это не самый оптимальный способ хранить публичный ключ.

Вы удивитесь, но второй формат называется compressed. Суть его в следующем: публичный ключ — это точка на кривой, то есть пара чисел удовлетворяющая уравнению . А значит можно записать только Х координату и если нам понадобится Y координата — просто решаем уравнение. Тем самым мы уменьшаем размер публичного ключа почти на 50%!

Единственный нюанс — если точка лежит на кривой, то для ее Х координаты очевидно существует два решения такого уравнения (посмотрите на графики выше, если сомневаетесь). Обычно мы бы просто сохранили знак для Y координаты, но когда речь идет о функции над конечным полем, то нужно воспользоваться следующим свойством: если для Х координаты существуют решения уравнения, то одна из точек будет иметь четную Y координату, а вторая — нечетную (опять же, можете сами в этом убедиться).

В первом случае используется префикс 0x02 , во втором — 0x03 . Вот иллюстрация процесса:

Address

1. Возьмем приватный ключ, например 45b0c38fa54766354cf3409d38b873255dfa9ed3407a542ba48eb9cab9dfca67
2. Получим из него публичный ключ в uncompressed формате, в данном случае это 04162ebcd38c90b56fbdb4b0390695afb471c944a6003cb334bbf030a89c42b584f089012beb4842483692bdff9fcab8676fed42c47bffb081001209079bbcb8db .
3. Считаем RIPEMD160(SHA256(public_key)) , получается 5879DB1D96FC29B2A6BDC593E67EDD2C5876F64C
4. Переводим результат в Base58Check с префиксом 0x00 — 17JdJpDyu3tB5GD3jwZP784W5KbRdfb84X . Это и есть адрес.

Sign & verify

Не думаю, что вам нужно обязательно знать технические подробности того, как именно ECDSA подписывает и проверяет сообщения, все равно вы везде будете пользоваться готовыми библиотеками. Главное, чтобы у вас было общее понимание того зачем это нужно, но если вам все таки интересно — полистайте Layman’s Guide to Elliptic Curve Digital Signatures, там внизу есть красивая визуализация всего процесса, можете сами попробовать.

У меня на этом все, следующая глава: Bitcoin in a nutshell — Transaction.

�� Код биткоина: как его получить и что с ним можно сделать

Биткоин — первая и самая известная криптовалюта в мире. Многих пользователей интересует вопрос, кто владеет и управляет Биткоином, а также – кто может вносить изменения в исходный код Биткоина. На самом деле, Биткоин не просто так называют децентрализованным. Он принадлежит одновременно всем и никому. Подробности рассказывает ProstoCoin.

Содержание

• Как выглядит код биткоина
• Возможности биткоина
• Почему цифровой код биткоина не принадлежит разработчикам
• Где можно получить исходный код биткоина
• Управление и изменение кода
• Популярные форки биткоина
• Выводы

Как выглядит код биткоина

По сути, Биткоин — протокол. То есть, язык, который используют компьютеры для совместной работы. Ключевой особенностью биткоина является полная децентрализация. За управлением монетой не стоит центральный администратор или его аналог. Монета полностью открыта. Те, кто хочет стать частью сети, просто должны установить программу-клиент. Все запущенные по всему миру программы соединяются между собой в одноранговую сеть, где каждый узел самодостаточный и равен остальным.

Важно, что биткоин имеет открытый исходный код. Программы с открытым исходным кодом доступны к изучению и изменению. Это позволяет не только убедиться в отсутствии уязвимостей, но открывает перспективы для использования программного кода в своих интересах.

Любой пользователь может просмотреть программный код биткоина, проверить наличие недокументированных возможностей или выявить недочеты в системе, предложить свой метод исправления или создать на основе кода биткоина собственный новый продукт, улучшенную или измененную версию.

Возможности биткоина

В биткоине доверие к эмитенту или любому другому управляющему органу заменено криптографией, математикой и алгоритмами. Децентрализация, отсутствие контроля разработчиков и влияния человеческого фактора гарантируют, что в один прекрасный момент система не закроется или не изменит кардинально правила.

Несмотря на отсутствие контроля, система полностью безопасна, поскольку работает по определенному алгоритму. Как децентрализованной платежной системе Биткоину свойственны следующие возможности и особенности:

• легкие и быстрые платежи с минимальными комиссиями;
• анонимность и защита персональных данных при транзакциях;
• равенство и независимость участников;
• глобальность;
• безопасность, надежность и защищенность, достигаемая при помощи криптографии;
• честный рыночный курс биткоина зависимый от соотношения спроса и предложения, а не установленный властями или создателем;
• отсутствие посредников при совершении транзакции;
• полный контроль над личными монетами и отсутствие финансовой цензуры, счет участника не может быть заморожен, а платеж не может быть запрещен.

Почему цифровой код биткоина не принадлежит разработчикам

Впервые о Биткоин заговорили в 2008 году, когда вся информация о принципах его функционирования и цифровой код появились в свободном доступе. Статья, подробно описывающая первую криптовалюту, была размещена на одном из форумов, где с ней мог бы ознакомиться любой желающий.

Главным преимуществом Биткоина является то, что он полностью децентрализован, то есть – не контролируется и не принадлежит правительству, банкам и даже разработчикам. Биткоин имеет открытый код, но, в отличие от большинства других открытых систем, в нем нет даже отдельного избирателя, который бы контролировал работу системы. Формально, сеть управляется только пользователями и майнерами. Хотя разработчики биткоина и имеют на него влияние, но работать с исходным кодом может любой желающий.

Цифровой код биткоина размещен на множестве информационных ресурсов для разработчиков. Обсуждение изменений ведется в нескольких чатах и на вебсайтах, а технология не принадлежит никому.

Создатель Биткоина – или группа лиц, скрывающихся за псевдонимом Сатоши Накамото и разместивших впервые статью о принципах работы криптовалюты – пожелал остаться анонимным и просто представил свое творение людям. Криптовалюты — наднациональная технология, сравнимая с Интернетом.

Где можно получить исходный код биткоина

Как упоминалось ранее, исходный код Биткоина размещен в открытом доступе. Любой желающий может его изучить или изменить на свое усмотрение. Найти официальную версию кода биткоина можно на страницах сервиса GitHub по этой ссылке.

GitHub — портал для разработчиков и программистов, куда выкладывается множество открытых кодов проектов для совместного изучения, работы, комментирования, а также для подтверждения надежности и открытости систем. На сервисе можно найти даже исходные коды таких гигантов, как Google или Microsoft.

С помощью данного сервиса любой желающий может получить код Биткоина для изучения или изменения.

Управление и изменение кода

В конечном счете, управление Биткоином ложится на обычных, равных между собой, участников сети, установивших на свой ПК соответствующее программное обеспечение. Данный тип управления можно сравнить с использованием английского языка в качестве международного. Нет управляющего органа, который бы закрепил статус английского языка как международного, но в нем есть единые грамматические правила, которых придерживаются все люди, использующие его. Точно так же и с Биткоином. В нем нет управления, но все участники сети придерживаются общего консенсуса. Основной тон дают пользователи, выполняющие большие транзакции по сети или владеющие большими подключенными мощностями.

Получить и изменить код Биткоина под силу любому программисту. Некоторые изменения протокола могут быть поддержаны множеством участников сети, другие — требует согласования со всей сетью для достижения общего консенсуса. При этом даже незначительное изменение программного кода может создать две абсолютно несовместимые между собой сети, создав новую криптовалюту.

Изменения, которые вносятся в код Биткоина, должны быть приняты и согласованы с пользователями, поскольку именно они должны будут обновить программное обеспечение и перейти на новую версию, оставив прошлую. Другими словами, пользователи должны начать использовать новую монету и принимать ее за Биткоин.

Разработчики Биткоина не имеют полномочий запретить использовать старую сеть или принудить использовать измененную. Это добровольный выбор каждого участника сети, установившего себе полную ноду. Максимум, что могут сделать разработчики, это дать совет и аргументировать необходимость принятия изменений.

Разработчики могут выпускать множество различных версий с измененным кодом, а участники могут просто игнорировать изменения и продолжать использовать прежнюю версию. Поэтому реальная проблема не в том, чтобы внести изменения в код, а в том, чтобы убедить участников, что эти изменения оправданы и можно перейти на новую сеть, приняв ее за единственно верный Биткоин.

Поэтому, чтобы избежать раскола сети, разработчики ядра Биткоина вносят изменения в софт форками, при которых на новую сеть должны переключиться все или никто. За принятие изменений участники голосуют хешированной мощностью. Если решение принимается, то пользователи, которые не желают переходить на новую сеть, должны быть готовы к тому, что, несмотря на совместимость с измененной сетью, их операции перестанут признаваться валидными, поскольку не будут соответствовать новым правилам сети.

Стоит отметить, что аналогичным образом большинство пользователей могут внести изменения в код Биткоина и без участия разработчиков, но если группа майнеров будет вносить изменения, противоречащие пользовательским интересам, то протокол Биткоина может быть изменен вместе с алгоритмом майнинга другими пользователями.

Популярные форки биткоина

Путем изменения исходного кода Биткоина может быть создана новая, похожая на Биткоин, но совершенно иная монета — форк, несовместимая с основной сетью. С момента появления Биткоина его код изменяли более 70 раз.

Некоторые форки Биткоина «помнит» только Интернет: они так и не смогли набрать достаточной популярности и привлечь внимание пользователей. К числу таких монет можно отнести Bitcoin Star, Bitcoin Coral, Bitcoin Hush и многие другие, чьи названия мало кто слышал и встречал. Список всех форков Биткоина можно найти на информационном сайте forkdrop.io.

По статистике, из 70 форков Биткоина в листинг на биржи попали только 10 монет, при этом их совокупная стоимость составляет всего 0,12 ВТС. Исключением из этого правила является Bitcoin Cash и Bitcoin Gold. Данные форки Биткоина обрели наибольшую популярность.

Bitcoin Cash был создан в результате раскола сети, когда некоторые пользователи всерьез озадачились проблемой масштабируемости блока Биткоина. Монета полностью повторяет оригинальный блокчейн, но имеет размер блока в 8 Мб, против 1 Мб в Биткоине. Благодаря чему ее транзакции более быстрые. В Bitcoin Gold был изменен алгоритм хеширования с SHA-256 на Equihash, что сделало более продуктивным майнинг на видеокартах.

Так что, несмотря на заявления разработчиков, предлагающих новые улучшенные варианты Биткоина с измененным кодом, мало какую монету имеют желание поддерживать участники сети и тем более единогласно принять ее за новый Биткоин, поэтому результатом внесения изменений является совершенно другая криптовалюта.

Выводы

Внести изменения в исходный код Биткоина может любой желающий, поскольку он полностью открытый и представлен в свободном доступе. Для того, чтобы эти изменения относились именно к основной сети Биткоина, они должны быть поддержаны большинством узлов связи, а для этого должны быть оправданы и полезны. Даже разработчики ядра Биткоина не могут вносить изменения без поддержки обычных пользователей.