Bitcoin Core :: Bitcoin Core 0.18.0

Running a Bitcoin node on a $11.99 SBC

Running a Bitcoin node on a $11.99 SBC
Just wanted to let you guys know that I'm successfully running a (pruned) Bitcoin node + TOR on a $11.99 single board computer (Rock Pi S).
The SBC contains a Rockchip RK3308 Quad A35 64bit processor, 512MB RAM, RJ45 Ethernet and USB2 port and I'm using a 64GB SDCard. It runs a version of Armbian (410MB free). There's a new version available that even gives you 480MB RAM, but I'm waiting for Bitcoin Core 0.19 before upgrading.
To speed things up I decided to run Bitcoin Core on a more powerful device to sync the whole blockchain to an external HDD. After that I made a copy and ran it in pruned mode to end up with the last 5GB of the blockchain. I copied the data to the SD card and ran it on the Rock Pi S. After verifying all blocks it runs very smoothly. Uptime at the moment is 15 days.
I guess you could run a full node as well if you put in a 512GB SDcard.
The Rock Pi S was sold out, but if anybody is interested, they started selling a new batch of Rock Pi S v1.2 from today.
Screenshot of resources being used
Bitcoin Core info
Around 1.5 GB is being transferred every day
---
Some links and a short How to for people that want to give it a try:
  1. This is the place where I bought the Rock Pi S.
  2. Here you find more information about Armbian on the Rock Pi S. Flash it to your SDCard. Follow these instructions.
  3. Disable ZRAM swap on Armbian. If you don't do this eventually Bitcoin Core will crash. nano /etc/default/armbian-zram-config ENABLED=false
  4. Enable SWAP on Armbian sudo fallocate -l 1G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile sudo swapon --show sudo cp /etc/fstab /etc/fstab.bak echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
  5. Set up UFW Firewall sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow ssh # we want to allow ssh connections or else we won’t be able to login. sudo ufw allow 8333 # port 8333 is used for bitcoin nodes sudo ufw allow 9051 # port 9051 is used for tor sudo ufw logging on sudo ufw enable sudo ufw status
  6. Add user Satoshi so you don't run the Bitcoin Core as root sudo adduser satoshi --home /home/satoshi --disabled-login sudo passwd satoshi # change passwd sudo usermod -aG sudo satoshi # add user to sudo group
  7. Download (ARM64 version) and install Bitcoin Core Daemon
  8. Download and install TOR (optional). I followed two guides. This one and this one.
  9. Create a bitcoin.conf config file in the .bitcoin directory. Mine looks like this: daemon=1 prune=5000 dbcache=300 maxmempool=250 onlynet=onion proxy=127.0.0.1:9050 bind=127.0.0.1 #Add seed nodes seednode=wxvp2d4rspn7tqyu.onion seednode=bk5ejfe56xakvtkk.onion seednode=bpdlwholl7rnkrkw.onion seednode=hhiv5pnxenvbf4am.onion seednode=4iuf2zac6aq3ndrb.onion seednode=nkf5e6b7pl4jfd4a.onion seednode=xqzfakpeuvrobvpj.onion seednode=tsyvzsqwa2kkf6b2.onion #And/or add some nodes addnode=gyn2vguc35viks2b.onion addnode=kvd44sw7skb5folw.onion addnode=nkf5e6b7pl4jfd4a.onion addnode=yu7sezmixhmyljn4.onion addnode=3ffk7iumtx3cegbi.onion addnode=3nmbbakinewlgdln.onion addnode=4j77gihpokxu2kj4.onion addnode=5at7sq5nm76xijkd.onion addnode=77mx2jsxaoyesz2p.onion addnode=7g7j54btiaxhtsiy.onion ddnode=a6obdgzn67l7exu3.onion
  10. Start Bitcoin Daemon with the command bitcoind -listenonion
Please note that I'm not a professional. So if anything above is not 100% correct, let me know and I will change it, but this is my setup at the moment.
submitted by haste18 to Bitcoin [link] [comments]

Why is does it take so long to shut down an node used only as a JSON-RPC server?

