[ANN] Spark | X11 | BTer/Bittrex/C-CEX | PoW/PoS | Exchanges | Roadmap |

[RentaMouse]

What we are talking about is standardising on the majority chain, which should be some way past 15k blocks now, I haven't checked it for a while. The network forked after block 10040, I've just pulled the timestamp from that block and it is Sat, 25 Oct 2014 14:33:32 GMT

Any txes Bittrex after that point are currently in the the "grey" area, we hope there werent many deposits/withdrawals as they could be a problem. Trades on Bittrex after that point might not be such an issue as they are off the blockchain.

[1713948420]

1713948420

[1713948420]

1713948420

[1713948420]

1713948420

[1713948420]

1713948420

[dellyz]

thx for clarification 

[Coinler]

"subver" : "/Spark:1.0.0/",  <-- should be an 1.0.0 client for now, the 1.1.0 is presumably a buggy linux client prone to take the bad fork...
"inbound" : false,
"startingheight" : 14144,
"banscore" : 0
}
]


---



I promissed a brief version -----------------v            

not sure that's correct. 1.1.0 should be the client that reads the proper blockchain with the configuration correction for pos to begin after block 14400. the 1.0.0 was set to begin POS at block 1000 in error which was corrected later in 1.1.0. RentaMouse can confirm if i got that correct.   

[RentaMouse]

I dont think the version numbers are that much help as I suspect the dev released two different version of v1.0.0 - all I can definitely say is that if you have v1.1.0 (I think you would have had to compile it yourself from Github) then you can't get on the majority chain.

What I can say now though is that I have released v1.2.0 on Github - https://github.com/RentaMouse/Spark/releases/tag/v1.2.0

Its just the Linux source for now, so a compile it yourself job, I will try and compile a Windows release from it asap.

Took me a bit longer as I was poking about, confirmed that 10041 was the last block which the two forks agreed on, so I have added a checkpoint to v1.2.0 which should ensure it can only sync to the "good" majority chain.

I don't understand the block verification code well enough to 100% confirm a reason for the fork, but my feeling is that its down to the part of the code which defined when the PoS phase started - the older version worked from block 10000, the newer version was on 14400. In v1.2.0 I have changed it back to 10000 in order to get the chain to sync, doesnt really matter now we have finished PoW anyway.

[Coinler]

sounds like you've gotten the chains to agree that they were both working with the 10000 setting. id say you've got the repairs under control. Good Show! pretty clear now i think. the 1.1.0  rejected POS from the 1.0.0 which was set at 10000. so the 1.1.0 was committed too late? lol

[edschroedinger]

I dont think the version numbers are that much help as I suspect the dev released two different version of v1.0.0 - all I can definitely say is that if you have v1.1.0 (I think you would have had to compile it yourself from Github) then you can't get on the majority chain.

What I can say now though is that I have released v1.2.0 on Github - https://github.com/RentaMouse/Spark/releases/tag/v1.2.0

Its just the Linux source for now, so a compile it yourself job, I will try and compile a Windows release from it asap.

Took me a bit longer as I was poking about, confirmed that 10041 was the last block which the two forks agreed on, so I have added a checkpoint to v1.2.0 which should ensure it can only sync to the "good" majority chain.

I don't understand the block verification code well enough to 100% confirm a reason for the fork, but my feeling is that its down to the part of the code which defined when the PoS phase started - the older version worked from block 10000, the newer version was on 14400. In v1.2.0 I have changed it back to 10000 in order to get the chain to sync, doesnt really matter now we have finished PoW anyway.

agree... more like a strong hint than evidence. yet... having just peers with those 1.1.0 clients should give a clear enough signal something is wrong

anyway, the first community release you provide is an important step that has been achieved


as of now, there's nothing really new from my side about situation @ bittrex,
but they've got the info they requested and are at at it and will getting back
that moment, they have something to get back with.

and as long as they stayed quite relaxed the whole time, I guess there's no
need to become nervous either



-- IMPORTANT --


now for something completely different....

IT MIGHT BE.... that starting with NOV 1ST. up to around NOV. 10TH
 ...I'M MORE OR LESS OFFLINE due to change of ISP :/

I so forgot about that switch as it's been my roommate caring for that this time...
...yet, I'm absolutely sure that I'm not completely blanked out for that time but
most likely there will be a difference within that 2 weeks.

for a situation like that I've got some umts modem I'm going to find now, that
should help bridge the gap...

as I'm sort of involved into fixing the already brittle situation, I thought you
should be informed about that situation, so you know
I've not as well contracted morbus vanishitis developitis or the likes


-- IMPORTANT --

[mistergee]

I appreciate the work of those that have risen to the challenge!

I sincerely hope the original dev is OK!

[minerpools]

So, which fork is being chosen by this update?

[Coinler]

So, which fork is being chosen by this update?

the checkpoint is set to use the suchpool/nova fork with pos being initiated at block 10000.

[minerpools]

So, which fork is being chosen by this update?

the checkpoint is set to use the suchpool/nova fork with pos being initiated at block 10000.

Good, we're all on that same fork

[RentaMouse]

Just to keep you updated, being in a Linux frame of mind I decided to try building the Windows daemon first, and wasted several hours discovering how out of date the makefile etc was before I decided to leave that and do the QT-GUI build instead....

Fingers crossed I'm nearly there compiling it, the QR code library has given me too much trouble so I may just leave it out for now.

[CryptoStoner]

How fast do you guys think you can resolve this, fork the wallet and reactivate markets? new ann must be made as well just copypaste and announce takeover

[richiela]

Can we add instamine coins to cover the difference?  Last i looked, we were 26-27k short.  I'm about to take the new build and see where we end up.

Thanks
richie

[CryptoStoner]

Can we add instamine coins to cover the difference?  Last i looked, we were 26-27k short.  I'm about to take the new build and see where we end up.

Thanks
richie

Thanks richie, keep us updated

[louiseth1]

SuchPool has upgraded to the community provided source.

Withdraws have been re-enabled! http://SuchPool.pw/spark

Thank you!

[ianta]

The Power of Community ...

https://i.imgur.com/wIeW9Jr.png

[richiela]

Can we add instamine coins to cover the difference?  Last i looked, we were 26-27k short.  I'm about to take the new build and see where we end up.

Thanks
richie

Thanks richie, keep us updated

43 deposits equaling 14499.19442

If the new devs wants to figure out how to reconcile that, we'll move over to the new fork and re-open the market.  Please cut us a ticket via our support channels and we can work through this.

Thanks
richie@bittrex

[CryptoStoner]

Can we add instamine coins to cover the difference?  Last i looked, we were 26-27k short.  I'm about to take the new build and see where we end up.

Thanks
richie

Thanks richie, keep us updated

43 deposits equaling 14499.19442

If the new devs wants to figure out how to reconcile that, we'll move over to the new fork and re-open the market.  Please cut us a ticket via our support channels and we can work through this.

Thanks
richie@bittrex

We could easily just gather this amount with the community and send it to you or we can instamine it, i'll let the others decide on that one, glad markets can reopen

[minerpools]

Minerpools is also updated to the community version!
Please remember to withdraw your coins

[Rigsuss]

can i trade spark?

thx for help