fake TX & died

[piratoskratos]

Hello. My core seems died since your lasts updates. I got some fake TX on my addresses, all of 150 pink which I can't invalidate (invalidate rpc seems not working) and he's stuck on 608555 height)

Need a full resync? What can I do?

[PinkDev]

Hello,

You're on a fork. Our explorer shows the correct chain: https://chainz.cryptoid.info/pink/. Please make sure you're running v2.2.0.3, make sure Pinkcoin is fully closed, and delete everything but your stake.dat and wallet.dat. If you're running windows, that folder is in %appdata%/Pink2. On linux it's $HOME/.pink2, and on mac it's ~/Library/Application Support/Pink2. Create a new pinkconf.txt file (temporarily move the one you already have if you're using one) and in it put the following:

connect=explorer.pinkarmy.ml connect=frankfurt.pinkarmy.ml connect=sydney.pinkarmy.ml connect=tokyo.pinkarmy.ml

Then save it.

Then you can go to https://getstarted.with.pink/download/ to download the bootstrap, and unzip it to the data dir I had you delete those files from. Then start Pinkcoin and it will sync to the proper chain. When it is fully sync'd, you can delete your pinkconf.txt and if you had one before, you can put it back as it was. Then restart pink and you should have no further trouble.

On Sat, Sep 22, 2018 at 12:41 PM piratoskratos notifications@github.com wrote:

Hello. My core seems died since your lasts updates. I got some fake TX on my addresses, all of 150 pink which I can't invalidate (invalidate rpc seems not working) and he's stuck on 608555 height)

Need a full resync? What can I do?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Pink2Dev/Pink2/issues/13, or mute the thread https://github.com/notifications/unsubscribe-auth/AHRXjyhBFOLsMIX8GZJLJuHvm1Q_Ezghks5udpJLgaJpZM4W1aYf .

[Scalextrix]

FYI I got on a fork as well, will slow sync work on 2.2.0.3?

[piratoskratos]

Yes I'm on 2.2.0.3. Full resync works. Thanks for your fast reply.

[PinkDev]

Absolutely. It is worth trying to just update to 2.2.0.3 and see if that sets you on the right chain if you haven't already. But yeah, a full sync from scratch works just fine.

On Sun, Sep 23, 2018 at 1:59 AM Steven Campbell notifications@github.com wrote:

FYI I got on a fork as well, will slow sync work on 2.2.0.3?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Pink2Dev/Pink2/issues/13#issuecomment-423801884, or mute the thread https://github.com/notifications/unsubscribe-auth/AHRXj8EeWVi2L7VWskuk-T7hEzkYi-Bmks5ud02MgaJpZM4W1aYf .

[piratoskratos]

I'm on 2.2.10 and now it's stuck on 652190 block. debug.log is like :

ProcessSyncCheckpoint: pending for sync-checkpoint 00000000001d7637dc3f0a6581629bde886132b4f6e890a04c46d58b63b5e018
ERROR: FetchInputs() : 71ca8cfc3c mempool Tx prev not found 9bb508b140
stored orphan tx 71ca8cfc3c (mapsz 14)
ERROR: FetchInputs() : 10ff76ef69 mempool Tx prev not found be09edd1e6
stored orphan tx 10ff76ef69 (mapsz 15)
ProcessBlock: ORPHAN BLOCK, orphan=4f0a421f6abd5ca7cba89c2f28f1728d82e923f2f42ec7be53ef329372d99fb0 prev=000000000014e0cc393cdc9bb786b164a362f23a5e5486dafc2864f8e64da419
ProcessBlock: ORPHAN BLOCK, orphan=f49c84ff5ee381ee4ecfdd8cf08ce91b250b17b302b18b14a1decf7a74068f9a prev=3b448b2990d88cbf1c443c1afeb7dd85ea6d5e1651356666c858b19a98b2c991
Could not get transaction for hash: 891a220eccee8aa2ee093dee23b10ac982f101b6250a78933aa919008222ee7c.
ERROR: ProcessBlock() : already have block (orphan) 4f0a421f6abd5ca7cba8
ProcessBlock: ORPHAN BLOCK, orphan=664f40152edcfc165f761be5e0fb980d87d11f59b53d3ed76bdccc4ee465f142 prev=efc219ffff178b2482a31766985e3b2b8f5c265e6001038d806ad85329fde7d0
ERROR: FetchInputs() : 14bc1b0b02 mempool Tx prev not found 6f6351a750
stored orphan tx 14bc1b0b02 (mapsz 16)
ProcessBlock: ORPHAN BLOCK, orphan=d9d82e913565d6f655af48c168a77374cb603b3fd29d6375d6d5097dd3bb6c66 prev=664f40152edcfc165f761be5e0fb980d87d11f59b53d3ed76bdccc4ee465f142
ERROR: FetchInputs() : 0299e141e6 mempool Tx prev not found 8e2b394781
stored orphan tx 0299e141e6 (mapsz 17)
connect() failed after select(): No route to host
Flushed 2606 addresses to peers.dat  43ms
connected 109.195.84.189:9134
send version message: version 60016, blocks=652190,....

