[ANN][MAX] MAXcoin - PoW, ASIC Resistance, Keccak GPU Mining - page 51.

Atrides

hero member

Activity: 658

Merit: 500

Admin of DwarfPool.com

Quote from: BTCspoon on September 06, 2014, 03:44:20 PM

agreed

Maybe time to turn the problem to it's head, just to clean the network a little bit faster, by just connecting to a single clean node for a couple of day (narrowing the problem to network or code):

with: -reindex -maxconnections=1 -connect=CLEANNODEIP1 -connect=CLEANNODIP2 -par=8

Agreed,

we need clear solution, clear blockchain. currently reindex may go to fork.

insanid

full member

Activity: 322

Merit: 100

Quote from: mig6r on September 06, 2014, 05:22:23 PM

the link to the new wallet windows does not work Huh

https://github.com/Max-Coin/maxcoin/releases

mig6r

sr. member

Activity: 826

Merit: 250

the link to the new wallet windows does not work Huh

miningpoolhub

legendary

Activity: 1456

Merit: 1006

Mining Pool Hub

Quote from: maxcoinproject on September 06, 2014, 02:26:58 PM

Pool owners and users who compile from source; the latest commit allows you to block 0.9.1 nodes which should clean up the network somewhat. I'll be testing this approach this evening and if it works I'll release a new binary tomorrow.

Whilst I understand that you are concerned for the network and your coins getting flustered in this thread isn't going to help anything. I am working to rectify the problem (which is something I've never come across before, hence the delay and the reason it occurred to begin with) and will release a fix as soon as possible. If you're concerned, leave your wallet closed until a known fix is released.

Thanks

I want to know that if you will decide to revert blockchain from around 600000 block height or not.

You told us like this.
"If 1gh continues to mine on their own fork it will be a sad loss to the network."

Our pool wallet is still trying to catch up, sync started 4 hours ago with "-reindex" and it's still around 546854. It's not stuck but it really needs time. I'm wondering if I have to open the pool when it's done. And it would stuck again like what happened at 6000067 when more than two pools start to mine.

Please tell us the answer, this is what I am concerning the most.

BTCspoon

full member

Activity: 238

Merit: 100

Quote from: subSTRATA on September 06, 2014, 03:00:08 PM

Quote from: maxcoinproject on September 06, 2014, 02:26:58 PM

Pool owners and users who compile from source; the latest commit allows you to block 0.9.1 nodes which should clean up the network somewhat. I'll be testing this approach this evening and if it works I'll release a new binary tomorrow.

All nodes except 0.9.2.1 should be filtered out, there are actualy still many of them using 0.9.0 and 0.8.9 versions. There are zero good reasons to tolerate nodes which use old
ruleset, just let them stay on their own blockchains isolated from healthy network. Also, syncing to only healthy nodes goes much faster if our nodes wasted minimum time on
those outdated nodes. For a perfect outcome, peers.dat file should be filtered as well so IPs of outdated nodes are not sent to other healthy nodes.

agreed

Maybe time to turn the problem to it's head, just to clean the network a little bit faster, by just connecting to a single clean node for a couple of day (narrowing the problem to network or code):

with: -reindex -maxconnections=1 -connect=CLEANNODEIP1 -connect=CLEANNODIP2 -par=8

subSTRATA

legendary

Activity: 1288

Merit: 1043

:^)

Quote from: maxcoinproject on September 06, 2014, 02:26:58 PM

Pool owners and users who compile from source; the latest commit allows you to block 0.9.1 nodes which should clean up the network somewhat. I'll be testing this approach this evening and if it works I'll release a new binary tomorrow.

All nodes except 0.9.2.1 should be filtered out, there are actualy still many of them using 0.9.0 and 0.8.9 versions. There are zero good reasons to tolerate nodes which use old
ruleset, just let them stay on their own blockchains isolated from healthy network. Also, syncing to only healthy nodes goes much faster if our nodes wasted minimum time on
those outdated nodes. For a perfect outcome, peers.dat file should be filtered as well so IPs of outdated nodes are not sent to other healthy nodes.

maxcoinproject

member

Activity: 156

Merit: 10

MaxcoinProject.org

Pool owners and users who compile from source; the latest commit allows you to block 0.9.1 nodes which should clean up the network somewhat. I'll be testing this approach this evening and if it works I'll release a new binary tomorrow.