I'm trying to sync a full node that will only be used as a JSON-RPC server (no mining). I tried to modify the config file and added a service unit, so that the node can run in a low-end VPS with minimum RAM and CPU capabilities. The problem is that the server takes too long to stop, and it's terminated by the system, so it always start rewinding blocks that have been already downloaded.
Here is my configuration file:
server=1 daemon=1 #debug=mempool debug=rpc # If run on the test network instead of the real bitcoin network # testnet=1 # You must set rpcuser and rpcpassword to secure the JSON-RPC api # Please make rpcpassword to something secure, `5gKAgrJv8CQr2CGUhjVbBFLSj29HnE6YGXvfykHJzS3k` for example. # Listen for JSON-RPC connections on  (default: 8332 or testnet: 18332) rpcuser=myuser rpcpassword=pypassword rpcport=8332 # Enable blocks pruning #prune=550 # Limit dbcache=50 maxconnections=4 rpcthreads=2 
And the service unit:
# It is not recommended to modify this file in-place, because it will # be overwritten during package upgrades. If you want to add further # options or overwrite existing ones then use # $ systemctl edit bitcoind.service # See "man systemd.service" for details. # Note that almost all daemon options could be specified in # /etc/bitcoin/bitcoin.conf [Unit] Description=Bitcoin daemon After=network.target [Service] ExecStart=/usbin/bitcoind -daemon=0 -datadir=/home/jsonrpc/bitcoin -conf=/home/jsonrpc/bitcoin/settings.conf ExecStop=/usbin/bitcoin-cli -datadir=/home/jsonrpc/bitcoin -conf=/home/jsonrpc/bitcoin/settings.conf stop # Creates /run/bitcoind owned by bitcoin #RuntimeDirectory=/home/jsonrpc/bitcoin WorkingDirectory=/home/jsonrpc/bitcoin User=jsonrpc Group=jsonrpc TimeoutStopSec=15m #CPUQuota=4% #MemoryLimit=128M #IOReadIOPSMax=10 #IOWriteIOPSMax=10 Type=simple #Restart=on-failure # Hardening measures #################### # Provide a private /tmp and /vatmp. PrivateTmp=true # Mount /usr, /boot/ and /etc read-only for the process. ProtectSystem=full # Disallow the process and all of its children to gain # new privileges through execve(). NoNewPrivileges=true # Use a new /dev namespace only populated with API pseudo devices # such as /dev/null, /dev/zero and /dev/random. PrivateDevices=true # Deny the creation of writable and executable memory mappings. # Commented out as it's not supported on Debian 8 or Ubuntu 16.04 LTS #MemoryDenyWriteExecute=true [Install] WantedBy=multi-user.target 
submitted by rraallvv 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]

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]

"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]

Bitcoin Core 0.13.0 release candidate 2 available | Wladimir J. van der Laan | Jul 31 2016

Wladimir J. van der Laan on Jul 31 2016:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Binaries for bitcoin Core version 0.13.0rc2 are available from:
https://bitcoin.org/bin/bitcoin-core-0.13.0/test.rc2/ 
Source code can be found on github under the signed tag
https://github.com/bitcoin/bitcoin/tree/v0.13.0rc2 
This is a release candidate for a new major version release, bringing new
features, bug fixes, as well as other improvements.
Preliminary release notes for the release can be found at
https://github.com/bitcoin/bitcoin/blob/0.13/doc/release-notes.md 
Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.13.0.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues 
Notable changes since rc1:

Build system

GUI

Wallet

P2P protocol and network code

Consensus

Mining

