Enforce mandatory softfork flags for segwit block/tx #8635

Open
wants to merge 1 commit into
from

Conversation

Projects
None yet
8 participants
Member

jl2012 commented Aug 31, 2016

(untested) If a node is able to relay a block/tx with witness, it must know all existing script softfork rules: BIP66, 65, 112, 141, 143. All related verify flags should be mandatory for such blocks/txs

@sipa sipa commented on an outdated diff Sep 5, 2016

@@ -2405,6 +2408,11 @@ bool ConnectBlock(const CBlock& block, CValidationState& state, CBlockIndex* pin
std::vector<std::pair<uint256, CDiskTxPos> > vPos;
vPos.reserve(block.vtx.size());
blockundo.vtxundo.reserve(block.vtx.size() - 1);
+ bool fHaveWitness = false;
@sipa

sipa Sep 5, 2016

Owner

I believe this is harmless in this specific case, but not necessary, and makes reasoning about forking risks much harder. The flags enabled for block validation should purely depend on consensus rules.

@sipa

sipa Sep 5, 2016

Owner

Actually, this shouldn't even have any effect. Since flags in the call to CheckInputs below only contains consensus flags, it should never overlap with STANDARD_NOT_MANDATORY_SEGWIT_VERIFY_FLAGS.

@sipa sipa commented on an outdated diff Sep 5, 2016

// SCRIPT_VERIFY_CLEANSTACK requires SCRIPT_VERIFY_WITNESS, so we
// need to turn both off, and compare against just turning off CLEANSTACK
// to see if the failure is specifically due to witness validation.
- if (CheckInputs(tx, state, view, true, scriptVerifyFlags & ~(SCRIPT_VERIFY_WITNESS | SCRIPT_VERIFY_CLEANSTACK), true) &&
- !CheckInputs(tx, state, view, true, scriptVerifyFlags & ~SCRIPT_VERIFY_CLEANSTACK, true)) {
+ if (CheckInputs(tx, state, view, true, scriptVerifyFlags & ~(SCRIPT_VERIFY_WITNESS | SCRIPT_VERIFY_CLEANSTACK), true, NULL, fHaveWitness) &&
@sipa

sipa Sep 5, 2016

Owner

This piece of code is removed in #8525. It may be worth it to rebase on top of that, to reduce the changes?

Member

jl2012 commented Sep 8, 2016

Rebased and removed the codes for block validation

Member

jl2012 commented Sep 8, 2016

Is this a target of 0.13.1?

laanwj added this to the 0.13.1 milestone Sep 8, 2016

Member

instagibbs commented Sep 12, 2016

Looks like you snagged a couple commits from another PR in here. That intentional?

Following this logic, any follow-up softfork from Core codebase would assume previous softforks will be followed then?

Member

jl2012 commented Sep 12, 2016

@instagibbs I just rebased on top of that PR. It was not merged at that time. Should I rebase again?

This one is special. Since segwit is a completely new tx format, there is no excuse for not respecting any known softforks, which have been enforced for months.

Following this logic, it should have been mandatory for version 2 transactions to follow all existing softforks (expect segwit), since no one should produce or relay v2 tx without knowing BIP68.

However, before the CSV softfork, we couldn't simply enforce mandatory flags since no change had been made in transaction version or format.

jonasschnelli removed this from the 0.13.1 milestone Sep 15, 2016

Contributor

TheBlueMatt commented Jul 11, 2017

Needs rebase. Not sure what the real value of this is, though...why is it a serious offense to relay such blocks? (we'd need careful to avoid any potential network-splitting issues with compact-fast-relay).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment