Topic: [ANN] Spark | X11 | BTer/Bittrex/C-CEX | PoW/PoS | Exchanges | Roadmap | - page 8. (Read 108612 times)

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

So, which fork is being chosen by this update?

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

I sincerely hope the original dev is OK!

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 --

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

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.

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.   

thx for clarification 

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.

I'd say, at least after ~blk 12600something, no transaction would be possible to get through with even 1 confirmation since no new block to contain one becomes generated. no PoW, cos no miner (I hope! what lunatic would that be), PoS not reached on that fork...
such tx'es will rot in tx cache til they are swept...



no one is on fork, we're all on spoon here



...now, seriously and in brief

the GOOD fork - that isn't one actually, but apparently the only valid blockchain.
it's the one currently at blk16000+somewhat, end of PoW reached as intended,
PoS currently active and working (like a ticking clock to be precise )

if your wallet got network clients at all (and there should be a lot around... got 12 active connections... had way less on bigger coins!)
then you're most probably in the right net anyway

the BAD fork that forked off after blk10041 is the one
with an erroneous blk10041 (and hard luck put bittrex on that fork as well as at least 2 of the miningpools).
this fork should end around 12600+somewhat when the last miner realized
that this leads to a dead end and went off.
the bad fork might as well already beeing abandoned (apart from the known ones) so sould only contain very
little nodes, if any.

if you go to the debug console and:
> getpeerinfo

you'll get a list of your next network neighbours. some of the info
is strong evidence about what network you joined. e.g.:

[
{
"addr" : "123.123.123.123:16665",
"services" : "00000001",
"lastsend" : 1414512845,   <-- should both be a very recent utime like this or higher
"lastrecv" : 1414512888,    <--- " --
"conntime" : 1414502352,
"version" : 70000,
"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 don't want to go as far as saying: no, but if:
a) they were deposited before block 10041
b) traded inside bittrex
then I'd say, there's good chance they won't even be touched by the problem and should
be available as soon as the wallet issue has been resolved.

if however deposits happend AFTER said 10041, then they might be in a contingent
where we need to find a solution to settle ledgers with bittrex... this is under investigation right now
after the guys at the rex got through it, we can work out a solution and foremost get a picture on
the volume of the difference to clean.
my impression when visually scraping the charts was that trading vol. should range at most at
around a few btc... 2-3 top maybe... likely some less... but that's just my eyes and 5 sec. look
and I'm pretty sure that tx volume won't top trading vol. in that relative short time window...

to me, that still sounds all well possible to fix






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

does this mean ppl who have spark on bittrex will lose them?

I am a bit confused who is on good chain and who is on fork that we are trying to adopt here...?

i dont think there will be an issue with txes on their fork as users/pools on their fork would still be able to deposit. it's the users/pools on the good fork who wouldnt have been able to deposit.

cool yup, I think binary demand runs close to zero for linux, yet a clean repository was necessary in the first place as a starter.
if you could get a wallet to make under mingw, that'd be awesome... last time I tried similar, I was blessed with too little time and to much quirks to get that going, so I stopped trying after some short time...

I think, it won't take all too long 'til there's info on the tx'es that would require to be compensated, if (and that will be a necessary step to get them in sync again) bittrex drops the bad fork and switches tracks.

in a few hours I'll have some time in row to care for getting someone at the other three exchanges sharing info on the situation and their according status...

I'll drop any further info on that as soon as I become aware of them

If anyone else already IS or HAS BEEN in contact (and as such has some contact person in mind) with one of B'TER, C-CEX or VaultEX, this would be your moment to speak up  
...else i'd go for them as well as announced somewhat later this day...


---


quick recheck of all the listed pools showed, only spark.hashhot.com
and spark.binpool.com seem to have jumped the wrong trail,

so I guess while we're moving on and situation becomes stable, all other
pools will soon as well be able to reopen for withdrawal, the moment
they see transactions are save to be performed further on.