Block and transaction handling

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCgAGBQJXngBiAAoJEHSBCwEjRsmmS5kIAMFiXFua9ruR8Vwu1fNgnWTb
X4tsNOdPScm7jwsFavcwygqZQlDNDURjcocQFcehHgEickBrk6eaplTuB4VJidPG
Aqw+nLrd6M//Ohy+7eke7aCg5/QV7poplM3glwow4gQfoSBvL0ywMEhWEzGL7EPH
FH5pyY9o4QZw5wGdvMWxvYVTLPZkm0W2cSWCHZ0WgzWvTkZ7aMzSQ5F5TXPfjzED
DNuQQRMm9H1H3LJkmWAwjCXLzKNMzjmefLujyEII388s6UoWnA1ufosqb1kMqL+h
kuEelzef4cMBZEvHgfzsvlLmba2DLr7xhwudd3HK2NHSmO/wAUdhbQOQSts9NoY=
=rN68
-----END PGP SIGNATURE-----
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012916.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Bitcoin Core 0.14.1 released | Wladimir J. van der Laan | Apr 22 2017

Wladimir J. van der Laan on Apr 22 2017:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Bitcoin Core version 0.14.1 is now available from:
https://bitcoin.org/bin/bitcoin-core-0.14.1/
Or, by torrent:
magnet:?xt=urn:btih:0482be8fc8e1c0b02162871e3591efc3d1d34585&dn;=bitcoin-core-0.14.1&tr;=udp%3A%2F%2Fpublic.popcorn-tracker.org%3A6969%2Fannounce&tr;=http%3A%2F%2Fatrack.pow7.com%2Fannounce&tr;=http%3A%2F%2Fbt.henbt.com%3A2710%2Fannounce&tr;=http%3A%2F%2Fmgtracker.org%3A6969%2Fannounce&tr;=http%3A%2F%2Fopen.touki.ru%2Fannounce.php&tr;=http%3A%2F%2Fp4p.arenabg.ch%3A1337%2Fannounce&tr;=http%3A%2F%2Fpow7.com%3A80%2Fannounce&tr;=http%3A%2F%2Ftracker.dutchtracking.nl%3A80%2Fannounce
This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoincore.org/en/list/announcements/join/
Compatibility

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later.
Microsoft ended support for Windows XP on April 8th, 2014,
No attempt is made to prevent installing or running the software on Windows XP, you
can still do so at your own risk but be aware that there are known instabilities and issues.
Please do not report issues about Windows XP to the issue tracker.
Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.
Notable changes

RPC changes
These interface changes break compatibility with 0.14.0, when the named
arguments functionality, introduced in 0.14.0, is used. Client software
using these calls with named arguments needs to be updated.
Mining
In previous versions, getblocktemplate required segwit support from downstream
clients/miners once the feature activated on the network. In this version, it
now supports non-segwit clients even after activation, by removing all segwit
transactions from the returned block template. This allows non-segwit miners to
continue functioning correctly even after segwit has activated.
Due to the limitations in previous versions, getblocktemplate also recommended
non-segwit clients to not signal for the segwit version-bit. Since this is no
longer an issue, getblocktemplate now always recommends signalling segwit for
all miners. This is safe because ability to enforce the rule is the only
required criteria for safe activation, not actually producing segwit-enabled
blocks.
UTXO memory accounting
Memory usage for the UTXO cache is being calculated more accurately, so that
the configured limit (-dbcache) will be respected when memory usage peaks
during cache flushes. The memory accounting in prior releases is estimated to
only account for half the actual peak utilization.
The default -dbcache has also been changed in this release to 450MiB. Users
who currently set -dbcache to a high value (e.g. to keep the UTXO more fully
cached in memory) should consider increasing this setting in order to achieve
the same cache performance as prior releases. Users on low-memory systems
(such as systems with 1GB or less) should consider specifying a lower value for
this parameter.
Additional information relating to running on low-memory systems can be found
here:
reducing-bitcoind-memory-usage.md.
0.14.1 Change log

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

RPC and other APIs

    • #10084 142fbb2 Rename first named arg of createrawtransaction (MarcoFalke)
    • #10139 f15268d Remove auth cookie on shutdown (practicalswift)
    • #10146 2fea10a Better error handling for submitblock (rawodb, gmaxwell)
    • #10144 d947afc Prioritisetransaction wasn't always updating ancestor fee (sdaftuar)
    • #10204 3c79602 Rename disconnectnode argument (jnewbery)

