My last pre 2016 block was 0d01310b80cbda7e2b51afbd9401dd2dbba012f193a6ab87d490a322fa5e6574 Status: 1234 confirmations
Date: 16/12/2014 08:09
From: unknown
To: BNYLnzDxoYCn7cvExFGeReeTKe7zSCJo7v (own address, label: iSpace.co.uk:3345)
Credit: 20.94335 RKC
Net amount: +20.94335 RKC
Transaction ID: 0d01310b80cbda7e2b51afbd9401dd2dbba012f193a6ab87d490a322fa5e6574 I am now up to v0.1.3.0-g99999-boc
Build date July 4, 2013
Current number of blocks 367126
Estimated total blocks 329905 Hope this helps. can you check your hash for block 357000 if it's 4e7666bb31c44138b41c78b06b170075ad1d0180108bc8b9bd7e71d2f49d7805 then you have ze official chain !!! that block is check pointed in the OG repo so must be legit. seemingly the one running atm forked about a year ago? at least since (lol i'd be sad cos i've mined a few on this theoretically illigitimate chain.) 19:13:31  getpeerinfo 19:13:31  [ { "addr" : "70.40.55.192:9015", "services" : "00000001", "lastsend" : 1425665587, "lastrecv" : 1425665587, "conntime" : 1425554788, "version" : 60006, "subver" : "/reikicoin:1.9.1/", "inbound" : false, "releasetime" : 0, "startingheight" : 291029, "banscore" : 0 }, { "addr" : "75.130.163.51:9015", "services" : "00000001", "lastsend" : 1425665586, "lastrecv" : 1425665586, "conntime" : 1425663871, "version" : 60006, "subver" : "/reikicoin:1.9.1/", "inbound" : false, "releasetime" : 0, "startingheight" : 290648, "banscore" : 0 } ]  |
|
|
|
hmmm someone performing a reseruction on this coin
I've always had a soft spot for reiki coin  but personally I don't think it'll really survive unless someone modifies staking ages. PoW is too much work lol. with min stake age at 30 days and 1 minute block times, it needs to have a base minimum of 43200 staking inputs to theoretically move on staking alone. With the current teeny network, I'd think something like 1 day min to 7 days max. min of 1 day, makes a base theoretical minimum of 1440 inputs, much more doable/reliable. and the 7 days max to vaguely keep calm the mayhem produced by someone opening an old wallet and staking their entire wallet in 3 seconds flat, if the stake diff was much higher it wouldn't be such a problem .that said I haven't done serious considerations on those numbers, but having the hybrid system helps to keep it moving if one or the other diff gets tremendously skewed, I guess the combine threshold could be rejigged too, I've never heavily considered the math involved in finding a good setting for that so should be interested to hear others opinions. "moneysupply" : 19940633.45941700, |
|
|
|
it also occurs to me that its' plausible that the available clients will not have that coded checkpoint. with this post predating the checkpoint update thx, is need build new demon for my node? it really depends on how old your daemon is, you've been posting for quite a while so maybe it pre-dates the checkpoint commit which will become the issue. AND given that your daemon is syncing fine, you probably don't have that checkpoint. you can also check IF you still have the src you compiled from. see if it matches this line which is the problematic checkpoint. https://github.com/ReikiLVL3/reikicoin/blob/master/src/checkpoints.cpp#L29compiling from my new source with new checkpoints will theoretically help a little in some circumstances as the point of having checkpionts is to hardcode the "official" chain so no fork is possible before those points. so it will only be a problem if anyone comes along with the actual chain matching the official checkpoint at 357000. /// \\\
So I open my wallet which is version "v0.1.3.0-g99999-boc' and it downloaded about 3k blocks and it is in sync and staking. I'll keep the wallet open for a while. The peers that I'm connteced to show
"version" : 60006,
"subver" : "/reikicoin:1.9.1/",
if you're looking for confirmation you're on the same chain, just check johan11's explorer |
|
|
|
If the chain matching "official" git is not found, I have forked the code and added some checkpoints to match current chain. https://github.com/bumbacoin/reikicoinI maybe able to compile a windows source sometime in the future but am currently not able to, I can however compile a mac wallet in the nearby future  I believe the windows qt's available would only have checkpoints hardcoded for block 1. So it is of no immediate hurry/concern as they shouldn't reject block 35700. it also occurs to me that its' plausible that the available clients will not have that coded checkpoint. with this post predating the checkpoint update I might upload a bootstrap as well to keep a copy of the current chain. |
|
|
|
|
lol i can't keep up with compiling these wallets.
hopefully will l have more spare soon ..
|
|
|
|
if anyone want to sync fast here are all my 30 connectionsaddnone=46.233.42.249:35575
addnone=89.178.177.49:64332
addnone=86.127.191.249:1189
addnone=45.63.1.27:50583
addnone=222.190.1.22:35575
addnone=79.136.7.138:58776
addnone=87.159.252.180:5607
addnone=81.162.199.253:4363
addnone=192.52.166.25:35575
addnone=37.59.18.108:44344
addnone=185.77.129.23:35575
addnone=196.210.42.249:5750
addnone=82.66.55.40:50193
addnone=218.156.98.243:5237
addnone=198.50.229.39:44870
addnone=213.202.214.140:355
addnone=79.69.39.40:64708
addnone=88.215.150.2:63554
addnone=88.206.187.247:2401
addnone=84.234.52.190:35039
addnone=82.199.107.147:5178
addnone=93.86.119.180:53138
addnone=139.218.211.177:638
addnone=151.77.195.64:56378
addnone=190.161.133.145:226
addnone=96.44.156.214:46508
addnone=174.19.112.18:56608
addnone=211.162.33.142:2183
addnone=92.233.105.50:50357
To help list Loco on exchange, retwit all my tweets!  lol --- i've been out of the loop for a few days, hopefully tomorrow i'll have time to check where the code is at and compile a new mac version |
|
|
|
Where is this from 1'st person to post the correct answer wins 1.5k Loco
In the land of the ill all things we thought where myths or dead are too fucking real
actually i don't give a shit about this but there's an error in "w here" so i doubt it can be from anywhere unless it's some faulty source or dev was too tired after fixing wallets lol that's probably the challenge. how else could you try a game like this in the land of google i spent a few minutes but couldnt find anything |
|
|
|
lol well you've broken shutdown for teh linux daemon root@vps:~# loco stop
Loco server stopping
root@vps:~# tail -f .loco/debug.log
Successfully synced, asking for Masternode list and payment list
sending: dseg (41 bytes)
sending: mnget (0 bytes)
sending: getsporks (0 bytes)
Successfully synced, asking for Masternode list and payment list
sending: dseg (41 bytes)
sending: mnget (0 bytes)
sending: getsporks (0 bytes)
connection to [2001:0:5ef5:79fb:a2:1206:b08d:ee69]:35575 timeout
ThreadRPCServer method=stop
SecureMsgThread 1462408370
trying connection 104.238.134.122:35575 lastseen=6.8hrs
connection to 104.238.134.122:35575 timeout
SecureMsgThread 1462408390
received: inv (37 bytes)
got inventory: block 5914a6a4c78dbe7ad46efc675e82ba332aa4c3676e1ccd3da34c3ad8000625b7 new
askfor block 5914a6a4c78dbe7ad46efc675e82ba332aa4c3676e1ccd3da34c3ad8000625b7 0 (00:00:00)
sending getdata: block 5914a6a4c78dbe7ad46efc675e82ba332aa4c3676e1ccd3da34c3ad8000625b7
etc |
|
|
|
|
in my transaction history, there is a number of bunches of PoS blocks all registering in the same minute.
is it plausible that the weight/difficulty is so broked that it causes similar weight inputs to stake almost simultaneously?
it would be interesting to compare chains around the forks and see if there is such a string of immediate blocks
-
another thing i noticed is that my Qt is receiving current blocks (42960) while syncing to earlier blocks (40469).
these current blocks register as orphans
(both blocks are valid on the chain my daemon is on)
8c4eb1d37b72091275a487a95890e8935fe2379092163c442db8fb2ab75cb998
ERROR: ProcessBlock() : already have block 40464 b3ad8fe415b9fa1003defd01e38caf44782305e0e8f897b3bbfeef83da99a320
ERROR: ProcessBlock() : already have block 40465 34585821e887e6fedd946cd94e0077c98f61353a13e323bc99b9a14451278fbd
SetBestChain: new best=03e96065257ea4bb4aa7068da4c12b27f4ac9aaf30e098befb70524a366c498d height=40466 trust=4133145183542959785 blocktrust=27541291718550 date=05/03/16 05:46:08
ProcessBlock: ACCEPTED
SetBestChain: new best=2471886cbc49d2ac19a42738e2b8b30671a6cf379dde213ad7d20b79df3ccd6a height=40467 trust=4133176227222266083 blocktrust=31043679306298 date=05/03/16 05:46:24
ProcessBlock: ACCEPTED
SetBestChain: new best=6184ed72977b8f78bf90e58111c620034dc7db1f335e7f9ff926cc190867d2a6 height=40468 trust=4133211218712946099 blocktrust=34991490680016 date=05/03/16 05:46:24
ProcessBlock: ACCEPTED
ProcessBlock: ORPHAN BLOCK 57, prev=00c7e9aa8faa74a1e57e5b9262a67b24e4af7393a88d16c6af6fb2f7aa0cc5b4
SetBestChain: new best=8080c3c3885650a3e0719aa6dbd6a90c85fd0c0260b700977b3517294f2d82ae height=40469 trust=4133252572357021641 blocktrust=41353644075542 date=05/03/16 05:46:56
ProcessBlock: ACCEPTED
ProcessBlock: ORPHAN BLOCK 58, prev=c75ab2afd2e432e24208015329ae0d8937c4303e6369896bf0cf9ede732fb7ca
SetBestChain: new best=8322e51aaaba5e27abb24c9fc78c360f197415fc072a5ad3568cd9331e45dfb2 height=40470 trust=4133297124651987452 blocktrust=44552294965811 date=05/03/16 05:46:56
ProcessBlock: ACCEPTED
ProcessBlock: ORPHAN BLOCK 59, prev=b0db7a75e96e219a069549209507405adf6806bc2010ffb3ae18551dc22c9972
SetBestChain: new best=1d2c0fcbf3a607183606cd3d984fd864ed6ed0f0e79df7b37a56d75353b715b1 height=40471 trust=4133349777433583154 blocktrust=52652781595702 date=05/03/16 05:57:20
ProcessBlock: ACCEPTED
etc
also. note blocks 40469 and 40470 both share the same block time of 1462254416
and belong to the same address.
|
|
|
|
woot another fork i am currently on block 42930 loco getpeerinfo | grep height "startingheight" : 41137, "startingheight" : 31237, "startingheight" : 41301, "startingheight" : 35478, "startingheight" : 41306, "startingheight" : 41306, "startingheight" : 42898, "startingheight" : 42898, "startingheight" : 25409, "startingheight" : 39886, "startingheight" : 42138, "startingheight" : 42911, "startingheight" : 41818, "startingheight" : 42911, "startingheight" : 41303, "startingheight" : 18603, "startingheight" : 42911, "startingheight" : 41137, "startingheight" : 42913, "startingheight" : 41809, |
|
|
|
another way to use nightz copy of the blockchain,
is to only use blk0001.dat, rename it to bootstrap.dat, place it in the datadir and start the qt.
if done correctly, the wallet will import the data from the bootstrap much quicker than downloading from the network.
Holy Batman.. it works.. seems to be.. I deleted everything from data directory except wallet.dat, peer.dat(knightz) and bootstrat.dat. It begun reading bootstrap right away.. didnt even had to importprivkey. haven't finished yet but will check if aforementioned knights block number matches. Old chain didn't match. Thanks a bunch!~!! if using nightz files as he directed, it would have been quicker as the entire chain was pre-loaded, then it would have been a matter of importing yr priv key. personally i generally use it as a bootstrap. i think i've had too many experiences of importing priv key failures :p -- i was wondering if there is any relationship between crazy weight figures and so many forks. perhaps the variances in difficulty between pow and pos are problematic. "netmhashps" : 50.57132355, "netstakeweight" : 1472530330345.55712891, |
|
|
|
|
another way to use nightz copy of the blockchain,
is to only use blk0001.dat, rename it to bootstrap.dat, place it in the datadir and start the qt.
if done correctly, the wallet will import the data from the bootstrap much quicker than downloading from the network.
|
|
|
|
We already raised 2% of the 35 BTC needed. 59.3 assets left.
How many BTC do you need to raise ? We need to raise a minimum of 35 BTC, but our objective is 50 BTC. The project will start as soon as we get 35 BTC. So no more than 50 assets will be distributed. for now. If we received more money we will just send it back. . typo?? |
|
|
|
|
recently compiled osx wallets include
Loco
2bacco
Chipcoin
Guarany
Nuclear
Coin66
|
|
|
|
|
lol.
this is like watching the weather and dodging cyclones
|
|
|
|
|
Show Posts
