Mining and Consensus⌗

  1. Why would some miners use parts of the version field as a nonce? What effect did this have on nodes?

    Miners have used the nonce, timestamp and coinbase transaction as sources of nonces for computing a block header for many years now. However a miner who is modifying the version field "as a nonce" is likely trying to profit from "overt ASICBOOST", rather than seeking more sources of nonce data. This would have a detrimental effect on the network as version is used to signal how a block should be decoded and processed, in addition to be used to co-ordinate upgrades.

  2. How do P2Pools work? Advantages and disadvantages? Why aren’t there any mainstream P2Pools today in the market?

    P2Pools work by creating a parallel blockchain with a lower difficulty than the main chain called the "share chain". Blocks for this chain would be valid for the main chain, if it were using a lower difficulty. When a peer finds a block, payout is calculated based on the ratio of share chain blocks found by each miner.

    1. This requires miners to keep a local full bitcoin node running and maintained, as well as a local full share-chain node running and maintained, jobs that are often not required in managed pools.

    2. There can be block size and latency issue with the share chain, which might find a block every 30 seconds or so.

    3. Share difficulty can be an issue; if the share chain uses nakamoto difficulty asjustment then, if a large miner joins, small miners would get fewer shares in the share chain and see an increased variance. At the extreme they find no shares, so you might have to split the pool up based on size.

    4. Selfish mining and 51% attacking the share chain is "easier" for a miner with a given hashrate.

  3. How far back into the past can the timestamp in blocks be? Is this validated? How can this be attacked?

    Block timestamps need to abide by two rules:

    1. Median Time Past (MTP) — must be more than the median of the last 11 blocks. Implies 6 blocks could be re-orged and time would still not move backwards.

    2. MAX_FUTURE_BLOCK_TIME — timestamp cannot be more than 2 hours in the future, relative to the median time from the nodes peers. Peer times are limited more conservatively to 90 minutes. Blocks with a timestamp too far in the future are not invalid, they can become valid as time moves forwards.

    Rule number one ensures that the blockchain continues to move forwards in time and rule number two ensures that the chain does not move too far forwards.

  4. Have we seen the difficulty retarget algorithm be manipulated in other projects? Is this a threat to Bitcoin?

    Bitcoin Cash had to introduce an Emergency Difficulty Adjustment (EDA) (algorithm) in 2017 to account for their fluctuating hash power, it was designed to decrease the mining difficulty of Bitcoin Cash by 20%, if the time difference between 6 successive blocks was greater than 12 hours.

    EDA adjustments caused instabilities in mining difficulty of the Bitcoin Cash system, resulting in Bitcoin Cash being thousands of blocks ahead of Bitcoin. To address the problem with stability, a change of the Bitcoin Cash DAA was implemented and the EDA canceled. The change took effect on 13 November 2017.

    The only annoyance this caused for Bitcoin proper was that while the DAA on Bitcoin Cash was being exploited for it’s weakness, both chains saw wild swings in mining power moving between chains, and therefore even less predictable block times than normal.

  5. In your opinion, is it a good or bad thing that specialized hardware is now needed to mine bitcoin rather than letting individual users participate in that part of the ecosystem?

    I think ASIC development, so long as there is (near) equal access to devices for all market participants, is a good development. If CPUs stayed dominant, there would be strong incentive for botnet owners and hackers to create chaos for no/minimal cost.

    With the ASIC solution, miners must expend capex on devices, then protect their investment by adhering to the protocol (and social?) rules whilst mining. This means that, generally, it costs and attacker a large amount of money to attack the chain.

    Note
    		 Some miners do sell hosted hash power available to rent on demand

    Also, I don’t believe that, with enough willpower, it’s possible to prevent Application Specific chips from being designed for any hash algorithm. For other consensus designs, I refer to ZmnSCPxj’s recent bitcoin-dev mailing list response:

    Ultimately all currency security derives from energy consumption. Everything eventually resolves down to proof-of-work.

    • Proof-of-space simply moves the work to the construction of more storage devices.

    • Proof-of-stake simply moves the work to stake-grinding attacks.

    • The optical proof-of-work simply moves the work to the construction of more miners.

    • Even government-enforced fiat is ultimately proof-of-work, as the operation and continued existence of any government is work.

    It is far better to move towards a more direct proof-of-work, than to add more complexity and come up with something that is just proof-of-work, but with the work moved off to somewhere else and with additional moving parts that can be jammed or hacked into.

    When considering any new proof-of-foo, it is best to consider all effects until you reach the base physics of the arrow of time, at which point you will realize it is ultimately just another proof-of-work anyway.

    At least, proof-of-work is honest about its consumption of resources.

    — ZmnSCPxj

  6. Consider the following scenario: Segwit2x didn’t happen (or miners didn’t throw in support for it) and UASF (BIP148) ended up causing a chain split on August 1st, 2017, with minority mining support (e.g. ~10-20%). What would likely happen as a result?

    With a minority of miners supporting UASF they would expect to mine blocks every 50 to 100 minutes on average. This would lead to long confirmation times and likely frustrate users until the next difficulty adjustment. Adjustments to the target are limited to a factor of 4 in either direction, so it would take two re-targets until the miinority chain could re-gain a 10 minute block time.

    In reality, miner profitability in conjunction with "economic use" of each system would largely determine the medium-to-long term outcome; if most economic use would perpetuated on one chain vs the other, miners might converge on that chain naturally. Alternatively (or in parallel), miner profitability might determine which chain miners move to, and if they left the minority chain it shoudl eventually cease having new blocks and die.

    In practice, we have seen two (major) hard forks in Bitcoin Cash and Bitcoin SV, both of which appear to show that, minority chains can survive in practice for much longer than expected. However it’s key to note that it would be trivial for a large Bitcoin (proper) miner to cause chaos on either of these chains at any moment, calling into question their decentralisation and longeivity.

