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