Bitcoin Core not using configured database cache size and ...

Bitcoin Fullnode Install Guide for Dummies ;-)

Bitcoin Fullnode Install Guide for Dummies ;-)
Feel free to stop at Level 0 or Level 1, which is fine. More advanced configs are offered to those with more tech savvy. This guide, obviously assumes a Windows 10 install, but other OSes work fine, just find a different guide. BTW, the "For Dummies" is a callback to a set of "tech" books in the 90's intended to be as easy as possible. It is in jest and not intended to insult the reader. Finally, if you dislike the formatting, a well formatted copy can be found here
There is a fairly small subset of Bitcoin users that run a full node. I think the idea of running a full node has gotten a bad rap over the years since there is so much talk about running on a Raspberry Pi, or getting zippy SSDs. Although all of this can be fun, it is often not really required at all. Here are some ways to run a full node starting with the very simple. I'll get into more complex configs, but these are all optional.

Tech Skill Level: 0 (the basics)

  1. Download Bitcoin Core
  2. Launch the downloaded installer and install the app
  3. Launch the installed "Bitcoin Core" app and let it run overnight
In many cases, thats it. If your running a new machine with a fairly good internet connection, 8 or 9 hours will be enough to complete the "Initial Block Download" (IBD). This may fill up your drive a bit, but again, on most new machines, 300 GB of space isn't that hard to come by.

Tech Skill Level: 1 (encrypted wallet)

One thing we left out in the level-0 exercise is encrypting your wallet. It's easy enough to do well, but a bit more difficult to do right. The main challenge is that humans generate really poor passwords. If you want a good password, the best way is to use something called "diceware". Basically, you just grab 4 or 5 dice and each throw of the dice represents a certain word on a special list. The throw {1,4,5,3,1} for example would be the word camping on the EFF-diceware-wordlist. So you repeat this a few times until you have a list of 8 or so words which becomes the passphrase you use to encrypt your wallet. Write it down, it is always hard to remember at first. So at level-1 your list becomes:
  1. Download Bitcoin Core
  2. Launch the downloaded installer and install the app
  3. Launch the installed "Bitcoin Core" app and let it run overnight
  4. Choose Encrypt Wallet from the Settings menu
  5. Enter your 8 word (or so) passphrase generated using the Diceware method

Wallet Encryption Dialog

Tech Skill Level: 2 (enable pruning if needed)

Though I said "300 GB of space isn't hard to come by", some times it actually is. If space is an issue, a simple way to fix it is to tell bitcoin to simple take less space. This is called "pruning" and can take that number from 300 GB down to below 5 GB. If you can't find 5 GB, then you'll have to read ahead to level-4 to add USB storage. But the good news is, enabling pruning is pretty easy, we just add another step to our working list:
  1. Download Bitcoin Core
  2. Launch the downloaded installer and install the app
  3. Launch the installed "Bitcoin Core" app and let it run overnight
  4. Do the wallet encryption steps here if you wish
  5. Choose Options from the Settings menu
  6. Choose Prune block storage to: and select the max size for the blocks to use
  7. Exit and restart the bitcoin application for the changes to take effect

Pruning Dialog
Note, even setting this to 1 GB will still leave you with about a 4.5 GB install. The blocks take up a lot of space, but the chainstate and other folders eat up at least 3.5 GB and they can't be pruned. Also, be aware, to disable pruning requires you to perform the entire IBD again. While pruned some other functions my be disabled as well, so just know that pruning does limit some functionality.

Tech Skill Level: 3 (verify the installer)

Although this is arguably something that should be done at level-0, some find the intricacies of comparing hash (thumbprint) values to be tedious and beyond the scope of a beginner. You will find these types of hash compares suggested quite often as a way to prevent running tainted programs. Programs are often tainted by bad disk or network performance, but most often, taint is malicious code inserted by viruses or malware. This is a way to guard yourself against those types of attacks.
What I cover here is a very basic comparison on the certificate, but a more thorough verification advised by mosts uses a program called Gpg4Win, and is beyond the scope of this beginners guide. But regardless, most users should strive to do this minimum level of validation.
  1. Download Bitcoin Core
  2. Launch the downloaded installer
  3. When prompted "Do you want to allow..." click Show more details
  4. In the details section select Show information about the publisher's certificate
  5. In the certificate window select the Details tab
  6. In the Details tab Subject should start with "CN = Bitcoin Core Code Signing Association"
  7. Ensure Thumbprint in Details reads ea27d3cefb3eb715ed214176a5d027e01ba1ee86
  8. If the checks pass, click OK to exit the certificate window and Yes to allow the installer to run.
  9. Launch the installed "Bitcoin Core" app and let it run overnight
  10. Do the wallet encryption steps here if you wish
  11. Do the optional pruning steps here if you wish

Certification Validation Windows
Note: The certificate used to sign the current Bitcoin installer is only valid from March 2020 to March 2021. After that point the thumbprint on the certificate will change. This is by design and intentional. If your reading this post after March 2021, then it is understood that the thumbprint has changed.

Tech Skill Level: 4 (use secondary storage)

We glossed over the "new machine with fairly good internet" part. Truth be known many people do not have fairly new machines, and find the IBD to take longer than the "over night" best wishes. For most people the slowdown is the disk access when calculating what is called chainstate. This requires fast random reads and writes to the disk. If you have an SSD disk, this will be no problem, but if you have a non-SSD "spinning" disk, random writes are always slow. Though an SSD will speed things up, they are pricey, so a nice middle ground may be a simple high-end USB key drive. You can get some with 10 to 15 MB/s random writes for $20 on Amazon. This is usually a order of magnitude faster than a "spinning" disk. And with pruning (see level-2), a small USB drive should be fine.
Once you decide on a drive, the tricky part will be to enable external storage. It requires editing a configuration file and adding a line. First, we want to create a directory on the key drive. You will need to determine the drive letter of your USB key drive. For the sake of this example, we will assume it is D:, but you must determine this yourself and correct the example. Once you know the drive letter, create a blank folder on the drive called Bitcoin. So for this example, creating Bitcoin on drive D: will create the path D:\Bitcoin. Once done, assuming that D: is your drive, here are the new steps including the edit of the configuration file:
  1. Download Bitcoin Core
  2. Launch the installer, verify it, then run it
  3. Launch the installed "Bitcoin Core" app and let it run overnight
  4. Do the wallet encryption steps here if you wish
  5. Do the optional pruning steps here if you wish
  6. Launch "Notepad" by typing "Notepad.exe" in the windows search bar then click Open
  7. Type the line datadir=D:\Bitcoin (depending on your drive letter) in the blank file
  8. Choose Save from the File menu in notepad
  9. Type %APPDATA%\Bitcoin\bitcoin.conf (note the percent signs) in the File name box
  10. Select All Files from the Save as type dropdown
  11. Click the Save button and overwrite the file if prompted
  12. Exit and restart the bitcoin application for the changes to take effect

Save As Dialog
Now that you've reached this level of technical expertise, there are many new configuration options that you can begin to modify if you wish. Most configuration data is contained in the bitcoin.conf file and learning how to maintain it is a key step for a node operator.

Tech Skill Level: 5 (all other customizations)

Here's a short list of various things you can ADD to your bitcoin.conf file. You generally just add a new line for each configuration settings.
  • addresstype=bech32
  • changetype=bech32
The addresstype / changetype allows your wallet to use the native-segwit (bech32) format. This is the most efficient and inexpensive way to spend bitcoin, and is a recommended configuration. The default uses something called p2sh-segwit which is more compatible with older wallets, but more expensive to spend.
  • minrelaytxfee=0.00000011
Changing the minrelaytxfee setting allows you to help propagate lower fee transactions. It will require more memory but TXN memory is capped at 300 MB by default anyways, so if you have enough memory, it is a good setting to choose.
  • dbcache=2048
