Normalization hard fork testing and support #210

New issue

Closed

opened 2018-10-04 21:22:35 +02:00 by alyssaoc · 4 comments

alyssaoc commented

2018-10-04 21:22:35 +02:00

(Migrated from github.com)

The Issue

With the blockchain upstream and normalization changes in the upcoming hard fork,
as blockchain developer,
I want to identify as many automated and manual tests as possible so that the hard fork does not break anything.

DOD/Acceptance Criteria

Identify all interactions with the blockchain and document
Identify and document possible testing scenarios for those interactions

As a goal, we should build a test environment for repeatable testing of future changes

## The Issue With the blockchain upstream and normalization changes in the upcoming hard fork, as blockchain developer, I want to identify as many automated and manual tests as possible so that the hard fork does not break anything. ## DOD/Acceptance Criteria Identify all interactions with the blockchain and document Identify and document possible testing scenarios for those interactions As a goal, we should build a test environment for repeatable testing of future changes

kaykurokawa commented

2018-10-08 07:08:08 +02:00

(Migrated from github.com)

For Regtest :
-Increment past the fork height
-Increment past the fork height and decrement it back to before the fork height
-Increment past the fork height , and restart it , making sure that it doesn't crash and can keep incrementing blocks

For Testnet / Mainnet:
-Check that a fresh node (no blockchain data) can sync up to the hard fork height and after
-Check that a node with block chain data before the hard fork height can sync up to the hard fork height and after
-Check that a node that has synced past the hard fork height can decrement to back before the hard fork height (by using invalidateblock command)

In a fork , we must first identify the difference between the old chain and the new chain. For each test listed below, we should make sure that all the difference in the hard fork is thoroughly covered (i.e. if we are testing normalization hard fork, we must make claims that triggers normalization after the hard fork) For Regtest : -Increment past the fork height -Increment past the fork height and decrement it back to before the fork height -Increment past the fork height , and restart it , making sure that it doesn't crash and can keep incrementing blocks For Testnet / Mainnet: -Check that a fresh node (no blockchain data) can sync up to the hard fork height and after -Check that a node with block chain data before the hard fork height can sync up to the hard fork height and after -Check that a node that has synced past the hard fork height can decrement to back before the hard fork height (by using invalidateblock command)

BrannonKing commented

2018-10-11 19:54:50 +02:00

(Migrated from github.com)

For the string normalization, I've attached a document with the names that would change (as of 26 Sep 2018). It has about 53k items. The document shows a number of claims of this pattern: ak-WVyroHDWyCk. It's obviously generated data; do we really want to lowercase those?
withCaps.txt

tzarebczan commented

2018-10-11 20:21:13 +02:00

(Migrated from github.com)

I don't think we are actually changing anything to be lowercase, but instead, they will be treated as if all the characters were lowercase in the claimtrie. So it there was another claim (unlikely) at ak-wvyrohdwyck, the one with the highest bid would resolve at ak-wvyrohdwyck or ak-WVyroHDWyCk or AK-WVYROHDWYCK.

kauffj commented

2018-10-11 20:37:07 +02:00

(Migrated from github.com)

Btw @BrannonKing, claims with that pattern are from the YouTube program

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/lbrycrd#210

No description provided.