< 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
< 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] 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/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.
< 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)
< 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
< 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