[ANN][XCN] Cryptonite - NEW Thread | 1st mini-blockchain coin | Bounties!

[bitfreak!]

I think that, when the sync bug is fixed, we will have no more issues with exchanges, hence why I'm having a dev work on it, and I will pay him bounty from my wallet (and from the people who will contribute).
I could do the fix myself, I just do not have enough time.

I will send you some XCN that I have, I don't have a whole lot so I might just send you all of it. I appreciate you guys trying to keep this coin alive in my absence. Some time ago I did try to figure out the sync issue by looking at the source code but it's so hard to understand such complex code especially when you didn't write that code yourself. I've been thinking seriously about writing a new coin from scratch using the MBC scheme along with some other stuff such as a quantum resistant signature scheme and the homomorphic encryption proposal by B.F. Franca (see this and this). I feel like if XCN did anything it has proven that the MBC scheme can work and isn't easy to exploit since it hasn't been done. I also think that when a coin is created from scratch it feels less like a simple clone of Bitcoin and people can appreciate it more, and it allows us to avoid all the issues inherent with the Bitcoin code. So much of the Bitcoin core code is also made redundant within the MBC scheme, like everything to do with scripts. The goal would be to create simple and elegant code that makes it easier to understand and modify. I would also prefer to avoid using Qt altogether, since the creation of GUI's should be a job for wallet software developers. That would also mean using a robust networking library instead of the one that comes with Qt. This is all just an idea right now, I'd like to hear what you guys think before going ahead with anything.

[bogdanb]

Hello @bitfreak!

Can you please help @pallas deal with btc38 team?
I understand that they expect answer from initial dev and they do not answer to pallas anymore.
Will be great to fix btc38 wallet problem, that exchange was primary market for xcn, with 10 times higher volumes then poloniex.

[pallas]

I think that, when the sync bug is fixed, we will have no more issues with exchanges, hence why I'm having a dev work on it, and I will pay him bounty from my wallet (and from the people who will contribute).
I could do the fix myself, I just do not have enough time.

I will send you some XCN that I have, I don't have a whole lot so I might just send you all of it. I appreciate you guys trying to keep this coin alive in my absence.

Thanks, but I prefer any contribution you can make to the coin ;-)
I'm working with a dev friend to find the sync issue and fix it, 3 heads are better than 2 at solving a problem!

Some time ago I did try to figure out the sync issue by looking at the source code but it's so hard to understand such complex code especially when you didn't write that code yourself. I've been thinking seriously about writing a new coin from scratch using the MBC scheme along with some other stuff such as a quantum resistant signature scheme and the homomorphic encryption proposal by B.F. Franca (see this and this). I feel like if XCN did anything it has proven that the MBC scheme can work and isn't easy to exploit since it hasn't been done. I also think that when a coin is created from scratch it feels less like a simple clone of Bitcoin and people can appreciate it more, and it allows us to avoid all the issues inherent with the Bitcoin code. So much of the Bitcoin core code is also made redundant within the MBC scheme, like everything to do with scripts. The goal would be to create simple and elegant code that makes it easier to understand and modify. I would also prefer to avoid using Qt altogether, since the creation of GUI's should be a job for wallet software developers. That would also mean using a robust networking library instead of the one that comes with Qt. This is all just an idea right now, I'd like to hear what you guys think before going ahead with anything.

I think that the two projects can cohexist. I will support your new coin if you make it, but XCN has been running for almost 3 years and, despite the sync bug, it's been pretty stable so far, which is a great achivement by itself, nonetheless.
Besides, I agree with you to separate the GUI code from standalone wallet.

[barrysty1e]

I think that, when the sync bug is fixed, we will have no more issues with exchanges, hence why I'm having a dev work on it, and I will pay him bounty from my wallet (and from the people who will contribute).
I could do the fix myself, I just do not have enough time.

hey man,
just reading.. what is the actual sync bug? does it halt/freeze at a given height on some nodes?
also, curious as to why you can't release a windows wallet, just strikes me as odd.
willing to help out if you can provide some details.
james

(starpost was the best game on vic20)

[oldschoolgamer]

i am having a wierd issue today , headers seem to be stuck at 3 days behind in my wallet , even tho i tried a backup of a synced blockchain from yesterday , it started at 28 hours behind on headers then went to 3 days behind and is stuck , bit of a worry . any1 else having this issue?

