[ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer!

[Crljeni]

This shit coin needs to go back into development stage and re-launch at block 16k in a couple of weeks when all bugs are patched.
I'm out.

EDIT: Sandor shut your pool down, and your nodes. We need to kill the coin to get some attention from the dev.

What are we doing here? Trying daily to sync wallet !!!???

[primer-]

Heres another bug that cripples the database

ERROR: HashBurnData() : Burn transaction does not meet minimum number of confirmations 0 < 6
ERROR: CheckProofOfBurnHash() : hash doesn't match nBurnBits
        ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff > 000000023e1c0000000000000000000000000000000000000000000000000000
ERROR: bool CTxDB::LoadBlockIndex() : deserialize error on PoB index 16034
Error loading blkindex.dat

[rfcdejong]

Anyone that has had syncing issues and has investigated it, please give me your *detailed* input please.

What I have noticed is that:

PoB blocks have DoS protection that bans good nodes if too many orphan PoB blocks are sent.
PoB blocks cannot be orphaned (yet), if an orphaned PoB block is sent, it will get rejected and not recorded anywhere.

I put such DoS protection to prevent any malicious activity, but it seems it is doing more harm that good.

I do not think the issue is in the PoS blocks. As for the stop at block 16000, I will have to create a hard fork from there, that is if I see more people wanting such fork.

The intermediate burn hash fix that takes affect at block 17000 fixes: A PoB block can be falsely rejected due to inaccuracy in floating point precision between two different machines. Some nodes will accept it and others will not (and this will not be able to get to the other blocks after it). This intermediate burn hash fix, does fix this, it is not a patch.

I wish i knew what the problem is, if it's PoS which causes issues then better remove PoS at all. Which open doors

Do you know which code is added / changed for dcrypt and PoB ? If so and if doable i suggest to take a fork from vertcoin, ignore the Script-N PoW and implement code for dcrypt and PoB. Remove the PoS which causes only trouble combined with PoB. All i know is that vertcoin has the best code vs litecoin by directly adding code from bitcoin.

And ofcourse offer a way to switch coins, best would be to let the new wallet work with the current blockchain, but that might be impossible because there is already PoS done. Maybe allow a service to exchange old coins to the new coins. Also burned coins should be able to be 'transfered' into the new coins.

[rfcdejong]

Heres another bug that cripples the database

ERROR: HashBurnData() : Burn transaction does not meet minimum number of confirmations 0 < 6
ERROR: CheckProofOfBurnHash() : hash doesn't match nBurnBits
        ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff > 000000023e1c0000000000000000000000000000000000000000000000000000
ERROR: bool CTxDB::LoadBlockIndex() : deserialize error on PoB index 16034
Error loading blkindex.dat

That happens when you have blocks in your blockchain newer than the latest valid block from another 'fork', a corrupted blockchain..

The dev could perhaps add a condition to be able to skip that a hash of "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"

[LIghtvelocityCoin]

totally give up. 
Watch you guys play. 

[bitspender]

Just post the pool's config file, so we can all sync on those nodes!!

[rfcdejong]

Just post the pool's config file, so we can all sync on those nodes!!

After a relaunch if you ask me, it would be nice when the wallet is also fixed so they don't get stuck on PoS or PoB blocks...

[rfcdejong]

pool is jumping back in blocks anyway, from 16148 back to 16080


slimcoin   2014-6-15 15:54:29 UTC   16080   0000001fcbf2d2f5ff2e304d4517f38b69ac384623f78534bde921b5e8392174   15.04   immature
slimcoin   2014-6-15 15:49:19 UTC   16148   0000001558f86806b2ea117cc1085bcd4573307ffbf91df13bafd8e6007be65e   14.63   immature

[rfcdejong]

pool is jumping back in blocks anyway, from 16148 back to 16080


slimcoin   2014-6-15 15:54:29 UTC   16080   0000001fcbf2d2f5ff2e304d4517f38b69ac384623f78534bde921b5e8392174   15.04   immature
slimcoin   2014-6-15 15:49:19 UTC   16148   0000001558f86806b2ea117cc1085bcd4573307ffbf91df13bafd8e6007be65e   14.63   immature

and again from 16157 down to 16082

slimcoin   2014-6-15 17:34:44 UTC   16082   0000000485f1de64dd4d33d978c39ebf0f60fdb6b99c653aa3ef8981ba4bcbf9   14.97   immature
slimcoin   2014-6-15 17:31:45 UTC   16157   0000002419e0d82cefc25ae9d7e05ef7301af2223ceb2e80e800eccd649f1c16   15.96   immature


I would love to see the debug logs of that

The dev will need it too

[AizenSou]

Today is holiday so everyone's taking a break. sandor111 is no where to find. Happy instamining, dude. I'm out.

[reflector]

are there any working nodes right now?

[rfcdejong]

are there any working nodes right now?

i have no idea at the moment, will see tomorrow.. currently my wallets are down and i'm mining monero with gpu and cpu
but the pool isn't really "instamine".. even thru it finds almost all blocks because it's the only one in the front of the chain..

the block target of 90 seconds is in place

[amanno44]

are there any working nodes right now?

i have no idea at the moment, will see tomorrow.. currently my wallets are down and i'm mining monero with gpu and cpu
but the pool isn't really "instamine".. even thru it finds almost all blocks because it's the only one in the front of the chain..

the block target of 90 seconds is in place

What speeds would you say a 7950 could pull with monero...I'm getting about 25-30 h/s with my cpu

[rfcdejong]

are there any working nodes right now?

i have no idea at the moment, will see tomorrow.. currently my wallets are down and i'm mining monero with gpu and cpu
but the pool isn't really "instamine".. even thru it finds almost all blocks because it's the only one in the front of the chain..

the block target of 90 seconds is in place

What speeds would you say a 7950 could pull with monero...I'm getting about 25-30 h/s with my cpu

i think it will do ~200 h/s, but that is just a suggestion. And it seems your cpu is slow My 4770 does ~200 h/s

[jadefalke]

with 200h/s how many monero do you get per day?

[rfcdejong]

Anyone that has had syncing issues and has investigated it, please give me your *detailed* input please.

What I have noticed is that:

PoB blocks have DoS protection that bans good nodes if too many orphan PoB blocks are sent.
PoB blocks cannot be orphaned (yet), if an orphaned PoB block is sent, it will get rejected and not recorded anywhere.

I put such DoS protection to prevent any malicious activity, but it seems it is doing more harm that good.

I do not think the issue is in the PoS blocks. As for the stop at block 16000, I will have to create a hard fork from there, that is if I see more people wanting such fork.

The intermediate burn hash fix that takes affect at block 17000 fixes: A PoB block can be falsely rejected due to inaccuracy in floating point precision between two different machines. Some nodes will accept it and others will not (and this will not be able to get to the other blocks after it). This intermediate burn hash fix, does fix this, it is not a patch.

We need an official statement about this!

Are blocks past 17000 the fix for the wallet being stuck? Or simply a high possibility? What about the blockchain getting corrupted everytime the network falls back blocks? One small error results into a big domino effect crumbling the current relative small distributed peer-to-peer network. Starting up as a decentralized network having some masternodes is a good solution to fix the sync problems when the wallet is fixed.

imo - Steps to take:

After the official statement work to be done something like this

1) Fix the wallet - is the 17000+ block enough?
2) Setup 6 master nodes on test network
3) Setup 3 seed nodes on test network
4) Alter OP topic with addnodes to the master nodes
5) Switch nodes to normal network and make it a fair relaunch at block 16000 - instruct pool owners

