lol i never voted.
i think Quit is currently best served by staying as is.

i'm curious. what happened to exclusive coin to make the chain over 1.1million blocks ??

i'm tyring to find the specs for carboncoin.

is it purely pow ? and how many coins in circulation ?
thanks.


edit
ok i see from http://www.blocktree.io/e/CARBON
there's about 15 billion coins, and i scanned a few blocks and all seemed pow.

is pos on the agenda ??

awesome, i have received said emails with said privkeys

ofc now i need to get them clients going on so i can import them.
thank you swisscex. lol

comkort are currently having problems with the chain apparently. and have suspended trading for the nonce.

https://comkort.com/cryptocurrency/eccoin

one thing i was thinking about, was whether it would be useful to create a very low overhead client/daemon.
i found the ECC daemon quite intensive and didnt like sharing it's resources.

i let my daemon die :p
so i'm just restarting and getting lots of that old checkpoints malarkey,
but i find that it generally fixes itself but i'm also restarting it every 2 hours which also seems to help when it does get stuck.

hopefully it'll be sunc fairly soon

i have put it back and it is fine.
seemed i wasnt up to that block (of the checkpoint).
i took out that checkpoint. compiled.
then it synced fine on the correct chain.
i put the checkpoint back. compiled.
all is good now.

except i'm waiting for comkort to update so i can withdraw


..
i must remember to explain myself better :p

compiled new version as daemon


