< gmaxwell> re https://github.com/bitcoin/bitcoin/pull/15985 ... it's not great if almost all our travis runs are using sanitizers, they radically change the compilers behavior (as that PR observes)
< booyah> perhaps tests should be run few times, for normal build, for ASAN, for UBSAN+TSAN
< gmaxwell> sipa: fun fact, buggy cpus exist where rdrand actually returns an error https://github.com/systemd/systemd/issues/11810#issuecomment-490165413 (also fun fact, systemd apparently iplements is own 'rng' call that uses rdrand only when available, and is caused to fail by this)
< wumpus> this was just a matter of time, using RDRAND only always was a bad idea
< wumpus> good for them the chip start returnsing an error instead of just predictable data
< wumpus> that would have been a much more subtle and hard to detect scenario
< gmaxwell> yeah, it returns an error, but most code doesn't check.
< gmaxwell> We recently added checks for the error condition because I went and read the intel docs, previously the code was just modeled after code sipa read elsewhere. (for our use, it's less critical to do any error handling)
< wumpus> right, failing to check is a less serious issue if it's only one of many randomness sources used, although you'd still want to detect "all random sources failed"
< gmaxwell> unfortunately some sources are "cannot ever fail" which of course means there is no way to tell if they failed. :P
< wumpus> https://software.intel.com/en-us/blogs/2014/01/13/rdrand-do-i-need-to-check-the-carry-flag-or-can-i-just-check-for-zero this makes my head hurt, apparently early RDRAND implementations could not return 0 as an actual random value
< gmaxwell> yep.
< gmaxwell> which is obnoxious when you really want actually uniform randomness, not close but no cigar uniformity.
< wumpus> at least it's 64 bit so a value of 0 is *very* unlikely, this is much worse for 32 bit APIs (where I've seen this too), but it's a stupid kind of bias
< wumpus> yes
< gmaxwell> the stm32 stuff seemed moderately concerning to me. (stuff in the trezor)
< gmaxwell> with weird rules about not using the first value out, and strange comments refreencing a LFSR...
< wumpus> ouch
< wumpus> you can generally trust hardware vendors to do the cheapest thing possible that they can get away with for ancillary functions like hw rng, in any case it's a black box, the most surprising thing is a way-too-common assumption "it's hardware randomness so it must be good!"
< wumpus> having some unlocked PLL feed into a LFSR sounds like a nice and cheap solution to get some random-ish output
< bitcoin-git> [bitcoin] ryanofsky opened pull request #15988: Add test for ArgsManager::GetChainName (master...pr/testset2) https://github.com/bitcoin/bitcoin/pull/15988
< fanquake> hey wumpus. 15766, 15794 & 15452 probably mergable
< bitcoin-git> [bitcoin] hebasto opened pull request #15989: RPC: Do not use cookie auth if -rpcauth set (master...20190509-rpcauth) https://github.com/bitcoin/bitcoin/pull/15989
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15990: Add tests and documentation for blocksonly (master...1905-docTestBlocksOnly) https://github.com/bitcoin/bitcoin/pull/15990
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/08788ce1701a...a65fd92f7b8e
< bitcoin-git> bitcoin/master beda0da Hennadii Stepanov: Upgrade gitian image before signing
< bitcoin-git> bitcoin/master a65fd92 Wladimir J. van der Laan: Merge #15766: scripts and tools: Upgrade gitian image before signing
< bitcoin-git> [bitcoin] laanwj merged pull request #15766: scripts and tools: Upgrade gitian image before signing (master...20190407-gitian-upgrade-image) https://github.com/bitcoin/bitcoin/pull/15766
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #15991: Bugfix: fix pruneblockchain returned prune height (master...2019/05/pruning_test) https://github.com/bitcoin/bitcoin/pull/15991
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a65fd92f7b8e...aebe990dfeb4
< bitcoin-git> bitcoin/master f4a230b Carl Dong: docs: Clarify PR guidelines w/re documentation
< bitcoin-git> bitcoin/master aebe990 Wladimir J. van der Laan: Merge #15794: docs: Clarify PR guidelines w/re documentation
< bitcoin-git> [bitcoin] laanwj merged pull request #15794: docs: Clarify PR guidelines w/re documentation (master...2019-04-doc-doc) https://github.com/bitcoin/bitcoin/pull/15794
< bitcoin-git> [bitcoin] Empact opened pull request #15992: Refactor (master...relay-inventory) https://github.com/bitcoin/bitcoin/pull/15992
< hebasto> promag: hi, could you elaborate your latest comment in #15684?
< gribble> https://github.com/bitcoin/bitcoin/issues/15684 | doc/dependencies: Fix typo libsrvg->librsvg by luke-jr · Pull Request #15684 · bitcoin/bitcoin · GitHub
< hebasto> The main purpose of GetDataDir() is to create the datadir, right?
< hebasto> promag: #15864 not 15684
< gribble> https://github.com/bitcoin/bitcoin/issues/15864 | Fix datadir handling by hebasto · Pull Request #15864 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] hebasto opened pull request #15993: net: Drop the ancient miniUPnPc API version support (master...20190506-drop-ancient-miniupnpc-api) https://github.com/bitcoin/bitcoin/pull/15993
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/aebe990dfeb4...de5af41e3567
< bitcoin-git> bitcoin/master 70946e7 Gregory Sanders: Replace CScriptID and CKeyID in CTxDestination with dedicated types
< bitcoin-git> bitcoin/master 78e407a Gregory Sanders: GetKeyBirthTimes should return key ids, not destinations
< bitcoin-git> bitcoin/master de5af41 Wladimir J. van der Laan: Merge #15452: Replace CScriptID and CKeyID in CTxDestination with dedicate...
< bitcoin-git> [bitcoin] laanwj merged pull request #15452: Replace CScriptID and CKeyID in CTxDestination with dedicated types (master...key_script_dest) https://github.com/bitcoin/bitcoin/pull/15452
< harding> sipa: will OP_CLTV and OP_CSV still require OP_DROP in tapscript? If so, it seems a tiny bit unfair counting that as two opcodes towards the opcode limit (although that seems like a very minor unfairness).
< sipa> harding: yes
< moneyball> wumpus: fyi one topic was proposed the past week ... topic proposed by MarcoFalke: windows 32 bit
< wumpus> ok
< wumpus> thanks !
< sipa> harding: there are many 'unfair' things in the scripting language i'm sure and nits to improve, but i fear a bikeshedding fest if we go into those
< wumpus> #startmeeting
< lightningbot> Meeting started Thu May 9 19:01:18 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< jonasschnelli> hi
< sipa> hi
< achow101> hi
< luke-jr> hello there
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral
< Chris_Stewart_5> hello
< meshcollider> hi
< wumpus> any proposed topics?
< wumpus> (besides moneyball's)
< MarcoFalke> hi
< luke-jr> MarcoFalke's*
< kanzure> hi
< kanzure> i have a small topic later about topics
< luke-jr> ._.
< kanzure> it's just topic collection for upcoming physical meeting.
< wumpus> #topic high priority for review
< wumpus> currently: #15427 #15024 #15006 #15512 #15870
< gribble> https://github.com/bitcoin/bitcoin/issues/15427 | Add support for descriptors to utxoupdatepsbt by sipa · Pull Request #15427 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/15024 | Allow specific private keys to be derived from descriptor by meshcollider · Pull Request #15024 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/15512 | Add ChaCha20 encryption option (XOR) by jonasschnelli · Pull Request #15512 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/15006 | Add option to create an encrypted wallet by achow101 · Pull Request #15006 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/15870 | wallet: Only fail rescan when blocks have actually been pruned by MarcoFalke · Pull Request #15870 · bitcoin/bitcoin · GitHub
< wumpus> anything to add/remove/remark?
< instagibbs> hi
< sipa> looks good to me, i'll try to go through those soon
< wumpus> thanks
< wumpus> that's all about this topic, I guess
< wumpus> please help review those ^^
< wumpus> #topic windows 32 bit (MarcoFalke)
< MarcoFalke> There has been at least one user who is running Bitcoin Core on windows 32 bit
< wumpus> #15939
< gribble> https://github.com/bitcoin/bitcoin/issues/15939 | gitian: Remove Windows 32 bit build by MarcoFalke · Pull Request #15939 · bitcoin/bitcoin · GitHub
< MarcoFalke> I didn't expect that initially
< wumpus> I've said what I wanted to say here: https://github.com/bitcoin/bitcoin/pull/15939#issuecomment-489568065
< luke-jr> MarcoFalke: does Windows still support 32-bit only?
< MarcoFalke> Windows 10 can be installed as 32 bit
< luke-jr> on 32-bit only CPUs?
< wumpus> e.g. there's good reason to only support MacOS and Windows on one architecture
< jonasschnelli> Yes
< MarcoFalke> So we ask users to upgrade their windows to 64 bit or buy new hardware?
< jonasschnelli> Also,... do we care about that "one" user?
< wumpus> that there's one windows 32 user left, well, I'm sorry for them :(
< MarcoFalke> A lot might be shy to report
< wumpus> come on, the last x86 hardware that didn't support 64 bit is from 2005 or so?
< wumpus> you can buy a raspberry pi 3 for <$100 and have faster hardware
< wumpus> and 64 bit ARM, at that
< MarcoFalke> Yeah
< wumpus> so, yeah, let's drop it
< booyah> why not support, is it about resources to gitian build?
< MarcoFalke> Enough for this topic
< wumpus> no, read my post
< MarcoFalke> booyah: No, testing
< wumpus> computer resources don't matter
< sipa> in 2011 apparently the last general computing intel cpu that was 32-bit only was introduced (some atom)
< wumpus> yes... so.. next topic
< luke-jr> booyah: the question at the end of the day is, if there's a problem, is anyone willing to deal with it?
< MarcoFalke> [15:04] <kanzure> i have a small topic later about topics
< wumpus> #topic a topic about topics (kanzure)
< achow101> there was at least one complaint about win32 support on bitcointalk.
< ryanofsky> are there 32 bit versions of windows running on 64 bit hardware that can now no longer run bitccoin?
< MarcoFalke> achow101: Link?
< luke-jr> if anyone is willing to support Win32, we should keep supporting it; if not, we can't realistically :p
< meshcollider> Presumably there'd be at least a few out there
< achow101> MarcoFalke: https://bitcointalk.org/index.php?topic=5139689.0 although I'm not sure whether the OP is just wondering why there is no win32 or whether they need win32
< wumpus> so the question is: is anyone willing to test and support windows 32, an debug problems that happen on it?
< ryanofsky> ok just responding to sipa's note about 2011 hardware, wondering if the last 32 bit windows was also released around that time or if it would matter
< wumpus> if no, it doesn't matter that 1 or 2 people are still using it
< luke-jr> I suppose there's a side question of: does testing Win32 identify any general code issues that other tests don't?
< ryanofsky> ok happy to move on
< achow101> ryanofsky: windows still makes 32 bit releases. you can download windows 10 32 bit
< wumpus> yes, let's move on
< wumpus> kanzure: you had a topic?
< wumpus> luke-jr: not more than ARM or Linux x86 32 identifies
< sipa> arguably win64 should catch more things (it's the only 64 bit platform where a 'long' is 32 bits)
< sipa> kanzure: ^
< luke-jr> I think he just wanted to solicit topics for Amsterdam
< MarcoFalke> close meeting?
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu May 9 19:21:46 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< sipa> let's assume he does, so #action: send topics for Amsterdam to kanzure
< sipa> i like these short meetings
< gwillen> so in principle, people still on 32-bit windows could build it htemselves, right?
< gwillen> (except it's probably a big pain in the ass)
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/de5af41e3567...79046d574980
< bitcoin-git> bitcoin/master faf666f MarcoFalke: Remove Windows 32 bit build
< bitcoin-git> bitcoin/master fa193dc MarcoFalke: doc: Remove win32 from the release process
< bitcoin-git> bitcoin/master 79046d5 Wladimir J. van der Laan: Merge #15939: gitian: Remove Windows 32 bit build
< wumpus> gwillen: maybe? does MSVC still support 32 bit?
< MarcoFalke> msvc is only for debug builds
< gwillen> well, if they're on a 32-bit platform they probably have an old MSVC to go with it
< bitcoin-git> [bitcoin] laanwj merged pull request #15939: gitian: Remove Windows 32 bit build (master...1904-GitianWin) https://github.com/bitcoin/bitcoin/pull/15939
< kanzure> sipa: yeah that's all it was, i thought it didn't need explanation :)
< wumpus> pretty sure sipsorcery & other MSVC builders only use windows 64, too, also, anything x86 32-bit-only is going to be too slow to either compile bitcoin core or do the initial sync
< wumpus> it's just a non issue
< gmaxwell> luke-jr: are you going to provide win32 builds of knots?
< luke-jr> gmaxwell: I am presently. I might so long as they continue to build, TBD
< luke-jr> (and then just drop them when they fail to build or someone reports them broken)
< instagibbs> If I were to remove bumpfee's totalFee argument, should I put it behind deprecation for a single release?
< instagibbs> just in case someone actually uses it?
< gmaxwell> I agree with wumpus on this but I also agree that a few complaints mean that there probably are a fair number of users, it would be nice if they had options.
< luke-jr> I suppose when there's something broken, we can always revisit the topic then
< ryanofsky> instagibbs, that seems like a good idea assuming it's not difficult to do
< wumpus> instagibbs: yes, that'd be the normal way to do it, deprecate it for one release then remove it the next
< instagibbs> is there a doc on deprecation procedure or a great example?
< instagibbs> of something in master
< luke-jr> git grep Deprec
< instagibbs> ok seems to be one example in master, thanks
< wumpus> deprecation can be as simple as mentioning it in the RPC help for the method and in the release notes
< wumpus> there's also IsDeprecatedRPCEnabled(...) but that's for deprecating entire entry points, not individual arguments
< instagibbs> looks like it's used for hiding "size" value of mempool entries under "size" label
< gwillen> luke-jr: my guess is the answer for people complaining will be "you can upgrade one final time to knots 0.18, and if you ever need 0.19 you're probably on your own"
< gwillen> and given that older versions will continue to function for a long time unless there are major forking changes in the future, and even then should somewhat function
< gwillen> this doesn't seem unreasonable
< luke-jr> I don't really expect Win32 to break unless we go out of the way to break it, anyway
< luke-jr> so it might even work with 0.19 *shrug*
< ryanofsky> i think it'd be fine to use IsDeprecatedRPCEnabled / Chain::rpcEnableDeprecated, it just needs a string describing the deprecated feature, not necessary a method name
< jonasschnelli> would someone be opposed to add a generatetowallet call?
< wumpus> didn't we deprecate mining to wallet only very shortly ago?
< wumpus> (or rather, even, remove)
< instagibbs> it was *just* removed
< instagibbs> lol
< ryanofsky> i think part of the motivation for #15492 was that non-wallet code was calling wallet code
< gribble> https://github.com/bitcoin/bitcoin/issues/15492 | [rpc] remove deprecated generate method by Sjors · Pull Request #15492 · bitcoin/bitcoin · GitHub
< ryanofsky> so if the call was handled in the wallet, maybe it would be ok?
< wumpus> generate is only used in test code isn't it? I'm not sure it warrants adding additional RPCs
< instagibbs> it's very easy to chain generatetoaddress with getnewaddress, imo
< instagibbs> functional tests implicitly do this already
< wumpus> right
< bitcoin-git> [bitcoin] sipsorcery opened pull request #15995: systemd service script: set usable permissions on /etc/bitcoin config dir (master...systemdconfig) https://github.com/bitcoin/bitcoin/pull/15995
< bitcoin-git> [bitcoin] instagibbs opened pull request #15996: Deprecate totalfee argument in `bumpfee` (master...deprecate_totalfee) https://github.com/bitcoin/bitcoin/pull/15996
< bitcoin-git> [bitcoin] promag opened pull request #15997: refactor: GuessVerificationProgress requires cs_main lock (master...2019-05-gvp) https://github.com/bitcoin/bitcoin/pull/15997
< bitcoin-git> [bitcoin] promag opened pull request #15998: refactor: Drop trivial X macro (master...2019-05-x) https://github.com/bitcoin/bitcoin/pull/15998
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15999: init: Remove dead code in LoadChainTip (master...1905-initNoDead) https://github.com/bitcoin/bitcoin/pull/15999
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #15998: refactor: Drop trivial X macro (master...2019-05-x) https://github.com/bitcoin/bitcoin/pull/15998
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #15933: Make chain state immutable outside of validation (master...1905-immVal) https://github.com/bitcoin/bitcoin/pull/15933
< MarcoFalke> Someone should add the `generate` method to the gui
< MarcoFalke> Would save me a lot of typing
< MarcoFalke> #16000
< gribble> https://github.com/bitcoin/bitcoin/issues/16000 | GUI: Add generate method · Issue #16000 · bitcoin/bitcoin · GitHub
< sipa> heh?
< sipa> any reason to specifically have that in the GUI?
< sipa> seems much easier to automate through RPC
< gmaxwell> maybe you should make it run it if you click the bitcoin logo ten times in quick succession.
< MarcoFalke> Lol, I am not trolling. It was removed from the rpc
< luke-jr> what is the use case⁇?
< sipa> MarcoFalke: a bash oneliner will work fin?
< MarcoFalke> Excuse me? I am not using bash, that is for peasants
< sipa> lol
< MarcoFalke> I run my tests in the gui because it has autocomplete
< * sipa> checks if this is actually MarcoFalke
< luke-jr> >implying bash doesn't autocomplete
< luke-jr> how do you even run the tests in the GUI?
< gmaxwell> I doubt anyone has created a bash-completion module for bitcoin-cli :)
< MarcoFalke> I mean manual tests
< luke-jr> gmaxwell: it's in the git repo..
< MarcoFalke> to run the functional tests in the gui you pass BITCOIND=bitcoin-qt
< gmaxwell> luke-jr: oh lol
< luke-jr> has been for years
< luke-jr> it just queries bitcoin-cli for the possible commands