I've found it much easier to just always use a well-tested rpc library than use something "bitcoin tailored"
the standard python bitcoin json library that people get linked to is not at all reliable (gets disconnected and then throws exceptions, and has to be wrapped to be usable) and I don't see anyone even complaining about it.
bitcoin-cli*, that is
no interpreters in bitcoin please
I mean with bitcoin-cli you have full access to bash' scripting/variable munging/etc capabilities, in the Qt console you don't, so this adds a bit of shell power to it
I think its better to start with it client-side QT only, and if it turns to be useful, add it to bitcoin-cli.
A better approach for the RPC layer would be to add it into bitcoin-cli
Please send me a quick message if anyone is interested in a short conversation regarding your personal experiences with Bitcoin and/or Ethereum (any blockchain technology). It shouldn't take longer than 10 minutes and is for my graduate work on these technologies: http://www.thejoeblankenship.com/research-proposal Your privacy, confidentially, and anonymity will be protected.
in my ideal world, Bitcoin Core would just do peer discovery, validation, and relay
I have a process connect to bitcoin core via p2p which receives inv messages and sends getdata
it should then be in an external library. putting reliable message delivery into bitcoin core would also make the binary liable in the event something (inevitably) goes wrong.
sipa: https://github.com/TheBlueMatt/bitcoin/commit/96cef326f9184aefd1c562f64a21298a15f0adde simplifies the total diff from master to be more readable, to me...it matches the bip, but another way to look at it is that you have two booleans: which version of compact blocks they want (which you use to send to them) and whether they will send us segwit cmpctblocks...you simply introduce the the do-they-support-v2 bool as an additional
kanzure: and #8680 introduces blocking calls. So you could "./bitcoin-cli waitfornewblock && ./dosomething.sh", which would essentially be blocknotify. Obviously the same could be done for wallet stuff
so- for example- imagine you are operating a lot of bitcoin infrastructure. you do a bunch of per-block processing. when you are running functional/integration tests, you can't run your test checks immediately after issuing a command because things take a while. so when do you expect to run? well you setup a hook and you ask your infrastructure to ping your tester as soon as the data's available, or you poll for some internal state.
/home/user/projects/bitcoin/bitcoin/src/test/addrman_tests.cpp:336:471: warning: stack frame size of 328360 bytes in function 'addrman_tests::addrman_delete::test_method' [-Wframe-larger-than=] whoa :) luckily only in the tests
Im trying to build v0.13.0 from source on a beaglebone black with debian jessie, i had to compile db4.8 from source but i installed libboost-all-dev, but in the ./configure stage the error i see is "configure: error: No working boost sleep implementation found." I went through https://github.com/bitcoin/bitcoin/issues/3003 with no success
jeremyrubin: With your new pull request (#8670), are you suggesting writing a new testing framework specific to bitcoin from scratch?