The dbcache setting controls how many MB of memory the program will use for the chainstate database. Since this is a key bottleneck in the IBD, setting this value high (2048 MB) will greatly speed up the IBD, assuming you have the memory to spare
  • blocksdir=C:\Bitcoin
  • datadir=D:\Bitcoin
In level-4 we discussed moving the datadir to a fast external storage, but the majority of the space used for bitcoin is the blocks directory (blocksdir). Although you should always use for fastest storage for datadir, you are free to use slow storage for blocksdir. So if you only want to consume a small amount of your SSD (assumed D:) then you can keep your blocks on your slow "spinning" drive.
  • upnp=1
One of the harder challenges you may face running a node, is to get incoming connections. If you are lucky, you may find that your firewall and network HW support the uPnP protocol. If they do, this setting will allow bitcoin to configure uPnP to allow incoming connections to your node. Other methods exist to make your node reachable, but they are well beyond the scope of this guide.
submitted by brianddk to Bitcoin [link] [comments]

Test

Test
There is a fairly small subset of Bitcoin users that run a full node. I think the idea of running a full node has gotten a bad rap over the years since there is so much talk about running on a Raspberry Pi, or getting zippy SSDs. Although all of this can be fun, it is often not really required at all. Here are some ways to run a full node starting with the very simple. I'll get into more complex configs, but these are all optional.

Tech Skill Level: 0 (the basics)

  1. Download Bitcoin Core
  2. Launch the downloaded installer and install the app
  3. Launch the installed "Bitcoin Core" app and let it run overnight
In many cases, thats it. If your running a new machine with a fairly good internet connection, 8 or 9 hours will be enough to complete the "Initial Block Download" (IBD). This may fill up your drive a bit, but again, on most new machines, 300 GB of space isn't that hard to come by.

Tech Skill Level: 1 (encrypted wallet)

One thing we left out in the level-0 exercise is encrypting your wallet. It's easy enough to do well, but a bit more difficult to do right. The main challenge is that humans generate really poor passwords. If you want a good password, the best way is to use something called "diceware". Basically, you just grab 4 or 5 dice and each throw of the dice represents a certain word on a special list. The throw {1,4,5,3,1} for example would be the word camping on the EFF-diceware-wordlist. So you repeat this a few times until you have a list of 8 or so words which becomes the passphrase you use to encrypt your wallet. Write it down, it is always hard to remember at first. So at level-1 your list becomes:
  1. Download Bitcoin Core
  2. Launch the downloaded installer and install the app
  3. Launch the installed "Bitcoin Core" app and let it run overnight
  4. Choose Encrypt Wallet from the Settings Menu
  5. Enter your 8 word (or so) passphrase generated using the Diceware method

Wallet Encryption Dialog

Tech Skill Level: 2 (enable pruning if needed)

Though I said "300 GB of space isn't hard to come by", some times it actually is. If space is an issue, a simple way to fix it is to tell bitcoin to simple take less space. This is called "pruning" and can take that number from 300 GB down to below 5 GB. If you can't find 5 GB, then you'll have to read ahead to level-3 to add USB storage. But the good news is, enabling pruning is pretty easy, we just add another step to our working list:
  1. Download Bitcoin Core
  2. Launch the downloaded installer and install the app
  3. Launch the installed "Bitcoin Core" app and let it run overnight
  4. Do the wallet encryption steps here if you wish
  5. Choose Options from the Settings Menu
  6. Choose Prune block storage to: and select the max size for the blocks to use
  7. Exit and restart the bitcoin application for the changes to take effect

Pruning Dialog
Note, even setting this to 1 GB will still leave you with about a 4.5 GB install. The blocks take up a lot of space, but the chainstate and other folders eat up at least 3.5 GB and they can't be pruned. Also, be aware, to disable pruning requires you to perform the entire IBD again. While pruned some other functions my be disabled as well, so just know that pruning does limit some functionality.

Tech Skill Level: 3 (verify the installer)

Although this is arguably something that should be done at level-0, some find the intricacies of comparing hash (thumbprint) values to be tedious and beyond the scope of a beginner. You will find these types of hash compares suggested quite often as a way to prevent running tainted programs. Programs are often tainted by bad disk or network performance, but most often, taint is malicious code inserted by viruses or malware. This is a way to guard yourself against those types of attacks. What I cover here is a very basic comparison on the certificate, but a more thorough comparison advised by mosts uses a program called Gpg4Win, and is beyond the scope of this beginners guide. But regardless, most users should strive to do this minimum level of validation.
  1. Download Bitcoin Core
  2. Launch the downloaded installer
  3. When prompted "Do you want to allow..." click Show more details
  4. In the details section select Show information about the publisher's certificate
  5. In the certificate window select the Details tab
  6. In the Details tab Subject should start with "CN = Bitcoin Core Code Signing Association"
  7. Also ensure Thumbprint reads ea27d3cefb3eb715ed214176a5d027e01ba1ee86
  8. If the checks pass, click OK to exit the certificate window and Yes to allow the installer to run.
  9. Launch the installed "Bitcoin Core" app and let it run overnight
  10. Do the wallet encryption steps here if you wish
  11. Do the optional pruning steps here if you wish

Certification Validation Windows
Note: The certificate used to sign the current Bitcoin installer is only valid from March 2020 to March 2021. After that point the thumbprint on the certificate will change. This is by design and intentional. If your reading this post after March 2021, then it is understood that the thumbprint has changed.

Tech Skill Level: 4 (use secondary storage)

We glossed over the "new machine with fairly good internet" part. Truth me known many people do not have fairly new machines, and find the IBD to take longer than the "over night" best wishes. For most people the slowdown is the disk access when calculating what is called chainstate. This requires fast random reads and writes to the disk. If you have an SSD disk, this will be no problem, but if you have a non-SSD "spinning" disk, random writes are always slow. Though an SSD will speed things up, they are pricey, so a nice middle ground may be a simple high-end USB key drive. You can get some with 10 to 15 MB/s random writes which is usually a order of magnitude faster than a "spinning" disk. And with pruning (see level-2), a small USB drive should be fine.
Once you decide on a drive, the tricky part will be to enable external storage. It requires editing a configuration file and adding a few lines. The configuration file needs to be in both the default directory, and USB key drive, but before we do that, we want to create a directory on the key drive. You will need to determine the drive letter of your USB key drive. For the sake of this example, we will assume it is D:, but you must determine this yourself and correct the example. Once you know the drive letter, create a blank folder on the drive called Bitcoin. So for this example, creating Bitcoin on drive D: will create the path D:\Bitcoin. Once done, assuming that D: is your drive, here are the steps to edit the two configuration files:
  1. Download Bitcoin Core
  2. Launch the installer, verify it, then run it
  3. Launch the installed "Bitcoin Core" app and let it run overnight
  4. Do the wallet encryption steps here if you wish
  5. Do the optional pruning steps here if you wish
  6. Launch "Notepad" by typing "Notepad.exe" in the windows search bar then click Open
  7. Type the line datadir=D:\Bitcoin (depending on your drive letter) in the blank file
  8. Choose Save from the File menu in notepad
  9. Type %APPDATA%\Bitcoin\bitcoin.conf (note the percent signs) in the File name box
  10. Select All Files from the Save as type dropdown
  11. Click the Save button and overwrite the file if prompted
  12. Exit and restart the bitcoin application for the changes to take effect

Save As Dialog
Now that you've reached this level of technical expertise, there are many new configuration options that you can begin to modify if you wish. Most configuration data is contained in the bitcoin.conf file and learning how to maintain it is a key step for a node operator.

Tech Skill Level: 5 (all other customizations)

Here's a short list of various things you can ADD to your bitcoin.conf file. You generally just add a new line for each configuration settings.
  • addresstype=bech32
  • changetype=bech32