Block and transaction handling

    • #10126 0b5e162 Compensate for memory peak at flush time (sipa)
    • #9912 fc3d7db Optimize GetWitnessHash() for non-segwit transactions (sdaftuar)
    • #10133 ab864d3 Clean up calculations of pcoinsTip memory usage (morcos)

P2P protocol and network code

    • #9953/#10013 d2548a4 Fix shutdown hang with >= 8 -addnodes set (TheBlueMatt)
    • #10176 30fa231 net: gracefully handle NodeId wrapping (theuni)

Build system

  • - #9973 e9611d1 depends: fix zlib build on osx (theuni)

GUI

  • - #10060 ddc2dd1 Ensure an item exists on the rpcconsole stack before adding (achow101)

Mining

    • #9955/#10006 569596c Don't require segwit in getblocktemplate for segwit signalling or mining (sdaftuar)
    • #9959/#10127 b5c3440 Prevent slowdown in CreateNewBlock on large mempools (sdaftuar)

Tests and QA

  • - #10157 55f641c Fix the mempool_packages.py test (sdaftuar)

Miscellaneous

    • #10037 4d8e660 Trivial: Fix typo in help getrawtransaction RPC (keystrike)
    • #10120 e4c9a90 util: Work around (virtual) memory exhaustion on 32-bit w/ glibc (laanwj)
    • #10130 ecc5232 bitcoin-tx input verification (awemany, jnewbery)
Credits

Thanks to everyone who directly contributed to this release:
    • Alex Morcos
    • Andrew Chow
    • Awemany
    • Cory Fields
    • Gregory Maxwell
    • James Evans
    • John Newbery
    • MarcoFalke
    • Matt Corallo
    • Pieter Wuille
    • practicalswift
    • rawodb
    • Suhas Daftuar
    • Wladimir J. van der Laan
As well as everyone that helped translating on Transifex.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCgAGBQJY+1YNAAoJEHSBCwEjRsmme+YIAIkJLCjimADYBJoM8bnHK2Dc
4KznlAjpXqFWb6taoSyWi+/6DtZxJF1MZm+iaDhqmTEy+ms313N2mBEd2xrSAPPL
nYf84e3tgnwq07sQmUxVZXyhZe2R+m/kgy75TTZw+bonyXwwA3384F0L8gvV5Iu+
kNNu6WggWUTvOADEFVKecgzWeT1FCYXklbNk+Z5T/YWWrKA8ATXgv45IIEKT8uI1
pqhKQxoqLM3ga7Df3VbzwXAYAOCaFzf+0nmTRoqDM5pX+FQ2hq0UM6joLnUNk2ee
G4/nsNWAKg/6eycrA7Wvawwcozr2iYAov/YDj6pEI8UoeGcOdlSh69Seb1cngHg=
=EHlY
-----END PGP SIGNATURE-----
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014228.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

[Informational] [CC0] Keeping Bitcoin Peer to Peer

The purpose of full nodes in the Bitcoin network is manifold. They exist as sovereign arbiters of the true state of the currency, they welcome new entrants into the network by sharing the history of the shared ledger, and they work together to spread new transactions to every corner of the earth.
There are many ways to use Bitcoin that do not require the use of a full node, however a full node describes something that offers the best level of security and privacy. As long as it is practical to use a full node, it's strongly suggested that one be used.
The precautionary suggestion to use a full node is one in which the user must be proactive about their own safety. The safety recommendation is analogous to wearing a seat belt in a car, or using a prophylactic device in an amorous encounter. Following a general guideline for safety that incurs some unwanted cost might not be immediately obvious, but on sober reflection of all the risks ignoring the guideline can be seen to be a mistake.

Strength in Numbers