getblocks -1 to 00000000000000000000 limit 500
received block c840f08a2eb692cddc17
ERROR: GetSyncCheckpoint: block index missing for current sync-checkpoint ae2e43c35a3346fa798a0a356ca7a4bce57885ee64e4319295f7f3b7210944f1
ECC: checkpoints.cpp:190: bool Checkpoints::CheckSync(const uint256&, const CBlockIndex*): Assertion `mapBlockIndex.count(hashSyncCheckpoint)' failed.




does that mean i need to resync again
:p


edit.
i took that checkpoint out of checkpoints.h, recompiled, and seems to be syncing fine now.
..
am now running the "official" code. and all is well.

word is that Exclusive daemon is a bit of a hog :p

will experiment without it and see how EEC syncs with new version.

cool. good to know it's not just me

the vps is a digital ocean one. on the amsterdam3 group.
it does seem a bit slow/laggy but that may well be related to physical location.

do you use digital ocean. if so what location is yr exclusive daemon running ?
i'm going to have to consider my options if it doesnt want to play friendly ...

..

twoturtles/syntaks
could you tell me what code you cloned for this version ? just curious.

i run a few daemons on a vps.

ExclusiveCoind is not that friendly it seems.

i left it running after syncing with one other daemon. and it lost sync and is several hundred blocks behind.

now looking at the debug - while the other daemon is running it gets a new block between 20 - 60 secs .
without it running it loads about 2/second


edit.
hmm seems the vps itself is laggy .. will have to test further

sorry i was tired and didnt really re-read my post so it was a bit scattered.

what i thought worth mentioning was >>

once i started ExclusiveCoind, then immediately it was generating lots of timeouts. not before. and this stopped after stopping ExclusiveCoind.

the other thing is that the debug.log was rapidly filling up. i will have to link it to /dev/null because it is far too big too quickly.
the getblock and processblocks entries were very fast and furious.

..
the other parts were questions really . i havent seen such a flurry of text before and i am curious ..
why why why ??

i have zero balance so i guess then that >>

received block 97839171ec906a734277
ProcessBlock: ORPHAN BLOCK with hash = 97839171ec906a734277, prevHash=82e8dab6440$
sending new getBlocks request from 02d4f1d14895027d1d240fbf947a364ee663f653ce1763$

is to do with other wallets minting ? or other chains trying to get accepted ??


similarly then the getblocks mayhave been related to multiple chains ? i guess i should try it with connecting only to seemingly synced nodes.

often the explorers take time to show new balances for address
but it should show the transaction in the block before it reconciles against the address.

>> try putting the tx id into the Blockcoin Super Search field.

strangely it was syncing nicely with 7 connections, couple hundred blocks left when i thought i would start the ExclusiveCoind. ( this same thing happened twice. below is from the second time)

then ECCoind started timing out. this is the transition. it just keeps timing out with random blocks being accepted.

ProcessBlock: ACCEPTED
trying connection 110.209.69.190:19118 lastseen=3.9hrs
received block 06c5093b43887d9cf25c
END: nStakeReward = 11255479 , CoinAge = 16433
SetBestChain: new best=06c5093b43887d9cf25c  height=687031  trust=1656361975363$
ProcessBlock: ACCEPTED
received block 85bd1d22bc4ed8b69040
END: nStakeReward = 8668493 , CoinAge = 12656
SetBestChain: new best=85bd1d22bc4ed8b69040  height=687032  trust=1656361989449$
ProcessBlock: ACCEPTED
connection timeout
trying connection 77.168.16.33:19118 lastseen=369988.4hrs
connection timeout
trying connection 99.192.9.251:19118 lastseen=2.6hrs
connection timeout
trying connection 110.211.33.129:19118 lastseen=369988.4hrs
connection timeout
trying connection 82.73.189.107:19118 lastseen=4.6hrs




after stopping ExclusiveCoind it starts working again.


edit.
as a further bonus. once it was in sync (#687329) with the explorer it started doing this


getblocks 218605 to 00000000000000000000 limit 500
  getblocks stopping at limit 219104 8eb1d719662893601a6e
getblocks 218605 to 00000000000000000000 limit 500
  getblocks stopping at limit 219104 8eb1d719662893601a6e
getblocks 218605 to 00000000000000000000 limit 500                   x100



then

received block 0a9392183b484dd32625
ProcessBlock: ORPHAN BLOCK with hash = 0a9392183b484dd32625, prevHash=322b35efd49e946e617c
sending new getBlocks request from 02d4f1d14895027d1d240fbf947a364ee663f653ce1763fdb7728a2d8053a152 to 0000000000000000000000000000000000000000000000000000000000000000
received block 97d184f6f334b9948b9d                        
                                                                               x10000


my debug.log will be gigs by morning at this rate. lol

ProcessBlock: ORPHAN BLOCK with hash = 97d184f6f334b9948b9d, prevHash=0a9392183b484dd32625



EDIT: pah. here... daemon appears in sync with BE

getinfo
{
    "version" : "v2.4.3.0",
    "protocolversion" : 60011,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "newmint" : 0.00000000,
    "stake" : 0.00000000,
    "blocks" : 687330,
    "timeoffset" : -1,
    "moneysupply" : 18725324198.16433716,
    "connections" : 7,
    "proxy" : "",
    "ip" : "178.62.208.32",
    "difficulty" : {
        "proof-of-work" : 37.53923539,
        "proof-of-stake" : 0.00024414
    },
    "testnet" : false,
    "keypoololdest" : 1431490686,
    "keypoolsize" : 102,
    "paytxfee" : 0.00000000,
    "mininput" : 0.00000000,
    "errors" : ""
}

here's a copy of the first "small" section of my debug.log

http://pastebin.com/edVHdMVx

it keeps filling rapidly up with large chunks of getblock requests. large chunks of orphan blockmessages
and small sections of connection timeouts.

ECC daemon is stuck and repeating this in debug.log numerous time/second

  getblocks stopping at limit 669051 8340463ca77fe621e4e5
getblocks 668552 to 00000000000000000000 limit 500
  getblocks stopping at limit 669051 8340463ca77fe621e4e5
getblocks 668552 to 00000000000000000000 limit 500
  getblocks stopping at limit 669051 8340463ca77fe621e4e5
getblocks 668552 to 00000000000000000000 limit 500
  getblocks stopping at limit 669051 8340463ca77fe621e4e5



edit. restart fixed it.

it doesnt look like we'll even get a chance to pay exhorbitant fees to reclaim our coins.

i'm seeing strange behaviour from my daemon.

start it up.
it is busy for a few minutes - high CPU /MEM usage and will not respond (this seems normal to previous behaviours)
once it's calmed down, to the point where previously it would respond.

it either
a) responds normally

b) responds once then shuts down. eg will give appropriate response to
Banksycoind getinfo
then shut down so next response will be "error: no response from server"

yet to capture anything from debug.log. it seems to be not doing this at the moment.

c) shuts down before responding. eg is running, upon a
Banksycoind listaddressgroupings
shuts down "error: no response from server"

there is nothing obvious in the debug.log and db.log is empty

debug ends with ->

>>> CheckStakeKernelHash: nTimeWeight = 5450902
>>> CheckStakeKernelHash: passed GetKernelStakeModifier
>>> bnCoinDayWeight = 33753, bnTargetPerCoinDay=298528506367175458951681909829523$
>>> CheckStakeKernelHash - hashProofOfStake too much
ThreadRPCServer method=listaddressgroupings



edit.
trying it with a new wallet.dat seems to have fixed it

lol sweet

i was just thinking the low coin count. 7.4 million.
also will help it from diving too low.

looks like pools are still dumping. . .


is there a requirement for the shop owners to hold their quit ?

quit hasnt died yet

and there are a few different options available for payment gateways i've found in the altcoin services section, it's just whether they are applicable to the shops as they are now. which i guess is being compatible with wordpress.

i fucked my daemon up by playing with it
 now it's syncing incredibly slowly

can someone check this hash against block 677930
6224eb1a07113c92fa30a8d92fe992a0a777148f8def044341affea7a0cd6c15

cheers


--
renbit your sig is pointing to the old thread..