Ready to get laser mining and start saving Electricity?это как дед говорил... если НЛО и прилетит, то это 100% будут русские. только русские идут до конца и возвращаються домой к семье. выращивайте пшеницу в космосе и поймете как работает гравитация. почему корешок к земле а жизнь в космос.
All information tends to be preserved. useful information tends to be disseminated.цепочка этого гена оказалась длинее чем цепочка биткоина? потому что кто то создал сатоши? а это ген создатель?
кто дольше проживет? эгоистичный ген или биткоин? если обсуждаю толь ко их?
и это вечные разговоры о жизни и ...
and now let's start mining on the finished results) maybe it will raise the complexity by 1000000 times)))) and then lower it))))
which means the blocks will be so slow you'll have to wait a year...
then by calculating the probability hash we get a legitimate correct result - a "nice" hash on the output, bingo.
So the math is all right here.
All that's left is to learn how to analyze the breath of the breeze... and the hash is broken.
Sounds like nonsense, but it is nonsense - and I warned you in the beginning.
What is all this for?
The bitcoin miner does not know in advance which 32 bit nonce value to choose. The miner is forced to go through all 4 billion of them to count the hash until it becomes "nice", until the hash value is less than target.
Fuzzy probabilistic arithmetic theoretically gets rid of brute force.
The very fact of absence prompted an investigation)
When the hashed file is read in its entirety and has been transferred to sha256_update(), all that remains is to call the final sha256_final() function, which, if the file size was not a multiple of 64 bytes, adds extra padding bytes, inserts the total length of data in bits at the end of the last data block and makes the final sha256_transform().
The hash result stays in the state array.
This is a "high level" so to speak.
For the bitcoin miner, of course, the developers think how to calculate less but more effectively.
It's simple: the header contains only 80 bytes, which is not a multiple of 64 bytes. Thus it would be necessary to do two sha256_transform() for the first sha256. Luckily for the miners, however, the nonce of the block is at the end of the header, so the first sha256_transform() can only be done once - it will be a so-called midstate. Next, the miner goes through all the nonce options, of which there are 4 billion, 2^32, and substitutes them in the appropriate field for the second sha256_transform(). This transform completes the first sha256 function. Its result is eight 32-bit words, that is, 32 bytes. Finding sha256 from them is easy - the terminating sha256_transform() is called, and that's it. Notice that the 32-byte input is smaller than the 64 bytes needed for sha256_transform(). So again the block will be padded with zeros and the block length will be written at the end.
All in all there are three calls to sha256_transform() of which the first one needs to be read only once to calculate midstate.
I tried to expand all data manipulations occurring when bitcoin block header hash is calculated in one function, so that it would be clear how all the calculation is done specifically for bitcoin
Когда хэшируемый файл весь считан и уже передан в функцию sha256_update() остается только вызвать завершающую функцию sha256_final(), которая если размер файла был не кратен 64 байтам, то добавит дополнительные padding байты, впишет в конец последнего блока данных общую длину данных в битах и сделает финальный sha256_transform().
Результат хэширования остается в массиве state.
Это так сказать «высокий уровень».
Применительно к майнеру биткоина, конечно разработчики думают как бы считать поменьше да поэффективней.
Все просто: заголовок содержит всего 80 байт, что не кратно 64 байтам. Таким образом нужно было бы для первого sha256 уже делать два sha256_transform(). Однако по счастью для майнеров, nonce блока находится в конце заголовка, значит первый sha256_transform() можно выполнить всего один раз — это будет так называемый midstate. Далее майнер перебирает все варианты нонсе, которых 4 миллиарда, 2^32 и подставляет их в соответствующее поле для второго sha256_transform(). Этот трансформ завершает первую функцию sha256. Ее результат — это восемь 32х битных слов, то есть 32 байта. От них найти sha256 просто — вызывается завершающий sha256_transform() и все — готово. Заметьте, что входные данные 32 байта меньше по размеру, чем нужные для sha256_transform() 64 байта. Значит опять блок будет дополнен нулями и в конец будет вписана длина блока.
Итого всего три вызова sha256_transform() из которых первый нужно считать только один раз для вычисления midstate.
Я попытался развернуть все манипуляции с данными происходящие при вычислении хэша заголовка блока биткоина в единую функцию, так, чтобы было понятно, как происходит все вычисление конкретно для биткоина и вот что получилось:
The whole planet is in search of the truth of chance? Is the algorithm for finding that chance correct? Is there something wrong with the algorithm itself?
You can see that some bits in the bitcoin nonce are not equally probable in their value and the graphs are shifted downwards. So the bit value is still slightly more likely to be zero than one.
Run the script and wait for it to finish. You will get a file like this with 2,000 lines:
Now let's divide this sample into groups of 100 values and perform statistical analysis on each group. Nonce is a 32-bit number. It stands to reason that every bit of the nonce is equally likely to take a value of one or zero. This is what I am going to check. I will write a script that counts the number of ones in each bit position in a group of 100 nonces.
The sha256( sha256( BlockHeader ) ) function used in the bitcoin hashing algorithm is believed to be very reliable. It is so reliable that there is only one way to pick up the golden nonce for the next block in the blockchain - by brute forcing during the mining process.
Currently, there are already over 530,000 blocks in the bitcoin blockchain. This is enough to perform a statistical analysis and answer the question, "are the bit values in the previously found nonsense really equally likely?".
The simplest statistical analysis can be done not on the whole blockchain, but only on the last few thousand blocks. This would require taking this information from, for example, btc.com. This blockchain explorer has quite an advanced api, which we will use. Let's write a simple script that uses requests library to download information about last 2000 blocks. I am interested in only one value - nonce, and I will write it to text file together with block number.
https://btc2.trezor.io/address/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
first satoshi address) 0 block
You will never be allowed to increase the block size to -3 megabytes, this will reduce the complexity of the network) because the search time plays the size of records with transactions?
а как америка блоки ворует знаете?
вот небольшой пример... некий майнер находит блок и транслирует его в сеть. американский пул быстро берет этот блок проверяет и переретранслирует как свой, потом быстро ищет новый блок что он точно попал в сеть. так это работает!)))
короче быстро копирует число нонс и отдает другому майнеру... вот так вот))) так что должна быть другая проверка подлиннасти блока а именно проверка со сдвигом во времени. тогда ни один майнер не сможет копировать даже другой блок))))
Do you know how America steals blocks?
here's a little example... Some miner finds a block and broadcasts it to the network. american pool quickly takes this block, checks and retransmits it as his, then quickly looks for a new block that it exactly hit the network. so it works!)))
in short, quickly copies the number of nones and gives it to another miner ... that's it))) so there should be another check of block authenticity, namely, a check with a shift in time. then no miner will be able to copy even another block))))