[pallas]

I think that, when the sync bug is fixed, we will have no more issues with exchanges, hence why I'm having a dev work on it, and I will pay him bounty from my wallet (and from the people who will contribute).
I could do the fix myself, I just do not have enough time.

hey man,
just reading.. what is the actual sync bug? does it halt/freeze at a given height on some nodes?
also, curious as to why you can't release a windows wallet, just strikes me as odd.
willing to help out if you can provide some details.
james

(starpost was the best game on vic20)

There is an explanation at the end of the OP.
In brief: when you sync from scratch, at times even when you already have a chain db in your data dir, it stops syncing at a certain height. When using the QT wallet, closing it may corrupt the wallet database.
About the windows wallet, I'm waiting for the bug to be fixed before releasing any new binary.

[pallas]

i am having a wierd issue today , headers seem to be stuck at 3 days behind in my wallet , even tho i tried a backup of a synced blockchain from yesterday , it started at 28 hours behind on headers then went to 3 days behind and is stuck , bit of a worry . any1 else having this issue?

how many connections have you got?
try running "getpeerinfo" and see what's your peers height (if they are up to date).

[barrysty1e]

I think that, when the sync bug is fixed, we will have no more issues with exchanges, hence why I'm having a dev work on it, and I will pay him bounty from my wallet (and from the people who will contribute).
I could do the fix myself, I just do not have enough time.

hey man,
just reading.. what is the actual sync bug? does it halt/freeze at a given height on some nodes?
also, curious as to why you can't release a windows wallet, just strikes me as odd.
willing to help out if you can provide some details.
james

(starpost was the best game on vic20)

There is an explanation at the end of the OP.
In brief: when you sync from scratch, at times even when you already have a chain db in your data dir, it stops syncing at a certain height. When using the QT wallet, closing it may corrupt the wallet database.
About the windows wallet, I'm waiting for the bug to be fixed before releasing any new binary.

ok; yes i saw it at #161, but notice that the hash it fails on is the same in the complete (downloaded from elsewhere) chain.
also noticed both liblmdb and leveldb, is there a cutover? or is only one used.
just looking through the source now.

[oldschoolgamer]


