Upgraded. Now waiting for client to stop saying checkpoint too old before I send my newly added coins from Cryptsy.
My pool is updated but I still get this message
"Checkpoint is too old..." message is normal, we are preparing TEK for autocheckpointing and the message just means that checkpointing server is not online yet. I just changed the code to not show this message, if you redownload the latest source it will disappear. Thanks, looks like things are getting better. Blocks are getting accepted and no longer being orphaned. |
|
|
|
I found this page https://gist.github.com/laanwj/efe29c7661ce9b6620a7 and it says -maxconnections=<n> - the maximum number of connections, this defaults to 125. Each active connection takes up some memory. Only significant if incoming connections are enabled, otherwise the number of connections will never be more than 8.
The part that I am most interest in is, Each active connection takes up some memory. Only significant if incoming connections are enabled. How much memory would each connection need/use? It doesn't seem that limiting it to values lower than 10 reduce the memory usage much further according to my results. Take for example, a Bitcoin and an altcoin (TekCoin) daemon: The configuration is limited to 3: Bitcoin is currently connected to 3 peers: The memory usage 1702 nobody 13 22 2 720M 304M uwait 653:12 0.00% /usr/local/bin/bitcoind -conf=/usr/local/etc/bitcoin.conf -d For my altcoin, I have limited it to 10 It currently has 8 peers connected The memory usage 29953 nobody 11 52 20 414M 345M wait 1 4:10 4.93% /usr/local/bin/tekcoind -conf=/usr/local/etc/tekcoin.conf I currently have all my coin daemons limited to 3 connections thinking it will save RAM, but it looks like I may not be. Also, is it true that if I have it limited to a value less than 8, then the daemon will not accept incoming connections? |
|
|
|
Wallet not connecting...
my gimpcoin.conf
server=1
listen=1
deamon=1
rpcuser=rpcuser01
rpcpassword=usedtomineblock01
port=15072
rpcport=15073
rpcallowip=*
addnode=137.ip-5-196-4.eu
addnode=gmp.coin-miners.info
You can try adding addnode=gimpcoin.securepayment.cc But it may take a while because all my connection slots are used up at the moment. |
|
|
|
My pool is updated but I still get this message [version] => v2.1.0.0-gf96a5a-noise23
[protocolversion] => 60008
[walletversion] => 60000
[balance] => x.x
[newmint] => x
[stake] => 0
[split threshold] => x
[blocks] => 640767
[moneysupply] => 3612234.97627
[connections] => 3
[proxy] =>
[ip] => x.x.x.x
[PoW difficulty] => 1087.77018474
[PoS difficulty] => 0.00031387
[testnet] =>
[keypoololdest] => 1415783531
[keypoolsize] => 102
[paytxfee] => 0.0001
[errors] => WARNING: Checkpoint is too old. Wait for block chain to download, or notify developers
|
|
|
|
It was just P&D like every other coin, I mined, I dumped took my money and now I wait for next coin, only idiot still hold  LOL Saving this for later. |
|
|
|
By rough estimate, do you mean you expect xnan to be work 16000 Satoshi at the time of your launch?
Or is this # based on the current market price?
This is quite clever, hopefully there is plenty of inventory to backup the demand and drive up the price to the correct levels to match the costs. |
|
|
|
|
By the way if someone is generous enough to fill the Nanite faucet (currently dry), please PM me that you did so. It's not an automatic process.
|
|
|
|
Proof of Work phase is now complete! Now it is PoS only, total XNAN generated from PoW is slightly less than anticipated as PoS blocks took up a couple of blocks.
Total XNAN from PoW: 995,717.36049088
Current Price (avg): 0.00002805 BTC
Total Market Cap: 27.9BTC (Rounded)
Seems that there is more demand than there is supply for Nanite  This should be interesting. |
|
|
|
Thanks I see them. They need to be manually added since it's using an offline wallet. I've also increased the payout amount. I sent 100000 coins to fauset for you but they never showed up
Status: 798 confirmations, broadcast through 4 nodes
Date: 6/11/2014 22:06
To: BLx9BmdVnTMNqevHdUUHYmc4aUF9UV1Kzt
Debit: -100000.00 B1BL3
Net amount: -100000.00 B1BL3
Transaction ID: 72c6d04a778def1695cd56c9d16e8ce84c5fdfaf18faafae6fa6511327dbe26c
|
|
|
|
I can't open or resolve zetacoin.cc
Loads fine here, west coast US. Probably because your ISP's DNS has some name server information cached. It appears that ans01.domaincontrol.com. and ans02.domaincontrol.com. are not answering lookup requests. |
|
|
|
I can't open or resolve zetacoin.cc dig zetacoin.cc
; <<>> DiG 9.8.3-P4 <<>> zetacoin.cc
;; global options: +cmd
;; connection timed out; no servers could be reached
dig zetacoin.cc +trace
; <<>> DiG 9.8.3-P4 <<>> zetacoin.cc +trace
;; global options: +cmd
. 74266 IN NS m.root-servers.net.
. 74266 IN NS l.root-servers.net.
. 74266 IN NS h.root-servers.net.
. 74266 IN NS e.root-servers.net.
. 74266 IN NS g.root-servers.net.
. 74266 IN NS i.root-servers.net.
. 74266 IN NS f.root-servers.net.
. 74266 IN NS j.root-servers.net.
. 74266 IN NS c.root-servers.net.
. 74266 IN NS b.root-servers.net.
. 74266 IN NS d.root-servers.net.
. 74266 IN NS k.root-servers.net.
. 74266 IN NS a.root-servers.net.
;; Received 369 bytes from 192.168.0.10#53(192.168.0.10) in 906 ms
cc. 172800 IN NS g5.nstld.com.
cc. 172800 IN NS c5.nstld.com.
cc. 172800 IN NS l5.nstld.com.
cc. 172800 IN NS h5.nstld.com.
cc. 172800 IN NS f5.nstld.com.
cc. 172800 IN NS a5.nstld.com.
cc. 172800 IN NS d5.nstld.com.
;; Received 325 bytes from 192.5.5.241#53(192.5.5.241) in 456 ms
zetacoin.cc. 172800 IN NS ns78.domaincontrol.com.
zetacoin.cc. 172800 IN NS ns77.domaincontrol.com.
dig: couldn't get address for 'ns78.domaincontrol.com': no more
The problem appears to be with Godaddy: dig NS domaincontrol.com
; <<>> DiG 9.8.3-P4 <<>> NS domaincontrol.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62426
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; QUESTION SECTION:
;domaincontrol.com. IN NS
;; ANSWER SECTION:
domaincontrol.com. 86356 IN NS ans01.domaincontrol.com.
domaincontrol.com. 86356 IN NS ans02.domaincontrol.com.
dig ns78.domaincontrol.com @ans01.domaincontrol.com
; <<>> DiG 9.9.5 <<>> ns78.domaincontrol.com @ans01.domaincontrol.com
;; global options: +cmd
;; connection timed out; no servers could be reached
dig ns78.domaincontrol.com @ans02.domaincontrol.com
; <<>> DiG 9.9.5 <<>> ns78.domaincontrol.com @ans02.domaincontrol.com
;; global options: +cmd
;; connection timed out; no servers could be reached
|
|
|
|
New coins: - Nanite
- B1bl3coin
- Aricoin
- Dogecoin
- Peercoin
- Unobtanuim
|
|
|
|
A few new coins added: - Gold Reserve
- Uro
- FireFlyCoin
Merged mining is still under development. Are you running the mining secure site I don't see any post or much info about the site. is there another forum where it is located. Yes I am. Right now the main forum is this post. Once this post gets busy enough I'll setup a dedicated forum. You can also follow the twitter feed https://twitter.com/SecurePaymentCCI mine tak coin mostly with you, why are so many double of the same block showing up such as 764673 comes up twice then 87 and so on. this happens a lot and some times I get a bunch of orphans all grouped togther. and like this 4 of them 764722: 2014-10-24 15:59:54 GMT-5 | Pending 764721: 2014-10-24 15:59:05 GMT-5 | Pending 764719: 2014-10-24 15:58:31 GMT-5 | Pending 764719: 2014-10-24 15:58:31 GMT-5 | Pending 764719: 2014-10-24 15:58:31 GMT-5 | Pending 764719: 2014-10-24 15:58:31 GMT-5 | Pending Currently the front end grabs the block number from what ever the mining pool software logs in the database. For this reason the block heights are not always going to be accurate with low difficulty coins. There are modifications pending on the front end so it grabs the height from the coin's network using the block hash (getblock) instead. This will be applied when I roll out the new payment infrastructure sometime in early Q2 of 2015. The technical explanation behind the duplications/orphans in groups is that your client submitted several valid shares (solutions) for the same block at a very high rate. The mining pool has a built-in wait time of 1 second between RPC calls to prevent a self inflicted DoS attack, and sometimes there can be a slow response to RPC calls when the coin's network is receiving several new blocks per second. If your client is submitting several solutions per second (as shown above), you'll see duplication. The system later validates each block on an individual bases using the block hash not the block number/height (which is why you see PENDING initially for up to an hour). You'll get paid for the valid block accepted by the network. The orphans are unfortunately a side effect of low difficulty coins with fast block times. |
|
|
|
A few new coins added: - Gold Reserve
- Uro
- FireFlyCoin
Merged mining is still under development. Are you running the mining secure site I don't see any post or much info about the site. is there another forum where it is located. Yes I am. Right now the main forum is this post. Once this post gets busy enough I'll setup a dedicated forum. You can also follow the twitter feed https://twitter.com/SecurePaymentCC |
|
|
|
i got my Zeta from Mintpal to my bittrex account
Same here, though my Bitcoins are still nowhere to be found. The ZET is more important anyway  |
|
|
|
send change back to the origin.
Thanks to CIYAM above, I now understand why this is not possible. You can't modify existing UTXO's, that's the reason for the blockchain's existence  . |
|
|
|
It doesn't really matter much if you *re-use* addresses for change (the address is not the relevant thing - the UTXO *is* so each change UTXO is still another UTXO regardless of what address it is tied to).
Thanks for explaining this, now I get it.  |
|
|
|
Thanks for the fast response. change addresses are *essential* due to the fact that all UTXOs are fully spent when you create a tx that uses them.
I understand that it must fully spend. My question is why does it need to send a new address? Can't it send back to the original address, the wallet's first address? Your issue with tiny amounts will be undoubtedly due to the way you have received your BTC It's the reverse. I started out with for example 1 BTC in my wallet and sent out several small payments over a period of several months. In short you *can't clean it up without paying fees* as you have too many very small UTXOs (lesson to be learned - don't get so many small amounts - they are more of a hassle than they are really worth). Lesson indeed learned. Would have using the 'sendmany' function prevented this situation? |
|
|
|
|
I have a wallet that has grown to 25 MB and has 16,915 addresses due to the amount of transactions being made each day.
Why does this happen? I understand the technical behavior behind it. Bitcoin will send 'change' back to a new address in the keypool. But why does it do that? Besides 'anonymity' what is the benefit of breaking up my Bitcoins into smaller and smaller outputs? Is their a technical reason for this? Can it be 'turned off'?
How do I clean this up without having to spend money on fees? It is going to be a very complex transaction if I want to send all these tiny outputs to a single input, and that will probably end up costing a very large transaction fee. Also from what I understand, it might not get mined due to the large amount of small inputs.
|
|
|
|
|
Show Posts
