< wumpus>
fanquake: it was a clean cherry-pick right?
< fanquake>
yes
< wumpus>
phew
< wumpus>
I really want to improve -getinfo now that it's no longer server side, e.g. show regtest/testnet/mainnet, make some information per wallet
< wumpus>
so if anyone has ideas let me know
< gmaxwell>
wumpus: pilfer ideas from that ncurses interface someone did a while back?
< wumpus>
maybe! to be clear I intend to keep it in JSON format, just want to update for changes since 0.10 or so when it last was depreceated and diceded to never change it again
< gmaxwell>
well one thing in terms of cli usability maybe don't do what many of our other info rpcs have done and put a billion and one vaguely useful things so that when you run them the good stuff scrolls off the top and its hard to sort out anything useful. :P
< wumpus>
removing stuff is open for suggestion too
< wumpus>
I mean, 'improve' doesn't always mean 'creep any possible feature into it'
< gmaxwell>
exactly.
< gmaxwell>
or alternatively, go fetch some useful fields out of e.g. getblockchaininfo
< gmaxwell>
I'll comment the next time I get wall of texted when trying to get a frequently used field.
< wumpus>
I'd say a good requirement for information on it is that it's dynamic, it's meant as a command for checking the status after all
< wumpus>
things that are only dependent on on-time configuration might be better to leave off
< wumpus>
(I mean, how useful is 'protocolversion' on there for example?) or 'keypoololdest', or settings like 'paytxfee'
< wumpus>
but, say, the hash of the most recent block would be useful to have
< fanquake>
could change testnet: to something like network, then specify main/test/reg ?
< wumpus>
fanquake: yes exactly
< wumpus>
that would be a simple and non-controversial improvement
< wumpus>
just grab getblockchaininfo.main directly
< wumpus>
eh, .chain
< wumpus>
"verificationprogress" is also more or less useful, though only during initial sync
< gmaxwell>
yea, I think what I mostly use getblockchaininfo is the hash of the most recent block, and its scrolled off...
< gmaxwell>
do we have anything that returns the time of the last updatetip?
< fanquake>
Maybe we could do something better for multiwallet use? i.e at the moment walletversion and balance are both just "null" if >1 wallet loaded
< fanquake>
* same for keypool*
< wumpus>
fanquake: walletversion doesn't need to be in there at all, but yeah, it should *list* wallets
< gmaxwell>
keypool shoudl probably be dropped.
< wumpus>
gmaxwell: I don't think so
< wumpus>
fanquake: the only interesting thing about the wallet in getinfo is the balance, so it could be a object {'walletname': balance} or such then it doesn't really become longer as well
< wumpus>
gmaxwell: do we even keep track of the time of an updatetip?
< sipa>
wumpus: IsInitialBlockDownload does iirc
< wumpus>
sipa: ok-in that case it'd make sense to report that on getblockchaininfo, I guess!
< bitcoin-git>
[bitcoin] fanquake opened pull request #15564: cli: remove duplicate wallet fields from -getinfo (master...cli-remove-duplicate-entries) https://github.com/bitcoin/bitcoin/pull/15564
< bitcoin-git>
[bitcoin] fanquake opened 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
< wumpus>
btw is "analyzepsbt" really returning a formatted string for the feerate? that's awful
< wumpus>
ah i see: result.pushKV("estimated_feerate", feerate.ToString());
< gwillen>
wumpus: the new AnalyzePSBT after my refactor in #15508 will return it as a CFeeRate, although it will still be flattened to a string in the same way before being returned from the RPC
< gmaxwell>
I think estimated_feerate sounds like it's a cosmetic field, like difficulty.
< sipa>
the feerate is computed as fee divided by expected serialized vsize
< gwillen>
this is in analyzepsbt, which returns information for examining the status of a PSBT
< wumpus>
in any case the current representation on RPC is useless, you don't want clients to be parsing units from strings
< gmaxwell>
for human inspection not programmatic manipulation, so it would be okay to print it as unicode domino characters.
< wumpus>
units and the semantics of values belong in the help, not in the value
< gwillen>
yeah, although I think it would be reasonable to return it in satoshis per K or something, and let the RPC client decide how to fancy display it
< sipa>
yeah
< wumpus>
right
< sipa>
how are feerates put in JSON elsewhere?
< gmaxwell>
are they, anywhere else?
< fanquake>
In mining I think
< gwillen>
I hate and fear floating point numbers and JSON decimals
< wumpus>
heck, even *if* you'd want to return it as a string, because you hate JSON decimals or whatever reason, don't add the unit to it
< gmaxwell>
gwillen: fortunately the purpose of this value is display purposes, woe be it to anyone trying to do anything programatic with it. (because exactly rounding matters, and...)
< * luke-jr>
wonders why estimatesmartfee is in mining
< gmaxwell>
luke-jr: because chaos
< wumpus>
but it makes sense to be consistent with other JSON/RPC calls
< gmaxwell>
all hail chaos
< wumpus>
that's a good point
< gwillen>
gmaxwell: well the nice thing about giving it in integer sat/k is that that's the internal representation so there's no rounding question at all
< gmaxwell>
also what is "nSatoshisPerK"? hopefully K is in units of thousands of vsize or something?
< gwillen>
heh, yeah that's presumably the case, I didn't think about that
< gmaxwell>
gwillen: the internal representation is a double, I believe.
< gmaxwell>
(feerates and guistuff and time are the things in bitcoin that use floats)
< gwillen>
negative, CFeeRate contains CAmount nSatoshisPerK, CAmount is an int64_t
< gwillen>
I only know this because I just looked
< gmaxwell>
ah okay, well its float in some places. :P good that it isn't in cfeerate.
< gwillen>
like I said, I hate and fear floating point
< gmaxwell>
Integer über alles.
< wumpus>
floating point for monetary value is always a bad idea
< gwillen>
yeah
< gmaxwell>
so one thing to keep in mind is that unfortuantely a bunch of websites adopted integer satoshi per byte as a fee unit, resulting in a lot of the ecosystem thinking the integer satoshi per byte is the fundimental primitive feerate unit.
< gwillen>
it's interesting that it's per k not per byte, that gives more resolution than any display of fee rate I've ever seen
< gwillen>
right
< gmaxwell>
(and also this results in some dumb behaviors)
< luke-jr>
gmaxwell: it probably should be?
< gmaxwell>
luke-jr: not at all... I mean you can have a fee of 1 satoshi for a 1000 vbyte transaction...
< gmaxwell>
feerate is naturally a rational number, there isn't any inherent obvious denominator but if you have to pick one, one the size of a reasonable transaction (like 1000) isn't so bad.
< luke-jr>
sure, but you could also have 1 sat for a 10k tx
< luke-jr>
hypothetically
< gmaxwell>
luke-jr: indeed.
< gmaxwell>
but there are no 1 byte transactions, so putting a one in a denominator is inherently losing about a factor of 50 in sensible precision.
< gwillen>
I guess it ultimately depends on what you're using it for ... for display it doesn't matter too much
< gwillen>
for other things it could matter quite a bit
< luke-jr>
for display, /kB is a good size to work with
< gmaxwell>
yea, I've always found per 1000 to be pretty reasonable, thats always what core's interfaces have had.
< gmaxwell>
unfortuantely all these fee estimation sites sprung up around a time when the min relay fee happened to be 1s/b, I think, which is what caused it to be treated as fundimental instead of the bitcoin per/1000b the bitcoin software used in it's interfaces
< gmaxwell>
in any case, I just bring up the common units so people will be mindful of the errors users might make.
< gmaxwell>
like, don't have interfaces for people to enter fees that take btc/1000 vbytes and fail to guard against users entering values like 10.
< gmaxwell>
(in spite of my love of integers, I'm also not super fond of satoshi interfaces... values are usually too big, and it's perfectly reasonable for bitcoin software to work in sub-satoshi amounts even though thats the network precision)
< wumpus>
i mean that's always been the problem with integer representation; it's only obvious if there is a single subdivision that makes sense, otherwise, you could end up reporting (or worse, taking) the same kinds of value in different precisions in different parts of the interface
< wumpus>
*whoops, overpaid by 1000x*
< wumpus>
decimal types (that have an explicit precision) exist for a good reason, it's unfortunate that language adoption of them is so bad
< gmaxwell>
the sad thing here is that json itself-- the spec-- is reasonable.
< wumpus>
yes
< gmaxwell>
Just everything that uses it, including javascript itself makes being reasonable with it hard in practice.
< gmaxwell>
I loved that time when json spirit silently snuck in a conversion to (float) ...
< teslasystems>
Can anyone tell, where is the button for creating new wallets in Bitcoin Core? It has disappeared after 0.16.3 release
< luke-jr>
teslasystems: that's a question for #bitcoin, not here
< wumpus>
besides that, I don't think we've ever had a button for creating new wallets
< luke-jr>
yes, I have that answer typed up waiting for him in #Bitcoin XD
< wumpus>
ok thanks :D
< teslasystems>
Sorry, but I thought that the question is related to development, will post to #bitcoin
< bitcoin-git>
[bitcoin] Sjors opened pull request #15567: Make OutputType consistent with Descriptor and return it (master...2019/03/descriptor-output-type) https://github.com/bitcoin/bitcoin/pull/15567