< bitcoin-git> [bitcoin] achow101 opened pull request #20892: tests: Run both descriptor and legacy tests within a single test invocation (master...better-descriptor-tests) https://github.com/bitcoin/bitcoin/pull/20892
< bitcoin-git> [gui] Bosch-0 opened pull request #178: Added icon policy documentation (master...icon_policy) https://github.com/bitcoin-core/gui/pull/178
< bitcoin-git> [gui] Bosch-0 closed pull request #143: Add icon policy documentation (master...icon_policy) https://github.com/bitcoin-core/gui/pull/143
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9158d6f34153...5574e489631b
< bitcoin-git> bitcoin/master 7117d75 Prayank: Update 'Secure string handling'
< bitcoin-git> bitcoin/master 5574e48 Wladimir J. van der Laan: Merge #20741: doc: Update 'Secure string handling'
< bitcoin-git> [bitcoin] laanwj merged pull request #20741: doc: Update 'Secure string handling' (master...walletname-security) https://github.com/bitcoin/bitcoin/pull/20741
< kallewoof> sipa: hum.. i vaguely recall this being on a wiki section of github but i can't figure out where.
< jonatack> (if i understand the question ;)
< kallewoof> jonatack: ah, thank you. was looking at the wrong repo
< kallewoof> yes!
< jonatack> cool
< kallewoof> sipa: changes LGTM
< aj> sipa: seem fine to me too
< wumpus> i'm disappointed that my PR to pass in an existing fd to libevent http is still open https://github.com/libevent/libevent/pull/479, this is just not going to work, at this rate we'll never have UNIX sockets support for RPC
< sipa> wumpus: that's so strange... how do other libevent users deal with local sockets
< wumpus> sipa: they don't use libevent's http, would be my guess
< wumpus> at least not for a *client*, the server support needs no change IIRC
< jb55> /home/jb55/var/img/ss/Jan09-093134.png
< jb55> sorry my kid just did that lol
< sipa> wumpus: ah, right
< fjahr> wumpus: has anyone ever evaluated alternatives to libevent? I have been following it because of that one crashing issue and there is really not much movement
< fjahr> Maybe not just alternatives but also viability of swapping it
< wumpus> fjahr: no, not really, it doesn't seem worth swapping the entire thing just for this
< fjahr> indeed, but it's a shame :-/
< wumpus> libevent itself works very well and robustly, it's the built-in http that is a bit too limited and an ongoing frustration to me, another thing that's not really possible is HTTP streaming (see #7759) due to the thread model
< gribble> https://github.com/bitcoin/bitcoin/issues/7759 | [WIP] rest: Stream entire utxo set by laanwj · Pull Request #7759 · bitcoin/bitcoin · GitHub
< fjahr> right, I remember seeing this before
< wumpus> there's also libevhtp which is supposed to be a better replacement for the http functionality in libevent (but using libevent's core): https://github.com/criticalstack/libevhtp never investigated it closely though if it would solve my problems
< sipa> wumpus: we're not going to have to make our own fork, right?
< wumpus> sipa: I think the http functionality is one c/h file, copying it into our repository would be easier
< wumpus> that said I really don't want to maintain a http library :-)
< sipa> do we even need much from it?
< wumpus> pretty much all of it, we use both the client and server part after all
< sipa> and just the client side, isn't that just printf'ing a few header lines?
< wumpus> it's really simple *if* you can assume the server is always bitcoind
< wumpus> there's a lot of complexity in handling http portably, but if you know exactly what your server does a lot of that falls away
< wumpus> but 'stealing' the client parts from libevent http is an interesting idea
< sipa> right
< wumpus> not sure how much of the total code that is
< wumpus> I think I considered it at the time but for some reason decided not to, don't know why anymore it's so long ago
< wumpus> I didn't expect it to be such a long issue for them to merge my (trivial) patch
< sipa> wumpus: it's not like we really need libevent on the client side... it's a single-threaded single-connection synchronous application
< sipa> being able to reuse the same code as the server side is nice.of course
< wumpus> right
< sipa> yeah
< sipa> maybe ping the issue?
< jb55> perhaps it was overlooked, looks pretty trivial indeed
< sipa> looks like CI is failing on it
< wumpus> some unrelated timeout IIRC
< wumpus> I can try rebasing it and re-pushing
< jamesob> hm, do we not generate an RPC cookie file by default on macOS? (no RPC creds specified)
< sipa> jamesob: where do you get that error?
< jamesob> sipa: I'm trying to connect via RPC using the python-bitcoinlib stuff (which tries to autodetect a cookie, lacking RPC info in the config file), and it barfs trying to find a cookie file, and I see there isn't one generated
< sipa> is it perhaps looking in the wrong place?
< jamesob> I don't think so - I'm `ls`ing the datadir and seeing debug.log/bitcoin.conf I expect, but no cookie file
< sipa> but maybe python-bitcoinlib is looking in another place?
< jamesob> nope, it's printing the path in its stacktrace; same location I'm lsing
< sipa> and you're sure the rpc server is running?
< sipa> (hate to ask that...)
< sipa> don't have -server=0 or running bitcoin-qt?
< jamesob> running bitcoin-qt, can access RPC via the console view, but oh, can't see *8332 in lsof
< jamesob> bitcoin-qt doesn't start the RPC server by default? I didn't see anything in the GUI configuration for it, so I assume it did it by default
< sipa> you need -server if you're running Qt
< jamesob> oooh :)
< sipa> RPC server isn't enabled by default
< jamesob> (veering off topic) what's the easiest way for non-technical end users to enable that; just editing bitcoin.conf?
< sipa> that works
< sipa> or run -server=1
< sipa> it's a bit of a contradiction for non-technical users to need RPC...
< jamesob> yeah... it's for some lightweight wallet software I'm writing that's intended to give non-tech users a gentle introduction to the commandline
< jamesob> anyway thanks for the help - I'm a GUI newbie :)
< wumpus> it would be nice to be able to turn on/off the RPC server in the GUI options
< jamesob> agreed
< jamesob> or at least give some indication of whether it's running or not, ports, whitelits, etc.
< hebasto> re "it would be nice to be able to turn on/off the RPC server in the GUI options" -- noted
< wumpus> that's probably overkill, most people would want to run it cookie-only on the default port on localhost
< wumpus> a checkbox would already be great :)
< sipa> or a status icon in the bottom
< wumpus> and that
< bitcoin-git> [gui] jonatack opened pull request #179: gui: add direction and type columns to peers window (master...add-peers-dir-and-type-columns) https://github.com/bitcoin-core/gui/pull/179
< bitcoin-git> [bitcoin] glozow opened pull request #20895: p2p: mildly discourage peers that violate feefilter (master...p2p-feefilter-violations) https://github.com/bitcoin/bitcoin/pull/20895