Bitcoin Basics - Discussion

Blockchain and Bitcoin 101
#167

The “Blockchain Demo” at https://andersbrownworth.com/blockchain/ is really great. I learnt a lot just following the easy explanation.

1 Like
#168

The target is programmed in the bitcoin software. The inventor (Satoshi) made bitcoin and this works so well, that we all agree on the consensus algorithm. Along the way, the community can propose changes with a BIP (bitcoin improvement proposal) then we need the majority to agree to inplement it.

The target get changed to keep an average of 10 minutes between every blocks. Miners keep guessing a number, this number when hashed with the block, the hash needs to be lower than that target. Hashes are always completely random, so it’s hard to get a hash with a bunch of zero’s in front.

1 Like
#169

Question:
Can a block hash be the same value of the difficulty target or can it only be less?

2 Likes
#170

Hi, I have not finished the blockchain 101 course jet. But I am wondering where exactly can you find your private key. I mean when you have a bitcoin wallet your computer generates a private key… and I understand how it is used. But is it visible somewhere?

1 Like
#171

Yes, in some wallets, you can export your keys. Or show bip39 mnemonic phrase.
All your keys are generated from those 12 or 24 words.
In Bitcoin core, you can also go into bitcoin-cli and export the private key only from some specific address:

dumpprivkey [your Bitcoin address here]
(this will return the private key that you can copy)

There are couple more ways as well

#172

Blockhash Must be below the target.

https://en.bitcoin.it/wiki/Target

#173

That picture is a part of a block header.
the target is a 256-bit number where a blockhash needs to be lower than this number to get accepted by the network.
Difficulty is a calculation of how difficult it is to achieve a hash below target.

Definition

How difficult it is to find a block relative to the difficulty of finding the easiest possible block. The easiest possible block has a proof-of-work difficulty of 1.

Synonyms

  • Difficulty
  • Network difficulty

Not To Be Confused With

A nice website explaining block headers:
https://learnmeabitcoin.com/guide/block-header

Here I pasted a more detailed explanation:

Block Headers

Edit | History | Report Issue | Discuss

Block headers are serialized in the 80-byte format described below and then hashed as part of Bitcoin’s proof-of-work algorithm, making the serialized header format part of the consensus rules.

Bytes Name Data Type Description
4 version int32_t The block version number indicates which set of block validation rules to follow. See the list of block versions below.
32 previous block header hash char[32] A SHA256(SHA256()) hash in internal byte order of the previous block’s header. This ensures no previous block can be changed without also changing this block’s header.
32 merkle root hash char[32] A SHA256(SHA256()) hash in internal byte order. The merkle root is derived from the hashes of all transactions included in this block, ensuring that none of those transactions can be modified without modifying the header. See the merkle trees section below.
4 time uint32_t The block time is a Unix epoch time when the miner started hashing the header (according to the miner). Must be strictly greater than the median time of the previous 11 blocks. Full nodes will not accept blocks with headers more than two hours in the future according to their clock.
4 nBits uint32_t An encoded version of the target threshold this block’s header hash must be less than or equal to. See the nBits format described below.
4 nonce uint32_t An arbitrary number miners change to modify the header hash in order to produce a hash less than or equal to the target threshold. If all 32-bit values are tested, the time can be updated or the coinbase transaction can be changed and the merkle root updated.

The hashes are in internal byte order; the other values are all in little-endian order.

An example header in hex:

02000000 ........................... Block version: 2

b6ff0b1b1680a2862a30ca44d346d9e8
910d334beb48ca0c0000000000000000 ... Hash of previous block's header
9d10aa52ee949386ca9385695f04ede2
70dda20810decd12bc9b048aaab31471 ... Merkle root

24d95a54 ........................... Unix time: 1415239972
30c31b18 ........................... Target: 0x1bc330 * 256**(0x18-3)
fe9f0864 ........................... Nonce

Block Versions

Edit | History | Report Issue | Discuss

The mechanism used for the version 2, 3, and 4 upgrades is commonly called IsSuperMajority() after the function added to Bitcoin Core to manage those soft forking changes. See BIP34 for a full description of this method.

As of this writing, a newer method called version bits is being designed to manage future soft forking changes, although it’s not known whether version 4 will be the last soft fork to use the IsSuperMajority() function. Draft BIP9 describes the version bits design as of this writing, although it is still being actively edited and may substantially change while in the draft state.

Merkle Trees

Edit | History | Report Issue | Discuss

The merkle root is constructed using all the TXIDs of transactions in this block, but first the TXIDs are placed in order as required by the consensus rules:

If a block only has a coinbase transaction, the coinbase TXID is used as the merkle root hash.

If a block only has a coinbase transaction and one other transaction, the TXIDs of those two transactions are placed in order, concatenated as 64 raw bytes, and then SHA256(SHA256()) hashed together to form the merkle root.

If a block has three or more transactions, intermediate merkle tree rows are formed. The TXIDs are placed in order and paired, starting with the coinbase transaction’s TXID. Each pair is concatenated together as 64 raw bytes and SHA256(SHA256()) hashed to form a second row of hashes. If there are an odd (non-even) number of TXIDs, the last TXID is concatenated with a copy of itself and hashed. If there are more than two hashes in the second row, the process is repeated to create a third row (and, if necessary, repeated further to create additional rows). Once a row is obtained with only two hashes, those hashes are concatenated and hashed to produce the merkle root.

Example Merkle Tree Construction

TXIDs and intermediate hashes are always in internal byte order when they’re concatenated, and the resulting merkle root is also in internal byte order when it’s placed in the block header.

