What is SPV mining, and how did it (inadvertently) cause the fork after BIP66 was activated?

1

SPV mining is the term commonly used for 'less-than-full-node-validation' mining. It usually means that miners skip the verification of the block and the transactions within, and immediately start mining a new block referencing the just-solved block header. However, since they don't know what is in the last block, they have to mine without any transactions (except for the coinbase transaction), to be sure that they don't mine a block with transactions that conflict with transactions in the previous block.

After BIP 66 became enforced, about 5% of the network was still solving version 2 blocks (BIP 66 enforces blocks use version number >= 3). One of the miners in this 5% solved a block with version 2, and if everyone had been doing full validation, then their block would have been ignored and replaced by a version 3 block. That is what was supposed to happen.

But, unfortunately, a few pools (F2Pool was the biggest one, I think), started mining a new block that...

0 0
2

I've been trying to understand what exactly happened in July 2015. Specifically, I can't figure out why F2Pool and AntPool mined for so long (~1 hour) on an unverified chain?

According to blockchain.info, the first orphaned block was generated at 2:09am [1], while the 6th block was generated at 3:05am [2]. This suggests that F2Pool was "SPV mining" for over an hour, which seems very risky considering they had no information about the validity of the preceding block that they built their first (invalid) block on (i.e. the block in [1]). I realize that block header timestamps could be off by a little bit, but the time should still be close to an hour, right?

Here's my understanding: I think I see how "SPV mining" can reduce orphan rates by starting to mine earlier on an empty block before verifying its predecessor. From [3] and [4], I understand that an SPV miner would mine block B on top of an unverified block header A (or hash, as in July 2015) under the assumption...

0 0
3

From BIP66:

The new rules are in effect for every block (at height H) with nVersion = 3 and at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also have nVersion = 3. Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion = 3, nVersion = 2 blocks become invalid, and all further blocks enforce the new rules.

I wrote this script to monitor the number of the last 1000 blocks that have nVersion set to 3.

