|
Hi,
Need just a quick heads up on setting up 1-2 local p2pool nodes...
- where can we get the latest version of the code?
- any specific considerations?
Thank you!
|
|
|
|
Every bit's appreciated, but we really need more like 2EH.
So 2 blocks in one week with (less than) 2PH and then even less than 1PH... or am I wrong? At least that's what https://miningpoolstats.stream/bitcoin reported anyway... Mining difficulty is now lightyears higher than it was back then, and the pool was bigger for periods during (the now defunct) halongmining burn in. 29. ckpool.org 1.13 PH/s 617393 7 hours |
|
|
|
Every bit's appreciated, but we really need more like 2EH.
So 2 blocks in one week with (less than) 2PH and then even less than 1PH... or am I wrong? At least that's what https://miningpoolstats.stream/bitcoin reported anyway... BTW my recent observations on multiple pools reveal a completely different/opposite picture than the popular opinion goes. Looks like smaller pools with fewer competing miners improve the overall pool efficiency, I guess it could be due to small pools by design/usage "relieve" the inevitable technical bottlenecks any large pool has. Just an intuitive guess of mine. |
|
|
|
Hello, I am one of them. I would like to understand how the SLR initial claim amount is calculated. I have asked for through the contact form on solarcoin.org website and to support (got a ticket number) but I didn't get any feedback. It seems no one at solarcoin.org is reading members inquiries. So, may be someone here can help me ? After registering my solar facility with solarcoin.org I have received the initial Solarcoin grand amount on November, 6th. This amount is 19.33 SLR. Transaction details : État: 20783 confirmations Date: 06/11/2019 05:17 De: Unknown À: 8XnZogQjgTKoRCEGRdVnZaMqg3C6mKHAQg (votre propre adresse, étiquette: Solarcoin.org) Crédit: 19.33000000 SLR Montant net: +19.33000000 SLR Transaction comment: text:AGRT-FR-31530-13699-2.94-7960-04/06/2010-11/01/2019 ID de la transaction: 2497ad8eec74c0a106bdaed1c801022576cb24e31e116d12bc17085739e75839 According to rules stated on solarcoin.org website, it should be as follow : "The annual calculation is 365 days X 24 hrs X 15% X Your KW Nameplate Capacity/1000. This works out to 1.314 X your installed KW Nameplate Capacity. The initial SolarCoin grant is retroactive to the install date of your facility or Jan 1, 2010; whichever is more recent. Ongoing SLR grants are made every 6 months based the facility install month." My solar installation nameplate capacity is 2.94 kWc. The install date is April 6th, 2010. Around 9.6 years ago. So, according to the formula, initial SLR grant amount should be around : 1.314 x 2.94 x 9.6 = 37.08 SLR How to explain the huge discrepancy with the SLR amount I have received ? Thank you. Hi, Earlier this year the "retroactive back to Jan 1 2010" was changed to "5 years back rolling", here is one of the announcements (on FB): https://www.facebook.com/groups/solarcoin/permalink/1189937807873418/Here is the linked post on Medium: https://medium.com/solarcoin/claim-your-solarcoin-now-each-day-passing-could-be-a-lost-reward-67b50c8e30a5I bet if you do the calculation according to this new rule you will get a match to what you received. The website info has been fixed accordingly ONLY in the FAQ section: http://solarcoin.wpengine.com/faqs/"...Earning SolarCoins.... SolarCoins can be granted retroactive to 5 years from the date of the initial claim. If your facility is older than 5 years old, claim now. Each day missed is lost SolarCoin." But as you correctly noticed, the Claim your SolarCoins section https://solarcoin.org/#claiming has NOT been updated accordingly, which needs to be fixed. Also the SolarCoin Policy Papers https://solarcoin.org/resources/ have NOT been updated (just checked the one in English), needs to be updated, too. As you also provided the Transaction comment: text:AGRT-FR-31530-13699-2.94-7960-04/06/2010-11/01/2019 it appears it has NOT been changed to reflect the new 5 years policy. Thank you so much for noticing the discrepancy & sharing your findings with so much detail! In appreciation of your effort I just sent you 100 SLR to your address. |
|
|
|
Oh.. I get it now, thanks again! |
|
|
|
Hi, I do realize this question may have been answered before, but it's a short one anyway: does the BTC pool support bc1 (Bech32 (P2WPKH)) payout addresses? Thanks!
Yes Legacy - 1.... P2SH 3.... bech32 bc1.... Great! Thank you! (fixed btc... to bc1... in your quote) |
|
|
|
|
Hi, I do realize this question may have been answered before, but it's a short one anyway: does the BTC pool support bc1 (Bech32 (P2WPKH)) payout addresses? Thanks!
|
|
|
|
2.1.7.1 is stable.
Good work!
Stable here so far, too. Good work! |
|
|
|
I seem to be back on the long chain again, so far so good
Just installed the new update and reloading blockchain. I will post the results 2.1.7.1 is ready to go. Help->Check for Update, then let me know if you are still having issues. Thanks, again, everyone. -Steve Now it doesn't even try to catch up - it's In Sync right after downloading the bootstrap. I will post a screenshot and a text file with the getpeerinfo. I am connecting from a cellular IP (random within the provider's range). EDIT: will repeat the bootstrap download, just to be sure it got right. EDIT2: Now it works! This time it did sync up to the current Explorer block height, and keeps on syncing. Will now go on to upgrade all wallets. Thank you Steve! Mine wont sync although it says in sync. Im missing about 20 blocks. When I got back from the cellular IP to my regular LAN/WAN setup, syncing stopped altogether - it does say "In Sync" (with a new empty wallet) and would apparently start staking with a non-empty wallet. As per Steve, my regular IP may have been banned for up to 24 hours, but shouldn't it be trying to sync during the ban, instead of staying In Sync and staking at the wrong block height? This time I need to post a snapshot - back here in a few minutes. Let me delete the peers.dat on the master node and see if that helps some of you that may be banned. I'll edit this post when done... EDIT: Done. solarcoiner, can you PM me your debug.log file? OK, I will try it now, but this current logic would still leave the possibility for any IP that gets banned to fork since it will stay In Sync & Staking instead of just hanging in a Syncing state until the ban expires. Or may be that would't be an issue later on? Still the possibility remains that anyone newly connected and syncing will have the (bad) chance to sync to a banned IP and join that fork. EDIT: Just re-loaded the blockchain from the bootstrap, synced to 1456166... took it a while waiting for 94 more blocks, but eventually decided it's In Sync at 1456166. |
|
|
|
I seem to be back on the long chain again, so far so good
Just installed the new update and reloading blockchain. I will post the results 2.1.7.1 is ready to go. Help->Check for Update, then let me know if you are still having issues. Thanks, again, everyone. -Steve Now it doesn't even try to catch up - it's In Sync right after downloading the bootstrap. I will post a screenshot and a text file with the getpeerinfo. I am connecting from a cellular IP (random within the provider's range). EDIT: will repeat the bootstrap download, just to be sure it got right. EDIT2: Now it works! This time it did sync up to the current Explorer block height, and keeps on syncing. Will now go on to upgrade all wallets. Thank you Steve! Mine wont sync although it says in sync. Im missing about 20 blocks. When I got back from the cellular IP to my regular LAN/WAN setup, syncing stopped altogether - it does say "In Sync" (with a new empty wallet) and would apparently start staking with a non-empty wallet. As per Steve, my regular IP may have been banned for up to 24 hours, but shouldn't it be trying to sync during the ban, instead of staying In Sync and staking at the wrong block height? This time I need to post a snapshot - back here in a few minutes. EDIT: uploading snapshot and getpeerinfo.txt, will post links in next edit. In this case it synced up to the lowest (as of the connection time) block height of all current connections. Or may be it has been doing exactly so in my previous observations, too? In any case, it's not (even trying to) syncing to the highest current block height. EDIT2: https://www.dropbox.com/s/b0my1o5ots6wcll/NotUpToDateButInSync.png?dl=0https://www.dropbox.com/s/xgmpb3srp8flfkk/getpeerinfo.txt?dl=0btw looks like there is already a fork from 1456166 on... it's now at 1456176 |
|
|
|
I seem to be back on the long chain again, so far so good
Just installed the new update and reloading blockchain. I will post the results 2.1.7.1 is ready to go. Help->Check for Update, then let me know if you are still having issues. Thanks, again, everyone. -Steve Now it doesn't even try to catch up - it's In Sync right after downloading the bootstrap. I will post a screenshot and a text file with the getpeerinfo. I am connecting from a cellular IP (random within the provider's range). EDIT: will repeat the bootstrap download, just to be sure it got right. EDIT2: Now it works! This time it did sync up to the current Explorer block height, and keeps on syncing. Will now go on to upgrade all wallets. Thank you Steve! |
|
|
|
Thats exactly what I posted yesterday when I temporarily fixed my wallet. However I am still having issues so the problem must be elsewhere
I'm currently trying this again but it just fixes the problem for a few hours and then the wallet gets stuck again...
Did your solarcoin.conf have just the master-node? I just did all the steps on one of the wallets, for the heck of it - same result - stuck in "syncing", every new connection with a smaller startingheight decreases the number of "Blocks Remaining", and the sync halts again. Right now I have 19 connections, non of those is sending my wallet any blocks. The solarcoin.conf has just the master-node in it: addnode=162.243.214.120 Thanks. I suspect you are not receiving blocks because your node is blocked. The block can last for 24 hours. I'm trying to identify the offending nodes, atm. Are the nodes identified/blocked by IP address? Also, I just got In Sync & Stacking. At block 1455297!!! Then it started syncing again, with much fewer block left to sync - it now shows 1455649 as the total number of blocks it is targeting to sync up to. And yes, the wallet started receiving blocks and syncing up to that target. Here is what getpeerinfo is showing for the several connections that just came in: { "addr" : "92.135.75.153:17445", "services" : "00000003", "lastsend" : 1478972794, "lastrecv" : 1478972758, "conntime" : 1478971893, "version" : 70005, "subver" : "/Satoshi:2.1.7/", "inbound" : true, "startingheight" : 1456003, "banscore" : 0 }, { "addr" : "40.112.185.197:1280", "services" : "00000003", "lastsend" : 1478972331, "lastrecv" : 1478972065, "conntime" : 1478972065, "version" : 70005, "subver" : "/Satoshi:2.1.7/", "inbound" : true, "startingheight" : 1455934, "banscore" : 0 }, { "addr" : "37.112.117.122:63750", "services" : "00000003", "lastsend" : 1478972110, "lastrecv" : 1478972107, "conntime" : 1478972107, "version" : 70005, "subver" : "/Satoshi:2.1.7/", "inbound" : true, "startingheight" : 1455297, "banscore" : 0 }, { "addr" : "125.193.49.2:56917", "services" : "00000003", "lastsend" : 1478972250, "lastrecv" : 1478972785, "conntime" : 1478972164, "version" : 70005, "subver" : "/Satoshi:2.1.7/", "inbound" : true, "startingheight" : 1456006, "banscore" : 0 }, { "addr" : "24.186.0.49:20986", "services" : "00000003", "lastsend" : 1478972252, "lastrecv" : 1478972250, "conntime" : 1478972249, "version" : 70005, "subver" : "/Satoshi:2.1.7/", "inbound" : true, "startingheight" : 1454513, "banscore" : 0 }, { "addr" : "81.247.156.211:18188", "services" : "00000003", "lastsend" : 1478972769, "lastrecv" : 1478972770, "conntime" : 1478972560, "version" : 70005, "subver" : "/Satoshi:2.1.7/", "inbound" : false, "startingheight" : 1439173, "banscore" : 0 }, { "addr" : "195.154.185.5:57135", "services" : "00000003", "lastsend" : 1478972723, "lastrecv" : 1478972790, "conntime" : 1478972716, "version" : 70005, "subver" : "/Satoshi:2.1.7/", "inbound" : true, "startingheight" : 1456015, "banscore" : 0 }, { "addr" : "174.57.202.216:49976", "services" : "00000003", "lastsend" : 1478972759, "lastrecv" : 1478972759, "conntime" : 1478972757, "version" : 70005, "subver" : "/Satoshi:2.1.7/", "inbound" : true, "startingheight" : 1455649, "banscore" : 0 } ] Now it is in sync & stacking at block 1455675. I have disabled staking (obviously why). I am re-confirming my observations:
I have been encountering the same issue as reported in the several previous posts - after upgrading to 2.1.7 and running fine for just a while, I am not able anymore to correctly sync any of 6 wallets on 4 machines (also tried connecting through my 4G internet provider to get a brand new IP address thus eliminate possible banning issues, but the result was the same).
There are 2 issues I noticed:
1 - the wallet "decides" it has synced (changes its status to In Sync) the moment it encounters a new connection with a lower startingheight than it's own, or lower than the previous higher height connections it found (I am using the getpeerinfo command from the Console). The wallet then (syncs to) and starts staking at that lower block height (if the total number of connections at that time is >= 3). Then only if it gets a new connection with a higher than it's own block height, it goes to Syncing mode but no blocks get further downloaded (see issue 2 below).
2 - the wallet remains in the state "Syncing" no matter how many connections with a higher startingheight it has. Then later on as soon as it gets accidentally a new connection to a node with a lower startingheight (than it's own or the previously found higher height connections) , it goes to issue 1 above. If the total number of connections at that time is >= 3, it even starts staking at that lower block height.
Right now I have re-loaded the blockchain from the newest bootstrap, up to block 1455297, and trying to sync from there on. I have snapshots of both issues, if needed.
Isn't the protocol originally supposed to choose the highest blockchain? Why does it decide to have synced and starts staking only when it finds a connection with a block height lower than the previously found? Was there any "hot-fix" change made to the basic-level consensus protocol so that the 2.1.6 -> 2.1.7 transition gets propagated faster?
|
|
|
|
Thats exactly what I posted yesterday when I temporarily fixed my wallet. However I am still having issues so the problem must be elsewhere
I'm currently trying this again but it just fixes the problem for a few hours and then the wallet gets stuck again...
Did your solarcoin.conf have just the master-node? I just did all the steps on one of the wallets, for the heck of it - same result - stuck in "syncing", every new connection with a smaller startingheight decreases the number of "Blocks Remaining", and the sync halts again. Right now I have 19 connections, non of those is sending my wallet any blocks. The solarcoin.conf has just the master-node in it: addnode=162.243.214.120 Thanks. I suspect you are not receiving blocks because your node is blocked. The block can last for 24 hours. I'm trying to identify the offending nodes, atm. Are the nodes identified/blocked by IP address? |
|
|
|
Thats exactly what I posted yesterday when I temporarily fixed my wallet. However I am still having issues so the problem must be elsewhere
I'm currently trying this again but it just fixes the problem for a few hours and then the wallet gets stuck again...
Did your solarcoin.conf have just the master-node? I just did all the steps on one of the wallets, for the heck of it - same result - stuck in "syncing", every new connection with a smaller startingheight decreases the number of "Blocks Remaining", and the sync halts again. Right now I have 19 connections, non of those is sending my wallet any blocks. The solarcoin.conf has just the master-node in it: addnode=162.243.214.120 |
|
|
|
All, We have just issued version 2.1.7, protocol version 70005, to fix the problem described below: "The reduced txn fee change caused 2.1.1 nodes to fork because 2.1.6 nodes were not paying enough fees. This in turn caused 2.1.6 nodes to fork sporadically." Please update your Qt wallet ASAP and begin staking so we can get the network moving again. Note: This update requires a Blockchain Reload. This is due to the fact that some 2.1.6 nodes are ahead of the master node, and we want to get everyone one the correct chain. After the reload, please rescan your wallet. If you are running a daemon, you can download the bootstrap.zip here: http://blockexplorer.solarcoin.org/downloads/bootstrap.zipPS: We will be notifying the exchanges and explorer ASAP. The website will be updated later today. PPS: After the rescan, you may see conflicted transactions from earned interest. You will make up the "lost" interest in future stakes. Hi Steve, Please let us know when the Explorer has been updated, so that we are sure we have the correct height there to compare to. Thanks! Yes I was also thinking about that. How do we really know what the real chain is? How do we even know the explorer is on the right chain. Since everyone was on a fork how can we tell? The CryptoID explorer was updated to 2.1.7 yesterday. It is on the same block as the masternode, and we are watching it. The 2.1.7 wallet is on protocol version 70005 and will block any nodes on 70004, so if you are still having syncing issues, please reload the blockchain and rescan your wallet. That works 99.9% of the time, but if not, shut down the wallet, remove your peers.dat and make sure the only addnode in your wallet config is: addnode=162.243.214.120 Also, please ensure that the clock on your computer is set accurately. This is known to cause some nodes to have trouble syncing. Thanks, for your patience. -Steve I have been encountering the same issue as reported in the several previous posts - after upgrading to 2.1.7 and running fine for just a while, I am not able anymore to correctly sync any of 6 wallets on 4 machines (also tried connecting through my 4G internet provider to get a brand new IP address thus eliminate possible banning issues, but the result was the same). There are 2 issues I noticed: 1 - the wallet "decides" it has synced (changes its status to In Sync) the moment it encounters a new connection with a lower startingheight than it's own, or lower than the previous higher height connections it found (I am using the getpeerinfo command from the Console). The wallet then (syncs to) and starts staking at that lower block height (if the total number of connections at that time is >= 3). Then only if it gets a new connection with a higher than it's own block height, it goes to Syncing mode but no blocks get further downloaded (see issue 2 below). 2 - the wallet remains in the state "Syncing" no matter how many connections with a higher startingheight it has. Then later on as soon as it gets accidentally a new connection to a node with a lower startingheight (than it's own or the previously found higher height connections) , it goes to issue 1 above. If the total number of connections at that time is >= 3, it even starts staking at that lower block height. Right now I have re-loaded the blockchain from the newest bootstrap, up to block 1455297, and trying to sync from there on. I have snapshots of both issues, if needed. Isn't the protocol originally supposed to choose the highest blockchain? Why does it decide to have synced and starts staking only when it finds a connection with a block height lower than the previously found? Was there any "hot-fix" change made to the basic-level consensus protocol so that the 2.1.6 -> 2.1.7 transition gets propagated faster? |
|
|
|
All, We have just issued version 2.1.7, protocol version 70005, to fix the problem described below: "The reduced txn fee change caused 2.1.1 nodes to fork because 2.1.6 nodes were not paying enough fees. This in turn caused 2.1.6 nodes to fork sporadically." Please update your Qt wallet ASAP and begin staking so we can get the network moving again. Note: This update requires a Blockchain Reload. This is due to the fact that some 2.1.6 nodes are ahead of the master node, and we want to get everyone one the correct chain. After the reload, please rescan your wallet. If you are running a daemon, you can download the bootstrap.zip here: http://blockexplorer.solarcoin.org/downloads/bootstrap.zipPS: We will be notifying the exchanges and explorer ASAP. The website will be updated later today. PPS: After the rescan, you may see conflicted transactions from earned interest. You will make up the "lost" interest in future stakes. Hi Steve, Please let us know when the Explorer has been updated, so that we are sure we have the correct height there to compare to. Thanks! |
|
|
|
... In the console you can use> getpeerinfo to see the version and blockheight for each of the nodes you are connecting to. could even edit the solarcoin.conf file to start with nodes that are both 2.1.6 and have blockheight similar to figure shown in Chainz explorer. https://chainz.cryptoid.info/slr/#... This was very helpful, thank you Nick! |
|
|
|
Looks like the wallet occasionally reports the wrong amount of coins available also. After a rescan it works itself out. We need some serious bugs fixes.
Yes, same here, its wildly off, I rescanned and reloaded the blockchain and it still cant add up, it seems to be when coins are staked the maths goes wrong. My observation is that this happens when the wallet still gets on the wrong blockchain. I had this going on on 2 separate machines and when the blockchain reload, sync & wallet re-scan was eventually done on the correct blockchain, the balances got right & stable with staking enabled and working. |
|
|
|
1446431 for some reason i am stuck at this block with no hope in sight  update*** completly uninstalled solarcoin again Re downloaded fresh wallet and did not import my wallet used the new one that comes with new install everything was good until i got stuck on same block lol 1446431 Restoring windows on the notebook maybe this will help There's definitely some compatibility issues in this release. My little netbook running windows 7 is running great. Can't get it working on my xp build. It was working (the xp machine) for a few days after "tricking" it with 2.1.1 then upgrading with a fully synchronized wallet, but it crashed and went back to not synching up properly again. Looking for a patch soon. I think it's a forking issue: many of the wallets that are already updated to 2.1.6 are still connecting&staking on the 2.1.1 blockchain, so both forks still go in parallel. One of my active wallets did it, too, even though it had been on the right blockchain for quite a while. I am now trying to put it back on the 2.1.6 blockchain - reloaded blockchain from the bootstrap, disabled staking, connected only to correctly synced 2.1.6 nodes, now will try to resume staking. We have to be checking our wallets for syncing against the blockchain explorer and manually bring them back on the right blockchain (if needed) to help the 2.1.6 hard fork establish itself faster on the network. added observation: after a wallet re-scan, when staking resumes balances on the Overview page get completely out of whack - this happens ONLY IF the wallet is STILL on the WRONG blockchain. |
|
|
|
y_virtual thanks for the tips
Now it says i am in sync but stuck on block 1440601
So maybe... if for any reason that client had gotten on the wrong blockshain...and now you got it on the right one, but it still got blocks from the wrong one (before the sync)... may be those do not get "overwritten" and confuse the client? In which case you may also have to re-download the blockchain and then it will have no forked blocks and will sync up to the correct current block since you are connecting to 2.1.6 nodes only (through the addnode commands)... Just guessing... |
|
|
|
|
Show Posts
