Closed skironDotNet closed 2 years ago
I'm starting to regret I got involved into this project especially for $4.5 ... here is help section
-assumevalid=<hex> If this block is in the chain assume that it and its ancestors are valid and potentially skip their script verification (0 to verify all, default: 50aff78270725ec253a722ec18069deb233f2e57eb7d64479f027141619cdda4, testnet: 3825896ac39b8b27220e7bfaed81c5f979ca11dc874e564c5e70756ad06077b0)
so I ran firod -assumevalid=acb9aa643db075676992df8328f863888d34f046a8c74d74ca234148ad9d7d10
and it's still invalid. Reindexed chain, still nothing. how come there is 22 peers in the network? how is this chain even spinning? thanks to PoW miners?
yeah yeah Mr. Dumbfvck _$4.5 @skironDotNet
have fun to ask some kindly help this way to sync your late updated node with the new Lelantus anonymity set.
Check if you are running the latest version which is at this time is v0.14.11.1. If you are on 0.14.11.1 and are stuck at 513614, please reindex and delete banlist.dat to allow for connections from other v0.14.11.1 nodes.
how come there is 22 peers in the network? how is this chain even spinning? thanks to PoW miners?
As written on the page, this block explorer only shows the nodes it saw for the past 24 hours, not how many nodes there are on the network. Your local wallet by default only connects and shows 8 nodes, doesn't mean there's only 8 nodes on the network.
@gernoox as for calling me Mr. Dumbfvck, if last chain number is 513614 (even if magically it has more blocks on top) and that block in old client is valid acb9aa643db075676992df8328f863888d34f046a8c74d74ca234148ad9d7d10 and in public explorer is same, I see no reason why client software would not be smart to keep continue, and even if magically it has more blocks on top of it, Barkley DB is not write only, but let say it is, what the problem, is start reading blocks from 0 (let say -reindex) go to last valid block, and write new valid blocks on top of it. And this is not about FIRO, I just can't understand how it was never solved in any project starting with BTC, although I think some projects this days can invalidate some last X number of block specified by the user, and start downloading from prev block.
And lastly to avoid above, why not to take action in software `if new client visible in the network, shutdown" with log saying why. This could bring the whole network down, but there must be a way to notify people without them being on Discord all the time. ZEC can shutdown early. Generally would be nice to have a protection against downloading wrong chain, or ability to revert later.
Feel free to close this ticket
I was trying to be smart about it, and I deleted 2 top most blk and rev files, and index folder and chainstate, and did reindex, saving 60GB of download, and it did work, just took the client some time to pick up