The addresstype / changetype allows your wallet to use the native-segwit (bech32) format. This is the most efficient and inexpensive way to spend bitcoin, and is a recommended configuration. The default uses something called p2sh-segwit which is more compatible with older wallets, but more expensive to spend.
  • minrelaytxfee=0.00000011
Changing the minrelaytxfee setting allows you to help propagate lower fee transactions. It will require more memory but TXN memory is capped at 300 MB by default anyways, so if you have enough memory, it is a good setting to choose.
  • dbcache=2048
The dbcache setting controls how many MB of memory the program will use for the chainstate database. Since this is a key bottleneck in the IBD, setting this value high (2048 MB) will greatly speed up the IBD, assuming you have the memory to spare
  • blocksdir=C:\Bitcoin
  • datadir=D:\Bitcoin
In level-4 we discussed moving the datadir to a fast external storage, but the majority of the space used for bitcoin is the blocks directory (blocksdir). Although you should always use for fastest storage for datadir, you are free to use slow storage for blocksdir. So if you only want to consume a small amount of your SSD (assumed D:) then you can keep your blocks on your slow "spinning" drive.
  • upnp=1
One of the harder challenges you may face running a node, is to get incoming connections. If you are lucky, you may find that your firewall and network HW support the uPnP protocol. If they do, this setting will allow bitcoin to configure uPnP to allow incoming connections to your node.
submitted by brianddk to brianddk [link] [comments]

Configuring bitcoin full node for faster RPC calls

I have been working with a bitcoin full node and attempting to parse the blockchain data, whilst storing it in an external database.
The script I am using iterates through each block using getblock[hash;2] which populates multiple tables. However in order to get the current blocks input values we have to perform an expensive getRawTransaction each previous txid.
We have singled this out as the bottleneck in the code for most time taken, rendering the script very slow. We have also tried using RPC batching but this also takes considerable amount of time, potentially more with a memory overhead.
I am wondering if there is a best configuration of the daemon to improve RPC call speed? i.e. using rpcthread/queue, increasing dbcache etc.
Another option would be to implement blocks only mode, by reducing the bandwidth could this improve RPC commands?
Bitcoin Core Daemon version v0.16.0.0-g4b4d7eb255
Server Details OS-Ubuntu 16.04 32 GB ram
submitted by dandan4561 to Bitcoin [link] [comments]

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]

I am now one of 6081 bitcoin nodes

It took about 2 weeks for me to download and verify the full blockchain on my 2011 iMac HD (no ssd), but I can proudly say that I'm now running a full node and it feels good. I highly recommend others to do the same and support the bitcoin network. If I can do it on my old machine, so can you. (assuming you have the hd space and bandwidth).
As others have mentioned, changing the dbcache value up to 50% of your available RAM while verifying helps. You can set it in the preferences (no need to use command line). And just let it run. I have seen no drops in internet performance during the dl and sync, but I have a fast connection (70Mb/s) so it's not the bottleneck.
It's a testament to the technology of Bitcoin that I can independently verify 8 years of global financial transactions on a 6 year old PC.
Happy Bitcoining!
EDIT: According to https://en.bitcoin.it/wiki/Clearing_Up_Misconceptions_About_Full_Nodes#Very_roughly_estimating_the_total_node_count, the estimated number of nodes is around 29,170. I was looking at https://bitnodes.21.co/, which only counts the listening nodes.
EDIT2: If you want to learn more about bitcoin nodes, please read this: https://bitcoin.org/en/full-node
submitted by shibenyc to Bitcoin [link] [comments]

Run a 0.14 Full-Node on RaspberryPi3 Pruned(less than 16GB SD needed)

Hi!
Happy if this guide helps you.
Tip if you want: 19656Uwdwko5RjtnuwQENpjBwE3ChzD59v
UPDATE 04/06/17
Add 'uacomment=UASF-SegWit-BIP148' into your bitcoin.conf if you want to signal UASF.
UPDATE 03/13/17
ADDED a tl;dr; Version at the end of this Post.
UPDATE 03/12/17:
Just to test it - I reinstalled all on 8GB SD and it works as well. But maybe you should use at least 16GB for the beginning.
Using a 128GB card for the first version was a little bit stupid - so I reinstalled everything on a 8GB SD card. Including Linux and a pruned blockchain - and it works.
I used prune=550 and Jessie Lite (headless / command line) - without wallet and gui.
The SD is almost full, but it works so far
I also updated the whole manual a bit to make things more clear. Thank you for all your feedback!
Just started my Bitcoin Node today and wanted to share the way I did it with people who are interested in running their own full node. It took some time to write everything down - hopefully correct so far.
I am sure, many people around bitcoin are way more informed and educated as I am - I am the noob. So I wrote this manual to help users like me - noobs, to get started with a cheap, simple bitcoin node on raspberry pi.
Have fun!
I wanted to get my Raspberry Pi 3 working as a node to support the network. Actually the process of installing and running the node was more or less easy - but for Noobs (like I am) it might be a bit tricky to start the whole thing, because there are different ways.
Did you - like me - think you would need +120GB on the raspi, external USB HDD to be a full node? You won't!
If you have a Raspberry and you know what Bitcoin is, I guess, you are a little bit aware of linux, networks and of course bitcoin - so I won't go into detail too much.
This guide is just a little helper to get a full node running on your raspberry pi. Thanks to the help of the nice people in this sub and of course the documentation by the developers, I got it working - and of course also special thanks to raspnode.com - as I followed their tutorial to start - I went some other ways here and there - so please read carefully.
For the Part 2 I would suggest to have http://raspnode.com/diyBitcoin.html open and read through my manual.
I split the tutorial in 2 Parts - PART ONE is about installing the client on your PC and downloading the Blockchain.
PART TWO is about the setup of the raspberryPi and transferring the pruned blockchain to the pi and run it as a full node!
The first thing to be aware of is: You actually need to download the whole blockchain to get this working - if you already have your bitcoin client synced on the PC / MAC great you can reuse it!
Now you might think "but you said less than 16GB in the title!"
Yes, but the good thing is you won't need to download it on your Raspberry, neither you need to sync it completely on your raspberry which took ages (weeks!) before. When you finished this Guide, you will just have a max. 4GB Blockchain on your Raspberry Pi - but it still is a full node! The magic word is Pruning.
Maybe even a 8GB SD Card works just fine including Linux (jessie lite)!
So, if you already have a full node on your PC - Great you can almost skip PART ONE - BUT have at how to Prune in PART ONE if you don't know about it.
For PART TWO you'll need a Raspberry Pi 2 or 3 (I used 3) min. 8GB (works also) or better 16GB SD Card. (I used a 128GB for the first version of this manual - which is way too big)

PART ONE

This is the manual how to get started on you PC / MAC / Linux (I did it on Win7)
Go to: https://bitcoin.org/en/download and download the core Client for your Machine (I used win64).
Install it and configure it to save the Blockchaindata to the directory of your choice - so instead getting 120GB on your C drive, I would suggest to download it to another place like a USB drive.
You can set this up during the install. Standard folder for the blockchain folder is "%APPDATA%\Bitcoin" on Windows.
or you can do it after the install by creating a bitcoin.conf file inside your installation folder / or %APPDATA%\Bitcoin and add
datadir=l:\yourfolder
to the file. Line by line.
By the way here you could also just add dbcache - to use more memory to speed up the process a bit:
dbcache=4096
if you don't want to use the settings inside the program. (you can also set this inside the program under settings! If you have this inside the bitcoin.conf you will see the amount you set there from inside the program - it overrides the values)
You can check inside the windows client under settings, if you can see a manual dbcache is set by having a look at the left footer area. When your dbcache value shows up, everything is fine.
So the Blockchain download process will take time - maybe a few days! Depending on your machine, internet connection and HDD.
The Blockchain is huge as it contains every single transaction of the past until today. You won't need to keep your PC running all the time, you can turn it off and on and it will resync automatically when you start bitcoin-qt.exe!
Make sure to close the client always via "quit" - ctrl+q.
After you have your bitcoin core installed, the blockchain downloaded and synced - you are ready to PRUNE!
First - close the Client and let it close smoothly. After it is really closed you can follow these steps:
By pruning, your blockchain will dramatically shrink. From 120GB to just a few GB.
Be aware, that you will lose your Downloaded Blockchain as pruning will erase a big chunk of it! If you have enough space, you could of course keep the full blockchain saved somewhere on another HDD.
You can prune by editing your bitcoin.conf file by adding:
prune=550
I used prune=1024 - not sure where the differences are right now (min. prune=550). (for my 8GB version I used 550! I suggest to use this.)
Save the bitcoind.conf file and restart your windows client.
It will now clean up the Blockchain. So just the latest blocks are saved. The client should start without any problems. Maybe it takes some time to prune the blockchain data.
Check if everything works normally (the client opens as usual, you can see an empty wallet) than close the client.
Inside the Bitcoin Folder, you'll find two folders called:
blocks chainstate
those are the interesting folders containing the important data (now pruned) - and we will transfer those two to the raspberry later!
Now you are good to start the raspi transfer explained in the next part.

