Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
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.
I think things are OK on the back end, but we might need another field - but first whats your sanc Ip, I can check some things to make sure I see your vote?
Btw, no - you should not have to vote manually, this is all automatic.
** Update **
So for the last few re-releases the common theme has been:
- No signs of a problem with abn weight, or gsc client side transactions, or creation of the pog points
- No signs of problems with actual POBH heat mining (IE no forks resulting from POW)
- No signs of problems on the *monthly* superblock budget system or its creation of budget data
- Every re-release so far and enhancement resulted from a problem related to the Daily superblock contract
(not a problem with the actual contract, a problem with the sancs not *finding* the contract, some find it, some lose it)
So I've been trying to hone in on this for the last 2 days - because at first I believed running only 3 sancs meant that one sanc out of 3 was not syncing properly- so we added rules to strengthen the minimum requirements of the voting required for a superblock to pass. Yesterday however, all 3 sancs could see the votes on the superblock (we had 4), but only 2 of them had the actual gobject in memory (that is obviously a problem).
Let me explain this a different way, so we can all understand how a soft consensus can still fork the chain in testnet.
Sanc #1 and Sanc #2 had the gobject in memory (this is the GSC contract with its payments and addresses). Sanc 1,2,and 3 had the *vote* for the gobject in memory and they all agreed the superblock was good and should pass.
Here is what happened on block 6990:
Sanc #1 found both the gobject and the trigger votes, and it said: Valid, accepted
Sanc #2 found the votes only, and said "valid superblock at this height" but actually rejected the block because: IsBlockValueValid, too few superblock payments <-- this is because it was missing the gobject with the hex data
So lets see what happens; Sanc #2 goes on its own chain now, Sanc 1 and 3 continue on the chain with the higher work. This actually splits the testnet network because now Sanctuary votes for 1 cause (mnpayments to decrease), IE do to our mnpayments relying on chainheights- this becomes a hard split - and in a small
testnet network we cant have this, so therefore we have to fix the root of the problem.
This ends up causing a hard fork, because #2 will never re-correct its view of this block until completely resynced as it has now marked the block as a fail.
First, lets stop testing again until I can release a plan to fix this.
(It does not appear to be watchman).
It appears to be more of a timing issue. In Dash, the gobjects are synced over a longer time span (as we normally have a month to get all the data for the monthly votes), but in our case, we are trying to sync (with 2 minute blocks) all the superblock data within 190 blocks (IE < 3 hours)-- so I can see if one sanc misses a gobject, its going to make a bad call on the next superblock.
So, my plan is this next:
1. I will investigate all code that syncs gobjects, and see if we are lacking something (Ie timing issues) and beef this up
2. I will do something special to allow us to Monitor the next daily gsc superblock, like a command line that will alert us that a node is going to make a bad call on the next block
3. We will make the sanc go out of its way to Pull the data it needs to make a good call on the block manually
Then we regroup here and do an in-depth analysis on the actual superblock heights as they are about to tick by and post something on the forum to see what the state of each one is as they occur.
Please hang on for the next version, it might take a day, it might take less depending on how complex the timing issue is.
1.4.0.8-TestNet Mandatory Upgrade
- Add Watchman On the Wall (BiblePay version)
- Modify Sanctuary IsSuperblockValid trigger rule to trigger when
fCachedFunding is set
- Add rpc command 'getpogpoints' (this shows the pog points for a
transaction)
If you send some tBBP, I can set up a sanc, if needed. or else, will just roll in testnet with zero.
yMSnfBPVTqdstm2grmztDxmxqkLdPzJCJG
Thanks!
So, I don't want to release an official testnet release until this superblock issue is tested, but I will release an alpha tonight for the brave users.
Anyone who feels like jumping in early can upgrade (after I post the release version in about 30 mins), testing is purely to help us reach block 5000.
If everything goes well we can stay on the chain.
NOTE: It is Extremely important to follow these directions before you upgrade:
cd testnet3
rm blocks -r
rm chainstate -r
rm evodb -r
rm mnc*
rm mnp*
rm gov*
cd ../SAN
rm pra* <-- Extremely important, you must remove the prayers file, as it contains cached campaign data that must be removed for testing to be successful
optional: rm testnet wallet.dat (this will just clean up the txlist and make it a smaller file.)
In this version, we needed to reset the chain again, primarily because of a change I made to DGW for testnet (to clean it up while our engine is on the floor).
So this means we also have to re-create our sancs.
I've recreated 3 new sancs in the cloud this time for more reliability, and we are synced up to block 2266 so far.
Linux users, you can get the latest now if you want, or wait until the alpha test is finished.
Remember we also must recreate our CPK (exec cpk nickname), and (exec join pog).
EDIT:
Ill need to release a mandatory upgrade tomorrow morning to ensure everyone is on the same chain. We have too many old versions floating around.
As you upgrade each node, please re-sync. You could be on your own chain (as this was a mandatory) and it was not released with a cutover height.
Also, someone can test Adding a fake proposal, and once it is in the chain and list, then vote on the proposal.
It may be annoying but posting the link is helpful if you don't mind
Ok, I just realized you were testing this from the Pool.
(You dont have to test the pool, as I know that part works - although yes we should test Evo against the pool a little later for sanity sake but I dont have the pool daemon pointed to Evo yet).
But yeah I would like to test Adding a proposal through the QT wallet, and voting on a proposal.
(I added a couple to the qt wallet and was able to vote on them but more eyes are better).