require_once 'jsonRPCClient.php'; $daemon = new jsonRPCClient('http://{my_user}:{my_password}@127.0.0.1:8332/'); $blkStart = 364136 - (24 * 14 * 6); $ver3InLast1000 = 0; for ($i = $blkStart;; $i++) { try { $blockHashOld = $daemon->getblockhash($i-1000); $blockHashNew = $daemon->getblockhash($i); $blockOld = $daemon->getblock($blockHashOld); $blockNew = $daemon->getblock($blockHashNew); } catch(Exception $e) { break; } // Don't want to start subtracting until have processed 1000 blocks if...
0 0
4

View unanswered posts | View active topics It is currently Sun Nov 20, 2016 4:00 pm


BIP34 and BIP66 activated

Please take a look here:

https://forum.namecoin.info/viewtopic.php?f=2&t=2354
_________________
nx.bit

- some namecoin stats


nf.bit

- shortcut to this forum

Wed Sep 16, 2015 9:24 am


Posts: 298

Re: BIP34 and BIP66 activated

That OpenSSL consensus thread doesn't answer flound1129's most important questions:

I suspect this getauxblock issue is the reason why jedimstr, too, has problems switching from Namecoin-Qt to namecore in his P2Pool mm setup. What is the reason for the changes to getauxblock?

Wed Sep 16, 2015 3:30 pm


Posts: 1788
os: linux

Re: BIP34 and BIP66 activated

Daniel would be the one to answer this for sure, but I'm pretty sure Eligius was able to drop in...

0 0
5

Co-written by Peter Smith and Kristov Atlas

Backgrounder: Bitcoin Network Upgrades

TL;DR Summary

Soft consensus forks render previously valid blocks invalid, and create security risks for non-upgrading nodes. Hard consensus forks render previously invalid blocks valid, and make non-upgrading nodes incompatible. Unplanned forks pose the greatest risk, and are generally caused by poorly understood software complexity or rushed changes. Both soft and hard consensus forks can be used to make complex changes to bitcoin; soft forks merely require a lower amount of consensus.

Introduction

At Blockchain, we monitor both the Bitcoin network and new proposed changes to it. With the current debate on how to scale the network ongoing, we thought it would be useful to provide some background and general information.

Bitcoin is useful because people all over the world can agree on the balance of their digital wallets, discriminating between valid...

0 0
6

This document is being updated as new information arrives. Last update: 2015-07-15 13:00. All times are UTC.

Note: this situation has not been fully resolved, and it does not appear that it will be fully resolved anytime soon. Users of the affected wallets listed below are still advised to wait additional confirmations or to switch to a safer wallet.

Summary

Your bitcoins are safe if you received them in transactions confirmed before 2015-07-15 12:00 UTC.

However, there has been a problem with a planned upgrade. For bitcoins received later than the time above, confirmation scores are significantly less reliable then they usually are for users of certain software:

Lightweight (SPV) wallet users should wait an additional 30 confirmations more than you would normally wait. Electrum users, please see this note. Bitcoin Core 0.9.4 or earlier users should wait an additional 30 confirmations more than you would normally wait or upgrade to Bitcoin Core...
0 0
7

There’s a significant debate going on at the moment in the Bitcoin world; there’s a great deal of information and misinformation, and it’s hard to find a cogent summary in one place. This post is my attempt, though I already know that it will cause me even more trouble than that time I foolishly entitled a post “If you didn’t run code written by assholes, your machine wouldn’t boot”.

The Technical Background: 1MB Block Limit

The bitcoin protocol is powered by miners, who gather transactions into blocks, producing a block every 10 minutes (but it varies a lot). They get a 25 bitcoin subsidy for this, plus whatever fees are paid by those transactions. This subsidy halves every 4 years: in about 12 months it will drop to 12.5.

Full nodes on the network check transactions and blocks, and relay them to others. There are also lightweight nodes which simply listen for transactions which affect them, and trust that blocks from miners are generally OK.

A normal...

0 0
8
...
0 0
9
BIP66 soft fork

Version 2.11.0 of Groestlcoin core fixes very important common vulnerabilities and exposures (classified as CVE-2015-3641) and all users MUST upgrade to this version as soon as possible. Deamons and QT wallets that are derived from Bitcoin and have a codebase prior to Bitcoin 0.10.2 needs to address this CVE as soon as possible.

To address this CVE, Groestlcoin used the BIP66 soft fork. The majority of the Groestlcoin miners have already upgraded to the latest version of Groestlcoin Core which activated the new BIP66 consensus rule. This soft fork was a two stage process where certain thresholds have been reached, consisting of the following conditions:


Once 75% of the last 1000 blocks are version 3, strict DER encoding for signatures will be enforced when new blocks are generated, preventing non-standard transactions from being included in them. Once 95% of the last 1000 blocks are version 3, propagation of version 112 (aka 1) and version 2 blocks...
0 0
10

A softfork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid. Since old nodes will recognise the new blocks as valid, a softfork is backward-compatible. This kind of fork requires only a majority of the miners upgrading to enforce the new rules.

New transaction types can often be added as softforks, requiring only that the participants (sender and receiver) and miners understand the new transaction type. This is done by having the new transaction appear to older clients as a "pay-to-anybody" transaction (of a special form), and getting the miners to agree to reject blocks including these transaction unless the transaction validates under the new rules. This is how P2SH was added to Bitcoin.

Mechanism

Given a set of valid blocks, you can take any subset of those blocks and that subset will also, of course, all be valid. A softfork changes the rules such that only a subset of blocks that were previously valid...

0 0
11

The delayed implementation of a Bitcoin Core update by a small number of the network's miners resulted in the addition of invalid transaction blocks to the bitcoin blockchain this weekend.

The result was a fork in the network that created two versions of the bitcoin blockchain, which continued for six blocks on 4th July. An additional three invalid blocks were added to the blockchain in a repeat of the issue the following day.

As a result, Core developers issued a warning on Bitcoin.org requesting that wallet providers place increased scrutiny on incoming transactions due to the risk that funds could be double spent as a result of the discrepancy between chains.

The post, which is still live on the website, is advising these entities wait an additional 30 confirmations before considering transactions valid.

Root of the problem

At the heart of the issue is arguably the decentralized nature of the bitcoin blockchain and the degree of...

0 0
12
UPDATE: BIP66 soft fork has completed. Previously we gave warnings about the WeMineLTC pool, however they have since upgraded and are safe to use again for mining.

The majority of the Litecoin miners have upgraded to the latest version of Litecoin Core, which will activate the new BIP66 consensus rule once certain thresholds have been reached. We expect the 95% threshold value to be reached in approximately 11 hours, dependant on the variance of solving blocks within that time period.

This soft fork is a two stage process, consisting of the following conditions:

Once 75% of the last 1000 blocks are version 3, strict DER encoding for signatures will be enforced when new blocks are generated, preventing non-standard transactions from being included in them. This has already occurred. Once 95% of the last 1000 blocks are version 3, propagation of version 2 blocks will be rejected from the network entirely.This has already occurred.

You can track the progress of it...

0 0