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

[RentaMouse]

Bit more info for you, I've managed to get the latest build of the Linux wallet to compile after some effort (issues with my system rather than with the code) and have been looking at the peer info - there are definitely two forks in existence currently, one is around block 12750 and the other is at block 15000. Looks like the major part of the PoW hash went on one fork but somehow the other one continued and got well behind in blocks whilst the difficulty was adjusting down to the reduced hashpower.

I've been digging a bit more though and its a bit peculiar, with my new daemon it will only sync on the 12750 chain and rejects PoS blocks from the other chain. If I set the conf file so it only connects to nodes on the 15000 blockchain and try resyncing it gets to block 10041 and then just rejects PoS blocks.

As I mentioned before, I'm a tinkerer not a coder, and I don't know the PoS stuff that well but from what I've seen so far I have a suspicion that the dev accidentally released two different versions of the daemon, if you look at this commit from around when the coin was launched there are a couple of key PoS changes made: https://github.com/RentaMouse/Spark/commit/71d360fdbb18aacf9c49179e0be882f0b9fac289 - the PoW endpoint in the PoS code is changed from 10000 to 14000, and the PoS key is changed. Pre-change daemons could have mined a PoS block after 10000, post change versions wouldnt accept it.

On GitHub there are actually two release versions, 1.0.0 and 1.1.0, looking at the peer info from my daemon there are a few nodes on 1.1.0 but none of those are on the 15k blockchain, which backs up my theory. I suspect Bittrex are running 1.1.0 because they would have compiled from Github and they added the coin later than most....

At the moment its too late for me to decide whether its actually a really bad thing, although I suspect it explains the disappearance of the dev, he may just be running from his backers cos he realised his error a week ago Quite possibly its not the end of the world as I suspect all the pools will be on the old code, so no miners should lose out on a load of coin, and Bittrex stopped their trading pretty quickly.

What I'm pretty sure of is that I can release an updated version of the wallet which will work properly with the 15000 chain so everyone can get in sync with that.

Discuss away, I'll be back in a few hours....

[CryptoStoner]

Bit more info for you, I've managed to get the latest build of the Linux wallet to compile after some effort (issues with my system rather than with the code) and have been looking at the peer info - there are definitely two forks in existence currently, one is around block 12750 and the other is at block 15000. Looks like the major part of the PoW hash went on one fork but somehow the other one continued and got well behind in blocks whilst the difficulty was adjusting down to the reduced hashpower.

I've been digging a bit more though and its a bit peculiar, with my new daemon it will only sync on the 12750 chain and rejects PoS blocks from the other chain. If I set the conf file so it only connects to nodes on the 15000 blockchain and try resyncing it gets to block 10041 and then just rejects PoS blocks.

As I mentioned before, I'm a tinkerer not a coder, and I don't know the PoS stuff that well but from what I've seen so far I have a suspicion that the dev accidentally released two different versions of the daemon, if you look at this commit from around when the coin was launched there are a couple of key PoS changes made: https://github.com/RentaMouse/Spark/commit/71d360fdbb18aacf9c49179e0be882f0b9fac289 - the PoW endpoint in the PoS code is changed from 10000 to 14000, and the PoS key is changed. Pre-change daemons could have mined a PoS block after 10000, post change versions wouldnt accept it.

On GitHub there are actually two release versions, 1.0.0 and 1.1.0, looking at the peer info from my daemon there are a few nodes on 1.1.0 but none of those are on the 15k blockchain, which backs up my theory. I suspect Bittrex are running 1.1.0 because they would have compiled from Github and they added the coin later than most....

At the moment its too late for me to decide whether its actually a really bad thing, although I suspect it explains the disappearance of the dev, he may just be running from his backers cos he realised his error a week ago Quite possibly its not the end of the world as I suspect all the pools will be on the old code, so no miners should lose out on a load of coin, and Bittrex stopped their trading pretty quickly.

What I'm pretty sure of is that I can release an updated version of the wallet which will work properly with the 15000 chain so everyone can get in sync with that.

Discuss away, I'll be back in a few hours....

Releasing an updated version would be perfect, if Dev does not appear we should seriously consider finding a dev that is willing to take over this project.

[edschroedinger]

if any of you end up with your windows-qt client crashing every time shortly after start, just to remember:
pull the network cable -> start client -> wait on UI finally popping up ->now connect back -> don't touch the 'market' buttons (or start with point 1)

Thanks Ed, your advice made me able to withdraw my few coins.

Same here.. Thanxs bro fixed!!!

no wrorries, good it worked...! that's some rather odd bug, to say the least... yet, credits go one step further @Framauro, he came up with that solution... and to be honest, I wouldn't have tried that myself in a hundred years


---