The link between Bitcoin's health and the health of the full node peer to peer network is often stated. This is because a distributed network of redundant peers is seen as the most durable configuration possible. Thousands upon thousands of full nodes give strength to the network through herd protection. To sever a geographic link to the network, every node in the geographic area would have to be terminated, even a single remaining node could bridge the replication gap. It is seen that every additional user running a node translates to another brick in the wall keeping the network alive.
It's hard to determine the exact number of nodes on the network at any given time, because the network is designed to be distributed and decentralized, with each node giving thought only to its connected peer nodes and not the greater network. Despite this design, services exist to attempt to map the nature of the network by deliberately attempting to connect to as many peers as possible. These services are easily misled by fake nodes, and they cannot easily connect to the vast majority of nodes behind firewalls or with other limiting factors, so their published data must be treated as suspect.

Node Cooperative Contribution

Nodes in the network act in a peer to peer way, meaning that they act as servers and clients. Acting as a client is a baseline requirement for every node, however some nodes can limit the ways in which they act as servers, to limit their costs or for other reasons. In a network of full nodes, the level of server-like nodes is not important beyond a certain degree due to the great level of redundancy and the low demands full nodes place on the network. Just like almost any server and client split network topology, clients may outnumber servers greatly without any ill effects.
There are a variety of methods in which a node may act as a server: relaying transactions and blocks, catching up other nodes on Blockchain history, helping peer discovery. Generally speaking, contributory full nodes service two types of clients: other full nodes, and light clients.
A full node server serving other full nodes generally speaking has very light requirements. Full nodes have very limited demands because they only require a tiny differential sync from their current state. This differential sync cost is easily covered by the altruism of other nodes, in a model generally seen as sustainable to a large degree.
A full node servicing light clients, also known as SPV clients, has a much more costly set of requirements. Light clients cannot query their own local data set and thus require syncs tasks which carry a high marginal cost in both networking and system resources. Covering this cost through generalized altruism is not seen as sustainable, so most light clients have moved to a model of querying more formalized servers instead of the network at large.

Full Nodes Promote Privacy

An important element of Bitcoin as a unit of account and a convenient medium of exchange is that every single unit of Bitcoin is equivalent to every other unit. If some coins became more valuable than other coins, despite their face value, it would make for a confusing and therefore lower utility experience in exchanging them.
Unfortunately, Bitcoins are implemented in such a way that every Bitcoin balance is accompanied by a wealth of metadata relating to its origin. This represents a risk to every unit being exchangeable for every other unit, also known as the fungibility of the currency. Coin metadata represents a risk to the coin owner's privacy that can have unwanted negative secondary consequences, such as being accused of being linked to a theft through the web of transactions.
Full nodes uniquely help the network and the user from this negative privacy outcome by carefully protecting the metadata surrounding balances and transactions. In wallets that do not sync the entire Blockchain, they must query outside third parties for information about the funds they control. This querying represents a leak of information: information that can link multiple addresses together, can link Bitcoin addresses to IP addresses, funds to identities and actions that tar the theoretically neutral value tokens with a harmful history of their use.
Bitcoin full nodes can even take obscuring metadata one step further, severing even the link of IP address to Bitcoin full node and transaction relaying by automatically detecting a local Tor connection and then rerouting connections using Tor to provide for the privacy of the node.

Full Node Validation Security

The security of a user's funds and exchanges using Bitcoin is guarantees by a set of rules that govern how Bitcoin works. These rules describe things like the total possible number of coins in the system, or the coin limit, which promotes the utility of Bitcoin as a scarce tradable commodity. People are incentivized to use full nodes to remove their risk of these rules being broken, and this also serves to limit the impact of rule breaking: validating nodes will refuse to relay and spread invalid data.
Other notable rules are the subsidy schedule, which describes how quickly the currency can be minted, double spending, which prevents a user from spending the same funds in two places, signature validation, which prevents unauthorized users from spending others' funds, the block size limit which promotes network durability by preventing network denial of service deliberately or indirectly, and Bitcoin script execution, which evaluates intelligent rules for spending coins, like the CLTV which prevents funds from being spent until a certain time.
The validation that a full node performs is complete and total. Every single piece of data supplied by a third party is checked, so that even if all information a full node receives is supplied by a malicious attacker, they cannot create any negative results by manipulating the supplied data. The one exception to this rule is a situation in which the full node itself is running on a compromised platform. Therefore it is considered that the most secure practice for using Bitcoin is to only run a Bitcoin node on a platform known to be secure: third party platforms like cloud services where trust is an unknown factor are not recommended.
Due to the stringent checks performed by full nodes rule violations are few and far between. However rule violations, even by miners, are not unknown, for example in July of 2015 invalid blocks were published to the network in multiple incidents. This proves in practice what is obvious in theory: data from third parties, even miners who are strongly incentivized to publish valid data, can at times be invalid, either maliciously or through simple error. A full node's validation mechanisms will automatically ignore invalid data from any source, even a miner, unlike many alternatives to a full node that offer reduced levels of validation.