Advances in block propagation⌗

  1. How can changes to Bitcoins p2p protocol affect mining?

    If blocks, and to a lesser extent transactions, are too slow to propagate through the p2p network, we could expect to see many short-length re-orgs which are realised in real life as "false confirmations". Miners will effectively be frequently mining on the "wrong" chain tip, wasting both their time (and profitability) and users' time spent waiting for confirmations.

  2. How is a high block-orphaning rate the best indicator that block propagation times are too high?

    Refer to week 3 paired question for more information.

  3. Alternatively, while a low block-orphaning rate can be an indicator that block propagation times are good, it could also be an indicator of something more problematic. What could be a bad reason for there to be very few orphans?

    asdf

  4. Greg Maxwell mentioned that miners are hesitant to connect with one another directly, even though it would speed up block propagation. Why?

    asdf

Compact blocks⌗

  1. How could we speed up block propagation in the network like FIBRE does, but without the drawback of having to trust others?

    asdf

  2. Compact block relay is a good way to reduce the amount of bandwidth to propagate new blocks to full nodes, but is it the fastest method for a synced node given peers may need to request missing transactions?

    asdf

Relay networks and FIBRE⌗

  1. How does the FIBRE network work and what were the motivations to iterate on the original Relay Network?

    asdf

Mining: No Good, The Bad, and The Ugly⌗

What is a BGP Hijack attack? What prevents it?

asdf

Why not encrypt all communications with pool operators?

asdf

Majority is not enough⌗

  1. What is the 'Selfish Mining' attack? How does it work? Is it a real threat?

    asdf

  2. Is it possible to identify and ignore a Selfish Miner’s chain? Must we follow the most-work chain even if we identify that it came from a selfish miner?

    asdf

Mining pools⌗

  1. How do pools give work assignments to client miners? Do all miners search the same block candidates?

    asdf

  2. What are 'shares' and how do they help facilitate pooled mining?

    asdf

Overview of the covert ASICBOOST allegation⌗

  1. What is the difference between overt and covert ASICBOOST?

    asdf