Bit more info for you, I've managed to get the latest build of the Linux wallet to compile after some effort (issues with my system rather than with the code) and have been looking at the peer info - there are definitely two forks in existence currently, one is around block 12750 and the other is at block 15000. Looks like the major part of the PoW hash went on one fork but somehow the other one continued and got well behind in blocks whilst the difficulty was adjusting down to the reduced hashpower.

I've been digging a bit more though and its a bit peculiar, with my new daemon it will only sync on the 12750 chain and rejects PoS blocks from the other chain. If I set the conf file so it only connects to nodes on the 15000 blockchain and try resyncing it gets to block 10041 and then just rejects PoS blocks.

As I mentioned before, I'm a tinkerer not a coder, and I don't know the PoS stuff that well but from what I've seen so far I have a suspicion that the dev accidentally released two different versions of the daemon, if you look at this commit from around when the coin was launched there are a couple of key PoS changes made: https://github.com/RentaMouse/Spark/commit/71d360fdbb18aacf9c49179e0be882f0b9fac289 - the PoW endpoint in the PoS code is changed from 10000 to 14000, and the PoS key is changed. Pre-change daemons could have mined a PoS block after 10000, post change versions wouldnt accept it.

On GitHub there are actually two release versions, 1.0.0 and 1.1.0, looking at the peer info from my daemon there are a few nodes on 1.1.0 but none of those are on the 15k blockchain, which backs up my theory. I suspect Bittrex are running 1.1.0 because they would have compiled from Github and they added the coin later than most....

At the moment its too late for me to decide whether its actually a really bad thing, although I suspect it explains the disappearance of the dev, he may just be running from his backers cos he realised his error a week ago Quite possibly its not the end of the world as I suspect all the pools will be on the old code, so no miners should lose out on a load of coin, and Bittrex stopped their trading pretty quickly.

What I'm pretty sure of is that I can release an updated version of the wallet which will work properly with the 15000 chain so everyone can get in sync with that.

Discuss away, I'll be back in a few hours....

yay @R.a.Mouse, that sounds like a scenario that actually might have happened quite the way you suspect...

yesterday I wrote back to ryan from bittrex to shed some info on how he evaluates the situation on their side and possible ways to fix... yet, no response. but they're following this thread anyway, so I guess they at least know that - even when dev doesn't show up anymore (and undeniably signs point on that with glow colours) - there's action gonna be taken to fix the issue and bring train back on rails...
...which will be of course some work to do, yet my senses told me it shouldn't be too much of a challenge, to get that thing going again... distribution so far seemed to run rather smooth during PoW period, even considering that fork.

so, the currency is there, and if handled with the necessary caution, this coin even has a good chance to get a save way back with the necessary amount of confidence from the community, so it won't become dumped to death the first day it hits markets back again .

unfortunately I have rather little time today but I will check back with bittrex to get some info on how next steps could evolve...

so, however... everyone just keep staking ...if wallet crashes on start - pull network cable. start and wait on wallet ui. plug network back in.

I'll check back in between randomly and keep u updated as soon as new intel is available.


---

Releasing an updated version would be perfect, if Dev does not appear we should seriously consider finding a dev that is willing to take over this project.

it's all a wee bit kept in between the last 3-4 pages... I guess we should consider the dev already MIA at this point, as there's no time to spend on pure waiting due to the nature of the stuck market problems to fix.
if he pops up again out of thin air (or even anonymously wants to free some resources or simply turn over info that would make a takeover easier), welcome...! that would make the whole thing moving further immediately, I guess. yet, at this point I evalutate the probability of this happening practically zero.
but things are already rolling... I believe, it won't take long till first results will follow

[LuckyAlt]

What RPC Port are you using?

[edschroedinger]

...we're moving forward


got response from bittrex (yet I won't get into much research myself today due to a great lack of time):

The best way for this to happen would be for the coin to come up on our same fork. We won't know how many coins we are short until the new wallet is up and we can see/process deposits/withdraws.

Have you found out at which block the fork happened? If we could find the first block where the blockhashes don't match we may be able to better determine how many deposits we have that would need invalidated.

well, now there's TWO questions to focus upon:

1st: when exactly did the chains start deviating... suchpool states 10042 and looking at the remarkable drop in network strength at that very time it must be exactly that block or just a few blocks earlier or later.

which opens up

2nd: who (apart from bittrex aparently) stayed on the other fork after around block 10042.
that might be folks that e.g. mined on hashhot and were able to withdraw from there, as hashot seems to as well become stuck on that other fork.

and - following my impression - the stronger chainfork after the split looks to me like it's the on suprnova, suchpool, ipominer locked as well (even the official blockchain explorer cannot access it's own wallet, yet it shows the current blockcount and time of even that fork) and it also seems to be the fork, the wallet syncs if going online ... but as I stayed in sync whith that fork only the whole time over, I'm completely unaware about any other forks possible stats.

so:

• after finding the EXACT first block with the chain beeing split

