It's not enough to run a full node in some raspberry pi that you will never use. You should use it to transact too, so it becomes an economic node and you are in charge of your money 100%, knowing what you are doing. The problem is keeping your bitcoins safe.. which is why im asking what is the best operating system to run a full node that is also used as a wallet: https://bitcointalk.org/index.php?topic=2332405.msg23830612please help. Linux of course. I think a good choice is Ubuntu (which is derived from Debian). This is what I run on my VPS and it is very easy to maintain and upgrade (I just upgraded to 17.10). My SPV desktop wallet (Windows 10) connects to just my VPS node, so I know that wallet transactions have been verified. |
|
|
|
So what will happen if I refuse to accept 2Mb blocks, and stay with a legacy node?
You will remain on the current chain. If you are running Bitcoin Core 0.13 or later, the witness data is not being stripped since your node does support segwit. The real question is what chain will be followed by the merchants and exchanges you use for your transactions. For me, this will determine which chain I follow. The worst case is that they are split between the two chains. In addition, if the user nodes run a mix of software, your transaction may or may not reach a miner for the desired chain (as well as being replayed on the other chain). |
|
|
|
There is also another potential factor that you ignored. If your internet connection is somehow throttled, it would definitely be much slower. In addition, if your internet is slow, that can be a bottleneck. Bitcoin Core is also heavily reliant on the disk speed. If your read/write speeds are slow, it would also be a bottleneck.
No, no, my internet has been neither throttled, nor slow. The only potentially possible bottleneck related to my computer could have been hard disk read/write operations (as it was a usual 7200 rpm hdd, not an SSD). But! At a moment (when the downloaded blockchain data had not exceeded 32Gb) I tried to move the data directories to a fast USB 3.0 flash card (exactly to find what was the bottleneck). The syncing did become a little bit faster indeed. But Not significantly! I run Bitcoin Core on a VPS with high-speed internet and SSD disks. The bottleneck during initial block download for me is definitely CPU (100% CPU utilization). I've noticed the same thing on my desktop system. So it really depends on your hardware and your internet connection. |
|
|
|
You should check the log for your node (debug.log in the Bitcoin data directory). See if connection attempts are being rejected or dropped. I run a 24/7 0.15 node on my VPS and I see a number of 0.14 inbound connections, so that shouldn't be the problem. As an aside, I currently have 100 connections and none of them identify themselves as S2X nodes. I'm not rejecting S2X connections (I modified 0.15 to only reject BitcoinABC connections), so that isn't the issue. When the fork happens in mid-November, it looks like the bulk of the user nodes will not follow the new chain but stay on the current chain (including my node). Unless the S2X nodes are in deep stealth mode and identify themselves as Bitcoin Core 0.15  |
|
|
|
|
Google Authenticator (or WinAuth on PC) is secure and does not rely on any network exchange. Coinbase no longer recommends Authy and tells its users to use Google Authenticator. If you use one of these programs, be sure to record the QR code (or the secret phrase) so you can recover the authenticators if you need to get a new phone.
|
|
|
|
Here is how you can build them yourself. Fucking routine! )))))))) I need two files. One library file and one .h file for compiling my c++ sources for my windows I do not want to install addional msys/mingw/compilers/tools/managers/etc/etc/etc Why the things in modern software development are so complicated?  I feel your pain The Windows 10 Creators Fall Update includes the Linux subsystem. It allows you to run Linux under Windows with better integration than using a separate virtual machine (such as VirtualBox). I'm part of the Windows Insider program and I installed Ubuntu without any problems and can directly read/write files in the Windows filesystem from my Ubuntu session (the reverse is not true - you cannot access Linux files from a Windows session). I successfully ran bitcoind in the Linux session. Unfortunately, there is no official GUI support in the Linux session, although I have seen reports of people who have gotten Gnome up and running. I may look into this some more after the Fall Update is officially released (it is getting close - I have been getting new builds every 2-4 days recently). |
|
|
|
The companies that have reneged on the NYA conduct very little business.
Coinbase and Bitpay (and similar) have a 'sticky' userbase that for the most part is apathetic towards which scaling solutions are implemented provided the cost of using Bitcoin is lower than the cost of using traditional fiat-based payment systems, and most importantly, these companies have significant user trust that is not easily replaceable. These companies also have elaborate customer service, regulatory compliance (among other) systems in place that takes significant time, expertise and investment to build up.
You cannot fork the Coinbase code, lower the fees a little bit and expect to do any meaningful amounts of business. The NYA on the other hand, literally forks the Bitcoin code, and there are plenty of qualified devs (even those that are not currently involved in Bitcoin or any other cryptocurrency) that can potentially work on Bitcoin in the future.
I live in NY and use Coinbase, Bittrex and BitPay. Having jumped through all of the regulatory hoops to prove my identity, it is unlikely that I will switch to another set of companies. And many companies do not do business with NY residents, as I have found out (no, I am not going to move to another state). So I will use whatever software is required so that I can continue to work with bitcoins. |
|
|
|
|
What is important to me is what software will be used by the companies that I do business with. If they use Bitcoin Core, then I must continue to use Bitcoin Core. If they switch to BTC1, then I'll need to switch as well. The worst case would be they are split between the two chains.
BitcoinABC included replay protection so you could use either chain (although you still needed to install software for both chains). But BTC1 has said they will not include replay protection, so this leads to transactions being accepted on both chains. I understand why BTC1 does not want replay protection: it would require new wallets for everybody to use the BTC1 chain.
|
|
|
|
Wow you really know what you are doing, im checking through your github now. ill spend a few hours reading through code to see if its something i could tackle in a reasonable amount of time or not.
My biggest issue with bitcoinj s that i cant manage to persist a balance without deleting and re-downloading the block-chain. in main net this would be horribly slow for a server side app. maybe i am wrong and im doing it incorrectly, but i have about a week experience with bitcoinj.
My plan b was, use bitcoin-j, rewrite the source a bit to allow for a more "direct" approach. but your classes look a lot like whats in bitcoinj too, did you use bitcoinj as a base? how did you go about writing that?
can you outline a bit about what was involved in writing yoru bitcoin core framework/library or whatever you may call it.
also i notice a lot of bloom filtering and merkel root classes, is this doing the same as bitcoinj by only using spv wallets? or are those classes just carried over?
My BitcoinCore library supports both servers and wallets. Thus it has support for bloom filters which are used by SPV wallets. You need the Merkel root support to validate incoming transactions. I started using BitcoinJ. When I decided to go my own way (mainly because BitcoinJ at that time did not support servers), I kept the same class names and parameters so that my existing application code would continue to work. Since then, the design has diverged significantly, especially with the addition of HD keys and segregated witness transactions. I'm not sure what you mean when you say you cannot persist a balance. Do you mean the wallet has no transactions after a restart? If you look at the BitcoinWallet class in the version-2 branch of TokenExchange, that uses the BitcoinJ wallet support. So that might give you some pointers on maintaining a wallet using BitcoinJ. The BitcoinWallet class in the master branch of TokenExchange stores the wallet transactions in a RDBM (H2) but still uses BitcoinJ for the network support. My BitcoinWallet and JavaBitcoin projects uses my BitcoinCore library for everything (no BitcoinJ dependency). If you are interested in using the Bitcoin Core RPC interface, take a look at my BitcoinMonitor project. This displays the status of a Bitcoin Core node. I use this to monitor my Bitcoin Core VPS node from my desktop. You can also look at the version-1 branch of TokenExchange which used a Bitcoin Core node for all of the Bitcoin support (as you can guess, I went through multiple design iterations for TokenExchange until I found one that I was happy with). |
|
|
|
Ok, understood. You use symlinks directly to the files, not to the whole directory. Makes sense, I haven't thought about this.
And thanks for describing the way to split the chain after the fork.
Just in the case someone download a complete new version of the blockchain, it might get tricky to find the correct last common data file as all files would have more or less the same time stamp (+/- 1 or 2 days, depends on download and validation speed).
That's true. I think stopping at blk00925.dat and rev00925.dat would be safe. They were last updated on 7/6/2017 on my system. There will be some variation in the .dat files depending on the number of orphan blocks encountered, but that should be early enough that all blocks would be before the split. |
|
|
|
|
I started using BitcoinJ but eventually ended up writing my own support (see my BitcoinCore project on GitHub). One of the problems I had was the fact that the entire wallet was rewritten on a checkpoint basis and I needed to integrate the wallet transactions into a database commit/rollback mechanism. I also needed to handle a large number of private keys and wanted to use a hash lookup when matching incoming transactions to account addresses. You can see an example in my TokenExchange project (which handles Bitcoin <-> Nxt exchanges).
I wrote a Java bitcoin node (JavaBitcoin). But I haven't maintained it since it was just a learning experience but it might provide some useful tips. I now run Bitcoin Core for the server but I still use my own wallet (BitcoinWallet).
|
|
|
|
I also think the easiest way not get any conflict with the data directories you should create two different users. Run bitcoin core with user 1 and bitcoin abc with user 2. If you build the bitcoind yourself from source, you should NOT execute the "make install" command. This would copy the bitcoind to /usr/local/bin. If you would do this for both versions, you will only have one bitcoind installed correctly, as for both clients the executable is named 'bitcoind' Instead you should execute the bitcoind from the build directory of your source (usually found in bitcoin/src/bitcoind). If you use precompiled clients from tar balls, you can also execute the bitcoind executable directly from the directory you extracted it. To speed up syncing I would start only the bitcoin core (version 0.15 - bit faster than 0.14) first to get the complete blockchain. After finished syncing, copy the complete datadir from core to the abc datadir and then start the bitcoin abc. I'm just not sure if copying the datadir will work correctly with the blocks mined after the fork. I've done this before the fork, so both blockchains were the same at that time. Now as they forked, maybe copying the datadir does produce errors with bitcoin abc. Maybe someone can tell if this is an issue or not? I ran both Bitcoin Core and BitcoinABC on Ubuntu. However, I installed both from tar files. You need to specify different data directories and ports. You can save space by using symlinks in the BitcoinABC 'blocks' directory for blocks before the split.
You also need to remember to specify the data directory when using the bitcoin-cli command. To prevent mistakes, I used simple shell scripts with different names to invoke the appropriate bitcoin-cli command.
Isn't using symlinks dangerious? Even only for the blocks directory? Both clients would write into the same directory and also same files. Before the fork they were identically, but after the fork they look different. So I'm not sure if this would mess up the data files? I used file symlinks only for blocks before the split. Blocks processed after the split are unique to each directory. I used a simple shell script to create the symlinks. This really isn't necessary unless you are tight for space (I use a VPS where I pay for each GB of data). If you are doing this after the split, don't copy blocks created after mid-July. And don't copy the blocks/index or chainstate directories. Don't copy peers.dat since BitcoinABC will have a different peer set. Instead, start BitcoinABC the first time with the -reindex parameter. This will recreate the blocks/index and chainstate directories. This is necessary since you didn't copy all of the existing blocks, thus invalidating the index and chain state. I didn't want to take a chance on corrupting my Bitcoin wallet. So I sent all of my pre-split bitcoins to new addresses before installing BitcoinABC. When I cloned BitcoinABC, I did not copy wallet.dat. Instead, I imported the pre-split private keys into a new wallet and let it rescan the block chain to pick up the transactions. Whether you use separate directories or separate userids is a personal choice. I prefer to manage all of the servers running on my VPS using a single account. Since I use accounts with no login passwords, this avoids having to manage multiple sets of login credentials on my workstation. |
|
|
|
|
I ran both Bitcoin Core and BitcoinABC on Ubuntu. However, I installed both from tar files. You need to specify different data directories and ports. You can save space by using symlinks in the BitcoinABC 'blocks' directory for blocks before the split.
You also need to remember to specify the data directory when using the bitcoin-cli command. To prevent mistakes, I used simple shell scripts with different names to invoke the appropriate bitcoin-cli command.
|
|
|
|
|
Your wallet must have connected to a BTC node. The transaction signing algorithm is different for BitcoinABC, so a transaction signed by a BTC wallet would be rejected by a BitcoinABC node (and vice versa). This is the replay protection implemented by BitcoinABC.
|
|
|
|
|
I held BCC until September and then exchanged it for BTC as the BCC price rose from 0.124 BTC to 0.142 BTC. That gave me 15 BTC of 'free' money. I don't plan to buy any BCC, especially given the potential November SegWit2X fork.
|
|
|
|
Yes no problem you can keep your coins there, and once the coins are received into a Segwit address, succeeding time they're spent or moved they'll be spent with all the features in Segwit. they'll be spent to any address once this happens. Segwit and paper addresses will move along side no problems, and it will not matter wherever they are from or where they are going to.
Can someone else confirm that there is no problem letting my BCH and BTC on a non-segwit address for a very long period? thanks Your bitcoins are safe and do not need to be moved (Bitcoin Cash does not even support SegWit). My wallet supports SegWit but leaves it to the user to decide which address to use (the same private key can be used with both P2PKH and P2SH-P2WPKH receive addresses). |
|
|
|
|
IPv6 public addresses are global (no need for address transalation or port forwarding). As a result, many routers block incoming IPv6 connections by default. If you change this to allow incoming connections, make sure you have a good firewall on your PC since you can't rely on NAT to protect your local network.
|
|
|
|
Hello everyone. I have a bitcoin client in my vps ubuuntu. but recently, I have no more space. to continue downloading the blocks of the blockchain. and search for google. and the only information I found was to remove two directories from the folder bitcoin -> blocks -> chainstate. but when I start the bitcoin client again. in less than 8 hours it again download all the blocks data. so my hdd is up again my question is. is there any way to erase the database. I do not want to again download all the blocks. jut start from 0 without having to uninstall the bitcoin client You can't run a full client without downloading the complete blockchain. However, you can run a pruned client which just keeps the latest blocks on disk. You do this by adding 'prune=n' to bitcoin.conf, where n is the number of MBytes to allocate for stored blocks (n must be greater than 550). Old blocks will be automatically removed when the prune limit is reached. Note that a pruned node cannot supply historical blocks to other nodes nor can it do a rescan operation without re-downloading the blockchain. |
|
|
|
As the number of users in bitcoin network are increased a lot during the past couple of years the transactions per day is increased and so the transactions fee is raised as its demand is increased. The transaction confirmation is prioritized now the more you will pay the transaction fee (miner fee) the more quickly your transaction will be confirmed.
Bitcoin system follows the principle of law of price demand where the increased of people supporting bitcoin as a from of using it as a mode of transaction it could also be a good way on development and growth to bitcoin price, value, transaction and security making it more capable on being a mode of transaction. And as a user of Bitcoin we should also be a part of its development so bitcoin would have development and growth to its price. True. As the transaction load has decreased (the mempool on my node currently has just 1,620 pending transactions), the fee has been decreasing. The estimated fee is now 0.0015 BTC/KB (150 Satoshis/Byte). Still high compared to last year but much lower than it was a month ago. |
|
|
|
hi all., i just wanted to know is it just me or everybody else, before august 1st i was connected to 60+ nodes but after 1st august, i can't get more than 23 nodes to connect to my client. here is how mine is showing. its been up and running from last 24 hours. [root@btc]# bitcoin-cli getinfo
{
"deprecation-warning": "WARNING: getinfo is deprecated and will be fully removed in 0.16. Projects should transition to using getblockchaininfo, getnetworkinfo, and getwalletinfo before upgrading to 0.16",
"version": 149900,
"protocolversion": 70015,
"walletversion": 139900,
"balance": 0.00000000,
"blocks": 483638,
"timeoffset": 0,
"connections": 23, <====== THIS IS WHAT I AM LOOKING AT
"proxy": "",
"difficulty": 888171856257.3206,
"testnet": false,
"keypoololdest": 1502287213,
"keypoolsize": 1999,
"paytxfee": 0.00000000,
"relayfee": 0.00001000,
"errors": "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"
} i think i have screwed something up, while moving from one server to another, while compiling bitcoin. it would be great if you guys could share yours node connected count. and tell me for how long your bitcoin-core is running. thanks I don't think it is just your node. My VPS node (which is up 24/7) used to have around 95 connections but now has around 55. |
|
|
|
|
Show Posts