[
{
"addr" : "85.14.250.2:38213",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787632,
"lastrecv" : 1488787637,
"bytessent" : 34732,
"bytesrecv" : 7389384,
"conntime" : 1488785010,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361388,
"banscore" : 0,
"syncnode" : true
},
{
"addr" : "77.233.244.74:59188",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787631,
"lastrecv" : 1488787634,
"bytessent" : 33278,
"bytesrecv" : 7143233,
"conntime" : 1488785016,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361388,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "82.116.52.170:57186",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787642,
"lastrecv" : 1488787643,
"bytessent" : 33620,
"bytesrecv" : 7144123,
"conntime" : 1488785017,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361388,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "86.127.154.22:53190",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787637,
"lastrecv" : 1488787638,
"bytessent" : 34777,
"bytesrecv" : 7147562,
"conntime" : 1488785068,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361388,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "46.105.118.15:8253",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787627,
"lastrecv" : 1488787630,
"bytessent" : 35712,
"bytesrecv" : 7164975,
"conntime" : 1488785095,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : false,
"startingheight" : 1361388,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "193.106.171.8:55480",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787633,
"lastrecv" : 1488787643,
"bytessent" : 33332,
"bytesrecv" : 7142384,
"conntime" : 1488785096,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361388,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "91.152.122.132:8253",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787626,
"lastrecv" : 1488787633,
"bytessent" : 33991,
"bytesrecv" : 7145145,
"conntime" : 1488785114,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : false,
"startingheight" : 1361388,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "85.14.250.2:58153",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787657,
"lastrecv" : 1488787658,
"bytessent" : 33781,
"bytesrecv" : 7144813,
"conntime" : 1488785174,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361388,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "158.69.27.82:54247",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488786990,
"lastrecv" : 1488786990,
"bytessent" : 189,
"bytesrecv" : 244,
"conntime" : 1488785189,
"pingtime" : 0.31630400,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 864817,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "188.252.239.235:55606",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787630,
"lastrecv" : 1488787638,
"bytessent" : 32369,
"bytesrecv" : 6897127,
"conntime" : 1488785195,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361389,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "188.252.239.235:62275",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787630,
"lastrecv" : 1488787638,
"bytessent" : 32706,
"bytesrecv" : 6898115,
"conntime" : 1488785197,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361389,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "84.201.247.230:35306",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787102,
"lastrecv" : 1488787102,
"bytessent" : 247739,
"bytesrecv" : 2618,
"conntime" : 1488785234,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 160,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "93.122.250.57:41108",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787614,
"lastrecv" : 1488787615,
"bytessent" : 27990,
"bytesrecv" : 5912447,
"conntime" : 1488785235,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361389,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "95.25.80.210:8253",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787635,
"lastrecv" : 1488787645,
"bytessent" : 31047,
"bytesrecv" : 6650886,
"conntime" : 1488785258,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : false,
"startingheight" : 1361390,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "81.0.115.79:53937",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787629,
"lastrecv" : 1488787641,
"bytessent" : 31413,
"bytesrecv" : 6652591,
"conntime" : 1488785281,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361390,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "180.245.251.159:61770",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787633,
"lastrecv" : 1488787636,
"bytessent" : 30847,
"bytesrecv" : 6649781,
"conntime" : 1488785287,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361390,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "68.193.116.54:55636",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787650,
"lastrecv" : 1488787650,
"bytessent" : 31043,
"bytesrecv" : 6652007,
"conntime" : 1488785347,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361390,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "[2001:0:338c:e558:1460:35d0:4303:1014]:60059",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787630,
"lastrecv" : 1488787644,
"bytessent" : 30023,
"bytesrecv" : 6404516,
"conntime" : 1488785371,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361391,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "93.122.250.57:48662",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787653,
"lastrecv" : 1488787654,
"bytessent" : 25504,
"bytesrecv" : 5418945,
"conntime" : 1488785430,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361391,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "5.157.115.132:45402",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787625,
"lastrecv" : 1488787629,
"bytessent" : 30080,
"bytesrecv" : 6406209,
"conntime" : 1488785473,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361391,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "59.1.52.130:51877",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787289,
"lastrecv" : 1488787289,
"bytessent" : 244,
"bytesrecv" : 244,
"conntime" : 1488785488,
"pingtime" : 0.00000000,
"version" : 10000,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 19709,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "118.174.167.10:14081",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787631,
"lastrecv" : 1488787634,
"bytessent" : 29789,
"bytesrecv" : 6403214,
"conntime" : 1488785528,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361391,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "188.252.239.235:54330",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787630,
"lastrecv" : 1488787637,
"bytessent" : 27431,
"bytesrecv" : 5910602,
"conntime" : 1488785623,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361393,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "182.71.181.102:21245",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787631,
"lastrecv" : 1488787653,
"bytessent" : 25782,
"bytesrecv" : 5663094,
"conntime" : 1488785765,
"pingtime" : 0.00000000,
"version" : 10000,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361394,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "188.252.239.235:56884",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787630,
"lastrecv" : 1488787637,
"bytessent" : 25195,
"bytesrecv" : 5418449,
"conntime" : 1488785898,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361395,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "188.252.239.235:53388",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787630,
"lastrecv" : 1488787641,
"bytessent" : 23153,
"bytesrecv" : 4926840,
"conntime" : 1488785929,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361397,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "178.26.208.109:63295",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787629,
"lastrecv" : 1488787636,
"bytessent" : 22833,
"bytesrecv" : 4926103,
"conntime" : 1488785958,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361397,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "188.252.239.235:61119",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787652,
"lastrecv" : 1488787652,
"bytessent" : 19466,
"bytesrecv" : 4186979,
"conntime" : 1488786061,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361400,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "[2001:0:338c:e558:3005:6fd:4303:1014]:54169",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787631,
"lastrecv" : 1488787649,
"bytessent" : 16548,
"bytesrecv" : 3691950,
"conntime" : 1488786340,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361402,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "188.252.239.235:62092",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787630,
"lastrecv" : 1488787636,
"bytessent" : 9025,
"bytesrecv" : 1969435,
"conntime" : 1488786719,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361409,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "24.246.60.145:59100",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787631,
"lastrecv" : 1488787638,
"bytessent" : 4497,
"bytesrecv" : 984564,
"conntime" : 1488787186,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1361413,
"banscore" : 0,
"syncnode" : false
},
{
"addr" : "188.142.158.116:55457",
"addrlocal" : "155.143.193.174:8253",
"services" : "00000001",
"lastsend" : 1488787665,
"lastrecv" : 1488787664,
"bytessent" : 245169,
"bytesrecv" : 3334,
"conntime" : 1488787616,
"pingtime" : 0.00000000,
"version" : 10100,
"subver" : "/Satoshi:0.1.1/",
"inbound" : true,
"startingheight" : 1353665,
"banscore" : 0,
"syncnode" : false
}
]