we need to find out:

• who went on on the 'dominant' chain (eg. suchpool, ipominer, suprnova in order of beeing open for mining. network still working fine to date)
• who is stuck on another chain (probably not reached 14400 and so should be unavailable by now)

to eventually vote a chain and see, how much and how to compensate losses.


so, ok... I'm looking back in later, already way overdue


will get to c-cex, bter and vaultex later to get some info about their status with SPARK so we keep the thing coordinated...

[Coinler]

...we're moving forward


got response from bittrex (yet I won't get into much research myself today due to a great lack of time):

The best way for this to happen would be for the coin to come up on our same fork. We won't know how many coins we are short until the new wallet is up and we can see/process deposits/withdraws.

Have you found out at which block the fork happened? If we could find the first block where the blockhashes don't match we may be able to better determine how many deposits we have that would need invalidated.

well, now there's TWO questions to focus upon:

1st: when exactly did the chains start deviating... suchpool states 10042 and looking at the remarkable drop in network strength at that very time it must be exactly that block or just a few blocks earlier or later.

which opens up

2nd: who (apart from bittrex aparently) stayed on the other fork after around block 10042.
that might be folks that e.g. mined on hashhot and were able to withdraw from there, as hashot seems to as well become stuck on that other fork.

and - following my impression - the stronger chainfork after the split looks to me like it's the on suprnova, suchpool, ipominer locked as well (even the official blockchain explorer cannot access it's own wallet, yet it shows the current blockcount and time of even that fork) and it also seems to be the fork, the wallet syncs if going online ... but as I stayed in sync whith that fork only the whole time over, I'm completely unaware about any other forks possible stats.

so:

• after finding the EXACT first block with the chain beeing split

we need to find out:

• who went on on the 'dominant' chain (eg. suchpool, ipominer, suprnova in order of beeing open for mining. network still working fine to date)
• who is stuck on another chain (probably not reached 14400 and so should be unavailable by now)

to eventually vote a chain and see, how much and how to compensate losses.


so, ok... I'm looking back in later, already way overdue


will get to c-cex, bter and vaultex later to get some info about their status with SPARK so we keep the thing coordinated...

i would say it was indeed around 10042. i was monitoring the entire network and basically witnessed the fork. getting on the bittrex fork is not possible due to the invalid block on that fork which was most likely a result of 51% attack or POS staking beginning early on some wallet. both reasons mean that the invalid fork with the invalid block at 10042 cannot be used or repaired due to blockchain encryption. attempting to repair it is like trying to hack the blockchain which will not be possible. there will be only 2 options.

repair the github and rollback the blockchain to block 1000 (will not sit well with anyone)
discard the illegal fork and move forward with our current pos network.

the working fork has no corrupt blocks and you cant patch a corrupt block to move forward. it means that the working fork as i said from the start is the only legitimate fork. and that is the suchpool/supernova fork.

[CryptoStoner]

...we're moving forward


got response from bittrex (yet I won't get into much research myself today due to a great lack of time):

The best way for this to happen would be for the coin to come up on our same fork. We won't know how many coins we are short until the new wallet is up and we can see/process deposits/withdraws.

Have you found out at which block the fork happened? If we could find the first block where the blockhashes don't match we may be able to better determine how many deposits we have that would need invalidated.

well, now there's TWO questions to focus upon:

1st: when exactly did the chains start deviating... suchpool states 10042 and looking at the remarkable drop in network strength at that very time it must be exactly that block or just a few blocks earlier or later.

which opens up

2nd: who (apart from bittrex aparently) stayed on the other fork after around block 10042.
that might be folks that e.g. mined on hashhot and were able to withdraw from there, as hashot seems to as well become stuck on that other fork.

and - following my impression - the stronger chainfork after the split looks to me like it's the on suprnova, suchpool, ipominer locked as well (even the official blockchain explorer cannot access it's own wallet, yet it shows the current blockcount and time of even that fork) and it also seems to be the fork, the wallet syncs if going online ... but as I stayed in sync whith that fork only the whole time over, I'm completely unaware about any other forks possible stats.

so:

• after finding the EXACT first block with the chain beeing split

we need to find out:

• who went on on the 'dominant' chain (eg. suchpool, ipominer, suprnova in order of beeing open for mining. network still working fine to date)
• who is stuck on another chain (probably not reached 14400 and so should be unavailable by now)

to eventually vote a chain and see, how much and how to compensate losses.


so, ok... I'm looking back in later, already way overdue


will get to c-cex, bter and vaultex later to get some info about their status with SPARK so we keep the thing coordinated...

i would say it was indeed around 10042. i was monitoring the entire network and basically witnessed the fork. getting on the bittrex fork is not possible due to the invalid block on that fork which was most likely a result of 51% attack or POS staking beginning early on some wallet. both reasons mean that the invalid fork with the invalid block at 10042 cannot be used or repaired due to blockchain encryption. attempting to repair it is like trying to hack the blockchain which will not be possible. there will be only 2 options.