this of course is not yet the status quo.

the situation on binpool and hashhot would have to be evaluated separately
and I hope in that sense, not too much of mhash went there after 10041
as I deeply suspect those shares will be gone for good...

I don't know If there are any funds still locked from before 10041 but
if so, that should be as well manageable after getting them in the right
network.

---

btw. if we do have a VOLUNTEER who would be able to set up
and provide a (temporary) BLOCK EXPLORER some time soon...

any abe based would certainly do, yet... the insight.js - as the original one - would be a
goodie, but it needs node.js on the server platform.
hehe, or someone wants to play generous sponsor for getting one at blockexperts.com.
they provide the most sophisticated one so far i'd say... but it costs 100milli/ann...
ok, the latter one might become an option, after all went good and the spark has become
reignited

I'll do the revised Linux wallet update on my Github fork, dont see much need for a binary of that as most ppl will compile their own anyway. There's documentation on the Github repo for doing a MingW Windows compile so I should be able to do that, depends how many dependencies I have to bodge in to get it working but hopefully I can get it up on Github as a downloadable binary in a few hours.

edschroedinger - since you are already talking to Bittrex makes sense to keep on if you dont mind, I assume its easy for them to pull the timestamp of block 10041 and then see how many txes they processed after that. Just hope its not a lot....

I suspect Bter will be on the majority chain as they had a wallet up early, but if anyone wants to try contacting them please do.

well, I remember earlz actually pointing at the very same two possible pitfalls in his review...
as we're after pow, part of is not needed anymore anyway. good you fixed that first
https://github.com/Earlz/coinreviews/blob/master/sparkcoin.txt

when you say, you could would be able to compile the wallet and release a binary, what architecture do you have in mind...?
if you go for windows, that'd be the one with the most demand i guess, we are at most there

however, later I should have some time to clone this and try getting it compiled with VS on another maschine...
'at most very superficial' would be the most adequate description of my experience on bitcoin-n-clones-code, so to speak...
...yet, seems to be a good time to change that.




info is already there ...yep, thought the rex (without diminishing the other exchanges) was the first to investigate as they had the highest frequence and the tightest gap in orders, so presumably the highest demand... thus first thing to become set straigt

yup, would be a real pitty to let that whole thing drown just because the old dev went lost (and I can vividly imagine him simply going: whow... such fork... very work to fix... many hates... such loose coins... I go... many not profit... whow!)
but apart from that dematerialized dev, guts told me that it won't require rocket science to get that thing going again...
and as of now, at least we're moving forward and chances are not bad to make a clean restart some time not too far in the future

Great work man, the investors of this coin are thankful. Hope we can get a dev in on this and have everything fixed and rolling soon. Try to sort it with trex before the others, at least ask their advice on how to move, at which block they halted trading etc

I actually am in contact with ryan from bittrex on that case and get to bter c-c and vaultex asap, to get info on their status...
...I guess, as things are moving further quite good, we're getting a good picture pretty soon

...it indeed went past me while reading, but however, knowing it beeing Blk 10041 makes us getting somewhere,
resp. that would be the starting point for bittrex to estimate the transaction volume that has to be devaluated,
if they need to drop their chain;
which - if I understand correctly - would be anyway the only option to get a spark wallet back into
the network with the (only) working blockchain. same, that is used by factually all spark wallets
to date beyond blk 14400 (15699 as of now).
now bottom line seems, that any other option would be either way technically impossible or economically gross unacceptable.

ok, I think after bittrex has a picture how much transactions volume got involved and would need to be compensated, we will see how to get past that problem

they probably suspended trading i think about 3hrs after i reported the problem. somewhere near block 10800. if noone has any objections RentaMouse you can go ahead and speak with bittrex as an official representative of the community. let them know what happened and why that chain cannot be repaired and let's see if we can get trading running again after they sync. i suspect that this all had something to do with why bittrex wallet kept getting corrupted when they first tried to implement it.