that is the peer info i get if you may shed any light on it , cheers.

[pallas]

I think that, when the sync bug is fixed, we will have no more issues with exchanges, hence why I'm having a dev work on it, and I will pay him bounty from my wallet (and from the people who will contribute).
I could do the fix myself, I just do not have enough time.

hey man,
just reading.. what is the actual sync bug? does it halt/freeze at a given height on some nodes?
also, curious as to why you can't release a windows wallet, just strikes me as odd.
willing to help out if you can provide some details.
james

(starpost was the best game on vic20)

There is an explanation at the end of the OP.
In brief: when you sync from scratch, at times even when you already have a chain db in your data dir, it stops syncing at a certain height. When using the QT wallet, closing it may corrupt the wallet database.
About the windows wallet, I'm waiting for the bug to be fixed before releasing any new binary.

ok; yes i saw it at #161, but notice that the hash it fails on is the same in the complete (downloaded from elsewhere) chain.
also noticed both liblmdb and leveldb, is there a cutover? or is only one used.
just looking through the source now.

https://bitcointalk.org/index.php?topic=713538.msg17284953#msg17284953

about the hash: looks suspicious, I will look thru it, time permitting :-)
please share the block height and hash.

[pallas]


[node list]

that is the peer info i get if you may shed any light on it , cheers.

my peer list looks similar to yours, I don't see anything wrong with it, except that there are a lot of clients on low height.
but, that is to be expected, given the infamous sync bug ;-)
please have a look at your debug.log and see if there is anything weird to report.
thanks

[barrysty1e]

about the hash: looks suspicious, I will look thru it, time permitting :-)
please share the block height and hash.

the error in debug.log while syncing:

Code:

2017-03-06 06:50:24 UpdateTip: new best=000000017ec0449e4ebc1e2bc7d0cc5836490048169d4ab01801dd7d5dc7ebdc  height=160  log2_work=35.256255  tx=161  date=2014-07-28 01:24:2                                      0 progress=1.000000
2017-03-06 06:50:24 Cannot fastforward chain because of missing data: 000000044c4e5c82cf3c93a3019f09ecd9005a30f5eeba2ff6952b349c7324ae
Cannot fastforward chain because of missing data: 000000044c4e5c82cf3c93a3019f09ecd9005a30f5eeba2ff6952b349c7324ae 2
2017-03-06 06:50:24 Activate 000000017ec0449e4ebc1e2bc7d0cc5836490048169d4ab01801dd7d5dc7ebdc

however putting a fully sync'd chain into place, running 'getblockhash 161', we get:
000000044c4e5c82cf3c93a3019f09ecd9005a30f5eeba2ff6952b349c7324ae

james

[pallas]

New blockchain snapshot:

https://mega.nz/#!BVAwgJYY!ZMRKcyzvYijWruSlpJ8BVPMcoAXMv4Bm7ZBaOA6fcRE

[pallas]

about the hash: looks suspicious, I will look thru it, time permitting :-)
please share the block height and hash.

the error in debug.log while syncing:

Code:

2017-03-06 06:50:24 UpdateTip: new best=000000017ec0449e4ebc1e2bc7d0cc5836490048169d4ab01801dd7d5dc7ebdc  height=160  log2_work=35.256255  tx=161  date=2014-07-28 01:24:2                                      0 progress=1.000000
2017-03-06 06:50:24 Cannot fastforward chain because of missing data: 000000044c4e5c82cf3c93a3019f09ecd9005a30f5eeba2ff6952b349c7324ae
Cannot fastforward chain because of missing data: 000000044c4e5c82cf3c93a3019f09ecd9005a30f5eeba2ff6952b349c7324ae 2
2017-03-06 06:50:24 Activate 000000017ec0449e4ebc1e2bc7d0cc5836490048169d4ab01801dd7d5dc7ebdc

