Safely way to stop Bitcoin Core client? : Bitcoin

Soo after almost 3 months of setting up I have my own LN full node running on RP3

Soo after almost 3 months of setting up I have my own LN full node running on RP3
I have been eager to try LN mainnet since the very beginning of it. I've found out about lnd, eclair, zap and other wallets but every scenario I tried to use it failed because of critical issues:
  • eclair does not really constitute a wallet, it's more like a credit card - you can send money but not receive it
  • lnd is okay, but requires a server and tons of resources for maintaining a full node, can't be used securely, efficiently and mobily at the same time
  • zap offers some cloud wallet (in testnet!) by default, this is a serious misunderstanding of my cryptoanarchy needs
  • web wallets - ah, forget it
So I've decided to use my Raspberry Pi with a very old laptop HDD attached (200GB so the pruning function has to be used) to create a backend wallet service and zap desktop (temporarily!) as my frontend control panel.
https://preview.redd.it/0vcq147887q11.png?width=1024&format=png&auto=webp&s=7bb6eccdd4110a857e5af0400acc2d7e1ee7ee85
Setting up Pi is easy, lots of tutorials over the internet, not gonna discuss it here. Then I had to obtain bitcoind (current rel: bitcoin-0.17.0-arm-linux-gnueabihf.tar.gz) and lnd (lnd-linux-armv7-v0.5-beta.tar.gz), create a bitcoin technical user, deploy the tools, configure and install new systemd services and go through the configs. This is a tricky part, so let's share:
# Generated by https://jlopp.github.io/bitcoin-core-config-generato # This config should be placed in following path: # ~/.bitcoin/bitcoin.conf # [core] # Set database cache size in megabytes; machines sync faster with a larger cache. Recommend setting as high as possible based upon machine's available RAM. dbcache=100 # Keep at most  unconnectable transactions in memory. maxorphantx=10 # Keep the transaction memory pool below  megabytes. maxmempool=50 # Reduce storage requirements by only storing most recent N MiB of block. This mode is incompatible with -txindex and -rescan. WARNING: Reverting this setting requires re-downloading the entire blockchain. (default: 0 = disable pruning blocks, 1 = allow manual pruning via RPC, greater than 550 = automatically prune blocks to stay under target size in MiB). prune=153600 # [network] # Maintain at most N connections to peers. maxconnections=40 # Use UPnP to map the listening port. upnp=1 # Tries to keep outbound traffic under the given target (in MiB per 24h), 0 = no limit. maxuploadtarget=5000 # [debug] # Log IP Addresses in debug output. logips=1 # [rpc] # Accept public REST requests. rest=1 # [wallet] # Do not load the wallet and disable wallet RPC calls. disablewallet=1 # [zeromq] # Enable publishing of raw block hex to 
. zmqpubrawblock=tcp://127.0.0.1:28332 # Enable publishing of raw transaction hex to
. zmqpubrawtx=tcp://127.0.0.1:28333 # [rpc] # Accept command line and JSON-RPC commands. server=1 # Username and hashed password for JSON-RPC connections. The field comes in the format: :$. RPC clients connect using rpcuser=/rpcpassword= arguments. You can generate this value with the ./share/rpcauth/rpcauth.py script in the Bitcoin Core repository. This option can be specified multiple times. rpcauth=xxx:yyy$zzz
Whooaa, this online config generator is really helpful, but I still had to manually correct a few things. The last line is obviously generated by rpcauth.py, I disabled the wallet functionality as lnd is going to take care of my funds. ZMQ is not available to the network so only my LND can use it, RPC usage I still have to think through a little, in general I would like to have my own block explorer some day but also be safe from any hacking attempts (thus I would need at least 2 RPC ports/user accounts - one for lnd, one for block explorer frontend). No ports open on firewall at this time, only UPnP is active and gently opens 8333 for block/tx transfers.
Now, synchronizing the blockchain took me time from mid-July to early September... The hard drive is really slow, also my external HDD drive has some trouble with its A/C adapter so Pi was getting undervoltage alerts all the time. Luckily, it is just downclocking when it happens and slowly but steadily synchronized the whole history. After all, I'm not paying even $5 monthly for a VPS, it is by design the cheapest hardware I could use to set up my LN wallet.
When bitcoind was ready (I've heard some stories about btcd but I don't trust this software yet, sorry), it's time to configure lnd.conf:
[Application Options] debuglevel=trace rpclisten=0.0.0.0:10009 externalip=X.X.X.X:9735 listen=0.0.0.0:9735 alias=X color=#XXXXXX [Bitcoin] bitcoin.active=1 bitcoin.mainnet=1 bitcoin.node=bitcoind [Bitcoind] bitcoind.rpchost=127.0.0.1 bitcoind.rpcuser=X bitcoind.rpcpass=X bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332 bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333 
Here I've had to XXX a little more fields, as not only the bitcoind RPC credentials are stored here, but also my node's public information (it should be illegal to run nodes without specifically selected color and alias!). It is public (and I had to open port 9735 on my firewall), but not necessarily connected to my reddit account for most of the adversaries, so let's keep it this way. In fact, I also see a security vulnerability here: my whole node's stability depends on the IP being static. I could swap it for a .tk domain but who can tell if the bad guys won't actively fight DNS system in order to prevent global economic revolution? As such, I would rather see node identification in LN based on a public key only with possible *hints* of last-known-ip-address but the whole discovery should be performed by the nodes themself in a p2p manner, obviously preventing malicious actors from poisoning the network in some way. For now, I consider the IP stability a weak link and will probably have to pay extra Bitcoin TX fees when something happens to it (not much of a cost luckily!).