Full Node Code Security

When selecting a wallet, important consideration should be given to the authorship of the wallet. Is the wallet open source? Has the code been reviewed? Has there been thorough security testing? Examining the methodology in developing and releasing a wallet can help prevent the use of malware that abscond with user funds, or buggy prototype wallets that lose coins through simple coding errors.
Bitcoin Core as the Bitcoin reference client represents a very thoroughly vetted wallet. The code produced by Bitcoin Core is seen by many eyes, the scope of the wallet is narrow and focused, the users of the wallet are wide and varied. Bitcoin Core is designed as a comprehensive client, meaning it should be seen as comprehensively reliable, and the code should be seen as thoroughly vetted and secure. These qualities help make Bitcoin Core a very attractive choice for security conscious use.

Altruism in Full Nodes

The Bitcoin network relies upon having some nodes to bear some costs without direct recompense. This mechanism generally relies upon altruism and default behavior. It's well understood that this is a weak mechanism, but realistic given a limited cost: some percentage of users of Bitcoin Core who are not inconvenienced by the limited costs of default altruism will not adjust their default settings and some percentage of Bitcoin users can be expected to even go out of their way to assist others in the network.
This system works because the cost of altruism is capped. Servicing the requests of other nodes can be extremely inexpensive, running a node from home barely carries a negative impact: through the effort of many hands light work is made of the task of keeping the network running.

Efforts to Reduce Node Operational Cost

Creating a positive result in the cost benefit analysis of running a full node can be attacked from both sides: cost and benefit. The benefits of running a full node are great: financial privacy, security, self-determination, and altruistic fulfillment. But if the costs of running a full node outweigh those benefits, a user may not pursue the full node path, leading to their sacrifice of those potential benefits and the networks' loss of the marginal durability value they represent. For this reason, minimizing node cost has been a strong priority of the Bitcoin Core project: CPU, memory, disk storage, bandwidth have all been heavily optimized over many years of work.
One oft lamented cost center of Bitcoin Core is the cost of storing the Blockchain, the entire history of transactions. The Blockchain network design calls for this shared history to be stored in a distributed fashion, but its growth to tens of gigabytes of data over the years has made that burden something of a hot potato. To address this, in Bitcoin Core version 0.11.0, a major new feature was added to reduce this burden by eliminating archival data, in a feature known as pruning. Pruning turns the storage burden of tens of gigabytes of Bitcoin data into a small two to three gigabyte task, even pruning progressively on initial syncs. Pruned nodes cannot help catch up other nodes, but they can still help the network stay in sync with the all important trailing differential that is all that caught up full nodes nodes require.
Another great technical barrier to syncing the Blockchain is the CPU cost of validating the cryptographic signature that accompanies every movement of funds. Marginally a signature cost is small, but the impact of tens of millions of transactions means that syncing the chain is a lengthy task even for the most powerful computing devices. To address this the Bitcoin Core developers worked for many years on an optimized version of their signature algorithm, resulting in the highly optimized libsecp256k1 signature library. This library was put into full use in Bitcoin Core version 0.12.0, resulting a massive seven hundred percent improvement in signature validation speed, making Blockchain sync much more accessible to a wider range of users and devices.
Bitcoin transactions have a limited memory footprint: at the median transaction size a single transaction requires about the same amount of memory as two Tweets. Thousands of transactions can fit in active memory without issue. Even with transactions' limited memory footprint, memory utilization still represents a significant cost center for some users, or in some unlikely but possible scenarios where unconfirmed transactions rise to extremely high levels. To address this memory usage issue, Bitcoin Core added a discrete limiter: the mempool size option. This makes the trade-off of ignoring unlikely to confirm transactions for the benefit of allowing a fixed cap on full node memory demands.
To address bandwidth costs, Bitcoin Core added an upload limiter to put a cap on upload bandwidth, and a new blocksonly configuration option that limits the download bandwidth requirement to a maximum of about two thousand bytes/second, well within reach of even a standard dialup modem.
In addition to optimizations to reduce the marginal burden of transactions, optimizations were also made to lift the weight of the initial Blockchain sync. After users began to be forced into using BitTorrent to perform the initial sync of the large Blockchain data files, Bitcoin Core developers integrated a superior solution into Bitcoin Core itself, in a mechanism called headers-first sync that removes the bandwidth bottleneck to an initial sync. The initial sync may also be sped up by adjusting the dbcache option which allocates the syncing Bitcoin Core process additional memory beyond the low impact defaults of a standard Bitcoin Core install.
Beyond all these options stands a general firewall to the cost limits of Bitcoin Core. This firewall is known as the block size limit, and it puts a hard cap on the introduction of new costs on a node. Not all costs are limited by this, for example the set of transactions that are kept in memory instead of on disk or pruned is not strictly limited, only at a gross level does the block limit apply in that case. But generally speaking, the block limit is a general, final limit that protects the full node peer to peer network, and thus Bitcoin's durability, by promoting a low barrier to entry and thus a diverse and wide set of participants.
submitted by pb1x to writingforbitcoin [link] [comments]