PART 2

Here is what I did:
1) I installed Raspian Pixel (https://www.raspberrypi.org/downloads/raspbian/) using a 128 GB SD - which is not needed because of "Pruning" - I think a 16GB card might work, too! (You can also install Raspian Jessie Lite - which saves you even more space, as it runs headless - only command line) (Updated: It is better to use Jessie Lite to save a lot of space - when you are fine with only command line)
2) I followed partly this tutorial to get everything running and setup:
http://raspnode.com/diyBitcoin.html
Please have a look at it - I have copied the Headlines in capitals to let you know what I did, and what I skipped.
On Tutorial Page: Start with RASPBIAN (OPTIONAL) CONFIG OPTIONS.
Set You RasPi up including "EDITING FILES" to save your Layout at the tutorial page and come back here.
I skipped the CONFIGURE USB AND SET AUTOMOUNT process, as we are going to use PRUNING to reduce the 120GB to a tiny filesize - so USB Devices are not needed here!
It was necessary to ENLARGE SWAP FILE to install bitcoin core - otherwise it didn't went through which ended in a frozen raspi.
So have a close look by following the raspnode tutorial at: ENLARGE SWAP FILE.
I have my raspi running via cable to router - but you can also WiFi setup everything described under NETWORKING ON THE RASPBERRY PI.
Now comes the interesting part: Follow the steps at DOWNLOADING BITCOIN CORE DEPENDENCIES - they work fine for 0.14.0 too. Git should be on Board already when you installed Pixel - otherwise you would need to install it.
sudo apt-get install git -y (only jessy lite)
I skipped the next command lines - as I don't use bitcoin-qt wallet. If you want to use it as wallet - do the step.
mkdir ~/bin cd ~bin
Now you are in the folder you want your bitcoin core data be downloaded to via git. I didn't Downloaded the Berkeley Database source code - so I also skipped the whole next command lines
[email protected]~/bin$ wget http://download.oracle.com/berkeley-db/db-4.8.30.NC.tar.gz [email protected]~/bin$ tar -xzvf db-4.8.30.NC.tar.gz [email protected]~/bin$ cd db-4.8.30.NC/build_unix/ [email protected]~/bin/db-4.8.30.NC/build_unix$ ../dist/configure --enable-cxx [email protected]~/bin/db-4.8.30.NC/build_unix$ make -j4
and went on with "INSTALLING BITCOIN"!
I followed the first part but instead downloading 0.13 I took of course the latest version:0.14
git clone -b 0.14 https://github.com/bitcoin/bitcoin.git cd bitcoin ./autogen.sh
this might take some time to start.
If you have trouble with hanging RESOLVING DELTAS - just restart the Raspberry Pi and remove the bitcoin folder inside /~bin using
rm -rf bitcoin
this command will delete the folder and you can reuse
git clone -b 0.14 https://github.com/bitcoin/bitcoin.git

For some reason RESOLVING DELTAS is a common problem with different downloads - so just retry it and at least after 3 times it should work!

as I didn't use the GUI/ Wallet, I ran
./configure --enable-upnp-default --disable-wallet
as I don't need the wallet functionality.
I didn't need to use "MAKE" which saves you maybe up to 2.5 hours.
instead you can just go ahead with:
sudo make install
(If I am wrong in doing so - please let me know)
The install takes some time - and just a heads up: when it gets stuck somewhere - just redo the installation process - it took three times to went through - stuck at some processing.
After the installation took place you can finally get your Raspberry Pi Node running in no time!
To test if the the installation went through - you can just start bitcoind using:
bitcoind &
than check if everything is working so far:
bitcoin-cli getinfo
after a few seconds you should see version: etc...
if not, something went wrong. Try to redo the steps in the raspnode tutorial.
(don't give up if it failed - retry! Ask your questions here)
IMPORTANT: you need to stop bitcoin on your raspberry now!
bitcoin-cli stop
If you don't need an external USB Drive - what I hope - as we are going to use pruning just go ahead and skip the USB part and create a file inside (or follow the raspnode tutorial on how to setup the USB drive):
cd .bitcoin
sudo nano bitcoin.conf
and enter the exact same pruning size you have used on your Desktop Machine to prune. I used 1024 but the minimum is 550. (used 550 for the 8GB SD card on PC and Raspberry)
prune=550
That's it for the raspi.
update: To signal UASF enter in a new line:
uacomment=UASF-SegWit-BIP148

TRANSFER

Now you have to transfer the two folders CHAINSTATE and BLOCKS from your PC bitcoind directory to your raspberry.
I am using a program called "WINSCP" - it is free and easy to use: https://winscp.net/eng/download.php
We need this to transfer the files to the Raspberry pi. Pretty sure you can also do it via SSH - but I am the noob. So let's keep it simple.
Open Winscp and put in the IP Address of your Raspberry Pi, User and Password (same as in SSH)
You should now see the directories on your Raspberry Pi. There is a folder called
.bitcoin
enter it and you will see the two folders
blocks & chainstate
you can delete them on the raspberry as they have some data from your previous test inside.
Make sure you can also see the bitcoin.conf file in that directory, which needs to contain the exact same prune line, like the one on your desktop machine. If not, make sure to edit it via SSH. The line "datadir=l:\yourfolder" is obviously not needed in the Raspberry bitcoin.conf file.
Now grab the two folders CHAINSTATE and BLOCKS from your PC and copy them to your .bitcoind folder.
I also copied banlist.dat, fee_estimation.dat, mempool.dat and peers.dat to the folder - not really knowing if needed! Not needed.
The whole copy process might take some minutes (against some weeks in the old way).
After copying is finished, you can now start bitcoind on the Raspberry.
bitcoind &
the & symbol let you still use the command line while the process is running btw.
The process - if succesfull - will take some time to finish.
bitcoin-cli getinfo
Will give you some informations what is going on right now. When you can see, that it is checking the blocks, this is good!
If you get an error - double check - if you have the correct prune size (same as on desktop machine) - in bitcoin.conf and that this file is inside .bitcoin on RaspberryPi. It took me some time, to find my mistakes.
Congrats! You are almost a part of the network!
To make your node now a fullnode, you will need to go to your router (often 192.168.1.1) and enable portforwarding for your raspberry pi - and open ports 8333 - that's it!
You can now go to: https://bitnodes.21.co/nodes/
scroll down to "JOIN THE NETWORK" and check check if your node IP is connected!
It will show up as soon as the blocks are checked and the raspi is running.
Well done!
Now you are running a full node, with a small Blockchain and got it working in Minutes, not weeks!
I really hope, my little tutorial worked for you and your are part of the Node network now.
If you have problems or I made a mistake in this helper tut, just let me know and I will try to make it better.
Have fun and NODL!
the noob
tl;dr; (if you are a real noob start with the non-tl;dr version!)
tl;dr; PART ONE
1) Download & install / setup bitcoincore @ https://bitcoin.org/de/download
2) change dbcache to something smaller than your memory and download the whole Blockchain (120GB).
3) create a file called bitcoin.conf put the line prune=550 (or higher) in to activate pruning on win inside %appData%/bitcoin
4) Open ports 8333 on your Router to make this a full node with a smaller Blockchain.
You are running a full node on your PC.
tl;dr; PART TWO
1) Install jessie lite and the needed dependencies on your SDCard - Raspberry
( >git clone -b 0.14 https://github.com/bitcoin/bitcoin.git )
  • see tutorial for more info.
2) create a file called bitcoin.conf inside .bitcoin and add the same prune=Number you had on your PC.
3) transfer the pruned folders BLOCKS and CHAINSTATE to the Raspberry Folder .bitcoin
4)Start "bitcoind &"
5) let everything sync
6) Make sure you have port 8333 opened on your router.
You are running a full node on your Raspberry with a super small Blockchain (I put all on a 8GB SDcard)
Tip if you want : 19656Uwdwko5RjtnuwQENpjBwE3ChzD59v
updated 03/12 - will update more, soon.
updated 03/12.2 - I updated the whole process a bit and also added some improvements.
updated 03/14/ Added a tl;dr version at the end.
submitted by I-am-the-noob to Bitcoin [link] [comments]