https://preview.redd.it/hjd1nooo77q11.png?width=741&format=png&auto=webp&s=14214fc36e3edf139faade930f4069fc31a3e883
Okay then, lnd is up and running, had to create a wallet and give it a night for getting up to speed. I don't know really what took it so long, I'm not using Windows nor 'localhost' in the config so the issues like #1027 are not the case. But there are others like #1545 still open so I'm not going to ponder much on this. I haven't really got any idea how to automatically unlock the wallet after Pi restart (could happen any time!), especially since I only tried to unlock it locally with lncli (why would I enter the password anywhere outside that host?), but let's say that my wallet will only be as stable as my cheap hardware. That's okay for the beta phase.
Finally, zap-desktop required me to copy tls.cert and admin.macaroon files to my desktop. If my understanding of macaroon (it's like an authentication cookie, that can later be revoked) is correct then it's not an issue, however it would be nice to have a "$50 daily limit" macaroon file in the future too, just to avoid any big issues when my client machine gets stolen. Thanks to this, I can ignore the silly cloud-based modes and have fully-secure environment of my home network being the only link from me to my money.
https://preview.redd.it/11bw3dgw47q11.png?width=836&format=png&auto=webp&s=b7fa7c88d14f22441cbbfc0db036cddfd7ea8424
Aaand there it is. The IP took some time to advertise, I use 1ml.com to see if my node is there. The zap interface (ZapDesktop-linux-amd64-v0.2.2-beta.deb) lacks lots of useful information so I keep learning lncli syntax to get more data about my new peers or the routes offered. The transactions indeed run fast and are ridiculously cheap. I would really love to run Eclair with the same settings but it doesn't seem to support custom lnd (why?). In fact, since all I need is really a lncli wrapper, maybe it will be easy to write my own (seen some web gui which weighs 700MB after downloading all dependencies with npm - SICK!). Zap for iOS alpha test registration is DOWN so I couldn't try it (and I'm not sure if it allows custom lnd selection), Zap for Android doesn't even exist yet... I made a few demo transactions and now I will explore all those fancy t-shirt stores as long as the prices are still in "early investor" mode - I remember times when one could get 0.001 BTC from a faucet...
https://preview.redd.it/42sdyoce57q11.png?width=836&format=png&auto=webp&s=7ec8917eaf8f3329d51ce3e30e455254027de0ee
If you find any of the facts presented by me false, I am happy to find out more in the discussion. However what I did I did mostly for fun, without paying much attention to the source code, documentation and endless issue lists on github. By no means I claim this tutorial will work for you but I do think I shared the key points and effort estimations to help others decide if they want a full-node LN client too. I'm also interested in some ideas on what to do with it next (rather unlikely that I will share my lnd admin.macaroon with anyone!) especially if it gives me free money. For example, I can open 1000 channels and start earning money from fees, although I no longer have more Bitcoins than the LN capacity yields... I will probably keep updating the software on my Pi until it leaves beta phases and only then will pour more money inside. I'm also keen on improving the general security of my rig and those comments I will answer more seriously.
submitted by pabou to Bitcoin [link] [comments]

Inadvisably small full node config

Disclaimer: As the subject implies, this is about an inadvisable config. The following is of zero practical use, but like cross-stitch, may be appealing to the random few people interested in such things. Opinions on the futility of this exercise can be considered already noted. Any suggestions to make this more ridiculously small are very welcome. Obviously I'm not running my primary wallet off of this config. It's just for fun.
TLDR: Wow look, my full node fit on a 0.5 CPU with 0.6 GB memory and 25 GB drive... yeah for me!

Background

I used to run a full node a good ways back, but stopped when the old 3rd string laptop I was using to run it was having drive issues. Still the early interest paid dividends as the price has gone exponential. Missing the good ol' days, I wanted to run another node, but really didn't want to do it on any of my work or lab units. My company took a hard stand years ago to prevent interns from mining on spare HW, so running even a full node on my corporate gear is kinda a capitol punishment. Round about this time, I got some spam for some free VPS service for a year. The promotion were really (I mean really wimpy VPSs). Crappy VPS + bitcoind performance tuning = my kind of waste of time.

Goal

My goal (perverse though it may be), is to get bitcoin or other forks running in very small VPSs. Maybe some of the tuning parameters could be used for a docker container or some whipy SOC. The system I was targeting has 0.5 CPU, 0.6 GB of memory and 25 GB of disk.

Observations

I found some interesting things out along the way that may be of interest to people tweeking bitcoind.

dbcache limits

Since I don't have the requisite memory required to run the node, I've limited memory using the dbcache parameter. Settings range from 100 to 150 depending on what other settings I have in place.

0.15.1 mallocs

I don't know what changed in 0.15.1 but it seems much more memory hungry than previous releases. Throughout the tuning process, I continually had either bitcoind quit due to memory allocation failures (logged in debug.log), or the kernel oom_killer take maters into its own hands (logged in /valog/syslog). This looks very similar to an issue that was logged against 0.14.0 that was patched in 0.14.1. My ultimate solution was to downgrade to 0.14.2 which seems to work great.

prune compromise

My initial thoughts were to use prune=550 to use the least amount of disk space possible. I found out that even on 0.14.2 this causes memory to fill up quick. I found making the pruning less aggressive with a setting of prune=10240 seems to be a good compromise for what I need done. This could possibly be an observation error, but the results seemed very reproducable.

blocksonly avoidance

I had thought to save some memory by using blocksonly. For some reason, on 0.14.2, this causes more problems than it solves. I had a hard time finding any config where blocksonly would work. Surprisingly, maxmempool=5 does effectively the same thing for the miserly cost of 5MiB of memory.

serial consoles

Seems ridiculous, but on my VPS, if bitcoind was running full speed, I would have a hard time connecting through SSH. There were other SSH clients and connection methods that seemed to work better. By far the quickest connections when under heavy utilization was to connect directly to serial ports. I wrote a small snippet to enable extended serial console on my systemd install.

canary log

Since logging into my system gobbles up memory, I wanted this config to be as low-touch as possible once in motion. After tooling up the serial ports, I found all the system log messages where peekable without logging into my VPS through my VPS provider. I wrote a small canary script to simply chirp to the serial port every 5 minutes to confirm that bitcoind was indeed alive and kicking.

Scripts

I made a few scripts during the process as the needs arose. They are very utilitarian, and could do with some major overhauls, but they did what I needed done at the time I needed it.
Scripts:

Final config

Here is my final config, that is still syncing, but seems to be stable on 0.14.2
/usbin/nice -n 15 bitcoind \ -dbcache=115 \ -prune=10240 \ -maxmempool=5 \ -daemon /usbin/nohup $HOME/canary.sh $1 300 $USER >/dev/null 2>/dev/null & cPid=$! sudo /usbin/renice -n -5 -p $cPid echo "Canary @ $cPid" 
Memory utilization while syncing seems to be at about 400MiB. Once I'm synced, I expect to retune for dbcache=60 and maxmempool=60.
Projected full blockchain sync completion in (gulp) 30 days. CPU utilization is currently reported between 30-60% but my provider offers boost periods where they unmeeter the VMs. I've gotten it up to 110% on their dashboard, for what its worth.
I'm well beyond the word limit so I'll drop off here, but I'll eventually put the snipits in a github repo in the near future.
PS If anyone knows of some free VPS or Docker hosting services, please chime in.
EDIT: s/VSP/VPS/g - lysdexia
submitted by brianddk to BitcoinDiscussion [link] [comments]

"Be the moon you want to see in the world."

Be the moon you want to see in the world! - Shibetoshi Nakamoto

In HBO’s Game of Thrones and the A Song of Ice and Fire books on which it is based, there is a character who wants to be king during the long running “War of the Five Kings” and its fallout. He should be king by right! He is good. He is very capable. He is the best thing going really, in terms of what’s there to serve this extraordinary purpose. But in the story--throughout his history really--in spite of his applied extraordinariness he keeps getting screwed over, really by equal parts happenstance and treachery. Ringing any bells from our own Dogecoin history?
You can’t keep a good man (or woman or shibe) down however, so he keeps trying and trying to be what he should be by all rights. He struggles extraordinarily but the problems just keep coming at an equal tempo. After seeing him go through this for quite a while, a loyal advisor pulls him aside and tells him:
You don't get recognized as the king by acting as if you should be king, you get recognized as the king when you act like the king. When you do the things a king does, you will be king.
That’s what I am here about today. To offer Dogecoin that same message about being what it wants to be.
Dogecoin is still very big. We are the third largest crypto behind Bitcoin and Ethereum as it is. At the time of writing, over the previous two days I have seen multiple tip bots spring up. I have also seen multiple channels about doge open on new communication platforms. The value has jumped by 26% in 24hrs.
But the “spread” is much wider now. This state is a more difficult state. But it is also stronger. We are in the US on Telegram and Slack and Reddit and IRC and Twitter and in the crypto forums. We are in China. We are in Russia. We are in Germany. All over the place and in those places we communicate in different forms.
Some think and have said that we are on the ropes because the price is [was] down or activity has fallen in the subreddit which is in turn is caused by some technical shortcoming or by design. I am not saying such things are not every bit as important as implied, but those are not the reason that we are where we are.
Once, every day--day in day out, we were making the impossible possible: NASCAR, Olympics, charities--I don’t need to spell it all out because I am sure it is just as burned into your brain as it is into mine. The mad pace of the sheer impossibility of it all! If we saw something amazing in the morning and we made it to evening without something else we were unimpressed.
Everyday an article would come out in Wired or Ars or somewhere big with some tech or life writer gushing about Dogecoin and the incredible things we were doing and our unique attitude and intensely positive disposition and generosity that extended to a fault--a fault that we knew was actually a strength. In turn everyday there was an influx of new, amazing people who shared our fundamental nature, our priorities and values. People new to doge, new to crypto--even new the the internet through outreach efforts to isolated communities! To be what we were, to be more than we were, we have to go back to that place. Let’s do some amazing things. By our amazing things, they will recognize our amazing nature.
This will take reckless confidence and hard work, vision and creativity, all that stuff. But if you think it can’t and won’t happen, you are wrong. I am still out there, and you are still out there. They are all still out there. And now? We all know now that it can be done. Right now you and I can do it. Because we have proved we are capable of having done so.
I argue this time will actually be easier. Dogecoin now is a pile of tinder--ideas, people, and technology--waiting for a spark. And you hold a match in this moment. Strike it and in a snap make it all real.
Counting all the people that have an interest in or actively support dogecoin but are “estranged” now while we aren’t our truest self, we have an unparalleled group of developers and artists and public relations people and writers and visionaries and crypto folks and just generally people who can and do get things done. You are these people and you know these people. So first, understand yourself that dogecoin is back. Then start right now getting the band back together.
Right now, you can open Dogecoin core and instantly make the network stronger--well, almost instantly (if you have 2GB of RAM to spare on your machine run it from the command prompt with “dogecoin-qt.exe -dbcache=2000” and sync much faster). Make a new post or comment, here or somewhere else. Do a photoshop you have long considered. Float an idea for a project. Fill in some specifics for how a goal should be achieved. Tip in a novel place. Bring some shibes together to brainstorm. Vote on a post so that more will see it.
Don’t do these things because you have to, but because you are a part of a newly resurgent and thriving Dogecoin that brings you the same joy it used to. Any seemingly mundane action of this kind can be the flap of a butterfly’s wings starting the chain reaction that takes us where we want to go. We won’t know this as it is happening. We will just notice the signs of movement as we are on our way. But never forget that our destination is not the soil of Earth’s moon, not really.
“The Moon” is wherever we are all together as our best selves. That is the sight that is truly the most wow (I have seen pictures and video of the lunar surface and it's really nothing next to something that makes Comic Sans pleasant). Dogecoin’s Moon is a collection of individuals being actively kind and unselfish, good-hearted and honest, productive and relentless, creative and funny, thoughtful and pragmatic, disruptive and confident. All in the best ways. I want to see that Moon rise again more than just about anything I can think of and it sits just below the horizon waiting on us to act.
Edit: Here is the same message typed up in an open to view Google Doc if anyone wants to share with some of those shibes I mentioned that don't Reddit. I don't know if it is worth translating for those many Chinese and Russian shibes out there but if you think so and you have a way to get it started please speak up.
submitted by Tezcatlipokemon to dogecoin [link] [comments]

Inadvisably small full node config

Disclaimer: As the subject implies, this is about an inadvisable config. The following is of zero practical use, but like cross-stitch, may be appealing to the random few people interested in such things. Opinions on the futility of this exercise can be considered already noted. Any suggestions to make this more ridiculously small are very welcome. Obviously I'm not running my primary wallet off of this config. It's just for fun.
TLDR: Wow look, my full node fit on a 0.5 CPU with 0.6 GB memory and 25 GB drive... yeah for me!

Background

I used to run a full node a good ways back, but stopped when the old 3rd string laptop I was using to run it was having drive issues. Still the early interest paid dividends as the price has gone exponential. Missing the good ol' days, I wanted to run another node, but really didn't want to do it on any of my work or lab units. My company took a hard stand years ago to prevent interns from mining on spare HW, so running even a full node on my corporate gear is kinda a capitol punishment. Round about this time, I got some spam for some free VPS service for a year. The promotion were really (I mean really wimpy VPSs). Crappy VPS + bitcoind performance tuning = my kind of waste of time.

Goal

My goal (perverse though it may be), is to get bitcoin or other forks running in very small VPSs. Maybe some of the tuning parameters could be used for a docker container or some whipy SOC. The system I was targeting has 0.5 CPU, 0.6 GB of memory and 25 GB of disk.

Observations

I found some interesting things out along the way that may be of interest to people tweeking bitcoind.

dbcache limits

Since I don't have the requisite memory required to run the node, I've limited memory using the dbcache parameter. Settings range from 100 to 150 depending on what other settings I have in place.

0.15.1 mallocs

I don't know what changed in 0.15.1 but it seems much more memory hungry than previous releases. Throughout the tuning process, I continually had either bitcoind quit due to memory allocation failures (logged in debug.log), or the kernel oom_killer take maters into its own hands (logged in /valog/syslog). This looks very similar to an issue that was logged against 0.14.0 that was patched in 0.14.1. My ultimate solution was to downgrade to 0.14.2 which seems to work great.

prune compromise

My initial thoughts were to use prune=550 to use the least amount of disk space possible. I found out that even on 0.14.2 this causes memory to fill up quick. I found making the pruning less aggressive with a setting of prune=10240 seems to be a good compromise for what I need done. This could possibly be an observation error, but the results seemed very reproducable.

blocksonly avoidance

I had thought to save some memory by using blocksonly. For some reason, on 0.14.2, this causes more problems than it solves. I had a hard time finding any config where blocksonly would work. Surprisingly, maxmempool=5 does effectively the same thing for the miserly cost of 5MiB of memory.

serial consoles

Seems ridiculous, but on my VPS, if bitcoind was running full speed, I would have a hard time connecting through SSH. There were other SSH clients and connection methods that seemed to work better. By far the quickest connections when under heavy utilization was to connect directly to serial ports. I wrote a small snippet to enable extended serial console on my systemd install.

canary log

Since logging into my system gobbles up memory, I wanted this config to be as low-touch as possible once in motion. After tooling up the serial ports, I found all the system log messages where peekable without logging into my VPS through my VPS provider. I wrote a small canary script to simply chirp to the serial port every 5 minutes to confirm that bitcoind was indeed alive and kicking.

Scripts

I made a few scripts during the process as the needs arose. They are very utilitarian, and could do with some major overhauls, but they did what I needed done at the time I needed it.
Scripts:

Final config

Here is my final config, that is still syncing, but seems to be stable on 0.14.2
/usbin/nice -n 15 bitcoind \ -dbcache=115 \ -prune=10240 \ -maxmempool=5 \ -daemon /usbin/nohup $HOME/canary.sh $1 300 $USER >/dev/null 2>/dev/null & cPid=$! sudo /usbin/renice -n -5 -p $cPid echo "Canary @ $cPid" 
Memory utilization while syncing seems to be at about 400MiB. Once I'm synced, I expect to retune for dbcache=60 and maxmempool=60.
Projected full blockchain sync completion in (gulp) 30 days. CPU utilization is currently reported between 30-60% but my provider offers boost periods where they unmeeter the VMs. I've gotten it up to 110% on their dashboard, for what its worth.
I'm well beyond the word limit so I'll drop off here, but I'll eventually put the snipits in a github repo in the near future.
PS If anyone knows of some free VPS or Docker hosting services, please chime in.
EDIT: s/VSP/VPS/g - lysdexia
submitted by brianddk to Bitcoin [link] [comments]

Bitcoin Price What Next After Fresh Surge Toward $14000 ... Bitcoin Price Today - 27 October 2020 - YouTube Schnell und einfach Online Geld verdienen [BitCoins] - YouTube Getting your Private Keys from the Bitcoin Core wallet ... Bitcoin Daytrader - YouTube

Verify and track bitcoin cash transactions on our BCH Block Explorer, the best of its kind anywhere in the world. Also, keep up with your holdings, BCH and other coins, on our market charts at Bitcoin.com Markets, another original and free service from Bitcoin.com. The post BCH Is An A-Class Crypto for Auditability appeared first on Bitcoin News. Szukaj projektów powiązanych z Bitcoin dbcache lub zatrudnij na największym na świecie rynku freelancingu z ponad 18 milionami projektów. Rejestracja i składanie ofert jest darmowe. I have 12 GB of RAM, so my current dbcache is set to 8000 (8 GB). ... The Bitcoin price this week in a nutshell. View Comments. Play. 0:00. 0:00. Settings. Fullscreen. 4.9k. 369 comments. share. save hide report. 4.0k. Posted by 5 days ago. Trump announces halt to all Bitcoin trading. Just kidding. That's impossible because no one controls the network. Keep hodling. 4.0k. 469 comments. share ... There are two variations of the original bitcoin program available; one with a graphical user interface (usually referred to as just Bitcoin), and a 'headless' version (called bitcoind ). They are completely compatible with each other, and take the same command-line arguments, read the same configuration file, and rea . trending; Bitcoin Qt Dbcache Bitcoin . Bitcoin Qt Dbcache . Apr 16, 2018 ... Bitcoin Crash 2018 Youtube - Android Litecoin Mining Pool, Bitcoin Core Dbcache, Bitcoin Hardware Comparison. Bitcoin crash 2018 youtube - Android litecoin mining pool, Bitcoin core dbcache, Bitcoin hardware comparison Ehow theft over time of crypto capitalized privative to our private the circumstance require the block the super AMOLED display Monero algunas only better rather them bitcoin ...

[index] [24558] [27183] [31312] [48857] [34203] [48784] [15954] [33218] [17720] [7466]

Bitcoin Price What Next After Fresh Surge Toward $14000 ...

Bitcoin price has been reaching closer to all time highs. In this video we discuss current events as well as where the price of bitcoin and ethereum may go b... #Bitcoin #Bitcoin_Price #Bitcoin_Today More information: https://cryptodayprice.com Bitcoin Price Today - 27 October 2020 Bitcoin Price Today: 13164,87 US Do... Vediamo come sincronizzare nel modo più veloce possibile il portafoglio Bitcoin Core ... in questo caso da opzioni del portafoglio alza dbcache a 4500 ( velocizza in maniera estrema sopratutto ... Bitcoin (BTC) prices rallied Tuesday, briefly trading above $12,000 for the first time in more than two months. Crushing Bitcoin Dominance Could Decimate Alt... Bitcoin has come back to life this month after a period of stagnation since the summer. The bitcoin price has shot up by around 20% through October, climbing...

#