EDIT : After another full sync, it's ok but; I won't make a full sync every weeks...

[Scalextrix]

Im not seeing that issue on a Linux daemon built from source, but I dont seem to be staking at all on 2.2.1.0

[aistrych]

@Scalextrix How many coins do you have and how big are your UTXOs? @piratoskratos Just update from scratch if you haven't yet. It's known behaviour for some specific circumstances. Nothing to worry about.

[Scalextrix]

@Astrych Im not a large stakeholder, have 30K+ coins, but usually stake every 10 days, its over 30 days now and all my coin weight is maxed out, most UTXOs are between 1-2k

[aistrych]

@Scalextrix Well, due to the new FPoS 2.0 mechanism all flash stakes are unavailable to you (FPoS staking require 100k+ UTXOs now). FPoS is like 220 blocks (150 coins each) per day and PoS is around 200 blocks (100 coins each) per day. That change should be balanced by total network weight drop (people moving to stake FPoS spend they weight faster) but it's still more profitable to stake FPoS so not enough people moved yet. I think that may be the main reason. Have you staked at all after FPoS 2.0 has started?

[Scalextrix]

@Astrych looks like I might have staked once or twice since that came in, it's clearly got a lot harder with the change you described which I had not realised. EDIT: Looking at my history before Sept 30th (FPOS 2.0 cutover I think) most of my stakes were FPOS with just the odd POS one. Since then I did have a couple of POS blocks but clearly thats the reason.

[Scalextrix]

@Astrych Just reading some more about the changes and Im not sure FPOS2.0 will realise better POS staking for smallholders. I get the idea that big holders might accumulate their coins into 100k+ UTXOs then use up all their stake-time getting the FPOS blocks, which then theoretically leaves POS for smaller holders. As you said it doesnt seem to have happened yet. Perhaps a scheme where the wallet auto-combines/splits UTXOs would help the transition?

EDIT: Something like: IF UTXO in address A stakes AND IF Address A contians >= 100k PINK AND IF Address A contains other UTXOs < 7 days accumulated coin weight THEN combine UTXOs with < 7 days weight to the UTXO that staked

Of course the whole problem for larger holders is any method of combining UTXOs causes them to lose coin weight, my method at least keeps it minimized to 1 week,

[aistrych]

@Scalextrix Well, number of UTXOs has dropped a little bit (first chart): https://github.com/Astrych/pink-stats/blob/master/Pinkcoin_UTXOs_and_addresses_statistics.ipynb Not enough yet but I'm sure it will drop more. Average PoS difficulty dropped also (second chart): https://github.com/Astrych/pink-stats/blob/master/Pinkcoin_difficulty_statistics.ipynb From 150 level to 75 now (chart is a few days old) and will probably drop a little bit more. Combining method doesn't matter to be honest. Staking FPoS in more profitable and start the same day someone combines his/her UTXOs because FPoS difficulty is very low (third chart): https://github.com/Astrych/pink-stats/blob/master/Pinkcoin_difficulty_statistics.ipynb People just don't want free coins :)

Anyway I think it's offtopic ;) @piratoskratos Have you solved your issue? Can you close that? And BTW Pinkcoin discord channel is much better for that type of questions/issues (because it's not issue with the code). Here it is: https://discord.gg/NnnyyBf

[piratoskratos]

Astrych I don't know if I can tell it's resolved. I'm updated. I follow this post to "resolve" it but as I had to do it twice already it's probably not normal.

[aistrych]

@piratoskratos There was an issue with the network (and you could find info about it in our official channels and even in description of last releases) but it was resolved in recent update (2.2.1.0). During that period wallets could fork and even check-pointing couldn't prevent that (from time to time). Your wallet got stuck on a fork and didn't receive a series of blocks on the correct fork (marked as orphaned). Blocks later in that series contained transactions that reference transactions contained earlier in the series of blocks so your wallet can't do anything about it (hasn't received that blocks with that transactions in the past so can't handle it now) This is the reason it is stuck now. I think it's "normal" for Bitcoin based coins. It's the way it works and it's hard to fix that without creating another attack vector. Only way to deal with it is to resync. And the true issue was with forking in the first place which was fixed. If your wallet in version 2.2.1.0 is synced and works properly now I think you can close that issue. If it will repeat (I don't think so) you can always reopen it again.