INFO: Starting snowfall on snow\snowblossom.0\snowblossom.0.snow with seed 'snowblossom.0' size 1073741824, MULTIPLICITY 128
Exception in thread "Thread-6" java.lang.OutOfMemoryError: Java heap space
at java.nio.HeapByteBuffer.<init>(Unknown Source)
at java.nio.ByteBuffer.allocate(Unknown Source)
at snowblossom.SnowFall.fillSnowMonster(SnowFall.java:230)
at snowblossom.SnowFall.<init>(SnowFall.java:86)
at snowblossom.miner.AutoSnowFall.run(AutoSnowFall.java:49)
Jun 06, 2018 12:37:17 AM snowblossom.miner.SnowBlossomMiner printStats
INFO: Mining rate: 0.0/sec
why mining rate 0? this work?
So what is happening here is that it is trying to create the snow fields that you need to mine and then running out of RAM. I'm guessing this is a pretty small VM? I haven't done much testing with systems small than 2gb in RAM. |
|
|
|
Hmm yeah I'm getting this:
Jun 05, 2018 6:24:35 PM snowblossom.miner.SnowBlossomMiner$BlockTemplateEater onNext
INFO: Work block load error: java.lang.RuntimeException: Unable to select a field of at least 3. Availible: [0, 1]
Jun 05, 2018 6:24:37 PM snowblossom.SnowFall <init>
INFO: Initial write complete
Jun 05, 2018 6:24:42 PM snowblossom.miner.SnowBlossomMiner$BlockTemplateEater onNext
INFO: Got block template: height:3050 transactions:1
Jun 05, 2018 6:24:42 PM snowblossom.miner.SnowBlossomMiner$BlockTemplateEater onNext
INFO: Required field: 3 - ocelot
Jun 05, 2018 6:24:42 PM snowblossom.miner.SnowBlossomMiner$BlockTemplateEater onNext
INFO: Work block load error: java.lang.RuntimeException: Unable to select a field of at least 3. Availible: [0, 1]
Jun 05, 2018 6:24:50 PM snowblossom.miner.SnowBlossomMiner printStats
INFO: Mining rate: 0.0/sec
Jun 05, 2018 6:24:50 PM snowblossom.miner.SnowBlossomMiner printStats
INFO: we seem to be stalled, reconnecting to node
Jun 05, 2018 6:24:50 PM snowblossom.miner.SnowBlossomMiner subscribe
INFO: Subscribed to blocks
Jun 05, 2018 6:24:50 PM snowblossom.miner.SnowBlossomMiner$BlockTemplateEater onNext
INFO: Got block template: height:3050 transactions:1
Jun 05, 2018 6:24:50 PM snowblossom.miner.SnowBlossomMiner$BlockTemplateEater onNext
INFO: Required field: 3 - ocelot
Jun 05, 2018 6:24:50 PM snowblossom.miner.SnowBlossomMiner$BlockTemplateEater onNext
INFO: Work block load error: java.lang.RuntimeException: Unable to select a field of at least 3. Availible: [0, 1]
So you need to either enable auto_snow in miner.conf to make field 3 or download it from here: https://snowblossom.org/snowfields/index.htmlAh, auto_snow is running: INFO: Initial write complete Just give it time. We are making the output more clear on that in the next release (already fixed in code). |
|
|
|
When launching node.bat on my test rig :
juin 05, 2018 1:20:14 PM snowblossom.db.rocksdb.JRocksDB <init>
INFOS: Loadng RocksDB with path snowdb
Exception in thread "main" java.lang.ExceptionInInitializerError
W10, java updated, rig rebooted
Try setting in your node.conf: db_type=lobstack This is a known issue. We had more notes about it, but might have been lost in a wiki fire. |
|
|
|
|
Fun fact, we load tested over 1.6 million transactions in testnet.
|
|
|
|
When you mean rough edges, do you include the website? Because it's like I timetraveled back to 2000.
Yeah, our team has a lot more backend programming talent that web design skills. Also didn't want to do the standard glowing circuits over black obelisks with lightning storms in the background. |
|
|
|
We've launched Snowblossom. Clean, Original Code. Custom POW. UTXO Built into Blocks Headers. Truly ASIC, Miner Centralization, and Quantum Resistant. No Premining. We're looking for legitimate involvement and interest. https://snowblossom.org/https://github.com/snowblossomcoin/snowblossomThe features we enable include: 1. Aggressive IO based PoW with large deterministic files should be very hard to ASIC in any sort of cost effective way 2. Quantum Resistance - Large RSA key support 3. UTXO root hash in block header to be able to give provable results to light clients It has the usual features as well: Child-pays-for-parent (CPFP) Transaction immutability Resilient peer-to-peer network Decentralized design Halfing-block reward over time First Seen First Added FSFA (double-spend protection) Thanks for your time. Spin up a node a check it out. There are still some rough edges, but everything is working. |
|
|
|
any chance to have dockerfile included in the project for easier deployment?
Maybe. Can you school me? Lets assume I'm familiar with cloud hosting servers (EC2, GCE) but have never messed with docker. Is it possible to get persistent SSD with that? (Or some persistent storage. An electrum server can't just run, it needs a pretty big database that takes a while to build or download. |
|
|
|
Great project. Keep up the good work, fireduck!
Thanks! I'm seeing a few more jelectrum servers running, which is great. |
|
|
|
|
I have looked as well without seeing anything. My guess is that the developers are:
1) Long on bitcoin in general (and have some from the old cheap days)
2) Professionals outside of bitcoin open source and have real jobs
So they are probably doing fine and not asking for anything. The hosting costs are probably pretty minimal. That is just my guess.
Someone could start and org that takes donations and uses the funds to run electrum servers.
|
|
|
|
I have a question about SSL versions. I have a java electrum server and with new versions of jvm it doesn't allow connections using SSLv2 or SSLv3. Here is a summary of what versions exist: http://en.wikipedia.org/wiki/Transport_Layer_Security#CipherIn short, for security reasons it would be good to go to TLSv2 as soon as is reasonable. Before I go on, I should note that this has nothing to do with the security of your bitcoin, your keys or your seed. All the SSL link is protecting is the privacy of which addresses you ask an electrum server about. This isn't super important because we are mostly using self-signed certs and these connections could be main in the middled already. So anyways, existing clients can't connect to my servers via SSL since the java SSL implementation wants some flavor of TLS now. The client python code does: ssl.wrap_socket(s, ssl_version=ssl.PROTOCOL_SSLv23, ... In new versions of python, SSLv23 doesn't mean SSLv2 or 3 only, it actually means anything not SSLv1. So after people start running newer python, this setting of SSLv23 will be fine. However it probably would be better to call for PROTOCOL_TLSv1_2 at some point. So really nothing needs be done. In my testing it looks like some of the existing python electrum servers support TLS 1.2 already. |
|
|
|
It is also possible that everything is fine, and jerks are just generating testnet blocks two hours in the future to mess with me.
Well, not to mess with you but because they can. Of course, if you generate a single block at the full difficulty you'll reorg out a wad of those blocks that came after you... so they shouldn't be blocking you from mining, only potentially from mining at difficulty 1. Sure. I've managed to do the testing I intended by accidentally having my node misbehave enough to isolate itself from the network and then build some blocks on my own side chain. |
|
|
|
|
It is also possible that everything is fine, and jerks are just generating testnet blocks two hours in the future to mess with me.
|
|
|
|
|
I'm pretty sure there is some bug somewhere in the block template caching relative to the testnet special difficulty after 20 minutes.
I just generated a block by commenting out a line.
pow.cpp
GetNextWorkRequired
I commented out this line:
if (pblock->GetBlockTime() > pindexLast->GetBlockTime() + Params().TargetSpacing()*2)
In my testing, the difference between
pindexLast->GetBlockTime() and pblock->GetBlockTime() is always 6004.
My guess is that something is creating a template block and then not updating it because there are no new transactions and because the next target hasn't changed. And the next target isn't changing because the block time is never changing.
But some of that is guesswork and I'm not sure.
|
|
|
|
|
If it is indeed working correctly, why do all the recent found blocks have a much higher hash than the target I am seeing (both before and after the block is found)?
"previousblockhash" : "00000000680260e45f57f0cdbe264366aa5095b4b60cbdf47b3a89b416b5d228",
"previousblockhash" : "00000000b76a0528040b33a15c474261c799ac626fcc889754d01e37f0351a36",
"target" : "00000000000003a2d80000000000000000000000000000000000000000000000",
Looking at the recent blocks, it appears they are coming in almost exactly every 20 minutes. I imagine the code that drops the difficulty (in testnet) if there are no blocks takes effect then. Maybe the node finding them has a clock set a few seconds ahead such that it sees the 20 minutes elapsed and makes a new block before I see the difficulty adjustment. I'm checking every second and am not seeing the window.
|
|
|
|
I've tried this with 0.8 release branch, 0.9 and head. I get the same results for each. The getdifficulty returns 1.0 and the found blocks confirm that this seems to be the case. However, getblocktemplate is showing a much harder difficulty in the target: 00000000000003a2d80000000000000000000000000000000000000000000000 Broken up for readability: 00000000000003a2 d800000000000000 0000000000000000 0000000000000000 For that difficulty it should be something like: 0000000100000000 0000000000000000 0000000000000000 0000000000000000 The most recent found block agrees with this: 0000000076f8abad2 ./bitcoind -testnet getblocktemplate ...transactions omitted... "coinbasevalue" : 2500081729, "target" : "00000000000003a2d80000000000000000000000000000000000000000000000", "mintime" : 1424334619, "mutable" : [ "time", "transactions", "prevblock" ], "noncerange" : "00000000ffffffff", "sigoplimit" : 20000, "sizelimit" : 1000000, "curtime" : 1424334619, "bits" : "1a03a2d8", "height" : 323482 } ./bitcoind -testnet getdifficulty 1.00000000 I'm trying to run some blocks on testnet to make sure my mining pool software still works correctly.  |
|
|
|
|
To answer a question that you didn't ask, you can absolutely use multiple electrum clients with the same seed. Each client will sync up on start and see whatever transactions it might have missed from the other clients and everything is cool.
I do this all the time.
|
|
|
|
I've just done some testing and my alternative server (Jelectrum) seems to work with 2.0b2 without issue. There are some new (and old) methods that my server doesn't support, but 2.0b2 doesn't seem to call them: blockchain.address.listunspent blockchain.address.get_balance blockchain.address.get_proof blockchain.address.get_mempool blockchain.utxo.get_address https://github.com/fireduck64/jelectrum |
|
|
|
|
jelectrum:
Saved block: 00000000000000001c5b4fd3a8ae6150f5a8c0e869ece137307cae59a8dd83b8 - 316980 - 1024 (1.138 seconds)
Saved block: 00000000000000001f9e4d8b0e9ae8d5a45f9d8f3afd249bc1b451ac9b556389 - 316981 - 1702 (2.313 seconds)
Saved block: 0000000000000000174fd2b47b1a8420217b7cdb3d2269c521cb9f35d06afeb2 - 316982 - 713 (0.924 seconds)
Saved block: 000000000000000029000da8903b3df605b111e91b9f18bea9503e53c22b3091 - 316983 - 1732 (2.068 seconds)
Saved block: 00000000000000001fc3cdede940822b24a29cbdda760547fcaab961b145c468 - 316983 - 1689 (0.955 seconds)
electrum-server:
INFO:electrum:blockchain: 316980 (15.073s)
INFO:electrum:blockchain: 316981 (35.007s)
INFO:electrum:blockchain: 316982 (21.482s)
INFO:electrum:blockchain: 316983 (39.583s)
INFO:electrum:blockchain reorg 316983 0000000000000000174fd2b47b1a8420217b7cdb3d2269c521cb9f35d06afeb2 000000000000000029000da8903b3df605b111e91b9f18bea9503e53c22b3091
Both of these were running at the same time on the same hardware. Jelectrum does seem to import blocks a lot faster.
|
|
|
|
|
"Unknown method - blockchain.address.listunspent"
Looks like I have work to do.
|
|
|
|
|
Show Posts