however putting a fully sync'd chain into place, running 'getblockhash 161', we get:
000000044c4e5c82cf3c93a3019f09ecd9005a30f5eeba2ff6952b349c7324ae

james

"Cannot fastforward chain because of missing data" means it can't find block data, which is normal for such an old block. Miniblockchain should go ahead and keep the header only. There must be something else.

[oldschoolgamer]

thanks heaps , it rly was a wierd thing , i tried a few diff blockchain snapshots i backed up myself and BOTH of em would basically sync backwards and end up at 3 days behind on headers (both snapshots were more recent than 3 days tho!) . ive now tried a backup from the 2nd this month (one from longer than 3 days ago) and it seems to be syncing from about 5500 blocks behind now , what i did notice tho is that transactions in my transaction list had weird dates that wernt even in the right order when id sort it by date (everything past a point was not verified by a green tick but was just a blue block in that section that would have the green tick . I think i may have possibly forked on my solo mining attempt the last few days? , it seemed to be working fine and i had been switching from solo to pool....and all working good.... i mined in pool overnight and opened wallet this morning tho and it was broken like this .... i could see my most recent transaction showing was from 6am this morning , but it said 3 days behind on headers . true wigout this one , totally new issue . ill let you know if it finishes its sync successfully or if it wigs again . I have a feeling theres a chasnce it will cause the last snapshot i tried seemed to be syncing at bout 3000 blocks to go then i looked at it 2 mins later and it say 3 days behind on headers lol , ahhhhhh ><

[pallas]

thanks heaps , it rly was a wierd thing , i tried a few diff blockchain snapshots i backed up myself and BOTH of em would basically sync backwards and end up at 3 days behind on headers (both snapshots were more recent than 3 days tho!) . ive now tried a backup from the 2nd this month (one from longer than 3 days ago) and it seems to be syncing from about 5500 blocks behind now , what i did notice tho is that transactions in my transaction list had weird dates that wernt even in the right order when id sort it by date (everything past a point was not verified by a green tick but was just a blue block in that section that would have the green tick . I think i may have possibly forked on my solo mining attempt the last few days? , it seemed to be working fine and i had been switching from solo to pool....and all working good.... i mined in pool overnight and opened wallet this morning tho and it was broken like this .... i could see my most recent transaction showing was from 6am this morning , but it said 3 days behind on headers . true wigout this one , totally new issue . ill let you know if it finishes its sync successfully or if it wigs again . I have a feeling theres a chasnce it will cause the last snapshot i tried seemed to be syncing at bout 3000 blocks to go then i looked at it 2 mins later and it say 3 days behind on headers lol , ahhhhhh ><

You may also try the new snapshot I just posted.
Please keep reporting your findings: we are working on fixing the sync bug and every piece of information may be useful.

[oldschoolgamer]

cheers , if this one syncing now doesn't work , will do ^^ . upon further inspection of this situation of mine , i do conclude that i did in fact fork off from the main chain at some point . i could provide a few screenshots of my scrambled transactions in the wallet if it helps , it appears every transaction after 3 blocks i mined solo (payouts from suprnova) was there in the transaction list but the dates were in the wrong order lol and they were not confirmed . The wierdest thing about this whole thing is that i had my wallet open this morning like 6 hours ago , it was synced and everything seemed to be fine ...... for some reason the wallet auto closed itself (it was there open and then it wasnt) ... i was like huh wtf wierd and didnt think much of it , but yeah sincethat moment BAM when i reopen wallet it did this 3 days headers behind thing . im at 4090 blocks behind now on this resync fingers crossed .

     ps. If i did fork from main chain , how the hell does that happen im only mining with 24 megahash .

            cheers .

[pallas]

cheers , if this one syncing now doesn't work , will do ^^ . upon further inspection of this situation of mine , i do conclude that i did in fact fork off from the main chain at some point . i could provide a few screenshots of my scrambled transactions in the wallet if it helps , it appears every transaction after 3 blocks i mined solo (payouts from suprnova) was there in the transaction list but the dates were in the wrong order lol and they were not confirmed . The wierdest thing about this whole thing is that i had my wallet open this morning like 6 hours ago , it was synced and everything seemed to be fine ...... for some reason the wallet auto closed itself (it was there open and then it wasnt) ... i was like huh wtf wierd and didnt think much of it , but yeah sincethat moment BAM when i reopen wallet it did this 3 days headers behind thing . im at 4090 blocks behind now on this resync fingers crossed .

     ps. If i did fork from main chain , how the hell does that happen im only mining with 24 megahash .

            cheers .

You may fork with just one block, but it should reorganize itself automatically, unless you have problems syncing.
Let me know how it goes.

[oldschoolgamer]

heres last bit of my debug log if that helps at all . can see it stoped on the 3rd which is where my blockcahin was stuck . Im still learning and its hard for me to make complete sense of it but seems somthing wasnt going right .

  here tis - 2017-03-06 12:03:43 ProcessBlock: ACCEPTED 1358160
2017-03-06 12:03:43 ERROR: ReadBlockFromDisk : OpenBlockFile failed
2017-03-06 12:03:43 ReadBlockFromDisk: Could not find block 00000000072e4e2ad210555476a21854aee06ac12f7f54a8fdc4842a0e429734
2017-03-06 12:03:43 receive version message: /Satoshi:0.1.1/: version 10100, blocks=1361599, us=155.143.193.174:8253, them=85.14.250.2:8253, peer=85.14.250.2:37304
2017-03-06 12:03:43 Cannot fastforward chain because of missing data: 00000000016ca234af629b3df816626b6b7e221298fabab3d440c3794ca063a6
2017-03-06 12:03:47 Activate 000000000e156f67e60c2b1168b169adb2236c1782cc0194facc34806b0e9ff2
2017-03-06 12:03:48 Writing file 000000000e156f67e60c2b1168b169adb2236c1782cc0194facc34806b0e9ff2
2017-03-06 12:03:48 Serialized: 238103 bytes
2017-03-06 12:03:48 ProcessBlock: ACCEPTED 1358185
2017-03-06 12:03:48 Cannot fastforward chain because of missing data: 00000000016ca234af629b3df816626b6b7e221298fabab3d440c3794ca063a6
2017-03-06 12:03:51 Activate 000000000e156f67e60c2b1168b169adb2236c1782cc0194facc34806b0e9ff2
2017-03-06 12:03:52 Writing file 000000000e156f67e60c2b1168b169adb2236c1782cc0194facc34806b0e9ff2
2017-03-06 12:03:52 Serialized: 238103 bytes
2017-03-06 12:03:52 ProcessBlock: ACCEPTED 1358145
2017-03-06 12:03:52 Requesting 2 blocks from [2001:0:338c:e558:28d8:9d2:4303:1014]:64041
2017-03-06 12:03:52 Cannot fastforward chain because of missing data: 00000000016ca234af629b3df816626b6b7e221298fabab3d440c3794ca063a6
2017-03-06 12:03:55 Activate 000000000e156f67e60c2b1168b169adb2236c1782cc0194facc34806b0e9ff2
2017-03-06 12:03:56 Writing file 000000000e156f67e60c2b1168b169adb2236c1782cc0194facc34806b0e9ff2
2017-03-06 12:03:56 Serialized: 238103 bytes
2017-03-06 12:03:56 ProcessBlock: ACCEPTED 1358161
2017-03-06 12:03:56 Requesting 4 blocks from 68.193.116.54:63509
2017-03-06 12:03:56 ERROR: ReadBlockFromDisk : OpenBlockFile failed
2017-03-06 12:03:56 ReadBlockFromDisk: Could not find block 0000000016c40a5ce91e747aaa82c850274faf579bd7c9fd3410914a3aca6c85
2017-03-06 12:03:56 receive version message: /Satoshi:0.1.1/: version 10100, blocks=1361599, us=155.143.193.174:54337, them=91.152.122.132:8253, peer=91.152.122.132:8253
2017-03-06 12:03:56 receive version message: /Satoshi:0.1.1/: version 10100, blocks=1361599, us=155.143.193.174:8253, them=0.0.0.0:0, peer=82.116.52.170:55779
2017-03-06 12:03:56 Cannot fastforward chain because of missing data: 00000000016ca234af629b3df816626b6b7e221298fabab3d440c3794ca063a6



like i dunno but those numebrs next to ACCEPTED dont even go in numerical order but they do so in the order on the timeline , seems wierd

[ryon]

good coin to trading