< emilengler> Is there a cmake file for bitcoin core?
< sipa> emilengler: it's an autotools project
< fanquake> hebasto: looks like ipglider hasn't been on GH for a while. I'm going to close #15768 as "Up for grabs", feel free to pick it up if interested.
< gribble> https://github.com/bitcoin/bitcoin/issues/15768 | gui: Add CMD+W shortcut in macOS by IPGlider · Pull Request #15768 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] fanquake closed pull request #15768: gui: Add CMD+W shortcut in macOS (master...add_cmd_w_support_in_macos) https://github.com/bitcoin/bitcoin/pull/15768
< emilengler> In which function/file are the blocks writen to the disk?
< emilengler> written*
< mryandao> emilengler: src/validation.cpp:1635 FlushBlockFile.
< mryandao> I think.
< mryandao> there's a lot of flushing going on in validation.cp
< bitcoin-git> [bitcoin] achow101 opened pull request #16528: [WIP] Native Descriptor Wallets (take 2) (master...wallet-of-the-glorious-future) https://github.com/bitcoin/bitcoin/pull/16528
< achow101> meshcollider: ^^^
< bitcoin-git> [bitcoin] Tech1k opened pull request #16530: doc: Fix grammar and punctuation in developer notes (master...Tech1k-patch-1) https://github.com/bitcoin/bitcoin/pull/16530
< meshcollider> achow101: \o/
< bitcoin-git> [bitcoin] harding opened pull request #16532: [0.18] Doc: remove old release notes about systemd and riscv changes (0.18...2019-07-0.18.1-release-notes) https://github.com/bitcoin/bitcoin/pull/16532
< fanquake> If anyone's interested, I've put up some notes about doing bitcoin* binary comparisons: https://github.com/fanquake/core-review/blob/master/binary-compare.md
< bitcoin-git> [bitcoin] fanquake opened pull request #16533: build: disable libxcb extensions (master...disable_xcb_extensions) https://github.com/bitcoin/bitcoin/pull/16533
< wumpus> fanquake: yes, I think that's very useful to write those things up on how to find what is causing the non-determinism
< wumpus> how to recognize this qt resource non-determism issue, for ex :)
< fanquake> wumpus: heh. From now on if I ever see what looks like language codes in a binary diff that's probably it.
< fanquake> wumpus: #16532 in then tag 0.18.1 ?
< gribble> https://github.com/bitcoin/bitcoin/issues/16532 | [0.18] Doc: remove old release notes about systemd and riscv changes by harding · Pull Request #16532 · bitcoin/bitcoin · GitHub
< fanquake> Moved #16414 to 0.18.2
< gribble> https://github.com/bitcoin/bitcoin/issues/16414 | 0.18: wallet: Fix -maxtxfee check by moving it to CWallet::CreateTransaction by promag · Pull Request #16414 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] fanquake reopened pull request #15768: gui: Add CMD+W shortcut in macOS (master...add_cmd_w_support_in_macos) https://github.com/bitcoin/bitcoin/pull/15768
< bitcoin-git> [bitcoin] Bushstar opened pull request #16534: [build] .gitignore add Qt Creator Makefile.am.user (master...patch-3) https://github.com/bitcoin/bitcoin/pull/16534
< setpill> in https://github.com/bitcoin/bitcoin/blob/master/contrib/init/bitcoind.service#L8-L9, why does the comment state "except for those explicitly specified as arguments in ExecStart="?
< setpill> surely aside from "-conf=[..]" the other daemon options can be specified in whatever conf you supply?
< jonasschnelli> setpill: I guess because the ones specified in ExecStart are overwritten by ExecStart
< setpill> Ah I see, just a matter of suboptimal phrasing then I guess
< setpill> To me it sounds like "these options need to be specified as arguments in ExecStart= because they cannot be specified in the conf"
< jonasschnelli> I guess -datadir is not possible, since datadir defines where the config file is stored...
< wumpus> yes, AFAIK the only option that cannot be specified in the configuration file is -conf, and -datadir if -conf is not used
< setpill> I don't think so
< setpill> I've used a -conf commandline option with a datadir specified in the referenced conf iirc
< wumpus> datadir only defines the standard location of the config file
< wumpus> if you override the location of the config file, you can specify a datadir in it
< wumpus> this allows putting the configuration file in a separate place e.g. /etc/ while the (writable) datadir is somewhere else
< setpill> Also, datadir implies a blocks dir but that can still be overwritten as well
< wumpus> right
< setpill> 12:10 <wumpus> yes, AFAIK the only option that cannot be specified in the configuration file is -conf, and -datadir if -conf is not used
< setpill> would a "datadir" option in the conf file found in the default location not be respected?
< kanzure> replied about mailing list issues.
< jonasschnelli> kanzure: thanks!
< kanzure> jonasschnelli: "congratulations! you have volunteered to moderate!"
< jonasschnelli> kanzure: I'm not qualifying the "neutral" requirement. :)
< jonasschnelli> jokes aside: I really think I should not be a moderator
< wumpus> jonasschnelli: I agree, same reason I should not be
< jonasschnelli> Maybe someone like moneyball or jonatack
< kanzure> ideally someone opposite of my timezone (e.g. checks the moderation queue when i am usually sleeping)
< wumpus> setpill: that's a good question actually, I don't know, it might!
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/e653eeff7651...9f54e9ab9038
< bitcoin-git> bitcoin/master fa8a823 MarcoFalke: test: Bump rpc_timeout in feature_dbcrash
< bitcoin-git> bitcoin/master fa1bb53 MarcoFalke: test: Add -acceptnonstdtxn to self.extra_args[3]
< bitcoin-git> bitcoin/master fa36aa4 MarcoFalke: Test: Set -acceptnonstdtxn in feature_fee_estimation
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16493: test: Fix test failures (master...1907-testRpcTimeoutBump) https://github.com/bitcoin/bitcoin/pull/16493
< provoostenator> For todays wallet meeting, it would be good to brainstorm if there's a way to avoid all the [ci skip] commits in #16341.
< gribble> https://github.com/bitcoin/bitcoin/issues/16341 | Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
< provoostenator> I can't figure out how.
< provoostenator> It's not that I mind skipping Travis, but I would find this PR much easier to review if it moved stuff to (Legacy)ScriptPubKeyManager more incrementally.
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/9f54e9ab9038...d759b5d26a7e
< bitcoin-git> bitcoin/master 4fcb698 Sjors Provoost: [rpc] walletcreatefundedpsbt: use wallet default RBF
< bitcoin-git> bitcoin/master 9ed062b Sjors Provoost: [doc] rpc: remove "fallback to" from RBF default help
< bitcoin-git> bitcoin/master d6b3640 Sjors Provoost: [test] walletcreatefundedpsbt: check RBF is disabled when -walletrbf=0
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15911: Use wallet RBF default for walletcreatefundedpsbt (master...2019/04/walletcreatefundedpsbt) https://github.com/bitcoin/bitcoin/pull/15911
< bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/d759b5d26a7e...be0e8b4bff88
< bitcoin-git> bitcoin/master 8c8aa19 Antoine Riard: Add BroadcastTransaction utility usage in Chain interface
< bitcoin-git> bitcoin/master 611291c Antoine Riard: Introduce CWalletTx::SubmitMemoryPoolAndRelay
< bitcoin-git> bitcoin/master 8753f56 Antoine Riard: Remove duplicate checks in SubmitMemoryPoolAndRelay
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15713: refactor: Replace chain relayTransactions/submitMemoryPool by higher method (master...2019-03-refactor-relay-tx-submit-pool) https://github.com/bitcoin/bitcoin/pull/15713
< ariard> at what time is wallet meeting ? I would like to get feedbacks on the rework of rescan logic I'm hacking on
< achow101> ariard: 1900 utc
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #16535: test: Explain why -whitelist is used in feature_fee_estimation (master...1908-testDocFeeEst) https://github.com/bitcoin/bitcoin/pull/16535
< ariard> thanks achow101
< elichai2> Is InferDescriptor *suppose* to add this fingerprint to keys(they started as regular descriptors with private/public keys, no BIP32 stuff involved)? `pkh([1fb31c4f]03462c64aa6089c6e28536c74b6ec4a8f3eaf2f5c5c36e1ae0abf39d563eeaf11e)` (it's something i'm seeing in my descriptors_tests)
< sipa> elichai2: it's unnecessary but harmless
< elichai2> So it's nothing i've done haha thanks :) (FYI it's starting to look nice, this is what my InferDescriptor *returns* to me :) `tap([46d3fd75]031e34802508ce0bbabb71935832c92129c6df82143a924d731c43362495111319,[pkh([1fb31c4f]03462c64aa6089c6e28536c74b6ec4a8f3eaf2f5c5c36e1ae0abf39d563eeaf11e),pk([2611005f]0257dd0c7c2e9036b845ff4f8a90eeed5daf821e7abd1f98dcbc8b65b0006d28ce)])#umstfklz`)
< elichai2> (I meant parsing and then inferring the scriptpubkey)
< sipa> cool!
< bitcoin-git> [bitcoin] ariard opened pull request #16536: [doc] Update and extend benchmarking.md (master...2019-08-update-benchmarking-docs) https://github.com/bitcoin/bitcoin/pull/16536
< bitcoin-git> [bitcoin] MarcoFalke pushed 11 commits to master: https://github.com/bitcoin/bitcoin/compare/be0e8b4bff88...3a3d8b835712
< bitcoin-git> bitcoin/master e0e18a1 Hennadii Stepanov: refactoring: Check IsArgKnown() early
< bitcoin-git> bitcoin/master e0d187d Hennadii Stepanov: Refactor InterpretNegatedOption() function
< bitcoin-git> bitcoin/master 265c1b5 Hennadii Stepanov: Add Flags enum to ArgsManager
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16097: Refactor: Add Flags enum to ArgsManager class (master...20190526-fix-negated-args) https://github.com/bitcoin/bitcoin/pull/16097
< elichai2> sipa: arghh. Is it important that every bracket will have it's own significant meaning? because using the same bracket for taproot branches and for bip32 derivations complicates stuff a bit (nothing that can't be handled with a few conditions but still) should be maybe introduce curly brackets?
< sipa> elichai2: if you think curly brackets is easier, sure
< bitcoin-git> [bitcoin] Sjors closed pull request #15414: [wallet] allow adding pubkeys from imported private keys to keypool (master...2019/02/keypool_import_private_keys) https://github.com/bitcoin/bitcoin/pull/15414
< sipa> TIL: the number of public keys participating in an OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY counts towards the 201 non-push opcodes limit, but *only* when executed
< meshcollider> #startmeeting
< lightningbot> Meeting started Fri Aug 2 19:00:21 2019 UTC. The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< meshcollider> #bitcoin-core-dev Wallet Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball
< achow101> hi
< provoostenator> hi\
< sipa> hi
< ariard> hi
< meshcollider> any topics? :)
< jonatack> hi
< jnewbery> hi
< achow101> Big news is #16528 opened last night for native descriptor wallets
< gribble> https://github.com/bitcoin/bitcoin/issues/16528 | [WIP] Native Descriptor Wallets (take 2) by achow101 · Pull Request #16528 · bitcoin/bitcoin · GitHub
< achow101> only 107 commits :p
< ariard> working on a rework of rescan logic https://gist.github.com/ariard/89f9bcc3a7ab9576fc6d15d251032cfa
< sipa> achow101: wow
< ariard> thanks to feedbacks design from ryanosfky
< sipa> ariard: tip for remembering his nickname: ryan of sky
< ariard> s/ryanosfky/ryanofsky/g
< ariard> sipa: already heard this one
< meshcollider> achow101: The 107 commits include the legacy rework PR right :p
< achow101> <provoostenator> For todays wallet meeting, it would be good to brainstorm if there's a way to avoid all the [ci skip] commits in #16341.
< gribble> https://github.com/bitcoin/bitcoin/issues/16341 | Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
< achow101> meshcollider: yes
< kanzure> hi
< achow101> I think provoostenator has the only topic suggestion today
< provoostenator> Yes, maybe it's impossible, but's pretty daunting to review otherwise
< meshcollider> Let's start with that then
< achow101> I had a look at doing that, and it gave me a headache
< meshcollider> #topic Avoiding the [ci skip]s in #16341
< gribble> https://github.com/bitcoin/bitcoin/issues/16341 | Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
< achow101> the problem is that a lot of functions are dependent on other ones, so there would need to be a pretty big commit just to add those
< meshcollider> Yeah I thought the whole reason you put them there in the first place was because we decided it was better than one massive commit that doesn't break stuff
< achow101> then as you add them into the wallet, things start becoming inconsistent if not all of the things that can effect each other are also added at the same time. these inconsistencies also result in test failures
< achow101> One idea I had was to combine implementation of the function in LegacyScriptPubKeyMan and replacement in CWallet, but still leave the CWallet stuff there to operate in parallel
< provoostenator> That's what I was thinking as well
< achow101> but that seemed kind of pointless because the new code wasn't really doing anything, and we would still need to have the gigantic "delete all the old things" commit at the end
< provoostenator> Maybe start with a bunch dummy methods in the LegacyScriptPubKeyMan and then move stuff over?
< provoostenator> Then in the end you still need to delete some calls, but no implementations.
< achow101> there is also some consistency issues with doing that because the wallet files could be overwritten by two different code paths and become inconsistent, also failing tests
< meshcollider> It's the moving which is the problem
< elichai2> crazy idea. PR into PR? (that way they could be reviewed seperatly but merged into master together)
< sipa> we must go deeper.
< achow101> elichai2: they're all separate commits, so it shouldn't actually be that hard to review separately
< achow101> provoostenator: I don't believe that there is a way to avoid having [ci skip] commits because tests will fail
< meshcollider> Ease of review > Travis passing on every single commit, as long as the tests pass at the end of the PR I think it's fine :)
< provoostenator> meshcollider: agree
< achow101> a lot of the commits are really small too
< provoostenator> Currently the dimmed-zebra can't help
< provoostenator> Which makes it super tedious to check if the new function bodies are the same
< sipa> having intermediary commits that pass CI is helpful for review, as you can be sure about things like "this method changes, did all call sites get updated too?" without needing much work
< achow101> having them all pass tests would be nice, makes bisect not suck
< sipa> yeah
< sipa> not saying it's a strict requirement, though it's certainly very helpful as a policy
< achow101> I spent a lot of time finding a bug that was introduced in one of the [ci skip] commits but bisect wasn't as helpful since the tests wouldn't get to the part where the bug was triggered
< achow101> but even then, having them all pass tests wouldn't be helpful since the new code isn't the one that's actually doing the work. it would still just be the old stuff and bisecting would just point you to the gigantic "change everything over" commit
< jonatack> at least the [ci skip] comments signal when the failure is to be expected, so there's that... but from a review perspective hygienic commits are much better
< jonatack> commit messages could contain the steps
< meshcollider> achow101: can CWallet just have an instance of a LegacyScriptPubkeyManager inside it right from the start and call methods inside it as they're moved into it?
< meshcollider> And then do some inheritance refactoring at the end
< meshcollider> Then the massive "move everything over" commit would just be deleting methods like foo(){ legacy.foo(); }
< achow101> no because methods are dependent on other ones
< achow101> for example, I thought that AddKey would be easy, it should be mostly by itself, right? Nope. Requres AddCryptedKey to be implemented, which requires Encryption stuff to be implemented. For some reason it also requires watch only things so you need to have setWatchOnly, HaveWatchOnly, RemoveWatchOnly
< achow101> and you need AddKey for loading keys in the first place!
< sipa> fun.
< meshcollider> Yeah... I think the [ci skip] are here to stay then
< meshcollider> Does anyone else want to discuss anything this week?
< achow101> (If you couldn't tell, I was very annoyed by this and spent a while cursing the person who wrote this code, which was probably sipa :p)
< * sipa> hides.
< ariard> meshcollider: if anyone has thoughts on this https://gist.github.com/ariard/89f9bcc3a7ab9576fc6d15d251032cfa it would be welcomed
< ariard> (not necessarily now)
< achow101> it would be nice for rescan (and other wallet things) to not need cs_main
< meshcollider> #action Read and feedback on ariard's proposal
< ariard> main idea is just to use a common thread between index and ChainClient to provide blocks in one sequence instead of redoing the work multiple times
< achow101> there's been a lot of complaints I've seen recently about RPCs taking a while, probably because cs_main is held by ~everything
< ariard> achow101: yes that's the end of goal, not relying at all on cs_main
< ariard> but will need multiple PRs to get there to avoid to big diff
< ariard> first step move all logic in a thread, future steps worker thread pool + cache what we need to avoid locking
< ariard> hope to submit code next week, people will get a better idea
< emilengler> By the way, what does the LOCK and cs_main mean? I see this nearly everywhere when I look in the code
< meshcollider> ariard: sounds good!
< emilengler> And why it needs to be in the curly brackets
< achow101> emilengler: cs_main is one of the locks, while one thread holds it, no other thread can acquire it. it is used to protect things from concurrency issues like race conditions. LOCK(cs_main) is the way to acquire cs_main, if it is held by someone else, the thread will wait
< sipa> emilengler: RAII
< meshcollider> emilengler: cs_main is something which only one thread can "hold" at once, making sure stuff which it protects isn't written twice at the same time or something which would result in race conditions
< sipa> emilengler: it introduces a lock in the scope it's defined at; it automatically unlocks when it goes out of scope
< sipa> emilengler: it's a general concept in C++ called RAII
< ariard> have a look in sync.h and threadsafety.h
< meshcollider> Anyway I think this wraps up the meeting
< emilengler> Ok so it is more a C++ thing? I usually don't work that often with multiple threads
< meshcollider> We can read the proposal and PR outside
< meshcollider> #endmeeting
< lightningbot> Meeting ended Fri Aug 2 19:31:49 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< achow101> anyone have suggestions for things that should be added to tests for descriptor wallets?
< achow101> I added a --descriptors switch to some of the wallet tests so those tests will also run with descriptor wallets
< sipa> that's a nice idea
< sipa> so you can test things against both old-style wallets and new-style ones?
< achow101> yes
< meshcollider> emilengler: other languages use locks too for multithreading
< meshcollider> I think java does
< achow101> sipa: it just needs to avoid things like imports and ismine
< meshcollider> achow101: I guess it's easier to suggest more tests when reviewing the tests in the PR
< achow101> but at least all of the transaction sending, transaction ismine, etc. things can be tested without writing wholly new tests
< achow101> meshcollider: better start reviewing then!
< meshcollider> achow101: just add tests for all the new codepaths :)
< meshcollider> You wrote it so you should know how to test it :)))
< achow101> I did a coverage report and I think just about everything has been hit
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #16538: test: Add missing sync_blocks to feature_pruning (master...1908-testPruneNoRace) https://github.com/bitcoin/bitcoin/pull/16538
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/784e218610d4...673919caf72c
< bitcoin-git> bitcoin/0.18 5f5b444 David A. Harding: Doc: remove old release notes about systemd and riscv changes
< bitcoin-git> bitcoin/0.18 673919c Wladimir J. van der Laan: Merge #16532: [0.18] Doc: remove old release notes about systemd and riscv...
< bitcoin-git> [bitcoin] laanwj merged pull request #16532: [0.18] Doc: remove old release notes about systemd and riscv changes (0.18...2019-07-0.18.1-release-notes) https://github.com/bitcoin/bitcoin/pull/16532
< emilengler> Where are the qt icons stored?
< emilengler> Ok nevermind got it
< emilengler> They are in src/qt/res
< bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/673919caf72c...bfa7183c4e5a
< bitcoin-git> bitcoin/0.18 bfa7183 Wladimir J. van der Laan: build: set CLIENT_VERSION_RC to 0 pre-final
< wumpus> `git ls-files|grep png`
< bitcoin-git> [bitcoin] Sjors opened pull request #16539: [wallet] lower -txmaxfee default from 0.1 to 0.01 BTC (master...2019/08/lower_txmaxfee) https://github.com/bitcoin/bitcoin/pull/16539
< emilengler> wumpus: Also thought about doing this but I wasn't sure about the file format
< wumpus> we've just disabled jpeg so :-)
< emilengler> Maybe a vector?
< bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/bfa7183c4e5a...fa27a0760792
< bitcoin-git> bitcoin/0.18 fa27a07 Wladimir J. van der Laan: doc: Bump manpages pre-final
< provoostenator> ^ sorry for the bike-shed risk, but I think it's worth considering every couple of years and it's been 5
< wumpus> emilengler: yea there's some svg but they're converted to png before being included afaik, don't think we include any actual vector icons for use by the qt code, but not 100% sure
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #16540: test: Add ASSERT_DEBUG_LOG to unit test framework (master...1908-UnitTestAssertDebugLog) https://github.com/bitcoin/bitcoin/pull/16540
< wumpus> provoostenator: sorry i'm not sure what that's about
< provoostenator> wumpus: my PR proposes lowering txmaxfee from 0.1 to 0.01 BTC
< wumpus> provoostenator: ohh good luck !
< bitcoin-git> [bitcoin] laanwj pushed tag v0.18.1: https://github.com/bitcoin/bitcoin/compare/v0.18.1
< wumpus> gkrizek: ^^ the bot really does work great
< provoostenator> With giant coin joins in mind maybe we should check the max fee per our own inputs, rather than the tx total.
< provoostenator> *for
< wumpus> yes, tx total has always been kind of a belts and suspenders measure
< wumpus> like 'if the total fee is more than *this* it's really absurd and something must be wrong'
< wumpus> could be because a wallet generates a transaction that's absurdly large, or because the feerate is absurdly large
< provoostenator> In #16257 I covered the case where a user types "1" as the feeRate thinking it's satoshi per byte. That works nicely with the current 0.1 BTC max.
< gribble> https://github.com/bitcoin/bitcoin/issues/16257 | [wallet] abort when attempting to fund a transaction above -maxtxfee by Sjors · Pull Request #16257 · bitcoin/bitcoin · GitHub
< provoostenator> But there may be other fat finger mistakes possible.
< provoostenator> I believe in earlier days people would sometimes forget a change address, though afaik that's pretty hard to do accidentally now in core.
< ghost43> provoostenator: is the maxtxfee check still done when using the sendrawtransaction RPC? Not that long ago at least that was the case
< provoostenator> I'm not sure, because that's no longer part of the wallet.
< ghost43> (I know the check was done there because it was affecting electrum users)
< provoostenator> ghost34: yes it still does that check, there's a maxfeerate argument to more easily override it
< achow101> ghost43: the absurdly high fee error?
< ghost43> yes
< ghost43> we had users with huge wallets creating almost 100 KB txs
< provoostenator> But it's not done for p2p transaction relay?
< ghost43> for those, the absurdity is breached around 100 sat/byte
< ghost43> but the electrum server is using the bitcoind sendrawtransaction RPC
< bitcoin-git> [bitcoin] emilengler opened pull request #16541: qt: Add better icon for Open URI (master...2019-08-qt-update-open-uri-icon) https://github.com/bitcoin/bitcoin/pull/16541
< ghost43> tbh, I think a "feerate" absurdity check would make a lot more sense than an "absolute fee" absurdity check
< achow101> ghost43: I think it's still an absolute fee. We should definitely change that...
< achow101> afaik maxtxfee is for the wallet
< achow101> ghost43: nvm, I'm wrong. it uses maxtxfee. you could also just bypass that check by using the `allowhighfees` parameter
< ghost43> looks like the wallet and the node maximum absolute fees were recently separated: https://github.com/bitcoin/bitcoin/pull/15620
< emilengler> Is the strprintf function for args who take user-input?
< sipa> for anything
< emilengler> But in init.cpp this function is used sometimes and sometimes not
< emilengler> So what is the actual purpose of it?
< sipa> it's used to convert things to a string
< sipa> i don't know what you mean by "sometimes not"
< emilengler> In the init.cpp at the part where the args are being added their is the second parameter sometimes this function or just a string
< emilengler> Like in line 356 it isn't used but in 383 it uses for example
< sipa> there is nothing to convert to a string in line 356
< sipa> it already is one
< emilengler> Yep I got it, your previous answer explained it. thanks :)
< bitcoin-git> [bitcoin] achow101 opened pull request #16542: Return more specific errors about invalid descriptors (master...descriptor-errors) https://github.com/bitcoin/bitcoin/pull/16542
< achow101> fanquake: maybe we should add a "descriptors" tag as descriptors by themselves aren't wallet related
< fanquake> achow101: sure
< elichai2> achow101: why doesn't `FillableSigningProvider` derives from `FlatSigningProvider`?