TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

[vuli]

Nothing happens, well no error, it just clear everything out.
I am using QT, desktop version. Unless I am doing smth wrong.

2019-04-11 16:59:19 WalletModel::CreateDiaryEntry::Creating diary entry ... DIARY ENTRY : HELLO WORLD OF BIBLE Received a GET request for / from 202.97.251.157:46264
2019-04-11 16:59:33 ProcessMessages(version, 109 bytes) FAILED peer=8360
2019-04-11 16:59:39 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 25553 fInitialDownload=0
2019-04-11 16:59:39 UpdateTip: new best=0368d885bd5aa5517ede5ff01bf470a270ad63e79df5154f3e2d39cb960e744a height=25553 version=0x20000001 log2_work=44.48151079 tx=81668 date='2019-04-11 16:59:28' progress=0.999999 cache=0.0MiB(0txo)
2019-04-11 16:59:39 {PNB}: ACC 
block rejected.CreateNewBlock() packages: 0.00ms (0 packages, 0 updated descendants), validity: 0.00ms (total 0.00ms)
2019-04-11 16:59:41  ABN OK: 1.000000 CreateNewBlock() packages: 0.00ms (0 packages, 0 updated descendants), validity: 0.00ms (total 0.00ms)
2019-04-11 16:59:44  ABN OK: 1.000000 CMasternodeMan::CheckAndRemove -- mMnbRecoveryGoodReplies size=0
2019-04-11 16:59:46 CreateNewBlock() packages: 0.00ms (0 packages, 0 updated descendants), validity: 0.00ms (total 0.00ms)
2019-04-11 16:59:46  ABN OK: 1.000000

[Rob Andrews]

Nothing happens, well no error, it just clear everything out.
I am using QT, desktop version. Unless I am doing smth wrong.

I have a different hash for 25553.  I am pretty sure some nodes banned each other (due to the mandatory), could you please rm chainstate -r rm evodb -r rm blocks -r rm banlist.dat, and resync and see if your hash matches the one from a few blocks earlier - then please retry the tx? 

Then also see if you can scrape the txid out of the transaction double click, and also, it should have the diary entry at the very end of the window.

I think we are on this blockhash :

09:03:54

getblockhash 25354


09:03:54

72887c9dec86fe2cc3c97ef7caa3691505c81adbb021af177fd34088c72fdbfd

[vuli]

this one is the sameon my side :

20:16:32

getblockhash 25354


20:16:32

72887c9dec86fe2cc3c97ef7caa3691505c81adbb021af177fd34088c72fdbfd

[Rob Andrews]

this one is the sameon my side :

20:16:32

getblockhash 25354


20:16:32

72887c9dec86fe2cc3c97ef7caa3691505c81adbb021af177fd34088c72fdbfd

But when you pasted your log it shows a bad hash here:

2019-04-11 16:59:39 UpdateTip: new best=0368d885bd5aa5517ede5ff01bf470a270ad63e79df5154f3e2d39cb960e744a height=25553 version=0x20000001 log2_work=44.48151079 tx=81668 date='2019-04-11 1

Did you resync just now?

[Rob Andrews]

We will have to be a little patient as we have most likely Slovakia playing games - the diff is 20 now in prod and chain is reorging. 

Im sure it has nothing to do with Evo or the latest version, because the mandatory height hasn't hit yet.

I see we rolled back when this person who tithes 666.66 hit us with big hash.

[oncoapop]

Seems that all my sanc are went out of sync and are unable to sync up to that block. Stuck at 23234 when I initially got one sanc to sync with your 3 even after resync.

isn't the ABN feature supposed to prevent these sorts of attacks? Please help me understand in layperson terms what is happening and how did that bypass ABN?

Thank you.

[Rob Andrews]

Seems that all my sanc are went out of sync and are unable to sync up to that block. Stuck at 23234 when I initially got one sanc to sync with your 3 even after resync.

isn't the ABN feature supposed to prevent these sorts of attacks? Please help me understand in layperson terms what is happening and how did that bypass ABN?

Thank you.

1) We had synced from 23234 up to about 23336 but with a difficulty of .10 (IE very low).
The wallet will reorganize back to 23234 if it finds a chain with greater total chain work (which is possible since 23234 had a diff of 20.)

(As long as the re-org block is valid).

2) ABN tries to prevent single rich kiddies (IE someone who has 20 servers) from solving an inordinate amount of blocks personally.  It does this by using up their coin-age.  But in testnet this 20 diff could come from a few high powered machines, although more likely 4-5 miners running full speed right up to that block (so you are correct abn might have helped, but in testnet everyone has a lot of coin age also).