A Guide to Keeping Keys Offline Using Armory +rPi

Hi Redditors.
I am going to post in this thread my experiences in getting my Desktop (Debian) machine running Armory in watch-only mode, and coupling that with an offline Raspberry Pi (which holds my private keys) for signing the transactions previously made in watch-only mode.
I actually compiled Armory from source directly on my Pi. This guide is probably more for the bitcoin 'power user', as to run Armory online, and broadcast the signed transactions, you need to have a bitcoin full node running (bitcoind).
Basic requirements:
Aimed-for Setup:
I'll post the guide in digestible sections...

Section 1

I should begin by saying I installed source code from git, and got Armory to build the DB on my desktop initially, WITHOUT creating a wallet.. (This allowed me to debug what was going on a little!)
Go to Bitcoin.org, select Armory..
It leads to a Download from Git:
https://github.com/goatpig/BitcoinArmory/releases
Followed the procedure for Linux Debian verify code, compile, install, all straight-forward..
Began by running bitcoind, and telling Armory where to find it. This is the command I used, obviously it was all on one line and didn't include the arrows/explanations!:
python ArmoryQt.py \ --satoshi-datadir=/BlockChain/chain20180414/blocks \ # <-----(where my bitcoind blocks live) --datadir=/ArmoryDataDi \ # <-----(this is instead of ~/.armory) --dbdir=/ArmoryDataDidatabases # <-------(again, non std. place used for Armory's databases.. my choice.) 
So, on the Desktop, after the initial "build databases"
(NB the initial "Build Databases" took about 1.5h and my two CPUs were maxed the whole time, Temps up to 62C. Not ideal; Im not in a rush!)
I then wanted to import a watch-only wallet.
Before I did this, I took a full backup of the Armory data dir:
/ArmoryDataDi
(or ~/.armory in a default installation).
I'd hate to have to make Armory do another full sync with the bitcoind node!

Section 2

Next step: offline wallet (with Private Keys) is on a Raspberry Pi.
I downloaded the source and managed to compile it on the pi itself! :)
Though there were some gymnastics needed to setup the Pi.
My Pi is running Raspbian based on Wheezy.. quite old!
I did the following on the Pi:
apt-get update apt-get upgrade (<---took about an hour!) apt-get install autotools-dev apt-get install autoconf 
Then I followed the instructions exactly as I had done for my Debian Desktop machine, EXCEPT:
I had to increase the Pi's swap space. I upped it from 100Mb to 400Mb.
The compilation took 7 hours, and my poor SD card got a thrashing.
But after compilation, I put the Swap back to 100Mb and Armory runs ok with about 150Mb of memory (no swap needed).
Swap increase on the Pi:
use your favourite editor, and open the file /etc/dphys-swapfile
add/change the following line:
CONF_SWAPSIZE=400 
Then, REBOOT the Pi:
sudo shutdown -h -P now 
Once the compilation was done on the Pi, put the swap back, rebooted and created an Armory wallet.
I added manual entropy and upped the encryption 'time' from 250ms to 2500ms - since the Pi is slow, but I'll be happy to wait for more iterations in the Key Derivation Function.
Once the wallet was created, it obviously prompts you for backup.
I want to add a private key of my own (i.e. import), so don't do the backup until this is over.
I import my Private Key, and Armory checks that this corresponds to a Public Key, which I check is correct.
This is the point now where the Pi storage medium (e.g an SD card) has to be properly destroyed if you ever get rid of it.
I had thought that now would be a good time to decide if your new wallet will generate Segwit receiving addresses, and also addresses used to receive 'change' after a transaction..
But it seems Armory WON'T let you switch to P2SH-P2WPKH unless your Armory is connected to a node offering "WITNESS" service.
Obviously, my Pi is offline and will never connect to a node, so the following will not work on the Pi:
NB: I thought about setting this on the Debian "watch-only" wallet, but that would surely mean doom, as the Pi would not know about those addresses and backups might not keep them.. who knows...
So, end result:- no segwit for me just yet in my offline funds.

--If anyone can offer a solution to this, I'd be very grateful--

Section 3

Ok, now this is a good point to back up your wallet on the Pi. It has your imported keys. I choose a Digital Backup - and put it on a USB key, which will never touch the internet and will be stored off-site. I also chose to encrypt it, because I'm good with passwords..
NB: The Armory paper backup will NOT back up your imported private keys, so keep those somewhere if you're not sweeping them. It would be prudent to have an Armory paper backup anyway, but remember it will likely NOT help you with that imported key.
Now for the watch-only copy of the wallet. I want to get the "watch-only" version onto my Desktop Debian machine.
On the Pi, I created (exported to a USB key) a "watching-only" copy of my wallet.
I would use the RECOMMENDED approach, export the "Entire Wallet File".
As you will see below, I initially exported only the ROOT data, which will NOT capture the watching-only part of the Private Key I entered manually above (i.e. the public Key!).
Now, back on the Debian Desktop machine...
I stopped all my crontab jobs; just give Armory uninterrupted CPU/memory/disk...
I also stopped bitcoind and made a backup prior to any watch-only wallet being imported.
I already made a backup of Armory on my Desktop, before any wallet import.
(this was needed, as I made a mistake.. see below)
So on the Debian Desktop machine, I begin by firing up bitcoind.
my command for this is:
./bitcoind -daemon -datadir=/BlockChain/chain20180414 -dbcache=400 -maxmempool=400 

Section 4

