< sipa>
the IP address to bind to when listening for incoming RPC connections
< tradermyx>
Then what is rpcconnect?
< tradermyx>
Which I thought was exactly that.
< sipa>
rpcconnect is an RPC client setting, it sets the IP address to connect to
< sipa>
rpcbind is an RPC server setting, it sets the IP address to listen on
< sipa>
rpcconnect only affects bitcoin-cli
< sipa>
rpcbind only affects bitcoind and bitcoin-qt (when running with -daemon)
< tradermyx>
I have rpcconnect, rpcport, rpcuser, rpcpassword set in my bitcoin.conf. Don't really understand why Bitcoin Core needs to be told where to connect... itself?
< sipa>
what are you trying to do?
< tradermyx>
Come to think of it, I don't really understand what bitcoin-cli is either. I use standard cURL requests to talk to http://127.0.0.01/ with the port specified (it works).
< sipa>
rpcconnect is something you'd use when your bitcoind is running on another system
< sipa>
if you use cURL, rpcconnect has no effect
< tradermyx>
Hmm. I see. So it's already implied to be 127.0.0.1 by default.
< sipa>
right
< tradermyx>
I didn't think Bitcoin Core itself had the ability to connect/do anything with the RPC API on a different machine.
< sipa>
bitcoin-cli is really just a slightly-specialized version of curl
< sipa>
it connects to a server, sends it a command, and shows the result
< sipa>
and you can tell it where to connect
< sipa>
but the default is 127.0.0.1
< tradermyx>
How come it's not recommended to simply use that binary to talk to the API?
< sipa>
what do you mean?
< tradermyx>
(I just upgraded to 0.17 and https://bitcoincore.org/en/releases/0.17.0/ seems like a lot of work was put into it... Although I won't be using these new "labels" seeing as "accounts" was deprecated. Better handle that myself if at all.)
< tradermyx>
sipa: I mean, why use cURL requests if I can just shell_exec() the bitcoin-cli binary?
< tradermyx>
(I already have the cURL stuff working, so I'm purely asking out of curiosity.)
< gmaxwell>
... is you web service shell_execing right now?
< tradermyx>
Nope.
< tradermyx>
Just wondering what the point of that feature is. Or why it's not recommended to use.
< gmaxwell>
It's the recommended way to use bitcoin from the commandline.
< gmaxwell>
Which is what it's for.
< tradermyx>
So for testing stuff manually?
< gmaxwell>
Usually one would not use it for programmatic access as it would be slower then making a connection via more conventional means.
< gmaxwell>
tradermyx: no, not just for testing-- for working with and using the node and wallet.
< tradermyx>
https://bitcoincore.org/en/doc/0.16.3/ <-- Is there not yet a 0.17 documentation uploaded? (Not in the menu and not when trying to modify the URL)
< tradermyx>
Ah.
< sipa>
but bitcoin-cli is a way for humans to talk to bitcoind
< sipa>
you wouldn't want to use it for another program; there are far more efficient and convenient ways
< tradermyx>
It's extremely hard to even find rpcconnect mentioned anywhere, BTW. That goes in general for documentation on this stuff; it's sprinked onto countless webpages on different domains.
< tradermyx>
Is the 0.17 documentation still being worked on and will become available soon?
< sipa>
butcoin-cli --hrlp
< sipa>
sorry
< sipa>
butcoin-cli --help
< sipa>
the website is just generated from the built-in help text
< tradermyx>
Then it's especially odd that it's not updated on the site, if it's automated. Note: Not "complaining" -- just pointing things out as I find them.
< tradermyx>
This is a fascinating piece of software for sure.
< tradermyx>
I like the idea of theoretically being able to control money in this way. My bank actively prevents even automating logging in to view saldo.
< sipa>
you're very welcome to help out with efforts to automate it :)
< tradermyx>
sipa: I thought it was already automated?
< karelb>
it's automated as in "someone has to run the script and git-commit and make a PR"
< karelb>
I have no idea how would to automate this on every release...
< karelb>
(the RPC diff is linked in the PR if you are interested)
< karelb>
(oh he quit already)
< karelb>
anyway how would one go automate this.... even putting binaries etc online is not automated and I see @harding putting them online manually each release?
< sipa>
karelb: perhaps one step would be adding it to the bitcoin core release process notes
< karelb>
sipa: 👍 good idea
< hebasto>
MarcoFalke: what is minimal codespell version to run test/lint/lint-spelling.sh successfully?
< fanquake>
Will there still be a meeting tomorrow morning? I'm hoping I might actually be able to join between flights
< harding>
Each week, I look through the previous week's commits for interesting ones to document for the Optech newsletter. As part of that weekly routine, I'd be willing to write up any undocumented notable changes for the release notes---hopefully significantly cutting down on the work during the RC cycle---but I'd like suggestions on the best way to do that. Should I submit a PR each week to update the release notes? Or save up my
< harding>
work for a monthly PR? Or maybe maintain the release notes on the devwiki full time? Or something else?
< sipa>
harding: that sounds awesome
< sipa>
though i think weekly is probably too ofte
< harding>
sipa: yeah, that's what I was thinking. I guess I'll start with monthly and we can tweak it from there.
< jcorgan>
it's the assert on L31 that non-deterministically fails?
< gmaxwell>
I could give a little update on our work on set recon relay which has been ongoing.
< wumpus>
lol that test doesn't even *test* zmq
< wumpus>
I don't understand how it can fail
< wumpus>
it jst tests some administrative rpc functions related to zmq
< wumpus>
gmaxwell: might be better to do that when there's more people
< gmaxwell>
OK
< wumpus>
but, is up to you
< jcorgan>
maybe it's interface_zmq.py
< wumpus>
jcorgan: that's the one that really tests the zmq interface, yes
< gmaxwell>
wumpus: well, I'd like to-- the people who aren't here will probably hear about it at the events there at. :)
< jcorgan>
right, but is that the one randomly failing?
< wumpus>
phantomcircuit: I don't understand it, you make P2P changes, and a test completely unrelated to P2P starts failing
< gmaxwell>
wumpus: I guess it can fail if the node isn't up by the time it attempts the rpc?
< wumpus>
unless your poll somehow interferes with libevent, but I wouldn't understand why
< gmaxwell>
like, e.g. poll having a sleep timeout during startup where the select didn't could slow down bringup slightly.
< wumpus>
the test framework is smart enough to wait for the RPC interface to actually work, AFAIK
< wumpus>
(there's this 'warmup' period that it needs to ignore, for example)
< gmaxwell>
if so, then I've got no suggstions. :)
< wumpus>
well it mightb be that this test does something ... special
< wumpus>
#topic recon relay (gmaxwell)
< gmaxwell>
Sipa, gleb, and I have been continuing to work on set recon relay. Gleb has made a lot of progress with simulations.
< gmaxwell>
In his simulated network topology he shows that the best possible (no 'overhead') relay using 8 byte tx identifiers would use about 44x less bandwidth for relay than what the code currently does.
< gmaxwell>
(optimal would basically be exach node gets exactly 1 inv per tx and no more) Simulations of our recon work don't quite achieve optimality (since we also want relay to be reasonably fast) but end up only using 2-3x the bandwidth of the theoretically optimal usage, which sounds pretty good compared to 44x. :)
< gmaxwell>
Sipa and I (mostly sipa) have been working on optimizing the recon code itself, which is in part important because its performance helps tell us what parameters make sense to propose.
< gmaxwell>
This shows how long it takes to do the computation for reconciling 150 differences (which is a good high watermark from glebs simulations), as a function of how long the short-txids we're using (in bits).
< gmaxwell>
The graph shows that some sizes are much faster in the implementation currently, for optimization (and the number theory that enables those optimizations) reasons.
< wumpus>
44x less bandwidth is more than impressive, I didn't know that the invs were such a large part of the traffic
< gmaxwell>
Ah! that figure is perfectly efficient invs (one inv per host) vs invs in what we do today. Invs are a majority of traffic on nodes right now, but those figure ignore all the non-inv traffic.
< wumpus>
but that's similar to my surprise how much (at least of outgoing traffic) is 'reject' messages
< gmaxwell>
So in terms of actual total traffic impact, maybe halve those numbers for your expectations.
< sipa>
ohai
< gmaxwell>
Basically gleb's simulator simulates a plausable bitcoin network topology, and then measures how transactions relay around in it with different relaying schemes, so we can try different ideas and measure their impacts.
< gmaxwell>
So in any case, lots of progress going on there.
< wumpus>
is this simulator available anywhere?
< gmaxwell>
Not yet. Sipa and I need to convince gleb that his code is not too awful, I think.
< wumpus>
no hurry, though it would be nice to have, if it was available we'd want to link it
< gmaxwell>
Absolutely.
< gmaxwell>
In any case, right now we're still in a fairly researchy mode, looping over detailed ideas and feeding the results back in to tell us what to try next.
< gmaxwell>
Thats all I've got for now, unless sleepwalking sipa has more.
< sipa>
not really
< wumpus>
you could say so, it's .. 04:36 there?
< wumpus>
thanks for the update!
< wumpus>
I guess it's time to close the meeting
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Oct 4 19:39:04 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< sipa>
i wasn't trying to make the meeting even (i completely.forgot about it), but jetlag made me randomly wake up
< gmaxwell>
That ZMQ rpc test looks like it has a pretty poor ratio of speed to utility. It doesn't really even seem to actually test anything other than calling the RPCs doesn't catch fire.
< gmaxwell>
Which is not totally useless, but not terribly useful either.
< jcorgan>
are there other tests like that one for other RPC calls?
< jcorgan>
i don't see any others that just test that one thing
< gmaxwell>
I was going to write that it would probably make sense to merge all 'just run the thing and don't test anything much' tests into a single test, but ZMQ might already just be seperate because the software might not be compiled with ZMQ support.
< jcorgan>
well it uses the skip check, those could be rolled in
< jcorgan>
i guess that would apply to the whole module, though, so no
< phantomcircuit>
gmaxwell, it's separate so it doesn't run when zmq isn't available
< phantomcircuit>
and that seems to be a module level thing