2a.  We actually don't have ABN turned on right now , I disabled it so we can test one feature at a time.  I planned on enabling qt next then abn later, but now we have to figure out this sync problem first.

3.  I am also rolled back to 23234 right now, so you are experiencing the same thing as me (another words the hash I posted is no longer valid).

Ill do some poking around.  We probably need to turn up our miners to more threads to solve the next block.

[oncoapop]

1) We had synced from 23234 up to about 23336 but with a difficulty of .10 (IE very low).
The wallet will reorganize back to 23234 if it finds a chain with greater total chain work (which is possible since 23234 had a diff of 20.)

(As long as the re-org block is valid).

2) ABN tries to prevent single rich kiddies (IE someone who has 20 servers) from solving an inordinate amount of blocks personally.  It does this by using up their coin-age.  But in testnet this 20 diff could come from a few high powered machines, although more likely 4-5 miners running full speed right up to that block (so you are correct abn might have helped, but in testnet everyone has a lot of coin age also).

2a.  We actually don't have ABN turned on right now , I disabled it so we can test one feature at a time.  I planned on enabling qt next then abn later, but now we have to figure out this sync problem first.

3.  I am also rolled back to 23234 right now, so you are experiencing the same thing as me (another words the hash I posted is no longer valid).

Ill do some poking around.  We probably need to turn up our miners to more threads to solve the next block.

Ok thank you for that explanation!  We seem to be moving along.

[vuli]

thats why I am stuck at 25237 after re-sync.
019-04-11 19:45:03 SPORK -- hash: 00f31f1feb64a49df40213e52e3e3ce2191e6f19f6241a1740043f08efdb1ba6 id: 10011 value:          0 bestHeight: 25237 peer=436 seen
2019-04-11 19:45:03 SPORK -- hash: 644278d68318691dc8f02c6f714a12eaf27a63764caf590fc8aaeb6118725051 id: 10090 value:          0 bestHeight: 25237 peer=436 seen
2019-04-11 19:45:27 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 25237 peer=5 seen
2019-04-11 19:45:27 SPORK -- hash: 00f31f1feb64a49df40213e52e3e3ce2191e6f19f6241a1740043f08efdb1ba6 id: 10011 value:          0 bestHeight: 25237 peer=5 seen
2019-04-11 19:45:27 SPORK -- hash: 644278d68318691dc8f02c6f714a12eaf27a63764caf590fc8aaeb6118725051 id: 10090 value:          0 bestHeight: 25237 peer=5 seen
2019-04-11 19:45:27 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 25237 peer=6 seen
2019-04-11 19:45:27 SPORK -- hash: 00f31f1feb64a49df40213e52e3e3ce2191e6f19f6241a1740043f08efdb1ba6 id: 10011 value:          0 bestHeight: 25237 peer=6 seen
2019-04-11 19:45:27 SPORK -- hash: 644278d68318691dc8f02c6f714a12eaf27a63764caf590fc8aaeb6118725051 id: 10090 value:          0 bestHeight: 25237 peer=6 seen
2019-04-11 19:45:29 ProcessMessages(version, 109 bytes) FAILED peer=558
2019-04-11 19:45:29 ProcessMessages(version, 109 bytes) FAILED peer=559
2019-04-11 19:45:33 ProcessMessages(version, 109 bytes) FAILED peer=561
2019-04-11 19:45:39 ProcessMessages(version, 109 bytes) FAILED peer=562
2019-04-11 19:45:41 ProcessMessages(version, 109 bytes) FAILED peer=563
2019-04-11 19:45:42 ProcessMessages(version, 109 bytes) FAILED peer=564
2019-04-11 19:46:17 ProcessMessages(version, 109 bytes) FAILED peer=565
2019-04-11 19:46:24 ProcessMessages(version, 109 bytes) FAILED peer=566
2019-04-11 19:47:07 ProcessMessages(version, 109 bytes) FAILED peer=568
2019-04-11 19:47:19 ProcessMessages(version, 109 bytes) FAILED peer=569
2019-04-11 19:47:22 ProcessMessages(version, 109 bytes) FAILED peer=570
2019-04-11 19:47:52 ProcessMessages(version, 109 bytes) FAILED peer=571
2019-04-11 19:47:53 ProcessMessages(version, 109 bytes) FAILED peer=572

[vuli]

But when you pasted your log it shows a bad hash here:

2019-04-11 16:59:39 UpdateTip: new best=0368d885bd5aa5517ede5ff01bf470a270ad63e79df5154f3e2d39cb960e744a height=25553 version=0x20000001 log2_work=44.48151079 tx=81668 date='2019-04-11 1

Did you resync just now?

Now I am resyncing.
Did I forked after 25354?

[Rob Andrews]

thats why I am stuck at 25237 after re-sync.
019-04-11 19:45:03 SPORK -- hash: 00f31f1feb64a49df40213e52e3e3ce2191e6f19f6241a1740043f08efdb1ba6 id: 10011 value:          0 bestHeight: 25237 peer=436 seen
2019-04-11 19:45:03 SPORK -- hash: 644278d68318691dc8f02c6f714a12eaf27a63764caf590fc8aaeb6118725051 id: 10090 value:          0 bestHeight: 25237 peer=436 seen
2019-04-11 19:45:27 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 25237 peer=5 seen
2019-04-11 19:45:27 SPORK -- hash: 00f31f1feb64a49df40213e52e3e3ce2191e6f19f6241a1740043f08efdb1ba6 id: 10011 value:          0 bestHeight: 25237 peer=5 seen
2019-04-11 19:45:27 SPORK -- hash: 644278d68318691dc8f02c6f714a12eaf27a63764caf590fc8aaeb6118725051 id: 10090 value:          0 bestHeight: 25237 peer=5 seen
2019-04-11 19:45:27 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 25237 peer=6 seen
2019-04-11 19:45:27 SPORK -- hash: 00f31f1feb64a49df40213e52e3e3ce2191e6f19f6241a1740043f08efdb1ba6 id: 10011 value:          0 bestHeight: 25237 peer=6 seen
2019-04-11 19:45:27 SPORK -- hash: 644278d68318691dc8f02c6f714a12eaf27a63764caf590fc8aaeb6118725051 id: 10090 value:          0 bestHeight: 25237 peer=6 seen
2019-04-11 19:45:29 ProcessMessages(version, 109 bytes) FAILED peer=558
2019-04-11 19:45:29 ProcessMessages(version, 109 bytes) FAILED peer=559
2019-04-11 19:45:33 ProcessMessages(version, 109 bytes) FAILED peer=561
2019-04-11 19:45:39 ProcessMessages(version, 109 bytes) FAILED peer=562
2019-04-11 19:45:41 ProcessMessages(version, 109 bytes) FAILED peer=563
2019-04-11 19:45:42 ProcessMessages(version, 109 bytes) FAILED peer=564
2019-04-11 19:46:17 ProcessMessages(version, 109 bytes) FAILED peer=565
2019-04-11 19:46:24 ProcessMessages(version, 109 bytes) FAILED peer=566
2019-04-11 19:47:07 ProcessMessages(version, 109 bytes) FAILED peer=568
2019-04-11 19:47:19 ProcessMessages(version, 109 bytes) FAILED peer=569
2019-04-11 19:47:22 ProcessMessages(version, 109 bytes) FAILED peer=570
2019-04-11 19:47:52 ProcessMessages(version, 109 bytes) FAILED peer=571
2019-04-11 19:47:53 ProcessMessages(version, 109 bytes) FAILED peer=572

The failed messages just mean we hang up on peers less than our version (they have not upgraded yet).

We solved about 5 more blocks after the 20 diff block, but Im still waiting for warnings to clear.

I think everything is ok, but lets solve a few more and let the warnings clear first then we can try another diary entry.

[vuli]

emm, I have differnet hash on that block like yesterday-

10:31:55

getblockhash 25354

10:31:55

ce7fbfd5dfbab275f35984dac4b447db7866d1bd38eac7c19010764b1f603085

[Rob Andrews]

emm, I have differnet hash on that block like yesterday-

10:31:55

getblockhash 25354

10:31:55

ce7fbfd5dfbab275f35984dac4b447db7866d1bd38eac7c19010764b1f603085

Yes, that matches mine, that is normal, we were reorganizing when I posted that hash yesterday and everyone was upgrading.

[Rob Andrews]

1.4.1.6-Mandatory Upgrade for TestNet

- Limit nickname length to 10 characters

[Rob Andrews]

Btw, our last Monthly governance superblock did pay out the rewards correctly.

I see someone has in an orphan sanctuary proposal, good, please monitor it to make sure it pays (and you receive the payment) when 27265 occurs.
I will enter a few more proposals now, but lets ensure we vote your Orphan Sanc up, and monitor the highest votes descending are included for payment.