< bitcoin-git>
[bitcoin] gmaxwell opened pull request #10945: Update defaultAssumeValid according to release-process.md. (master...201707-update-assumevalid) https://github.com/bitcoin/bitcoin/pull/10945
< wumpus>
(or alternatively, sending them to some other wallet of yourself, but the idea is to not have to add anything extra for fee, resulting in change)
< wumpus>
this used to be a process of bisection
< sipa>
gmaxwell: ah, i see!
< sipa>
i just wrote thst PR to verify your nMinimumChainWork
< gmaxwell>
sipa: yes, I responded to that PR to point out that the info is already in getblockchaininfo, the release process docs tell you how to verify it. :)
< wumpus>
"The fee rate (in %s/kB) used to discard change (to fee) if it would be dust at this fee rate (default: %s) Note: We will always discard up to the dust relay fee and a discard fee above that is limited by the longest target fee estimate"
< wumpus>
this confuses translators
< wumpus>
- "the dust relay fee" -- this sounds like a fee applied to relaying dust; is it?
< wumpus>
- "a discard fee" -- this sounds like a fee applied when discarding something, which is probably isn't. Does it relate to the fee rate which seems to be the main topic of this string?
< wumpus>
- "discard change (to fee)" -- perhaps the explanation in the parentheses could be more precise. Does this suggest that the change is added to the fee in case it is otherwise considered dust? Then perhaps the parentheses may say something like "(by adding change to the fee instead)"?
< wumpus>
- "longest target fee estimate" -- which of the other words does "longest" relate to here? Could this be rewritten as "longest estimete of the target fee", or perhaps "fee estimate of the longest target", or something else?
< wumpus>
is this a user-servicable option at all? if not, might I propose moving it to debug-help wholesale and not translating it?
< wumpus>
it uses too many internal technical terms that appear nowhere else, which indicates that someone that doesn't know internal wallet logic has no business setting it
< sipa>
longest refers to long term estimate, i believe
< sipa>
i would agree with making it an expert/debug option
< gmaxwell>
I don't think the target thing should really be a user servisable option.
< gmaxwell>
The discard threshold is.
< wumpus>
this is about 'discardfee=<amt>'
< wumpus>
well if so, it needs better documentation
< wumpus>
this is from a person that has been translating bitcoin strings to Danish for a long time, I think it's a good indication that if he doesn't understand any of it, no other non-dev will
< gmaxwell>
Right!
< wumpus>
this again makes me doubt whether it makes sense to translate option helps at all. It's a bit like translating obscure error messages - having a variant of the technical terms in every language doesn't make it easier to look for
< wumpus>
especially if the translators don't understand it and just do a literal translation
< bitcoin-git>
[bitcoin] NicolasDorier opened pull request #10947: [Wallet] Bare segwit scriptPubKey are not considered change by the wallet (master...importaddresssegwit) https://github.com/bitcoin/bitcoin/pull/10947
< sipa>
wumpus: we have a number of obvious but invasive scripted refactors... what is your opinion on what a good time for those is?
< sipa>
i was thinking (assuming they're acceptable, of course), that right before branching may be advisable, so as to not hurt backportability of fixes
< sipa>
that does go against the idea of not having invasive changes after freeze
< wumpus>
sipa: well as long as they're not features, straightforward, and low-risk, it could be ok
< gmaxwell>
My view is that getting those kinds of safe refactors in before branching is good because it helps backports.
< wumpus>
well it seems to be quite quiet this time before branch, so it seems we could get around to that
< wumpus>
which ones is this about?
< sipa>
wumpus: #10483 at elast
< gribble>
https://github.com/bitcoin/bitcoin/issues/10483 | scripted-diff: Use the C++11 keyword nullptr to denote the pointer literal instead of the macro NULL by practicalswift · Pull Request #10483 · bitcoin/bitcoin · GitHub
< sipa>
i assumed there were more, but they're not scripted
< wumpus>
tagged them for 0.15
< morcos>
wumpus: re: -discardfee help
< morcos>
I agree it is a slightly involved concept
< morcos>
I originally had a shorter message but ryanofsky asked me to include the information about its interaction with dust and estimates
< morcos>
It's almost like that more technical information should only be included if you have showDebug
< wumpus>
yes, the problem is not so much that there is extra information, but that it refers to all kinds of terms that are unknown to users
< morcos>
I kind of agree with gmaxwell that this is kind of a user serviceable option. It's your tolerance for throwing money away to fee rather than creating a small output
< wumpus>
maybe that's a better help message :)
< wumpus>
those are terms everyone can relate to :-)
< morcos>
The only issue is where the correct place is to document how it interacts with these other things... but perhaps the code is sufficient
< wumpus>
but yeah the question is when someone would set it
< wumpus>
heh it's almost as if having only option documentation isn't enough anymore
< wumpus>
not that we have any kind of other documentation where this would be a good place for :/
< morcos>
I'm guessing they would set it if they wonder why they are occasionally paying a higher fee and they are really trying to avoid that
< morcos>
You know.. maybe we should just move it to be a debug option
< morcos>
Well I'm wiling to change it whichever way we think is best
< wumpus>
as I said, another option would be to never translate command line option help at all, I don't think descriptions like this will be improved by translation in most cases
< morcos>
Yes or could we just not have them translate the "Note:" part
< wumpus>
translation would be ideally used for things like UI messages that use normal english, and a set of defined common terms for the application
< wumpus>
there's not really any win in translating concepts we've made up ourselves
< wumpus>
yeah
< morcos>
The fee rate (in %s/kB) that indicates your tolerance used for discarding change by adding it to the fee. (default: %s) Note: An output is discarded if it is dust at this rate, but we will always discard up to the dust relay fee and a discard fee above that is limited by the longest target fee estimate
< wumpus>
what is funny, in practice the command-line options are only translated when you call --help through bitcoin-qt, not when using bitcoind
< wumpus>
(the latter doesn't contain the translation data)
< morcos>
s/used//
< morcos>
1.) Change to above 2) Change to above and delete note. A) Move to Debug option
< wumpus>
morcos: better!
< morcos>
I'm fine with 1,2,1A,2A or nothing
< wumpus>
I'm fine with all as well, but 1 seems best
< morcos>
will do
< sipa>
morcos: it is user servicable? things will may go badly though if you set if sufficiently different from the rest of the network, no?
< morcos>
sipa: how do you mean?
< morcos>
no, it is only used to increase what would be already thrown away by the dustrelayfee
< morcos>
which is also an option but i agree a non-user-servicable one that should not be changed
< morcos>
actually not sure if we are there yet, but ideally once we have this option, then it should be fine to lower the dustrelayfee to accomplish greg's goal of no longer having that concept, as long as your discardfee doesn't go below the OLD dustrelayfee.
< morcos>
but there are some slight other issues there such as with fee estimation
< jonasschnelli>
Lightsword: I guess it makes sense on OSX 10.12(+) ..
< jonasschnelli>
Lightsword: Do you expect other operating systems providing getentropy() via sys/random.h?
< Lightsword>
jonasschnelli, well looks like it’s there on solaris but I don’t really have a way to test against that, OSX also uses the weak import fork backwards compatibility
< jonasschnelli>
Lightsword: By "generalize" you mean removing the && defined(MAC_OSX)?
< Lightsword>
yeah
< jonasschnelli>
I don't see a reason why not do to that.
< Lightsword>
well there was a glibc issue right?
< jonasschnelli>
But maybe ask cfields what he things
< jonasschnelli>
thinks
< wumpus>
Lightsword: I'd make it macosx specific
< wumpus>
we should vet OSes where using getentropy is safe one by one
< Lightsword>
wumpus, yeah I went that way since there was an openbsd specific version
< wumpus>
right.
< wumpus>
I initially made it too generalized, which caused a few issues (with linux, for example) in the first place
< wumpus>
not serious issues with randomness, luckily, but build problems
< kanzure>
sendtoaddress doesn't seem to do any chaining off of other sendtoaddress-constructed unconfirmed outputs. and getbalance doesn't have a flag to ignore amounts stuck in unconfirmed sendtoaddress-generated outputs. i think fundrawtransaction is my only option, is that right?
< kanzure>
i guess i could use listunspent minconf=1 and check if the result is empty and/or take the sum of the amounts if any.
< kanzure>
anyway, the getbalance RPC docstring could at least mention that it is a highly promiscuous definition of available, and the sendtoaddress docstring could mention the lack of chaining..
< sipa>
kanzure: well getbalance follows the mempool's rules for availability... and long chains of dependent transactions don't get into the mempool
< sipa>
getbalance will aim to avoid spending low-confirmation count outputs, and avoid long-ubconfirmed-chain outputs if possible
< kanzure>
my use case was very simple, i had mined some initial blocks, needed to spend them somewhere, was spending a bunch of tiny amounts, exhausted available utxos; my test was checking getbalance and mining a block if the balance was below some threshold. but the balance is reported as very high despite having no sendtoaddress-spendable coins, oops.
< kanzure>
also, how do i debug "insufficient fee" in regtest mode? the transaction is 3528 bytes paying 30 sat/byte (so 105840 sat).