Best Bitcoin mining BITCOIN MINING trailer Raspberry Pi 4 Bitcoin Mining For 24 Hours! Best Bitcoin mining Best Bitcoin Mining Site  Without Investment  Payment Proof!

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 read and write the same data files. Instant bitcoin exchange rate contact bitcoin2wire for best cyptocurrency exchange for usd to bitcoin , wire transfer to bitcoins at lowest ratesthis comprehensive graded list of bitcoin exchange reviews is. Dbcache bitcoin wallet limonero 4 estaciones precious metals Dbcache bitcoin wallet fx a tdfc litecoin charts Feb 12, In Bitcoin Core 0. Build 1: The Entry Level Miner. Your first choice is an entry level system designed for modest mining. This will put some spare spending coin in your pocket without being a daunting investment. Bitcoin Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.8+, and Windows Vista and later. Microsoft ended support for Windows XP on April 8th, 2014 , No attempt is made to prevent installing or running the software on Windows XP, you can still do so at your own risk but be aware that there are known Bitcoin Cash Ico - Bitcoin Lending Program, Bitcoin Core Size Of Database Cache, Litecoin Free Coins. NAGA Debit prior way bitcoin cash ico but faster deposit new currency the geopolitical system.Every Charge of cookies Polis the day any more than 5 years it hits such as 25% of Tech, (Technical responsor commodated blocks" of a barrests.Even a zombie-fille neighbors.Brent crypto-asset rug grip

[index] [30982] [4784] [10371] [1258] [2318] [21295] [15009] [29125] [26019] [2896]

Best Bitcoin mining

How To Pay Off Your Mortgage Fast Using Velocity Banking How To Pay Off Your Mortgage In 5-7 Years - Duration: 41:34. Think Wealthy with Mike Adams Recommended for you Bitcoin mining a block is difficult because the SHA-256 hash of a block's header must be lower than or equal to the target in order for the block to be accepted by the network. Bitcoin Mining - How To Cash In With Cloud Mining In 2020 In this video, I divulge how I've been earning large returns with bitcoin smart cloud mining. I utilize the platform IQ Mining and buy ... Bitcoin Mining, We offer free high quality display card mining service. We are the only bitcoin mining company that provides this service for free. With simple interface and ease of use you can ... Today I am showing you how anyone can start mining bitcoins using their current or old computer!! Nice Hash - https://www.nicehash.com/ Check out the officia...

Flag Counter