< bitcoin-git> [bitcoin] promag opened pull request #15575: 0.17: Backport 15297 (0.17...2019-03-backport-15297-017) https://github.com/bitcoin/bitcoin/pull/15575
< bitcoin-git> [bitcoin] ldm5180 opened pull request #15576: constexpr: Increase constexpr usage in strencodings (master...constexpr-strencodings) https://github.com/bitcoin/bitcoin/pull/15576
< promag_> are we open to replace libevent?
< promag_> wumpus: ping
< promag_> dongcarl: you mentioned libevent recently
< promag_> I'm trying libuv
< promag_> and it looks very cool - it lacks http server though
< promag_> but it has child process support: uv_spawn and works really cool cc provoostenator
< gmaxwell> Why???
< promag_> you mean why replacing libevent?
< gmaxwell> Right.
< promag_> no particular reason, I was checking alternatives to boost::process
< promag_> found libuv, then found #5677, you also commented there: https://github.com/bitcoin/bitcoin/pull/5677#issuecomment-135961325
< gribble> https://github.com/bitcoin/bitcoin/issues/5677 | libevent-based http server by laanwj · Pull Request #5677 · bitcoin/bitcoin · GitHub
< wumpus> replace libevent? oh no
< wumpus> would consider it when C++ adopts an asynchronous i/o framework as standard
< promag_> got it
< wumpus> it's *nice* but we don't need fine-grained async communication with child processes for anything planned at this time, definitely not for 'launch a process and capture its stdout'
< promag_> yeah sure
< promag_> in 5677 dcousens mentioned it would be better, and some mentioned it would be easy to switch later - however I'm curious how since libuv has no http support
< wumpus> i'm sure there's something comparable to libev or better for that, but yea that would be another dependency ... i just don't think this is a good conern to have now
< promag_> just doing some tests before ack'ing boost::process
< promag_> and as usual one thing leads to other..
< wumpus> okay!
< rafalcpp> wumpus: fyi, if anything then ASIO, might become std::asio. But probably in like 4+ years anyway
< rafalcpp> I assume any performance issues with it would be mostly ironed out first
< wumpus> rafalcpp: boost::asio was pretty meh at the time, lots of overhead and fragility, but who knows in four years
< wumpus> right
< promag_> achow101 ken2812221 ryanofsky please see #15575
< gribble> https://github.com/bitcoin/bitcoin/issues/15575 | 0.17: Backport 15297 by promag · Pull Request #15575 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/257f750cd986...887f57eb7276
< bitcoin-git> bitcoin/master 890396c fanquake: cli: replace testnet with chain and return network name as per BIP70.
< bitcoin-git> bitcoin/master 887f57e MarcoFalke: Merge #15566: cli: replace testnet with chain and return network name as p...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15566: cli: replace testnet with chain and return network name as per BIP70. (master...cli-testnet-to-network) https://github.com/bitcoin/bitcoin/pull/15566
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/887f57eb7276...c94852e7912e
< bitcoin-git> bitcoin/master 3f6568d fanquake: cli: remove duplicate wallet fields from -getinfo
< bitcoin-git> bitcoin/master c94852e MarcoFalke: Merge #15564: cli: remove duplicate wallet fields from -getinfo
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15564: cli: remove duplicate wallet fields from -getinfo (master...cli-remove-duplicate-entries) https://github.com/bitcoin/bitcoin/pull/15564
< hebasto> @luke-jr: hi! Not sure if understand correctly your comment on #15574
< gribble> https://github.com/bitcoin/bitcoin/issues/15574 | build: Default size for the LXC disk is no longer enough · Issue #15574 · bitcoin/bitcoin · GitHub
< hebasto> *if I understand*
< luke-jr> hebasto: make-base-vm fails if you try to make a bionic VM; so I don't understand how wumpus tested it
< luke-jr> (bionic is what we require for current tags)
< hebasto> make-base-vm works for me too.
< luke-jr> O.o
< luke-jr> hm, maybe it's different for LXC; I only ever tried for KVM
< hebasto> yes, I tested it with LXC. I didn't try KVM.
< luke-jr> ok, I guess that explains it
< bitcoin-git> [bitcoin] JeremyRand opened pull request #15577: Docs: Enable TLS in link to chris.beams.io (master...chris-beams-tls) https://github.com/bitcoin/bitcoin/pull/15577
< wumpus> luke-jr: LXC doesn't use make-base-vm
< luke-jr> O.o
< wumpus> I forgot the --lxc initially and can confirm that didn't work
< hebasto> using LXC it creates base-bionic-amd64 file for me. How it could be?
< wumpus> I don't understand your question
< hebasto> maybe I didn't understand your words "LXC doesn't use make-base-vm"?
< wumpus> uhm, I mean it doesn't use *vmbuilder*
< wumpus> which is what is broken for bionic IIRC
< wumpus> it makes a minimum ubuntu install using debootstrap instead
< hebasto> ah, it is clear now.
< luke-jr> ^
< bitcoin-git> [bitcoin] Ethicnology opened pull request #15579: Fix french translation (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15579
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #15579: Fix french translation (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15579
< bitcoin-git> [bitcoin] dongcarl opened pull request #15580: depends: native_protobuf: avoid system zlib (master...2019-03-depends-native_protobuf-no-zlib) https://github.com/bitcoin/bitcoin/pull/15580
< bitcoin-git> [bitcoin] dongcarl opened pull request #15581: depends: Make less assumptions about build env (master...2019-03-true-neutral-depends) https://github.com/bitcoin/bitcoin/pull/15581
< jonasschnelli> sipa: maybe you have time to quickly formally review the encryption ChaCha pseudocode to reduce the ChaCha rounds: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#packet-handling
< gmaxwell> jonasschnelli: aside observation, if you write a protocol description that sounds like it uses floating point, some people will implement it that way, and I will feel ever so slightly more like jumping off a bridge.
< jonasschnelli> gmaxwell: do you mean because of floor(packet_sequence_number / 21)?
< gmaxwell> yeah.
< jonasschnelli> I see... unsure how to avoid that...
< gmaxwell> if it's pseudocode, maybe consider python style // for truncating division? (or maybe I'm crazy, but floor() is explicitly a floating point function)
< gmaxwell> or you can just write it witout having any large counters.
< jonasschnelli> gmaxwell: I think its safe to just remove the floor
< jonasschnelli> Since its just integer division (AFAIK should always result in floor)
< gmaxwell> Probably writing the example without the big counters is better. e.g. keep a counter that goes from 0 to 21. and when it hits 21, increments packet_sequence_number and generates new data. and just start it at 22.
< gmaxwell> that replaces the div and mod, and just converts one counter to a small cyclic counter.
< gmaxwell> (which also avoids running into issues with position_in_keystream wrapping.)
< jonasschnelli> sounds safe,... takes for the hint
< jonasschnelli> will change
< bitcoin-git> [bitcoin] sipa opened pull request #15582: Fix overflow bug in analyzepsbt fee: CAmount instead of int (master...201903_analyzepsbtoverflow) https://github.com/bitcoin/bitcoin/pull/15582
< bitcoin-git> [bitcoin] promag opened pull request #15583: wallet: Ignore recursive_directory_iterator errors in ListWalletDir (master...2019-03-fix-listwalletdir) https://github.com/bitcoin/bitcoin/pull/15583