Target nBits

Edit | History | Report Issue | Discuss

The target threshold is a 256-bit unsigned integer which a header hash must be equal to or below in order for that header to be a valid part of the block chain. However, the header field nBits provides only 32 bits of space, so the target number uses a less precise format called “compact” which works like a base-256 version of scientific notation:

Converting nBits Into A Target Threshold

As a base-256 number, nBits can be quickly parsed as bytes the same way you might parse a decimal number in base-10 scientific notation:

Quickly Converting nBits

Although the target threshold should be an unsigned integer, the original nBits implementation inherits properties from a signed data class, allowing the target threshold to be negative if the high bit of the significand is set. This is useless—the header hash is treated as an unsigned number, so it can never be equal to or lower than a negative target threshold. Bitcoin Core deals with this in two ways:

  • When parsing nBits, Bitcoin Core converts a negative target threshold into a target of zero, which the header hash can equal (in theory, at least).
  • When creating a value for nBits, Bitcoin Core checks to see if it will produce an nBits which will be interpreted as negative; if so, it divides the significand by 256 and increases the exponent by 1 to produce the same number with a different encoding.

Some examples taken from the Bitcoin Core test cases:

nBits Target Notes
0x01003456 0x00
0x01123456 0x12
0x02008000 0x80
0x05009234 0x92340000
0x04923456 -0x12345600 High bit set (0x80 in 0x92).
0x04123456 0x12345600 Inverse of above; no high bit.

Difficulty 1, the minimum allowed difficulty, is represented on mainnet and the current testnet by the nBits value 0x1d00ffff. Regtest mode uses a different difficulty 1 value—0x207fffff, the highest possible value below uint32_max which can be encoded; this allows near-instant building of blocks in regtest mode.

2 Likes
#174

It is blockchain demo here.
You have several simulations whether you want to test Hashing function, blocks, distributed, etc. Service.

3 Likes
#175

Hi everyone ! I have a question what is following hex code of private ? thx :slight_smile:

#176

I have just watched the lesson 7 about transactions and UTXOs and I have a question: isn’t there the risk of DDoS attacks if a person sends the same amount of BTC to himself millions of times and/or splits a transaction into millions of UTXOs (all to the thousands of wallets that he owns) so that it generates infinite recursions of transactions with millions of inputs and millions of outputs? Also a miner could theoretically flood the network if a transaction which generates an infinite recursion is processed multiple times. Does bitcoin have a protection against it? Thanks in advance

1 Like
#177

Hello Community. Hope everybody is safe. I have just concluded the mining session and I have few questions that appreciate any clarification.

  • What is the limit criteria to define when a certain chain in the block is actually the longest and does not become a stale block? There is a time or quantity of blocks limitation (maybe 6)? Because both “paths” may continue “growing”…
  • How the next miner decides which block to append? it this by network distance, preference, etc?
    Hopefully I was clear enough in my question.
#178

Cool! This demo is pretty good :slight_smile:

1 Like
#179

How could the use of transaction inputs and outputs increase privacy in a transaction? Question number 4 on the Homework on Bitcoin Transactions and UTXO is similar to this. I think I missed that part in the video I just watched. Thanks.

1 Like
#180

When your tx is put into the blockchain, being the newest of the block. Then it has 0 confirmations. When the next block has been created you have 1 confirmation, next one would be 2, the miners are continue to build on the chain which your tx is in. The more blocks/confirmation,…more secure your transaction has become. That is why it is recommended to wait for confirmations.

#181

I feel that I understand well how the security of the bitcoin blockchain is guaranteed by mining and by linking blocks by way of hashing. I also understand why it is probabilistically speaking not realistic to ever create a dishonest but formally coherent blockchain that is longer than the honest chain unless one controls a majority of the mining power. But what if it were possible to control a majority of all the nodes in the network? So far as I understand there are nodes that are miners and there are nodes that are not miners, and it is all these nodes in their entirety that are responsible for the initial consistency test that an unconfirmed transaction must pass before it can enter the mempool. So if, say, 51% of all nodes conspired to fraudulently change and to dishonestly acknowledge as valid an unconfirmed transaction in the mempool, then the PoW argument would no longer apply because the fraud would happen before a transaction is placed in a block by a miner. So is this kind of fraud impossible because there simply are too many nodes in order for anyone to ever control more than half of them? Or is there some other safety mechanism coming into play that I am not aware of?

Please let me know.

1 Like
#182

In part 21 “Orphaned and Stale Blocks…” you say the transactions that are part of the stale block are returned to the mempool. What if the good chain has them as part of their mined transactions already. I’m guessing the alg checks that they have not already been made part of the good chain before adding them back to the mempool…

#183

Can the branched chains be longer than 1 block? I’m assuming that they could be as long as 5 blocks before the network picks and propagates the winning branch because they say to wait 6 confirmations? Are their records of this happening? Do stale blocks get saved and tagged on the blockchain for logging purposes?

#184

Thank you for your answer :slight_smile:

1 Like
#185

What happens if there is another coin that out performs bitcoin? Will that coin be a replacement for it?
Another question is what is the mathematics behind cryptocurrency? I would like to see the formula just to admire it since I am a mathematician. Thank you.

#186

Just started learning about crypto in the last month and have been having lots of fun! Anyway, been trying to setup a Divi masternode to learn more about the mining process. I had no idea a Bitcoin wallet could take up to 10 days to synchronize. At least it will only take 9 more hours for this divi wallet to syncronize. It’s really cool to do a project like mining when going through the school. I am a little old school and need to see things work…

2 Likes