Whilst I understand that you are concerned for the network and your coins getting flustered in this thread isn't going to help anything. I am working to rectify the problem (which is something I've never come across before, hence the delay and the reason it occurred to begin with) and will release a fix as soon as possible. If you're concerned, leave your wallet closed until a known fix is released.

Thanks

subSTRATA

legendary

Activity: 1288

Merit: 1043

:^)

Quote from: ElBurro on September 06, 2014, 01:32:55 PM

Quote from: miningpoolhub on September 06, 2014, 12:45:33 PM

Current maxcoin source has fatal error, can be fork anytime like what darkcoin suffered few months ago. There's no test time. It's disaster. Fix it now.

To Dev. Don't debug now. Just revert. This is what Darkcoin team had done on blockchain forking. checkpoint resync is not a easy problem to debug.

If the dev is going to have to rollback anyway why are people wasting resources mining it right now?

And blocks are being found much faster than what was stated.

Something is definitely not right with block rate (quick analysis shows it is around 2 or 3 blocks per minute - it should be around 1) or difficulty calculation is wrong somewhere.

goombaloon

newbie

Activity: 17

Merit: 0

You need to launch with the -reindex param. This will (eventually) sync up. However, as mentioned elsewhere, you must keep the wallet open at that point. Otherwise, the next time you open the wallet you'll get stuck again and will have reindex again.

Obviously, this isn't the final solution, but it works until the final solution is sorted out and implemented.

ElBurro

member

Activity: 101

Merit: 10

Quote from: miningpoolhub on September 06, 2014, 12:45:33 PM

Current maxcoin source has fatal error, can be fork anytime like what darkcoin suffered few months ago. There's no test time. It's disaster. Fix it now.

To Dev. Don't debug now. Just revert. This is what Darkcoin team had done on blockchain forking. checkpoint resync is not a easy problem to debug.

If the dev is going to have to rollback anyway why are people wasting resources mining it right now?

And blocks are being found much faster than what was stated.

Spoetnik

legendary

Activity: 1540

Merit: 1011

FUD Philanthropist™

Quote from: miningpoolhub on September 06, 2014, 12:45:33 PM

Quote from: Spoetnik on September 06, 2014, 12:26:15 PM

just searched the windows QT and daemon .exe's and the keyword "resync" was NOT found.

snippagnessnesslessness
To Dev. Don't debug now. Just revert. This is what Darkcoin team had done on blockchain forking. checkpoint resync is not a easy problem to debug.

agreed and you sound like you know what your talking about with all your comments Wink

and i searched in the .exe and -reindex does in fact exist and is prob what Luke meant to say originally i think.. not -resync

i vote what he said.. roll it back or what ever dev
i don't care just make it work LOL

Spoetnik

legendary

Activity: 1540

Merit: 1011

FUD Philanthropist™

Quote from: BTCspoon on September 06, 2014, 12:29:45 PM

Quote from: Spoetnik on September 06, 2014, 12:26:15 PM

just searched the windows QT and daemon .exe's and the keyword "resync" was NOT found.

Try -rescan

that DOES show up..
but the description i think says that is for attempting to find missing transactions,
so i am not sure that would help current related issues.

more importantly i was pointing out that the dev posted trouble shooting help for a command that does not exist.
he says..

Quote

After a few minutes you should see your wallet begin to sync once more. If the problem persists, please close the wallet and re-open it with the “-resync” flag.

you'll be waiting Wink

that command won't do anything LOL
you might as well put this on your shortcut --waitdumbass
this is not the first time coin devs have done that.. i have seen some of them post commands that don't exist before hahahha

so guys.. your welcome ahaha
i just saved you some time pissing around trying something pointless and wasting your time.

Luke i don't wanna be a dick.. ok will i do a little, hell i'm Spoetnik dammit Cool

but, i wanna say your not coming across as a very "competent" dev here bra..
you best be hitting up Shakezulu's "Cloning coins for fun and profit" tutorial some more dawg LOL

this has turned into a debacle hahha

The Max coin wallet update has turned into The Crypto-Fappening Saga

Oh and i am trying to re-download the block chain With-Out my Wallet.dat and my conf with nodes added (required for connections)

miningpoolhub

legendary

Activity: 1456

Merit: 1006

Mining Pool Hub

Quote from: Spoetnik on September 06, 2014, 12:26:15 PM

just searched the windows QT and daemon .exe's and the keyword "resync" was NOT found.

Start the daemon with -reindex and do not restart the daemon. It will be broken again when the daemon restarts.
This is the only way I found it working.
It will load blockchain from scratch so few hours will be needed to catch up.