I try running Armory like this:
(I'm actually starting Armory from a script - StartArm.sh)
Inside the script StartArm.sh, it has the line:
python ArmoryQt.py --ram-usage=4 --satoshi-datadir=/BlockChain/chain20180414/blocks --datadir=/ArmoryDataDi --dbdir=/ArmoryDataDidatabases 
I know from bitter experience that doing a scan over the blockchain for a new wallet takes a looong time and a lot of CPU, and I'd like it to play nicely; not gobble all the memory and swap and run my 2xCPUs both at 100% for four hours...
So... I aim to run with --ram-usage=X and --thread-count=X
(For me in the end, X=1 but I began with X=4)
I began with --ram-usage=4 (<--- = 4x128Mb)
The result is below...
TypeError: cannot concatenate 'str' and 'int' objects 
It didn't recognise the ram-usage and carried on, crippling my Debian desktop PC.
This is where it gets dangerous; Armory can gobble so much memory and CPU that the windowing environment can cease up, and it can take over 30 minutes just to exit nicely from bitcoind and ArmoryDB.
So, I ssh to the machine from another computer, and keep an eye on it with the command
"free -h" 
I'd also be able to do a "sudo reboot now" if needed from here.

Section 5

So, trying to get my --ram-usage command recognised, I tried this line (added quotes):
python ArmoryQt.py --ram-usage="4" --satoshi-datadir=/BlockChain/chain20180414/blocks --datadir=/ArmoryDataDi --dbdir=/ArmoryDataDidatabases 
But no, same error...
Loading Armory Engine: Armory Version: 0.96.4 Armory Build: None PyBtcWallet Version: 1.35 Detected Operating system: Linux OS Variant : ('debian', '9.4', '') User home-directory : /home/ Satoshi BTC directory : /BlockChain/chain20180414 Armory home dir : /ArmoryDataDi ArmoryDB directory : /ArmoryDataDidatabases Armory settings file : /ArmoryDataDiArmorySettings.txt Armory log file : /ArmoryDataDiarmorylog.txt Do wallet checking : True (ERROR) ArmoryUtils.py:3723 - Unsupported language specified. Defaulting to English (en) (ERROR) ArmoryQt.py:1833 - Failed to start Armory database: cannot concatenate 'str' and 'int' objects Traceback (most recent call last): File "ArmoryQt.py", line 1808, in startArmoryDBIfNecessary TheSDM.spawnDB(str(ARMORY_HOME_DIR), TheBDM.armoryDBDir) File "/BitcoinArmory/SDM.py", line 387, in spawnDB pargs.append('--ram-usage=' + ARMORY_RAM_USAGE) TypeError: cannot concatenate 'str' and 'int' objects 

Section 6

So, I edit the Armory python file SDM.py:
if ARMORY_RAM_USAGE != -1: pargs.append('--ram-usage=4') #COMMENTED THIS, SO I CAN HARDCODE =4 # ' + ARMORY_RAM_USAGE) 
Running it, I now have acknowledgement of the --ram-usage=4:
(WARNING) SDM.py:400 - Spawning DB with command: /BitcoinArmory/ArmoryDB --db-type="DB_FULL" --cookie --satoshi-datadir="/BlockChain/chain20180414/blocks" --datadir="/ArmoryDataDi" --dbdir="/ArmoryDataDidatabases" --ram-usage=4 
Also, even with ram-usage=4, it used too much memory, so I told it to quit.
It took over 30 minutes to stop semi-nicely. The last thing it reported was:
ERROR - 00:25:21: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unexpected fcgi header version 
But that didn't seem to matter or corrupt the Armory Database, so I think it's ok.
So, I get brave and change SDM.py as below, and I make sure my script has a command line for --ram-usage="ABCDE" and --thread-count="FGHIJ"; the logic being that these strings "ABCDE" will pass the IF criteria below, and my hardcoded values will be used...
if ARMORY_RAM_USAGE != -1: pargs.append('--ram-usage=1') #COMMENTED THIS, SO I CAN HARDCODE =1 # ' + ARMORY_RAM_USAGE) if ARMORY_THREAD_COUNT != -1 pargs.append('--thread-count=1') #COMMENTED THIS, SO I CAN HARDCODE =1 #' + ARMORY_THREAD_COUNT) 
So, as usual, I use my script and start this with: ./StartArm.sh
(which uses command line:)
python ArmoryQt.py --ram-usage="ABCDE" --thread-count="FGHIJ" --satoshi-datadir=/BlockChain/chain20180414/blocks --datadir=/ArmoryDataDi --dbdir=/ArmoryDataDidatabases 
(this forces it to use my hard-coded values in SDM.py...)
So, this is the command which it reports that it starts with:
(WARNING) SDM.py:400 - Spawning DB with command: /BitcoinArmory/ArmoryDB --db-type="DB_FULL" --cookie --satoshi-datadir="/BlockChain/chain20180414/blocks" --datadir="/ArmoryDataDi" --dbdir="/ArmoryDataDidatabases" --ram-usage=1 --thread-count=1 
Again, this is where it gets dangerous; Armory can gobble so much memory and CPU that the windowing environment can cease up. So I ssh to the machine and keep an eye on it with:
"free -h" 

Section 7

So, on the Debian Desktop PC, I inserted the USB stick with the watch-only wallet I exported from the Pi.
Start Armory...
Import "Entire Wallet File" watch-only copy.
Wait 4 hours..
YAY!!!
After running Armory for about 30m, the memory usage dropped by 400m... wierd...
It took ~2 hours to get 40% completion.
After 3.5 hours it's almost there...
The memory went up to about 1.7Gb in use and 900Mb of Swap, but the machine remained fairly responsive throughout, apart from a few (10?) periods at the start, where it appeared to freeze for 10-30s at a time.
(That's where my ssh session came in handy - I could check the machine was still ok with a "free -h" command)
Now, I can:
Create an unsigned transaction on my Desktop,
Save the tx to USB stick,
Move to the Pi,
Sign the tx,
Move back to the Desktop,
Broadcast the signed tx.

Section 8

My initial Mistake:
This caused me to have to roll-back my Armory database, using the backup. so you should try to avoid doing this..
On the Pi, I exported only the ROOT data, which will NOT capture the watching-only part of the Private Key
It is RECOMMENDED to use the Digital Export of Entire Wallet File from the Pi when making a watch-only copy. If you just export just the "ROOT data", not the "Entire Wallet File", you'll have problems if you used an imported Private Key in the offline wallet, like I did.
Using the ROOT data text import, after it finished... my balance was zero. So,. I tried a Help->Rescan Balance (Restart Armory, takes 1minute to get back up and running) No Luck. Still zero balance.
So, I try Rescan Databases.. This will take longer. Nah.. no luck.
So, I tried again, thinking it might be to do with the fact that I imported the text "root data" stuff, instead of following the (Recommended) export of watching-wallet file.
So, I used my Armory backup, and wound back the ArmoryDataDi to the point before the install of the (zero balance) wallet. (you should not need to do this, as you will hopefully use the RECOMMENDED approach of exporting the "Entire Wallet File"!)
submitted by fartinator 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]

A guide to sign a super bitcoin (SBTC) transaction offline with patched Electrum for paranoid. Supports any wallets supported by Electrum (including segwit-p2sh and bech32 and all BIP39 seeds). Later BCD will be added.

This is quite advanced. This guide assumes you have some basic experience with the command line, can run Linux and you understand the basics of keys/signing/broadcasting transactions. And that you can compile and run Bitcoin Core and run Electrum. Also, some JSON experience is also nice.
Move you bitcoins to safe addresses first. It is best to use a new seed. Although the procedure in this guide is safe even for hot addresses (containing bitcoins), there is always a risk of a critical mistake. So play it safe.
Why such a guide? I followed these steps because I did not want to expose the keys to any online machine at all. Even if the keys do not have any bitcoins, you can some day have bitcoins sent to these addresses or you have a fork that you have not claimed. All can be stolen if you exposed your key.
This procedure should work with everything that Electrum supports (except maybe F2A that may be not supported on the SBTC chain), so Electrum seed legacy or segwit, LedgeTrezor with legacy or segiwt-p2sh (m/'49) derivation. Similarly, any BIP39 seeds or a single key. are also fine.
  1. Download Electrum. git clone https://github.com/spesmilo/electrum
  2. Apply my patch patch -P0 also this article. The guide assumes that you use patched Electrum from now on.
  3. Run the patched Electrum and catch up with your wallets you want to claim (the wallets can and rather should be watch only, or on ledgetrezor, otherwise your keys are exposed). Now go offline or set localhost as your server that Electrum connects to so no connection is performed. It's required so Electrum will not update the wallet after you edit it.
  4. You can manually create a transaction from the command line but you can use Electrum GUI. You need to locate the wallet file and remove all the transactions from the wallet file except for the one that funds the address you want to claim (the wallet obviously must not be encrypted but for watch-only this is OK). This is tricky. You need to make sure, you gave a proper JSON file, so all the final commas must be dropped. So "addr_history":, "transactions": , "tx_fees":, "txi", "txo", and "verified_tx3": should only contain the funding transaction(s), i.e. the one that you want to spend from.
  5. Run Electrum and check if the wallet is OK. Electrum will show an error if not. You will probably make a few errors so go back to editing the wallet.
  6. Download SBTC bitcoin core clone. git clone https://github.com/superbitcoin/SuperBitcoin
  7. Compile it and let it sync the blockchain (it will take a long time). Run it it with as large -dbcache= as you can. If you have a Bitcoin blockchain you can copy the blocks up to the fork date and issue sbtcd with -reindex. It will just reindex them and it will be faster.
  8. Generate a sbtc address with sbtc-cli getnewaddress. You can skip this step and send directly to an exchange but this intermediate step is safer.
  9. Create a transaction in Electrum to this address. Select all the bitcoins and use as small fee as possible (SBTC blocks are empty so any fee above 1 SBTCsat/byte should be OK).
  10. Save the transaction to a pendrive
  11. Download and install Kubuntu 16.04 (Kubuntu has all the QT libraries for Electrum) on a pen drive.
  12. Copy patched Electrum and the save the transaction to a pen drive (separate from Kubuntu will be more convenient).
  13. Run Kubuntu from the USB without any network access. Run Electrum from the pendrive. Create a wallet from the seed or private keys. The wallets are stored in RAM so after you reboot the computer, they will be gone. Load the transaction, sign it and save it to the pen drive.
  14. Go back to the SBTC Core on the online machine. Display the raw transaction (starts with the hex=). Check in the SBTC Core if it is correct sbtc-cli decoderawtransaction hex
  15. If it looks fine (and your blockchain got synced), broadcast it sbtc-cli sendrawtransaction hex
If there is no error, congratulations, you sent the transaction to the specified address. If it is to your SBTC Core wallet, wait until it confirms and send it further with sbtc-cli setfee feeperkb sbtc-cli sendtoaddress "addr" value "" "" true true
I'm going to update this guide when I figure out the BCD transactions intrinsics. You can download and run the BitcoinDiamond Core clone in the meantime.
SBTC tips: 1KjuY8CTrwMhdLt3uF3hCcSgfkHMyo1ELf
submitted by PVmining to BitcoinAirdrops [link] [comments]

Running an ABC node on Hetzner. €35/mo, initial block download in less than 4 hours

Inspired by Running an ABC full node for one month on Google Cloud, I set up an ABC node on Hetzner. I had not previously used Hetzner's services and decided this rainy Sunday afternoon would be good time for trying them out.
The server I picked: Intel i7-3770 (4 cores @ 3.40GHz, with hyperthreading), 16GB RAM, 2x2TB HDD, 1Gbit unlimited traffic. Costs ~€35/mo. My criteria was: a decent CPU and 16GB of RAM. Based on my past experience, I don't think having 32GB or more RAM would make much difference for a Bitcoin node. For storage, I also considered going with a SSD instead of the "spinning rust". When I looked, SSD offers were around €42/mo for 240GB of storage. Ultimately I went with the cheaper HDDs, assuming the "hot" data will be cached in RAM anyway.
Hetzner verified my fresh account and sent me login details in about 10 minutes (remember, it's Sunday). Setting up Ubuntu 17.04 on the server was reasonably straightforward: type "installimage" and follow instructions. The installimage script gave more flexibility with partition setup, filesystem types etc. than e.g. DigitalOcean does. A few minutes later I was logged in the freshly baked 17.04 system as a root user.
Create an unprivileged system user, download and extract the Bitcoin ABC client, run it with "-dbcache 12000". Initial block download completed in 3 hours 35 minutes. Now, I don't actually have an use for a node, but will keep this running for at least a month just to see how it do. So far I'm happy with Hetzner: works as advertised and no fuss.
The thing with Google Cloud Platform (which I am also a happy customer of): their network is really fancy: custom hardware, private fiber optic links, and an army of engineers managing all of that. Combine with Google's Global Load Balancer (obviously only available in Google Cloud) and the value proposition for running production web apps is pretty solid. Plus their VMs are server-class hardware, their storage has redundancy etc. But it's an overkill for running an enthusiast bitcoin node which really just needs a big disk, some RAM and a cheap, fast-enough network connection.
PS I've written before about setting up a node on a €50 secondhand laptop. That node is up doing great.
submitted by medieval_llama to btc [link] [comments]

bitcoind crashing and corrupting chain, can't get the node synced -- known issue? Possible fix?

I'm running Bitcoin Classic from the official PPA on an Atom CPU using 2 GB of RAM and
bitcoind -disablewallet -daemon -dbcache=1000 
to launch bitcoind. Every time I checked, RAM usage was below 1.5 GB. Today, I came back to see the following in the log:
2016-03-12 17:32:29 Pre-allocating up to position 0x1000000 in rev00363.dat 2016-03-12 17:32:29 UpdateTip: new best=000000000000000005efb0fa564aebed1543e91fb7cbb3666f76518d04beeab4 height=381436 log2_work=83.542258 tx=90266769 date=2015-10-31 19:48:01 progress=0.884439 cache=716.5MiB(399486tx) 2016-03-12 17:32:29 UpdateTip: new best=0000000000000000047b1c27126c0a92cc353deed82a8308ec3f14b21f56bae0 height=381437 log2_work=83.542286 tx=90266771 date=2015-10-31 19:42:28 progress=0.884436 cache=716.5MiB(399488tx) 2016-03-12 17:32:31 UpdateTip: new best=000000000000000009b442d95f5c8944916990d3bd73564cfdf06c80ec51f630 height=381438 log2_work=83.542313 tx=90269011 date=2015-10-31 19:48:59 progress=0.884443 cache=718.0MiB(401474tx) 2016-03-12 17:32:33 UpdateTip: new best=00000000000000000e8e6eb74e60af14a855276d2cdb9fc0a4502720e39f9d61 height=381439 log2_work=83.54234 tx=90271316 date=2015-10-31 19:55:44 progress=0.884450 cache=718.8MiB(403323tx) 2016-03-12 17:32:39 ************************ EXCEPTION: St9bad_alloc std::bad_alloc bitcoin in ProcessMessages() 2016-03-12 17:32:39 ProcessMessages(block, 270899 bytes) FAILED peer=12 2016-03-12 17:32:41 ERROR: ConnectBlock(): inputs missing/spent 2016-03-12 17:32:41 Misbehaving: 5.9.101.143:8333 (0 -> 100) BAN THRESHOLD EXCEEDED 2016-03-12 17:32:41 InvalidChainFound: invalid block=00000000000000000be349d51a1fc4cc9a70f9ca067517aeedffbbf83304e5eb height=381440 log2_work=83.542368 date=2015-10-31 20:09:22 2016-03-12 17:32:41 InvalidChainFound: current best=00000000000000000e8e6eb74e60af14a855276d2cdb9fc0a4502720e39f9d61 height=381439 log2_work=83.54234 date=2015-10-31 19:55:44 2016-03-12 17:32:41 ERROR: ConnectTip(): ConnectBlock 00000000000000000be349d51a1fc4cc9a70f9ca067517aeedffbbf83304e5eb failed 2016-03-12 17:32:41 InvalidChainFound: invalid block=00000000000000000be349d51a1fc4cc9a70f9ca067517aeedffbbf83304e5eb height=381440 log2_work=83.542368 date=2015-10-31 20:09:22 2016-03-12 17:32:41 InvalidChainFound: current best=00000000000000000e8e6eb74e60af14a855276d2cdb9fc0a4502720e39f9d61 height=381439 log2_work=83.54234 date=2015-10-31 19:55:44 2016-03-12 17:32:41 connect() to [2001:41d0:1:a5b8::1]:8333 failed: Network is unreachable (101) 2016-03-12 17:32:41 connect() to [2001:470:507d:0:6ab5:99ff:fe73:ac18]:8333 failed: Network is unreachable (101) 2016-03-12 17:32:42 receive version message: /Classic:0.12.0/: version 70012, blocks=402365, us=163.172.136.98:49308, peer=22 2016-03-12 17:32:45 Pre-allocating up to position 0x2000000 in blk00366.dat 2016-03-12 17:32:49 Pre-allocating up to position 0x3000000 in blk00366.dat 2016-03-12 17:32:52 Pre-allocating up to position 0x4000000 in blk00366.dat 2016-03-12 17:32:54 Pre-allocating up to position 0x5000000 in blk00366.dat 2016-03-12 17:32:59 Pre-allocating up to position 0x6000000 in blk00366.dat 2016-03-12 19:01:05 tor: Thread interrupt 
The last line is me rebooting the box. When the node came back up, it started vomiting all over the log, which I assume means the block database is FUBAR (again) and I'll have to delete and re-download everything:
2016-03-12 19:01:30 Bitcoin version v0.12.0.0-unk (Mar 9 2016, 01:41:30) 2016-03-12 19:01:30 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1 2016-03-12 19:01:30 Using OpenSSL version OpenSSL 1.0.1f 6 Jan 2014 2016-03-12 19:01:30 Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010) 2016-03-12 19:01:30 Default data directory /home/bitcoin/.bitcoin 2016-03-12 19:01:30 Using data directory /home/bitcoin/.bitcoin 2016-03-12 19:01:30 Using config file /home/bitcoin/.bitcoin/bitcoin.conf 2016-03-12 19:01:30 Using at most 125 connections (1024 file descriptors available) 2016-03-12 19:01:30 Using 2 threads for script verification 2016-03-12 19:01:30 scheduler thread start 2016-03-12 19:01:30 HTTP: creating work queue of depth 16 2016-03-12 19:01:30 No rpcpassword set - using random cookie authentication 2016-03-12 19:01:30 Generated RPC authentication cookie /home/bitcoin/.bitcoin/.cookie 2016-03-12 19:01:30 HTTP: starting 4 worker threads 2016-03-12 19:01:30 Bound to [::]:8333 2016-03-12 19:01:30 Bound to 0.0.0.0:8333 2016-03-12 19:01:30 Cache configuration: 2016-03-12 19:01:30 * Using 2.0MiB for block index database 2016-03-12 19:01:30 * Using 257.5MiB for chain state database 2016-03-12 19:01:30 * Using 740.5MiB for in-memory UTXO set 2016-03-12 19:01:30 init message: Loading block index... 2016-03-12 19:01:30 Opening LevelDB in /home/bitcoin/.bitcoin/blocks/index 2016-03-12 19:01:31 Opened LevelDB successfully 2016-03-12 19:01:31 Using obfuscation key for /home/bitcoin/.bitcoin/blocks/index: 0000000000000000 2016-03-12 19:01:31 Opening LevelDB in /home/bitcoin/.bitcoin/chainstate 2016-03-12 19:01:32 Opened LevelDB successfully 2016-03-12 19:01:32 Using obfuscation key for /home/bitcoin/.bitcoin/chainstate: 0000000000000000 2016-03-12 19:01:41 LoadBlockIndexDB: last block file = 366 2016-03-12 19:01:41 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=120, size=88408331, heights=381171...381988, time=2015-10-30...2015-11-04) 2016-03-12 19:01:41 Checking all blk files are present... 2016-03-12 19:01:41 LoadBlockIndexDB: transaction index disabled 2016-03-12 19:01:42 LoadBlockIndexDB: hashBestChain=00000000000000000e8e6eb74e60af14a855276d2cdb9fc0a4502720e39f9d61 height=381439 date=2015-10-31 19:55:44 progress=0.884403 2016-03-12 19:01:42 init message: Verifying blocks... 2016-03-12 19:01:42 Verifying last 288 blocks at level 3 2016-03-12 19:01:42 ERROR: DisconnectBlock(): added transaction mismatch? database corrupted 2016-03-12 19:01:42 ERROR: ApplyTxInUndo: undo data adding output to missing transaction 2016-03-12 19:01:42 ERROR: ApplyTxInUndo: undo data overwriting existing transaction 2016-03-12 19:01:42 ERROR: ApplyTxInUndo: undo data overwriting existing output 2016-03-12 19:01:42 ERROR: ApplyTxInUndo: undo data adding output to missing transaction 
I thought this may have been a "speciality" of the ARM version I compiled myself when I saw it previously, but now it's happening with official binaries on a completely different platform (still hosted at Scaleway, but their x86_64 based offering, not their ARM offering). Of course, I can't rule out Scaleway somehow being unable to deal with the traffic pattern of bitcoind and corrupting the DB - is there a way to debug that?
Does anyone know what may cause this or what to do against it? I don't believe in the "out of RAM" theory since I also had similar crashes happen on nodes with ridiculous amounts of swap enabled (this box didn't though). I really can't run a node if it's going to keep blowing up.
If any somewhat-well-known developer wants to debug this/have a look at the corrupted database, send me your SSH public key and I'll give you access to the node. There's nothing of value on the box, the cost is limited, and traffic doesn't cost me anything, so I'm happy to let you play with it for a month or so.
submitted by aaaaaaaarrrrrgh to btc [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]

