< mryandao>
when calling getrawmempool true, should all fees be in sats or btc? because nFee field is in BTC while the others (ancestorfees, decendentfees) are in sats.
< Randolf>
mryandao: Consistency in that area seems like a good idea to me.
< bitcoin-git>
[bitcoin] mryandao opened pull request #12240: changed fee to be in sats instead of btc (master...fix-getrawmempool-fee-representation) https://github.com/bitcoin/bitcoin/pull/12240
< meshcollider>
sidd_: you're in the wrong channel, please take this to #bitcoin
< mryandao>
heh, so with fees, the reason why the test are failing is because the `getnetworkinfo` rpc endpoint reports minrelayfees in btc denominations as well
< mryandao>
is there a convention as to what denomination fees should be in?
< wumpus>
the idea is that all amounts on the RPC interface should be in BTC
< wumpus>
there are some exceptions which have to do with specific BIPs (getblocktemplate etc)
< mryandao>
so `ancestorFee` and `decendentFee` should be in BTC instead?
< wumpus>
but the guideline is to use AmountFromValue and ValueFromAmount for all monetary amounts unless there is a really good reason otherwise
< wumpus>
I guess - though changing the interface is dangerous
< mryandao>
the two fields report in satoshis when you make a `getrawmempool true`
< promag>
what output format should createmultisig use if wallet is not enabled?
< wumpus>
if people have already built software that makes the assumption that values are in a certain unit, changing it can lead to enormous funds loss
< wumpus>
but so can having mixed units on one call, so I don't know...
< mryandao>
uhh, i'll leave the PR there and wait for more comments?
< bitcoin-git>
[bitcoin] fanquake opened pull request #12241: [trivial][docs] Fix incorrect link in /test/ README.md (master...trivial-fix-util-link) https://github.com/bitcoin/bitcoin/pull/12241
< mryandao>
promag: ok, i'll note that for future reference -- not breaking changes in RPC.
< mryandao>
but wumpus did mention that fees shown in RPC calls should be in BTC.
< mryandao>
so i'm thinking of changing `ancestor/decendentFees` to btc-denominations instead.
< promag>
mryandao: that is also a no-go
< promag>
mryandao: you can add breaking change behind a flag. bad example: `bitcoind -fixrpcunits` - the user knows what he is doing so we can expect he fixes his software
< wumpus>
meh, I wouldn't add flags
< wumpus>
the way to do this would be to add fields
< wumpus>
then deprecate the old ones at some point in the far future
< promag>
wumpus: yes I also prefer that
< fanquake>
Afternoon
< promag>
o/
< promag>
Morning
< wumpus>
new options need to have a very good rationale, there are too many of them already
< wumpus>
o\
< mryandao>
alright, i'll add new fields
< mryandao>
what should I call them?
< mryandao>
`ancestorFeeInBTC`?
< promag>
I tend to like structured json, so "fees": { ..., "ancestor": ..., ... }
< wumpus>
no opinion on names...
< meshcollider>
agree with promag, new fees object would be cleaner
< mryandao>
that's a pretty big breaking change
< wumpus>
adding fields is never a breaking change
< mryandao>
oh, but i leave existing fields intact.
< mryandao>
right
< promag>
the docs would say units in "fees" are BTC
< mryandao>
gotcha
< wumpus>
promag: exactly, the unit should be in the doc, not the name/handle
< wumpus>
removing the fields at some point would be a big breaking change, but let's wait a few major versions for that... if it's just for consistency there's no hurry to break software
< fanquake>
wumpus I see more wormhole activity from you :p
< wumpus>
fanquake: how, exotic particle leaks, is the shielding failing? :p
< fanquake>
wumpus it's not quite magic ;)
< zelest>
I think I just had a quite clever idea... What about showing bitcoin addresses in certain colors? E.g, convert it to hex and pick the 6 values (like, 2 form the beginning, 2 from the middle, 2 from the last) and use it as RGB and color it..
< zelest>
That way people can quickly verify if an address is wrong :)
< wumpus>
isn't blockchair (the block exporer) doing that?
< zelest>
It is?
< fanquake>
There is an issue open for something similar. I cannot find it.