repair the github and rollback the blockchain to block 1000 (will not sit well with anyone)
discard the illegal fork and move forward with our current pos network.

the working fork has no corrupt blocks and you cant patch a corrupt block to move forward. it means that the working fork as i said from the start is the only legitimate fork. and that is the suchpool/supernova fork.

POS is working good, so the 2nd option to disgard the bad fork would be the most viable option

[RentaMouse]

Sorry, I probably didnt make it clear in my last post, but 10041 was the "bad" block, the forks appear to deviate after 10042, glad others corroborate that.

Unfortunately I think Bittrex are on the minority chain which we probably dont want to switch back to as the PoW phase isnt complete yet, and we'd have a load of miners upset about losing 4000 blocks worth of PoW mining. How that will affect Bittrex probably depends on how soon they suspended trading after block 10041

Unless someone comes up with a good reason not to I think I will see about releasing an updated wallet later that will definitely sync with the majority chain, as the current version on Github (and I assume the Windows download, I havent tested it yet) will not.

[CryptoStoner]

Sorry, I probably didnt make it clear in my last post, but 10041 was the "bad" block, the forks appear to deviate after 10042, glad others corroborate that.

Unfortunately I think Bittrex are on the minority chain which we probably dont want to switch back to as the PoW phase isnt complete yet, and we'd have a load of miners upset about losing 4000 blocks worth of PoW mining. How that will affect Bittrex probably depends on how soon they suspended trading after block 10041

Unless someone comes up with a good reason not to I think I will see about releasing an updated wallet later that will definitely sync with the majority chain, as the current version on Github (and I assume the Windows download, I havent tested it yet) will not.

you should discuss this directly with bittrex , will be faster to find a resolution, they've dealt with this before

[Coinler]

Sorry, I probably didnt make it clear in my last post, but 10041 was the "bad" block, the forks appear to deviate after 10042, glad others corroborate that.

Unfortunately I think Bittrex are on the minority chain which we probably dont want to switch back to as the PoW phase isnt complete yet, and we'd have a load of miners upset about losing 4000 blocks worth of PoW mining. How that will affect Bittrex probably depends on how soon they suspended trading after block 10041

Unless someone comes up with a good reason not to I think I will see about releasing an updated wallet later that will definitely sync with the majority chain, as the current version on Github (and I assume the Windows download, I havent tested it yet) will not.

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.

[edschroedinger]

Sorry, I probably didnt make it clear in my last post, but 10041 was the "bad" block, the forks appear to deviate after 10042, glad others corroborate that.

Unfortunately I think Bittrex are on the minority chain which we probably dont want to switch back to as the PoW phase isnt complete yet, and we'd have a load of miners upset about losing 4000 blocks worth of PoW mining. How that will affect Bittrex probably depends on how soon they suspended trading after block 10041

Unless someone comes up with a good reason not to I think I will see about releasing an updated wallet later that will definitely sync with the majority chain, as the current version on Github (and I assume the Windows download, I havent tested it yet) will not.

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

[edschroedinger]

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.

you should discuss this directly with bittrex , will be faster to find a resolution, they've dealt with this before

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

[CryptoStoner]

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.

you should discuss this directly with bittrex , will be faster to find a resolution, they've dealt with this before

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

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

[edschroedinger]

...I've been digging a bit more though and its a bit peculiar, with my new daemon it will only sync on the 12750 chain and rejects PoS blocks from the other chain. If I set the conf file so it only connects to nodes on the 15000 blockchain and try resyncing it gets to block 10041 and then just rejects PoS blocks.

As I mentioned before, I'm a tinkerer not a coder, and I don't know the PoS stuff that well but from what I've seen so far I have a suspicion that the dev accidentally released two different versions of the daemon, if you look at this commit from around when the coin was launched there are a couple of key PoS changes made: https://github.com/RentaMouse/Spark/commit/71d360fdbb18aacf9c49179e0be882f0b9fac289 - the PoW endpoint in the PoS code is changed from 10000 to 14000, and the PoS key is changed. Pre-change daemons could have mined a PoS block after 10000, post change versions wouldnt accept it.

On GitHub there are actually two release versions, 1.0.0 and 1.1.0, looking at the peer info from my daemon there are a few nodes on 1.1.0 but none of those are on the 15k blockchain, which backs up my theory. I suspect Bittrex are running 1.1.0 because they would have compiled from Github and they added the coin later than most....

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.

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

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

[RentaMouse]

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.

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.

[edschroedinger]

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.

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

[Coinler]

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.

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.

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.

[SnjafSnjaf]

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

[dellyz]

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

[edschroedinger]

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.

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

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

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


---

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

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