Programming in Visual Basic .Net How to Connect Access ... Come velocizzare sincronizzazione portafoglio Bitcoin Core - Guida Definitiva Sans limites TV - YouTube Getting your Private Keys from the Bitcoin Core wallet ...

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 ... I have also tried removing -dbcache=700 from my bitcoin.conf and instead setting 1000 MB as the database cache option in the GUI options window (and restarting of course). Neither the bitcoin.conf nor the database cache size option in the options seem to affect how much memory is allocated to bitcoin core, even tho I have at least 800MB free. Once this value reaches almost 1 (0.999…), the blockchain is up-to-date and fully validated. 🚨 Please let Bitcoin Core sync fully before proceeding. This can take up to a week when using a Raspberry Pi 4, depending mostly on your external drive (SSD good, HDD bad; USB3 good, USB2 bad). Explore bitcoin-cli . If everything is running smoothly, this is the perfect time to familiarize ... Fixes: #11788 Shows correct value according to command line override or value in bitcoin.conf. bitcoinlib.db_cache module¶ class bitcoinlib.db_cache.DbCacheAddress (**kwargs) [source] ¶. Bases: sqlalchemy.ext.declarative.api.Base Address Cache Table. Stores transactions and unspent outputs (UTXO’s) per address. A simple constructor that allows initialization from kwargs.

[index] [4044] [24265] [45761] [1567] [40368] [9740] [5198] [24792] [37352] [29806]

Programming in Visual Basic .Net How to Connect Access ...

Chaine d'information Sans Limites TV éditée par le Groupe GSL Communication, Ouest Foire Dakar ( Sénégal ) Directeur de Publication : Yankhoba SANE SERVICE C... 👨‍🏫 Join this channel to get access to perks: Online Programming Courses! 🎓 https://www.youtube.com/channel/UCb3Ryh3sdgpDBiVVAgi1I7g/join 🚀 Tutorials ... In this tutorial we are going to get our private keys from the bitcoin core wallet. This only works when you created the bitcoin address in the same wallet. ... Programming Made Fun and Simple High quality tutorials that are fun, educational, and easy to follow. Teaching programming is my passion! I find joy in makin... Gossip Room est une communauté sur les réseaux sociaux, créée il y a 7 ans, qui regroupe aujourd’hui des millions de passionnés d’actualité TV, people, série...

#