No Blocks in 2 Days? [Serious]

by Brown, Saturday, August 29, 2020, 18:19 (463 days ago) @ Brown

I hate to be the bearer of bad news, but the current inability to stake a block is due to a serious bug. There actually is no possible valid successor block to the latest block.

There's a bug with the computation of propositions for the reward bounties that causes some (16 apparently) propositions to get generated repeatedly. Until today I thought the probability of generating the same propositions was extremely low, and it does seem like this was the intention. Generating the same proposition more than once is not the end of the world, it just means multiple bounties get put onto it. However, there is a limit of 32 on the total number of assets that can be held at an address, and bounties technically count as assets. Two proposition addresses now have 32 bounties on them:

TMR5rhXMF2Aa6iws9ccofrfWsUrKgDU6EdN
TMMZYuzwYGxKG4d78SDkLhvVkLmK4B57qJr

It is now illegal to add any more bounties to either of these. Based on the Litecoin information associated with the latest Proofgold block, the next Proofgold block must put a new reward bounty onto TMR5rhXMF2Aa6iws9ccofrfWsUrKgDU6EdN. Since this is impossible, there is no possible valid successor block.

If you want to verify that would be the next reward bounty address, you can call rewardbountyprop with the Litecoin blockid and Litecoin txid of the last Proofgold burn:

rewardbountyprop a4a48955c1eeea9fec3d87ee9d09f1101c5dca7daa88211e5321a7e092a0ed92 506637ad1545d85d6ac508611e3ecfd64b0825903d6d9d0a446778cd042b0354

There is a way forward, but it isn't good. Someone (like me) can call "invalidateblock " on the latest block and start staking on the previous block (orphaning the latest block). Then at least one node (like mine) would continue to orphan blocks in the future that repeat this situation. Right now that would only be about 2% of blocks, but very soon it will be 18% of blocks (since the other 14 of the 16 propositions are close to 32 bounties already). I don't think orphaning 18% of blocks is acceptable, but I can't see a way around it without doing a hard fork.

If no one else uses invalidateblock by tomorrow (Sunday August 30 2020 at Noon UTC), then I will do it, but I will stake blocks sparingly to try to minimize orphans until there's some decision about what to do. I recommend either stopping staking or at least set put this into your proofgold.conf file:

maxburn=0

This will at least prevent you from burning litecoins to get a Proofgold block that may be orphaned.

Here is the actual bug. It's in the function sei_poly3 in checker.ml. This function is used to generate a polynomial for Diophantine and Diophantine Modulo problems. The problem is specifically in the following code:

for x = 0 to 3 do
for y = 0 to 3 do
for z = 0 to 3 do
let (b,c) = i 4 c in
update_p b x y z
done
done
done;

In context the idea from reading the code is clear: use 4 bits from the 'c' variable to create coefficients ranging from 0 to 15 for monomials of the form x^i * y^j * z^k where i,j,k range from 0 to 3. However, this is functional programming, and so the reference to 'c' in "i 4 c" is always the same "c". The "c" in (b,c) is never used. As a result, it keeps reusing the same 4 bits for every coefficient.

In other places in the code this is handled correctly, e.g., in sei_abstr_hf_prop in checker.ml. The relevant part of the code there looks as follows:

let cr = ref c in
for j = 1228 downto 0 do
if not (j = concl) then
let (b,c) = i 4 (!cr) in
cr := c;
if b = 0 then p := Imp(ahfprops.(j),!p)
done;

The ref cr is used to update the c value after using some bits, and then the updated value is used the next time. The same idea could be used to fix sei_poly3. This fix would definitely be a hard fork though.