< jonasschnelli> sipa: would adding 'h' as equivalent to ' in the descriptor xpub/xpriv range definition makes sense? >'< in conjunction with JSON and the GUI/bitcoin-cli/shell seems to be a hassle
< sipa> jonasschnelli: yes perhaps; but for compatibility with existing RPCs i stayed with '
< jonasschnelli> sipa: is think it should not be OR, it should be AND
< jonasschnelli> support ' AND h
< brighton36> so, I'm looking to find out a few things about the bitcoincore.org site. Chiefly, content changes are delegated. Who can I speak to about that?
< brighton36> *how
< brighton36> Is there a policy somewhere perhaps?
< harding> brighton36: I help maintain the site. I don't relaly understand your question. There's a basic contributing policy at https://github.com/bitcoin-core/bitcoincore.org/blob/master/CONTRIBUTING.md but the basic process is the same for any open source project: people open PRs proposing changes, other people provide feedback, once the feedback is generally positive, the PR is merged. If the PR never gets to that stage, it's
< harding> eventually closed. If there's something wonky going on (like lots of comments from unknown accounts), that's factored into the merge/no-merge decision.
< brighton36> thank-you harding :)
< brighton36> I get that this is a heavily politicized issue. But, I'd like to know what the process is
< brighton36> I think a mission statement would help greatly
< brighton36> less would obviously be more, but, just being able to point at a mission would help us out greatly
< brighton36> Borrowing one from any other prominent open source project, and redacting specifics would seem productive. Less is more.
< brighton36> Is there a process by which the stakeholders could decide that, or is a PR the process?
< harding> brighton36: I'm not sure what you're talking about, but it feels a bit off topic for this channel. Would you mind joining #bitcoin-core-website to discuss further? (Or you can PM me if you're a registered user.)
< brighton36> yep
< brighton36> thank-you sir
< sipa> MarcoFalke: AssertionError: not(0.00700000 == 0.007)
< sipa> any idea how to deal with that in tests?
< luke-jr> sipa: maybe assert_approx?
< sipa> i don't see that anywhere in our source code
< sipa> this can't be the only place where this is an issue
< sipa> so i must be doing something wrong
< sipa> (it's ValueFromAmount output in RPC
< sipa> i'll just try to stick to integer amounts
< luke-jr> sipa: test/functional/wallet_groups.py
< sdaftuar> sipa: are both values coming from rpc calls, or is one hardcoded in? i think we use Decimal() in the test framework a bunch, presumably to solve that problem
< sipa> sdaftuar: ah!
< sipa> one is hardcoded
< jonasschnelli> sipa: re xpub range in descriptors...
< gmaxwell> :( even we can't get it right.
< jonasschnelli> sipa: if you disagree with the index <= vs <, then I guess you need to +1 when populating the range from the JSON or change the doc
< jonasschnelli> Because the doc states: "\"range\": n, (numeric, optional) Up to what child index HD chains should be explored (default: 1000)\n""
< jonasschnelli> if you pass in 1000, it will only derive up to 999
< jonasschnelli> I think the doc is correct and would recommend to +1 somewhere else
< sipa> jonasschnelli: good point
< jonasschnelli> IMO if one puts a range of 1500, then one probably expect that key at index 1500 will be included...
< jonasschnelli> sipa: why not a real range X-Y? instead of pure Y?
< sipa> ok, will fix
< sipa> jonasschnelli: sounds like something for a later extension?
< jonasschnelli> (although could be changed later)
< jonasschnelli> agree
< sipa> GAH
< sipa> AssertionError: not(0.00200000 == 0.00200000000000000004163336342344337026588618755340576171875)
< sdaftuar> sipa: i think you need to do `Decimal("0.002")`?
< sdaftuar> at least, that's what i see all over our python test code
< sipa> sdaftuar: thanks! that works
< sipa> jonasschnelli: regarding support for "h" instead of "'", should it roundtrip?
< jonasschnelli> no... I think only input
< sipa> ok, that's easy enough then
< jonasschnelli> Yes.
< jonasschnelli> I guess no-one will complain about the missing roundtripness...
< jonasschnelli> IMO it's mainly useful to bypass shellish input sources
< jonasschnelli> *shellish input source restrictions
< satwo> Has the bitcoind config param -rpcclienttimeout been removed? I'm getting errors trying to set it in both the command line and in bitcoin.conf.
< sipa> satwo: no, but it's a bitcoin-cli command line option; not a bitcoind one
< satwo> Would it be appropriate to remove the section for rpcclienttimeout there? Or am I missing something?
< sipa> in bitcoin.conf it should work fine; that file should be read by both bitcoind and bitcoin-cli
< satwo> That's what I thought, but I got the following error when starting bitcoind: Error reading configuration file: Invalid configuration value rpcclienttimeout
< sipa> oh, of course
< sipa> right; you can't put it in bitcoin.conf anymore, because it's not a bitcoind option
< sipa> and since 0.17 bitcoind will give an error if an invalid option is passed
< sipa> we could add an exception to ignore it
< satwo> For just that one param?
< sipa> no, this is true for every parameter
< sipa> in earlier versions bitcoind would just ignore unknown options; now it will give an error
< satwo> Got it. What do you mean exactly by adding an exception to ignore it? Show the error/warning but allow bitcoind to start anyway?
< sipa> but we should probably make it ignore bitcoin-cli only options like this one, when present in bitcoin.conf
< wumpus> it's good that it now gives errors on unkonwn options, this was a long-running issue
< wumpus> but yes, that's firly annoying too...
< wumpus> sipa: though that means that all executables need to have knowledge of all other executables' flags
< wumpus> which is exactly what we were trying to avoid by modularizing the options system
< sipa> wumpus: or we need a way to specify bitcoin.conf options that only apply to a particular binary
< wumpus> it's kind of annoying, maybe cli-specific options could have their own sections?
< sipa> like the network sections
< wumpus> right
< wumpus> for 0.17 I agree we could just make it a warning
< wumpus> if an unknown option is specified
< wumpus> then for 0.18 think about for to sensibly enforce this
< sipa> that's one possibility
< sipa> or we could use the deprecation mechanism
< sipa> (by default it's enforced, unless you pass -ignoreunknownconfigoptions or so; and then it still only applies to bitcoin.conf and not to command line options)
< wumpus> yes
< luke-jr> wumpus: actually, it might be annoying if users get errors for Knots configs in bitcoin.conf
< luke-jr> perhaps there should be a way to explicitly say "don't error if you don't understand this"
< wumpus> sipa has a good point
< luke-jr> per-option seems safer IMO
< wumpus> make it an error if an unknown option on the command line
< luke-jr> though we could do both
< wumpus> but a warning if in bitcoin.conf
< luke-jr> sure
< satwo> Happy to attempt an implementation of this, if no one else wants to knock it out.
< sipa> i vaguely remember we already have an exception for some option, but i can't check right now
< wumpus> satwo: would be awesome
< satwo> wumpus: Will work on it this weekend. Still learning C++ but I'll do the best I can
< cfields> jonasschnelli: 0.16.2 macOS signature ping :)
< jonasschnelli> cfields: Oh. Yes. Just started the build,... will PR the detatched sig tomorrow (in 10-12h).
< cfields> jonasschnelli: np, thanks
< jhfrontz> Is there anything that needs to be done to enable use of the 0.16.2 version of contrib/gitian-descriptors/gitian-linux.yml (when using a docker-based gitian build)?
< jhfrontz> I'm getting errors about missing symbols (like described here: https://github.com/bitcoin/bitcoin/issues/12511#issuecomment-386740137 ).
< jhfrontz> It looks like all the signers of 0.16.2 for linux so far have used "trusty" (instead of the 0.16.2-gitian-linux.yml-spec'd "bionic"). So maybe I shouldn't be using the new version?
< wumpus> yes 0.16.2 is built with trusty
< wumpus> no releases yet have been built with bionic, though this is the plan for 0.17
< sipa> jhfrontz: if you build on bionic (even if it works), you won't get the same binaries as others
< jhfrontz> OK, tnx. I must've pulled down the wrong version?
< wumpus> I guess so? I'm not sure how you end up in that situation at all, the descriptors on the 0.16 branch shouldn't point to bionic
< jhfrontz> of gitian-linux.yml, I mean
< jhfrontz> doh, wrong branch…