But, this kind of fork can happen again. It happened about 600067 block height
and 1gh, miningpoolhub, dwarfpool all stopped at that moment.
Any pool could find new block for about 5 hours at that moment, getting weird proof-of-work error.

I think community need to vote or gather opinions about reverting to pre-hardfork block height.

And I can't trust recent checkpoint resync source code.
Even wallets can sync with -reindex option, it has two problem.
- It cannot be restarted, or it will be not able to sync again. -reindex and wait few hours again.
- It can be splitted to several blockchain again like which happened at 600067 block height.

I tested several times, seems like to work by copying blockchain which was piled upto less than 600000.
enforcecheckpoint timing issue or whatever.. it's broken.

Current maxcoin source has fatal error, can be fork anytime like what darkcoin suffered few months ago. There's no test time. It's disaster. Fix it now.

To Dev. Don't debug now. Just revert. This is what Darkcoin team had done on blockchain forking. checkpoint resync is not a easy problem to debug.

miningpoolhub

legendary

Activity: 1456

Merit: 1006

Mining Pool Hub

Quote from: subSTRATA on September 06, 2014, 11:02:51 AM

Quote from: miningpoolhub on September 06, 2014, 10:52:46 AM

Quote from: maxcoinproject on September 06, 2014, 10:23:22 AM

Quote from: subSTRATA on September 06, 2014, 10:02:37 AM

Quote from: miningpoolhub on September 06, 2014, 09:40:42 AM

Actually checkpoint is not needed for hardfork. Hardfork don't need to be holding 51% major hash.

Not even major hashrate is needed for successful hardfork - what new nodes must do is ignore any node which does not comply to the new ruleset, it is as easy as that. Even
some coins laughed at by most people did it right (see Flappycoin, if node is not at least v3.1 it will end up ignored immidiately, you will never ever see it connect even for a split
second) but instead of just using what worked - which is what they did in the first place by cloning Bitcoin - so called developers opted for some untested techniques and stuff
that realy make no sense.

Unfortunately the wallet version was not updated with the client so we cannot do this until the majority of users has updated to the most recent fix. Once this happens we will ban previous versions.

Instructions for updating to the most recent version can be found at http://maxcoinnews.net/maxcoin-0-9-2-1-release/

Well coins don't determine to disconnect by the version information since it will behave abnormally when connected to malicious peer.
Validating block's reward amount and block hash is already implemented to check peer to peer and it disconnects automatically from the hardfork.

Client version doesn't do anything. You can implement to force disconnect from reading the version info but don't need to do that. It's implemented already on all altcoins.

If node reports old version ignore it else connect to it (or accept connection) and proceed with additional checks (block hash and so on). That is the way only few altcoins work.

With current hardfork, block reward amount changed and block reward is checked by all altcoins.
If block reward from the other peer does not matches local wallet's block reward calculation, then it disconnects.

All altcoins have this implemented.

BTCspoon

full member

Activity: 238

Merit: 100

Quote from: Spoetnik on September 06, 2014, 12:26:15 PM

just searched the windows QT and daemon .exe's and the keyword "resync" was NOT found.

Try -rescan

Spoetnik

legendary

Activity: 1540

Merit: 1011

FUD Philanthropist™

just searched the windows QT and daemon .exe's and the keyword "resync" was NOT found.

ElBurro

member

Activity: 101

Merit: 10

1gh appears to be finding 3 or so blocks a minute. That can't be right....

Spoetnik

legendary

Activity: 1540

Merit: 1011

FUD Philanthropist™

stuck.. still.. followed instructions
http://maxcoinnews.net/maxcoin-0-9-2-1-release/

602571 blocks
and -resync flag or --resync flag on my windows shortcut is not doing anything i think.

Spoetnik

legendary

Activity: 1540

Merit: 1011

FUD Philanthropist™

https://bitcointalk.org/index.php?topic=771511.new#new

added update info in my topic in the main section to help spread the word..

coa032

hero member

Activity: 602

Merit: 500

Quote from: coa032 on September 06, 2014, 10:54:28 AM

I think there's a option to leave a message in wallet...if you know what I mean. You can leave a message in 0.9.1 wallet that everybody who use it needs to change to 0.9.2 or something like that.

bump
dev is it possible to do this?

Topic: [ANN][MAX] MAXcoin - PoW, ASIC Resistance, Keccak GPU Mining - page 51. (Read 914556 times)