|
I run a full node on a Digital Ocean VPS supporting both IPv4 and IPv6 connections. It is up 24/7. I imagine I will have to move to another provider some time in the future when disk space becomes a concern (DO uses SSD with small fixed sizes - I currently have a 60GB drive).
|
|
|
|
Well, for what I'm building I needed the code to be more modular to work with all cryptos that are QT based (all except NXT and its clones), so the json-rpc interface was the best choice for connecting to bitcoin, as json-rpc is supported as a standard.
I use the json-simple library to access the bitcoind RPC functions. Take a look at Request.java in BitcoinMonitor for an example. |
|
|
|
ScripterRon, rather than use JNI you could look at JNA. It will let you eliminate all the C code from your project and just call into the library with a regular Java interface. It's much more convenient.
Thanks, Mike. I did look at JNA but I decided to stay with JNI since the interface stub is only a couple of lines of C code and I didn't want to add another dependency to my project. I was already familiar with JNI (I just finished writing native hash routines for a Nxt project). |
|
|
|
That works too. It does mean that you can't do "pure" anything other than c++.
It depends on what you do in your JNI stub (the stub is what is loaded by the Java runtime). I simply turn around and call the consensus library routines after getting the appropriate C-style pointers to the Java data. By the way, it seems to be working. I brought my node up on Windows and it successfully synchronized with the network, using the consensus library to verify block transactions. I need to compile the stub on Linux and then I can switch my VPS node to use the consensus library. |
|
|
|
|
I'm in the process of changing my Java node to use the bitcoin consensus library. I'm using the Java Native Interface (JNI) to directly call the consensus library routines. So I can use the so/dll libraries shipped with Bitcoin Core 0.10.
There are just two routines in the library at this time: one returns the library version and the other verifies that a transaction correctly spends an output. The inputs are byte arrays and integers, so there shouldn't be a problem.
I do miss the extended error messages though. The consensus library returns a TRUE/FALSE indicator and nothing to say why it failed (the error code just applies to interface problems such as deserialization failure). It would be nice to get back a message describing exactly why the verification failed (bad public key, signature failure, etc).
|
|
|
|
yeah, but hopefully bandwidth can start scaling faster with Fiber internet. That is one of the biggest reaosns people don't run full nodes is because it uses alot of upload bandwidth.
I don't think people would mind running nodes if bandwidth wasn't such an issue.
Running a node on a VPS is okay, that's what I do now, but it's not organic.
I run a Debian VPS with 2 processors, 2GB RAM, 40GB SSD, 4TB data transfer. This costs $20/month. Bandwidth hasn't been a problem but the 40GB SSD will become a problem as the blockchain continues to increase in size. As far as setting up the node, that is pretty simple if you understand Unix/Linux commands. The hardest part was setting up the firewall rules for IPv4 and IPv6  |
|
|
|
Has your full node re-implementation been reviewed? The Core developers usually discourage people from re-implementing the bitcoin protocol as the people fix intentional quirks.
My node has been up and running since last December and has successfully processed the entire block chain starting with the genesis block. Since I do not support mining, I don't see a problem since I don't create new blocks which could cause a fork. The worst that happens is the node refuses to accept a block until I figure out what is causing the problem (the blocks generated by Luke Jr are great for testing the script parser ...) And yes, I've had to implement the bugs in order to match the reference code. |
|
|
|
JavaBitcoin ( https://github.com/ScripterRon/JavaBitcoin) is a full node which supports SPV clients such as MultiBit. It uses LevelDB or H2 as the database. Spent transaction outputs are pruned from the database. The block chain is not pruned since it is still needed to support new clients that need to download the block chain (I'll add block chain pruning once a mechanism is established for determining which nodes have which parts of the chain). |
|
|
|
JavaBitcoin is a full node (no mining support) which uses either LevelDB or H2 for the database. LevelDB is a mapped database while H2 is a SQL database. Note that LevelDB is much faster than any of the SQL databases that I have tried (H2, Firebird, PostgreSQL), especially when deleting rows. I went with H2 because it is a small embedded database manager compared to Firebird or PostgreSQL. If you want to use another SQL database, you will need to tweak some of the database definitions to handle the differences in data type definitions. If you decide to use a SQL database, it is best to first download the blockchain using the LevelDB database and then migrate the LevelDB database to the H2 database (JavaBitcoin will do this for you). The actual blocks are stored in external files in the same format as Bitcoin-QT (JavaBitcoin will import the block chain from the Bitcoin-QT blocks directory if available). You can browse the source code on GitHub ( https://github.com/ScripterRon/JavaBitcoin). It requires Java 8 since I'm using some of the new features in the latest version. |
|
|
|
What are the advantages? Why was it implemented?
I've used LevelDB, H2, Firebird and PostgreSQL with my JavaBitcoin node. LevelDB wins hands-down on both performance and database size. It is ideal for a bitcoin database where you have a small number of keys (usually just the transaction or block hash) and don't need the complexity of the SQL SELECT statement. It is easy to implement a secondary index (such as block height->block) using a separate map. Ron |
|
|
|
|
My ISP (Time Warner in upstate NY) just recently enabled IPv6 residential connections. So I'm starting to see some IPv6 connections, but the majority are still IPv4.
|
|
|
|
|
The 0.9.0 release reduced the minimum transaction relay fee/kB to 1000 satoshis (0.00001 BTC) and the dust limit is now 546 satoshis. That is 1/10 of the 0.8.6 amount.
Of course, until the various wallets update their algorithms, you won't be able to use the new minimums. And the delay is wise because the majority of the network is still running 0.8.x clients which would reject the lower fee. Just looking at the current connections to my server, I see 0.8.1, 0.8.3, 0.8.5, 0.8.6 and 0.9.0 with 0.9.0 still being in the minority (although it is improving)
|
|
|
|
Saw several of these today in my node server log: 09:59:08 9 Script.processMultiSig: Non-canonical public key: Key 0000400800150016002300420000400800150016002300420000400800150016002300420000400800150016002300420000400800150016002300420000000000
09:59:08 9 Script.processMultiSig: Non-canonical public key: Key 0000400800150016002300420000400800150016002300420000400800150016002300420000400800150016002300420000400800150016002300420000000000
09:59:32 9 BlockStoreLdb.setChainHead: Block added to block chain at height 291820
000000000000000056103025e0b77f2fcc75d85abd7d179bd7cd2fc01d5f85a2
09:59:32 9 BlockStoreLdb.deleteSpentTxOutputs: Deleting spent transaction outputs
09:59:33 9 BlockStoreLdb.deleteSpentTxOutputs: 4,074 spent transaction outputs deleted
10:01:23 9 Script.processMultiSig: Non-canonical public key: Key 0000400800150016002300420000400800150016002300420000400800150016002300420000400800150016002300420000400800150016002300420000000000
10:01:23 9 Script.processMultiSig: Non-canonical public key: Key 0000400800150016002300420000400800150016002300420000400800150016002300420000400800150016002300420000400800150016002300420000000000
10:01:25 9 BlockStoreLdb.setChainHead: Block added to block chain at height 291827
0000000000000000cf0fbb1878c2a4a3b4f41cadaaf63dce470f927b566f0e4e
10:01:25 9 BlockStoreLdb.deleteSpentTxOutputs: Deleting spent transaction outputs
10:01:26 9 BlockStoreLdb.deleteSpentTxOutputs: 0 spent transaction outputs deleted
I'm rejecting non-canonical public keys since that is another source of transaction malleability. Interestingly enough, this doesn't cause the signature verification to fail since the remaining public keys are sufficient to sign the transaction. I don't know what software package is creating the public key, but this might become a problem down the road if the reference client decides to enforce canonical keys. |
|
|
|
Anything goes on testnet - it is very cheap with the new bitcoin relay rules to spam testnet tx, for better or worse. If you can break testnet with tx spam, then it is a canary-in-the-mine for Bitcoin, so you might watch the way that Bitcoin becomes harder to use under such load and make your own bug reports if you can quantify.
I've been seeing large 'inv' messages for transactions on prodnet as well. When you send a 'getdata' request to the node, though, it doesn't respond. I've also been getting incoming connections that don't respond to a 'version' message and just disconnect and then connect again. I had one yesterday that did this continually until I banned the IP address. And, of course, my favorite which sends dozens of double-spend transactions one after the other in rapid succession. |
|
|
|
there is also a version in GO, not sure about Java or Python, or PHP for that matter  You can take a look at my node server written in Java at https://github.com/ScripterRon/JavaBitcoin. It has been running for several months now and supports everything except mining. The wallet is a separate application (ScripterRon/BitcoinWallet) and uses SPV to communicate with the network (similar to MultiBit and Android Wallet). So there are several open-source implementations around that should help keep everybody honest. Even though my node doesn't support mining, it will reject blocks that it receives if they don't conform to the rules. |
|
|
|
|
By the way, you might try copying the db headers to /mingw/include as well. I have them in both places. I seem to recall having a problem with 'configure' and 'make' looking in different places, but it has been awhile now since I built bdb4.8 and I was trying all kinds of things to get it to work.
|
|
|
|
|
I'm building 0.9. From your description, it looks like you are building 0.8.x since there is no makefile.mingw in 0.9. I've never tried to build 0.8.x, so I can't help you there.
The only problem I had with 0.9 was an empty else clause that caused configure to fail. This was fixed and bitcoind now builds without any editing of the supplied scripts. You might consider building the latest from github (they are preparing for RC2 now).
Here is the bitcoin build steps that I use after building the dependencies (openssl-1.0.1e, db-4.8.30.NC and boost-1_55_0):
cd bitcoin/0.9.0
./autogen.sh
BOOST_ROOT=~/boost_1_55_0 CPPFLAGS="-D_WIN32_WINNT=0x0602 -DWINVER=0x0602" ./configure --enable-tests=no
make
strip bitcoind.exe
strip bitcoin-cli.exe
I've been told that I shouldn't need to specify CPPFLAGS, but the build fails if I don't (at least on my Windows 7 system).
Note that I build just the daemon and not the GUI (bitcoin-qt). Getting Qt to build on MinGW is an adventure in its own right. I know people have done it but it just isn't worth the effort since I have my own node server and my own wallet. I run bitcoind locally just so I can check its debug.log to see if it is unhappy with anything that I'm doing.
|
|
|
|
I have successfully built bitcoind.exe and bitcoin-cli.exe from the latest master using MinGW. I also ran into these problems and solved them with a hammer by simply copying files to places that are checked by default  I copied the BDB include files to /mingw/include/bdbd4.8 and the BDB library files to /mingw/lib I copied the SSL library files to /mingw/lib Boost is handled by specifying BOOST_ROOT=path-to-boost-install as part of the configure command. For example: BOOST_ROOT=~/boost_1_55_0 ./configure --enable-tests=no Note that /mingw is an msys mount point, so the files actually go to C:\MinGW\include and C:\MinGW\lib if you are using Windows commands to move things around. |
|
|
|
Working fine out of the box for me. Could you post your gcc -v output?
I took all of the defaults when installing MinGW a couple of months ago. I haven't worked on Unix for 10 years, so I admit I'm rusty now. I used C at work and I've been using Java since I retired, so troubleshooting C++ and shell script problems is a slow process for me. But bitcoind and bitcoin-cli are up and running now. I didn't even bothering trying to build Bitcoin-Qt since I have my own node (ScripterRon/JavaBitcoin) and SPV wallet (ScripterRon/BitcoinWallet). I just needed the daemon to validate my implementation (and help the reference client developers a bit by reporting any problems I encounter). Ron $ gcc -v Using built-in specs. COLLECT_GCC=C:\MinGW\msys\1.0\MinGW\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/msys/1.0/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --ena ble-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32 -registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-sy stem-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv -prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIM E_T Thread model: win32 gcc version 4.8.1 (GCC) |
|
|
|
|
Show Posts