PS: Let others setup some master nodes until the network speed is secure, write a guide

[rfcdejong]

with 200h/s how many monero do you get per day?

With a mining difficulty of 300000000 nearly 1 XMR a day, yes the diff is high!

but the diff is even higher...
2014-Jun-15 22:54:12.010615 BH: 86883, DIFF: 410702438, HR: 6845040 H/s

look at http://pool.cryptoescrow.eu/ and see you get only 0.67 XMR with 200 h/s

[slimcoin]

Are blocks past 17000 the fix for the wallet being stuck? Or simply a high possibility? What about the blockchain getting corrupted everytime the network falls back blocks? One small error results into a big domino effect crumbling the current relative small distributed peer-to-peer network. Starting up as a decentralized network having some masternodes is a good solution to fix the sync problems when the wallet is fixed.

The origin for the blockchain forks is the PoB block discrepancies in hashes. All blocks after 17000 will be fixed of that. The blockchain corruption you talk about is not really corruption and is an easy fix, I am working on now.

It does look like a good idea to have a fair relaunch at block 16000 with a few master-nodes as currently, no one but a select few people on the correct blockchain are able to mine. Also, a relaunch would get everyone on the same place. Anyone that has comments about this, I would like to hear your ideas.

Also, adding a DNS seed node would definitely add stability to the network.

[tilteer]

Do we lose the coins we already have if there is a relaunch?

[reflector]

Are blocks past 17000 the fix for the wallet being stuck? Or simply a high possibility? What about the blockchain getting corrupted everytime the network falls back blocks? One small error results into a big domino effect crumbling the current relative small distributed peer-to-peer network. Starting up as a decentralized network having some masternodes is a good solution to fix the sync problems when the wallet is fixed.

The origin for the blockchain forks is the PoB block discrepancies in hashes. All blocks after 17000 will be fixed of that. The blockchain corruption you talk about is not really corruption and is an easy fix, I am working on now.

It does look like a good idea to have a fair relaunch at block 16000 with a few master-nodes as currently, no one but a select few people on the correct blockchain are able to mine. Also, a relaunch would get everyone on the same place. Anyone that has comments about this, I would like to hear your ideas.

Also, adding a DNS seed node would definitely add stability to the network.

Relaunch at 16000 sounds good.  I can host a DNS seed node if need be.