Search content
Sort by
Showing 20 of 26 results by maxeprom
Re: PhoenixMiner 5.9d: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)
Hi all,
I posted this question couple of days before, but was deleted. I wonder why, since it's fully on-topic, and perhaps a simptom of a problem woth PhoenixMiner (or it's just me, but the question is honest).
Well, the cas is I got an out of memory problem mining ETC (eth classic) with my 3GB nVidia GTX1060, since a couple of days ago.
Coincidentally with change to epoch #238 (5.9d say's to be good up to epoch #240 and 3gb cards should be able to mine etc until june/22 or so).
Any one with the same issue?
This is the command line:
./PhoenixMiner -pool us1-etc.ethermine.org:4444 -wal 0xblablabla -worker myworker -pass x -coin etc
This is the output:
Phoenix Miner 5.9d Linux/gcc - Release build
--------------------------------------------
CUDA version: 11.0, CUDA runtime: 8.0
NVML library initialized
Nvidia driver version: 470.86
OpenCL driver version: 20.40-1147287
Available GPUs for mining:
GPU1: ASUS NVIDIA GeForce GTX 1060 3GB (pcie 1), CUDA cap. 6.1, 3 GB VRAM, 9 CUs
GPU2: ASUS NVIDIA GeForce GTX 1060 3GB (pcie 2), CUDA cap. 6.1, 3 GB VRAM, 9 CUs
Eth: the pool list contains 1 pool (1 from command-line)
Eth: primary pool: us1-etc.ethermine.org:4444
Starting GPU mining
Eth: Connecting to ethash pool us1-etc.ethermine.org:4444 (proto: EthProxy)
GPU1: 35C 26% 7W, GPU2: 36C 27% 40W
GPUs power: 47.1 W
Eth: Connected to ethash pool us1-etc.ethermine.org:4444 (172.65.245.119)
Listening for CDM remote manager at port 3333 in read-only mode
Eth: New job #e801904e from us1-etc.ethermine.org:4444; diff: 4000MH
GPU1: Starting up... (0)
GPU1: Generating etchash light cache for epoch #238
GPU2: Starting up... (0)
Eth: New job #764e3116 from us1-etc.ethermine.org:4444; diff: 4000MH
Light cache generated in 2.0 s (22.7 MB/s)
GPU2: Allocating DAG (2.87) GB; good for epoch up to #240
GPU2: Generating DAG for epoch #238
GPU1: Allocating DAG (2.87) GB; good for epoch up to #240
CUDA error in CudaProgram.cu:393 : out of memory (2)
GPU1: CUDA memory: 2.95 GB total, 2.87 GB free
GPU1 initMiner error: out of memory
Fatal error detected. Restarting.
GPU2 initMiner error: Unable to initialize CUDA miner
Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
GPUs: 1: 0.000 MH/s (0) 2: 0.000 MH/s (0)
Hope somebody could help, and thanks in advance for any hint,
I posted this question couple of days before, but was deleted. I wonder why, since it's fully on-topic, and perhaps a simptom of a problem woth PhoenixMiner (or it's just me, but the question is honest).
Well, the cas is I got an out of memory problem mining ETC (eth classic) with my 3GB nVidia GTX1060, since a couple of days ago.
Coincidentally with change to epoch #238 (5.9d say's to be good up to epoch #240 and 3gb cards should be able to mine etc until june/22 or so).
Any one with the same issue?
This is the command line:
./PhoenixMiner -pool us1-etc.ethermine.org:4444 -wal 0xblablabla -worker myworker -pass x -coin etc
This is the output:
Phoenix Miner 5.9d Linux/gcc - Release build
--------------------------------------------
CUDA version: 11.0, CUDA runtime: 8.0
NVML library initialized
Nvidia driver version: 470.86
OpenCL driver version: 20.40-1147287
Available GPUs for mining:
GPU1: ASUS NVIDIA GeForce GTX 1060 3GB (pcie 1), CUDA cap. 6.1, 3 GB VRAM, 9 CUs
GPU2: ASUS NVIDIA GeForce GTX 1060 3GB (pcie 2), CUDA cap. 6.1, 3 GB VRAM, 9 CUs
Eth: the pool list contains 1 pool (1 from command-line)
Eth: primary pool: us1-etc.ethermine.org:4444
Starting GPU mining
Eth: Connecting to ethash pool us1-etc.ethermine.org:4444 (proto: EthProxy)
GPU1: 35C 26% 7W, GPU2: 36C 27% 40W
GPUs power: 47.1 W
Eth: Connected to ethash pool us1-etc.ethermine.org:4444 (172.65.245.119)
Listening for CDM remote manager at port 3333 in read-only mode
Eth: New job #e801904e from us1-etc.ethermine.org:4444; diff: 4000MH
GPU1: Starting up... (0)
GPU1: Generating etchash light cache for epoch #238
GPU2: Starting up... (0)
Eth: New job #764e3116 from us1-etc.ethermine.org:4444; diff: 4000MH
Light cache generated in 2.0 s (22.7 MB/s)
GPU2: Allocating DAG (2.87) GB; good for epoch up to #240
GPU2: Generating DAG for epoch #238
GPU1: Allocating DAG (2.87) GB; good for epoch up to #240
CUDA error in CudaProgram.cu:393 : out of memory (2)
GPU1: CUDA memory: 2.95 GB total, 2.87 GB free
GPU1 initMiner error: out of memory
Fatal error detected. Restarting.
GPU2 initMiner error: Unable to initialize CUDA miner
Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
GPUs: 1: 0.000 MH/s (0) 2: 0.000 MH/s (0)
Hope somebody could help, and thanks in advance for any hint,
Re: PhoenixMiner 5.9d: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)
Got an out of memory problem mining ETC (eth classic) with my 3GB nVidia GTX1060, since a couple of days ago.
Coincidentally with change to epoch #238 (5.9d say's to be good up to epoch #240 and 3gb cards should be able to mine etc until june/22 or so).
Any one with the same issue?
Command line:
./PhoenixMiner -pool us1-etc.ethermine.org:4444 -wal 0xblablabla -worker myworker -pass x -coin etc
Output:
Phoenix Miner 5.9d Linux/gcc - Release build
--------------------------------------------
CUDA version: 11.0, CUDA runtime: 8.0
NVML library initialized
Nvidia driver version: 470.86
OpenCL driver version: 20.40-1147287
Available GPUs for mining:
GPU1: ASUS NVIDIA GeForce GTX 1060 3GB (pcie 1), CUDA cap. 6.1, 3 GB VRAM, 9 CUs
GPU2: ASUS NVIDIA GeForce GTX 1060 3GB (pcie 2), CUDA cap. 6.1, 3 GB VRAM, 9 CUs
Eth: the pool list contains 1 pool (1 from command-line)
Eth: primary pool: us1-etc.ethermine.org:4444
Starting GPU mining
Eth: Connecting to ethash pool us1-etc.ethermine.org:4444 (proto: EthProxy)
GPU1: 35C 26% 7W, GPU2: 36C 27% 40W
GPUs power: 47.1 W
Eth: Connected to ethash pool us1-etc.ethermine.org:4444 (172.65.245.119)
Listening for CDM remote manager at port 3333 in read-only mode
Eth: New job #e801904e from us1-etc.ethermine.org:4444; diff: 4000MH
GPU1: Starting up... (0)
GPU1: Generating etchash light cache for epoch #238
GPU2: Starting up... (0)
Eth: New job #764e3116 from us1-etc.ethermine.org:4444; diff: 4000MH
Light cache generated in 2.0 s (22.7 MB/s)
GPU2: Allocating DAG (2.87) GB; good for epoch up to #240
GPU2: Generating DAG for epoch #238
GPU1: Allocating DAG (2.87) GB; good for epoch up to #240
CUDA error in CudaProgram.cu:393 : out of memory (2)
GPU1: CUDA memory: 2.95 GB total, 2.87 GB free
GPU1 initMiner error: out of memory
Fatal error detected. Restarting.
GPU2 initMiner error: Unable to initialize CUDA miner
Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
GPUs: 1: 0.000 MH/s (0) 2: 0.000 MH/s (0)
Thanks for any hint, cheers,
Coincidentally with change to epoch #238 (5.9d say's to be good up to epoch #240 and 3gb cards should be able to mine etc until june/22 or so).
Any one with the same issue?
Command line:
./PhoenixMiner -pool us1-etc.ethermine.org:4444 -wal 0xblablabla -worker myworker -pass x -coin etc
Output:
Phoenix Miner 5.9d Linux/gcc - Release build
--------------------------------------------
CUDA version: 11.0, CUDA runtime: 8.0
NVML library initialized
Nvidia driver version: 470.86
OpenCL driver version: 20.40-1147287
Available GPUs for mining:
GPU1: ASUS NVIDIA GeForce GTX 1060 3GB (pcie 1), CUDA cap. 6.1, 3 GB VRAM, 9 CUs
GPU2: ASUS NVIDIA GeForce GTX 1060 3GB (pcie 2), CUDA cap. 6.1, 3 GB VRAM, 9 CUs
Eth: the pool list contains 1 pool (1 from command-line)
Eth: primary pool: us1-etc.ethermine.org:4444
Starting GPU mining
Eth: Connecting to ethash pool us1-etc.ethermine.org:4444 (proto: EthProxy)
GPU1: 35C 26% 7W, GPU2: 36C 27% 40W
GPUs power: 47.1 W
Eth: Connected to ethash pool us1-etc.ethermine.org:4444 (172.65.245.119)
Listening for CDM remote manager at port 3333 in read-only mode
Eth: New job #e801904e from us1-etc.ethermine.org:4444; diff: 4000MH
GPU1: Starting up... (0)
GPU1: Generating etchash light cache for epoch #238
GPU2: Starting up... (0)
Eth: New job #764e3116 from us1-etc.ethermine.org:4444; diff: 4000MH
Light cache generated in 2.0 s (22.7 MB/s)
GPU2: Allocating DAG (2.87) GB; good for epoch up to #240
GPU2: Generating DAG for epoch #238
GPU1: Allocating DAG (2.87) GB; good for epoch up to #240
CUDA error in CudaProgram.cu:393 : out of memory (2)
GPU1: CUDA memory: 2.95 GB total, 2.87 GB free
GPU1 initMiner error: out of memory
Fatal error detected. Restarting.
GPU2 initMiner error: Unable to initialize CUDA miner
Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
GPUs: 1: 0.000 MH/s (0) 2: 0.000 MH/s (0)
Thanks for any hint, cheers,
Re: PhoenixMiner 5.9d: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)
⭐ Merited by vapourminer (1)
Wow as Im reading about all these hacks I see a post about 6.0 beta. Reported that ish. DO NOT DOWNLOAD ANY VERSIONS OF ANYTHING FROM "NEW MEMBERS"
Now that you mention about "other" downloads, what about phoenixminer.ORG? It differ's from phoenixminer.INFO?
Re: Looks like some of the big pools in china are having DNS problems
Completely off the grid: https://www.whatsmydns.net/#A/viabtc.com
Not doing great but slowly improving: https://www.whatsmydns.net/#A/poolin.com
Still a bit shaky: https://www.whatsmydns.net/#A/f2pool.com
Not sure if a network issue in the china firewall or what, but it would be interesting to see the failover data stats. One big pool going down like that could cascade to other pools getting knocked out when all the miners fail over to their secondary pools*
Unless they are using bitfury software, as that only allows one pool
Probably by the time you read this it will all be fixed, but its been going on for a while now, not sure how much its affecting mining or just access to the web sites.
Not doing great but slowly improving: https://www.whatsmydns.net/#A/poolin.com
Still a bit shaky: https://www.whatsmydns.net/#A/f2pool.com
Not sure if a network issue in the china firewall or what, but it would be interesting to see the failover data stats. One big pool going down like that could cascade to other pools getting knocked out when all the miners fail over to their secondary pools*
Unless they are using bitfury software, as that only allows one pool
Probably by the time you read this it will all be fixed, but its been going on for a while now, not sure how much its affecting mining or just access to the web sites.
By the time I'm reading this, still no DNS for ViaBTC, Poolin and F2pool :-(
Re: PhoenixMiner 5.6d: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)
The new beta version is finally ready. You can download PhoenixMiner 5.6d from here:
PhoenixMiner_5.6d_Windows.zip (GitHub)
PhoenixMiner_5.6d_Linux.tar.gz (GitHub)
The new features in this release are:
The support for -ttj, -ttmem, -tmaxj, and -tmaxmem for Nvidia 3090 and 3080 GPUs is not yet ready for release. We hope to have it ready for the final 5.6 release.
For more robust integrity check, you can use our GPG public key, which was verifyed with ETH transaction from our main devfee account as explained here: https://bitcointalk.org/index.php?topic=2647654.msg56755869#msg56755869.
Please let us know if you have any problems or questions related to PhoenixMiner 5.6d.
PhoenixMiner_5.6d_Windows.zip (GitHub)
PhoenixMiner_5.6d_Linux.tar.gz (GitHub)
The new features in this release are:
- The problem with the missing GPU temperatures on Nvidia GPUs is fixed
- Added native kernels for AMD RX6700 GPUs. These are faster than the generic kernels and produce a lot less stale shares
- Increase the max supported DAG epoch to 550 (should be enough to about Jan 2023)
- Full support for setting clocks, fan speeds, voltages, and memory timings of AMD RX6900/6800/6700 cards
- The specific hashrate is now shown in the form of kilo hashes per joule (kH/J). Example: if a GPU has hashrate of 30 MH/s with 100W power usage, the specific hashrate is 300 kH/J
- Added new command-line parameters -ttj and -ttmem, allowing automatic fan speed control based on GPU hotspot (junction), and memory temperatures respectively. Example: -ttmem 83 will keep the GPU memory temperature at or bellow 83C by increasing the fan speed as necessary. These parameters can be combined with -tt, as well as with each other. These options are supported only on AMD GPUs that report junction and memory temperatures
- Added new command-line parameters -tmaxj and -tmaxmem, allowing to decrease the GPU usage when the GPU hotspot (junction), or GPU memory temperatures are above the specified thresholds. These options are supported only on AMD GPUs that report junction and memory temperatures
- Added support for AMD Windows drivers 21.3.2, and 21.3.1
- Added support for AMD Linux drivers 20.50.x. Use this drivers only if you have Polaris or older GPUs, or the latest RX6x000 GPUs. WARNING: Vega, Radeon VII, and Navi GPUs won't work with these drivers!
- Turn off the zero fan feature on AMD cards whenever a fixed fan speed is used (e.g. -tt -40), or when an auto fan with min fan speed is used (e.g. -tt 63 -minfan 35). To disable this feature, add -fanstop 1 command-line parameter
- When -mcdag 1 is specified under Linux, the miner will not wait for the daggen.sh script to finish before starting to generate the DAGs. Instead it will for a fixed 7 seconds. This allows you to do all the following in the daggen.sh: turn off the overclocking of Nvidia GPUs, sleep for 30-60 seconds to allow time for DAG generation, and then re-apply the overclocking of the Nvidia GPUs
- Other small improvements and fixes
The support for -ttj, -ttmem, -tmaxj, and -tmaxmem for Nvidia 3090 and 3080 GPUs is not yet ready for release. We hope to have it ready for the final 5.6 release.
For more robust integrity check, you can use our GPG public key, which was verifyed with ETH transaction from our main devfee account as explained here: https://bitcointalk.org/index.php?topic=2647654.msg56755869#msg56755869.
Please let us know if you have any problems or questions related to PhoenixMiner 5.6d.
Why this version from github is different (and bigger) than the version from phoenixminer.info?
Which one is the good one?
It is suspicious that the github account is so recent, please tell me why should i trust it.
Thanks,
Restart the software. Can you try directly connecting one of the publicly available nodes using the 'addnode' command? Node list: https://bitnodes.earn.com/.
Yep! Already try, with about 30 of them, but no better luck. Sometimes got 2 or 3 peers, but they gone in a while. And the "socket recv error" remains a lot.No, the port is ok. I've tested it from other networks, and my ISP ensures network neutrality
BTW, I can run other coins (eg monero) and the btc testnet works fine for me.
Restart the software. Can you try directly connecting one of the publicly available nodes using the 'addnode' command? Node list: https://bitnodes.earn.com/.
Yep! Already try, with about 30 of them, but no better luck. Sometimes got 2 or 3 peers, but they gone in a while. And the "socket recv error" remains a lot.
Hello,
I have installed Bitcoin Core 0.18.1 on my linux box. It has fixed and public IP, and no firewall so port 8333 is ok.
I just ran "bitcoind", starts ok, generates the files at $HOME/.bitcoin, but then complains "socket receive error Connection reset by peer (104)"
forever.
After 24 hours, I got connection with just one node, as it shows netstat and bitcoin-cli getpeerinfo.
Getblockcount is always 0.
I've tryied connecting to testnet (bitcoind -testnet), and no problem. After a minute or two, I got 8 peers, blockchain filesize at .bitcoin/testnet3 increasing, bitcoin-cli returns good info.
But of course, I wan to ran my node on the real net!
What can I do?
Here's some of my debug.log
2019-08-27T04:43:34Z Bitcoin Core version v0.18.1 (release build)
2019-08-27T04:43:34Z Assuming ancestors of block 0000000000000000000f1c54590ee18
d15ec70e68c8cd4cfbadb1b4f11697eee have valid signatures.
2019-08-27T04:43:34Z Setting nMinimumChainWork=000000000000000000000000000000000
0000000051dc8b82f450202ecb3d471
2019-08-27T04:43:34Z Using the 'sse4(1way),sse41(4way)' SHA256 implementation
2019-08-27T04:43:34Z Default data directory /home/btc/.bitcoin
2019-08-27T04:43:34Z Using data directory /home/btc/.bitcoin
2019-08-27T04:43:34Z Config file: /home/btc/.bitcoin/bitcoin.conf (not found, sk
ipping)
2019-08-27T04:43:34Z Using at most 125 automatic connections (1024 file descript
ors available)
2019-08-27T04:43:34Z Using 16 MiB out of 32/2 requested for signature cache, abl
e to store 524288 elements
2019-08-27T04:43:34Z Using 16 MiB out of 32/2 requested for script execution cac
he, able to store 524288 elements
2019-08-27T04:43:34Z Using 8 threads for script verification
2019-08-27T04:43:34Z scheduler thread start
2019-08-27T04:43:34Z HTTP: creating work queue of depth 16
2019-08-27T04:43:34Z No rpcpassword set - using random cookie authentication.
2019-08-27T04:43:34Z Generated RPC authentication cookie /home/btc/.bitcoin/.coo
kie
2019-08-27T04:43:34Z HTTP: starting 4 worker threads
2019-08-27T04:43:34Z Using wallet directory /home/btc/.bitcoin/wallets
2019-08-27T04:43:34Z init message: Verifying wallet(s)...
2019-08-27T04:43:34Z Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 201
0)
2019-08-27T04:43:34Z Using wallet /home/btc/.bitcoin/wallets
2019-08-27T04:43:34Z BerkeleyEnvironment::Open: LogDir=/home/btc/.bitcoin/wallet
s/database ErrorFile=/home/btc/.bitcoin/wallets/db.log
2019-08-27T04:43:34Z init message: Loading banlist...
2019-08-27T04:43:35Z Cache configuration:
2019-08-27T04:43:35Z * Using 2.0 MiB for block index database
2019-08-27T04:43:35Z * Using 8.0 MiB for chain state database
2019-08-27T04:43:35Z * Using 440.0 MiB for in-memory UTXO set (plus up to 286.1
MiB of unused mempool space)
2019-08-27T04:43:35Z init message: Loading block index...
2019-08-27T04:43:35Z Opening LevelDB in /home/btc/.bitcoin/blocks/index
2019-08-27T04:43:35Z Opened LevelDB successfully
2019-08-27T04:43:35Z Using obfuscation key for /home/btc/.bitcoin/blocks/index:
0000000000000000
2019-08-27T04:43:35Z LoadBlockIndexDB: last block file = 0
2019-08-27T04:43:35Z LoadBlockIndexDB: last block file info: CBlockFileInfo(bloc
ks=1, size=293, heights=0...0, time=2009-01-03...2009-01-03)
2019-08-27T04:43:35Z Checking all blk files are present...
2019-08-27T04:43:35Z Opening LevelDB in /home/btc/.bitcoin/chainstate
2019-08-27T04:43:35Z Opened LevelDB successfully
2019-08-27T04:43:35Z Using obfuscation key for /home/btc/.bitcoin/chainstate: 1a
a07bbe3971b111
2019-08-27T04:43:35Z Loaded best chain: hashBestChain=000000000019d6689c085ae165
831e934ff763ae46a2a6c172b3f1b60a8ce26f height=0 date=2009-01-03T18:15:05Z progre
ss=0.000000
2019-08-27T04:43:35Z init message: Rewinding blocks...
2019-08-27T04:43:35Z init message: Verifying blocks...
2019-08-27T04:43:35Z block index 363ms
2019-08-27T04:43:35Z init message: Loading wallet...
2019-08-27T04:43:35Z BerkeleyEnvironment::Open: LogDir=/home/btc/.bitcoin/wallet
s/database ErrorFile=/home/btc/.bitcoin/wallets/db.log
2019-08-27T04:43:35Z [default wallet] nFileVersion = 180100
2019-08-27T04:43:35Z [default wallet] Keys: 2001 plaintext, 0 encrypted, 2001 w/
metadata, 2001 total. Unknown wallet records: 0
2019-08-27T04:43:35Z [default wallet] Wallet completed loading in 10
1ms
2019-08-27T04:43:35Z [default wallet] setKeyPool.size() = 2000
2019-08-27T04:43:35Z [default wallet] mapWallet.size() = 0
2019-08-27T04:43:35Z [default wallet] mapAddressBook.size() = 0
2019-08-27T04:43:35Z mapBlockIndex.size() = 1
2019-08-27T04:43:35Z nBestHeight = 0
2019-08-27T04:43:35Z torcontrol thread start
2019-08-27T04:43:35Z AddLocal(146.83.56.69:8333,1)
2019-08-27T04:43:35Z Discover: IPv4 eth0: 146.83.56.69
2019-08-27T04:43:35Z Bound to [::]:8333
2019-08-27T04:43:35Z Bound to 0.0.0.0:8333
2019-08-27T04:43:35Z init message: Loading P2P addresses...
2019-08-27T04:43:35Z Loaded 282 addresses from peers.dat 35ms
2019-08-27T04:43:35Z init message: Starting network threads...
2019-08-27T04:43:35Z net thread start
2019-08-27T04:43:35Z opencon thread start
2019-08-27T04:43:35Z addcon thread start
2019-08-27T04:43:35Z dnsseed thread start
2019-08-27T04:43:35Z init message: Done loading
2019-08-27T04:43:35Z msghand thread start
2019-08-27T04:43:35Z Imported mempool transactions from disk: 0 succeeded, 0 fai
led, 0 expired, 0 already there
2019-08-27T04:43:36Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:37Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:38Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:38Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:39Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:40Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:40Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:41Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:42Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:43Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:46Z Loading addresses from DNS seeds (could take a while)
2019-08-27T04:43:50Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:50Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:50Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:51Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:52Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:52Z 294 addresses found from DNS seeds
2019-08-27T04:43:52Z dnsseed thread exit
2019-08-27T04:43:53Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:53Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:54Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:54Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:55Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:56Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:57Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:58Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:58Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:59Z socket recv error Connection reset by peer (104)
2019-08-27T04:44:00Z socket recv error Connection reset by peer (104)
2019-08-27T04:44:00Z socket recv error Connection reset by peer (104)
2019-08-27T04:44:01Z socket recv error Connection reset by peer (104)
2019-08-27T04:44:02Z socket recv error Connection reset by peer (104)
...... and so on forever
I have installed Bitcoin Core 0.18.1 on my linux box. It has fixed and public IP, and no firewall so port 8333 is ok.
I just ran "bitcoind", starts ok, generates the files at $HOME/.bitcoin, but then complains "socket receive error Connection reset by peer (104)"
forever.
After 24 hours, I got connection with just one node, as it shows netstat and bitcoin-cli getpeerinfo.
Getblockcount is always 0.
I've tryied connecting to testnet (bitcoind -testnet), and no problem. After a minute or two, I got 8 peers, blockchain filesize at .bitcoin/testnet3 increasing, bitcoin-cli returns good info.
But of course, I wan to ran my node on the real net!
What can I do?
Here's some of my debug.log
2019-08-27T04:43:34Z Bitcoin Core version v0.18.1 (release build)
2019-08-27T04:43:34Z Assuming ancestors of block 0000000000000000000f1c54590ee18
d15ec70e68c8cd4cfbadb1b4f11697eee have valid signatures.
2019-08-27T04:43:34Z Setting nMinimumChainWork=000000000000000000000000000000000
0000000051dc8b82f450202ecb3d471
2019-08-27T04:43:34Z Using the 'sse4(1way),sse41(4way)' SHA256 implementation
2019-08-27T04:43:34Z Default data directory /home/btc/.bitcoin
2019-08-27T04:43:34Z Using data directory /home/btc/.bitcoin
2019-08-27T04:43:34Z Config file: /home/btc/.bitcoin/bitcoin.conf (not found, sk
ipping)
2019-08-27T04:43:34Z Using at most 125 automatic connections (1024 file descript
ors available)
2019-08-27T04:43:34Z Using 16 MiB out of 32/2 requested for signature cache, abl
e to store 524288 elements
2019-08-27T04:43:34Z Using 16 MiB out of 32/2 requested for script execution cac
he, able to store 524288 elements
2019-08-27T04:43:34Z Using 8 threads for script verification
2019-08-27T04:43:34Z scheduler thread start
2019-08-27T04:43:34Z HTTP: creating work queue of depth 16
2019-08-27T04:43:34Z No rpcpassword set - using random cookie authentication.
2019-08-27T04:43:34Z Generated RPC authentication cookie /home/btc/.bitcoin/.coo
kie
2019-08-27T04:43:34Z HTTP: starting 4 worker threads
2019-08-27T04:43:34Z Using wallet directory /home/btc/.bitcoin/wallets
2019-08-27T04:43:34Z init message: Verifying wallet(s)...
2019-08-27T04:43:34Z Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 201
0)
2019-08-27T04:43:34Z Using wallet /home/btc/.bitcoin/wallets
2019-08-27T04:43:34Z BerkeleyEnvironment::Open: LogDir=/home/btc/.bitcoin/wallet
s/database ErrorFile=/home/btc/.bitcoin/wallets/db.log
2019-08-27T04:43:34Z init message: Loading banlist...
2019-08-27T04:43:35Z Cache configuration:
2019-08-27T04:43:35Z * Using 2.0 MiB for block index database
2019-08-27T04:43:35Z * Using 8.0 MiB for chain state database
2019-08-27T04:43:35Z * Using 440.0 MiB for in-memory UTXO set (plus up to 286.1
MiB of unused mempool space)
2019-08-27T04:43:35Z init message: Loading block index...
2019-08-27T04:43:35Z Opening LevelDB in /home/btc/.bitcoin/blocks/index
2019-08-27T04:43:35Z Opened LevelDB successfully
2019-08-27T04:43:35Z Using obfuscation key for /home/btc/.bitcoin/blocks/index:
0000000000000000
2019-08-27T04:43:35Z LoadBlockIndexDB: last block file = 0
2019-08-27T04:43:35Z LoadBlockIndexDB: last block file info: CBlockFileInfo(bloc
ks=1, size=293, heights=0...0, time=2009-01-03...2009-01-03)
2019-08-27T04:43:35Z Checking all blk files are present...
2019-08-27T04:43:35Z Opening LevelDB in /home/btc/.bitcoin/chainstate
2019-08-27T04:43:35Z Opened LevelDB successfully
2019-08-27T04:43:35Z Using obfuscation key for /home/btc/.bitcoin/chainstate: 1a
a07bbe3971b111
2019-08-27T04:43:35Z Loaded best chain: hashBestChain=000000000019d6689c085ae165
831e934ff763ae46a2a6c172b3f1b60a8ce26f height=0 date=2009-01-03T18:15:05Z progre
ss=0.000000
2019-08-27T04:43:35Z init message: Rewinding blocks...
2019-08-27T04:43:35Z init message: Verifying blocks...
2019-08-27T04:43:35Z block index 363ms
2019-08-27T04:43:35Z init message: Loading wallet...
2019-08-27T04:43:35Z BerkeleyEnvironment::Open: LogDir=/home/btc/.bitcoin/wallet
s/database ErrorFile=/home/btc/.bitcoin/wallets/db.log
2019-08-27T04:43:35Z [default wallet] nFileVersion = 180100
2019-08-27T04:43:35Z [default wallet] Keys: 2001 plaintext, 0 encrypted, 2001 w/
metadata, 2001 total. Unknown wallet records: 0
2019-08-27T04:43:35Z [default wallet] Wallet completed loading in 10
1ms
2019-08-27T04:43:35Z [default wallet] setKeyPool.size() = 2000
2019-08-27T04:43:35Z [default wallet] mapWallet.size() = 0
2019-08-27T04:43:35Z [default wallet] mapAddressBook.size() = 0
2019-08-27T04:43:35Z mapBlockIndex.size() = 1
2019-08-27T04:43:35Z nBestHeight = 0
2019-08-27T04:43:35Z torcontrol thread start
2019-08-27T04:43:35Z AddLocal(146.83.56.69:8333,1)
2019-08-27T04:43:35Z Discover: IPv4 eth0: 146.83.56.69
2019-08-27T04:43:35Z Bound to [::]:8333
2019-08-27T04:43:35Z Bound to 0.0.0.0:8333
2019-08-27T04:43:35Z init message: Loading P2P addresses...
2019-08-27T04:43:35Z Loaded 282 addresses from peers.dat 35ms
2019-08-27T04:43:35Z init message: Starting network threads...
2019-08-27T04:43:35Z net thread start
2019-08-27T04:43:35Z opencon thread start
2019-08-27T04:43:35Z addcon thread start
2019-08-27T04:43:35Z dnsseed thread start
2019-08-27T04:43:35Z init message: Done loading
2019-08-27T04:43:35Z msghand thread start
2019-08-27T04:43:35Z Imported mempool transactions from disk: 0 succeeded, 0 fai
led, 0 expired, 0 already there
2019-08-27T04:43:36Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:37Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:38Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:38Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:39Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:40Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:40Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:41Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:42Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:43Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:46Z Loading addresses from DNS seeds (could take a while)
2019-08-27T04:43:50Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:50Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:50Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:51Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:52Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:52Z 294 addresses found from DNS seeds
2019-08-27T04:43:52Z dnsseed thread exit
2019-08-27T04:43:53Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:53Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:54Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:54Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:55Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:56Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:57Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:58Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:58Z socket recv error Connection reset by peer (104)
2019-08-27T04:43:59Z socket recv error Connection reset by peer (104)
2019-08-27T04:44:00Z socket recv error Connection reset by peer (104)
2019-08-27T04:44:00Z socket recv error Connection reset by peer (104)
2019-08-27T04:44:01Z socket recv error Connection reset by peer (104)
2019-08-27T04:44:02Z socket recv error Connection reset by peer (104)
...... and so on forever
Re: [ANN] [SUMO] SUMOKOIN - 🔏 Digital Cash For Highly-Confidential Transactions 🔏
If they change to ASIC and bitmain can use their recently launched cryptonight ASIC to secure the network, i guess its not a bad idea at all.
PS: I dont hold any SUMO.
PS: I dont hold any SUMO.
The point is ASICs are not intended to secure netowrks, and furthermore tend to centralize.
Not to mention the impairment to small miners.
PS. I mine SUMO, now, not sure I should hold them
Re: [ANN] [SUMO] SUMOKOIN - 🔏 Digital Cash For Highly-Confidential Transactions 🔏
really? back to cryptonight and ASICs? Have you not followed what happened to Electroneum? They had the attack and then were forced to fork the ASICs off (is just happening).
I can understand that you would like to move away from CN-heavy, it uses too much resources on the mining side, why not move to IPBC/BITTUBE or other variant on CN-lite? Or if you like the 2MB scratchpad, why not CN7?
I can understand that you would like to move away from CN-heavy, it uses too much resources on the mining side, why not move to IPBC/BITTUBE or other variant on CN-lite? Or if you like the 2MB scratchpad, why not CN7?
They said "We believe in Decentralization ASICs bring to a Cryptocurrency since they are a vital part of the eco system.
and this could provide only good for Sumo."
So, Sumo Team *wants* ASICs
Hi guys,
Has anybody been in trouble with turtle.atpool.party?
Since yesterday seems to be not sinchroized (according to it's dashboard) and has stopped paying in the last 24 hours, but continues mining and finding blocks.
Unfortunately that pool has no further info.
Already moved to another pool, but it would be nice to know.
Cheers,
Has anybody been in trouble with turtle.atpool.party?
Since yesterday seems to be not sinchroized (according to it's dashboard) and has stopped paying in the last 24 hours, but continues mining and finding blocks.
Unfortunately that pool has no further info.
Already moved to another pool, but it would be nice to know.
Cheers,
Re: 1 Trillion coin supply you say? That's not really that many actually...
One Trillion Turtles: Coin Supply and Unit Economics @_turtlecoin https://medium.com/@turtlecoin/one-trillion-turtles-coin-supply-and-unit-economics-5bfbea0aa1f1
The highlight from that article, remove the decimal places from these coins and this is how many units there are of each coin.
1 Trillion + 2 decimals is less than 21 Million + 8 decimals.
I can do 2 decimal math in my head, 8 decimals, not so much...
1 Trillion sounds big compared to 21million, as soon as you remove the decimal and focus on actual units, it turns out to be less.
The highlight from that article, remove the decimal places from these coins and this is how many units there are of each coin.
Code:
TRTL: 100,000,000,000,000
BTC: 2,100,000,000,000,000
IOTA: 2,779,530,283,277,761
LTC: 8,400,000,000,000,000
ETH: 97,879,990,190,000,000,000,000,000
BTC: 2,100,000,000,000,000
IOTA: 2,779,530,283,277,761
LTC: 8,400,000,000,000,000
ETH: 97,879,990,190,000,000,000,000,000
1 Trillion + 2 decimals is less than 21 Million + 8 decimals.
I can do 2 decimal math in my head, 8 decimals, not so much...
1 Trillion sounds big compared to 21million, as soon as you remove the decimal and focus on actual units, it turns out to be less.
That's easy for YOU to say... I mean... That requires actually using your brain and doing simple math.
The crypto world is inundated with low IQ miners and/or investors. Simple math simply does not compute.
I'm afraid numerical scales are not unversal.
For my understanding as I learned at school:
1,000,000 = 1 million
1,000,000,000,000 = 1 billion (or a million of millions)
1,000,000,000,000,000,000 = 1 trillion (or a million of -previous- billions)
... and so on.
so, I think we better state numbers instead of words :-)
Cheers,
ya están minando
y donde baja uno la wallet para poder minar tambien?
mmmhhh, al conectarse a pool.cryptoluka.cl sale algo distinto a lo de la foto :-/
Re: [ANN] #3 [XUN] UltraNote is READY, Everyone is welcome to mine.
Not unhappy, but worried about several hours without blocks.
And worried because interested in this good coin XUN.
And worried because interested in this good coin XUN.
Yes, More blocks been found now, and you are still not happy!!!
Well, no blocks for almost 14 hours, suddenly 25 blocks straight in less than an hour, but now the blockchain seems to be stucked at #33871 again, we don't know for how long.
Could be profitable anyway, but that's not what we miners expect, though.
Really? 37 blocks with a reward of about $80 worth of XUN coins don't pay a day mining?
37 blocks found in 24 hours. Doesn't pay even the electricity! 
Well, no blocks for almost 14 hours, suddenly 25 blocks straight in less than an hour, but now the blockchain seems to be stucked at #33871 again, we don't know for how long.
Could be profitable anyway, but that's not what we miners expect, though.
Re: [ANN] #3 [XUN] UltraNote is READY, Everyone is welcome to mine.
Really? 37 blocks with a reward of about $80 worth of XUN coins don't pay a day mining?
37 blocks found in 24 hours. Doesn't pay even the electricity!
Well, no blocks for almost 14 hours, suddenly 25 blocks straight in less than an hour, but now the blockchain seems to be stucked at #33871 again, we don't know for how long.
Could be profitable anyway, but that's not what we miners expect, though.
Re: [ANN] #3 [XUN] UltraNote is READY, Everyone is welcome to mine.
If I use XUN for transfer transactions, will my transaction record be protected and others will not see my records?
That's the problem with XUN right now. Your TX is ok, but hours between blocks, will take days for it to be completed.
Not quite reliable, IMHO
Re: [ANN] #3 [XUN] UltraNote is READY, Everyone is welcome to mine.
Yes, We are working on the issue. Just be patient and wait for difficulty to drop down
The network hashrate increased almost 10x.
3 hours hav passed, and no new blocks.
Weird !
The network hashrate increased almost 10x.
3 hours hav passed, and no new blocks.
Weird !
