< luke-jr> aj: yt?
< aj> luke-jr: yo
< luke-jr> wouldn't checking before wait_until result in a race?
< luke-jr> eg, sleep after the check, then resume before wait_until?
< luke-jr> the Travis thing is weird - it's crashing the entire VM somehow :/
< aj> yes, i think you're right there'd still be that window for the bug
< aj> the travis thing is just causing the test to hang until the travis timeout hits, isn't it?
< luke-jr> the entire VM hangs
< luke-jr> I'm running it in debug mode so I can strace/top/etc, and I can't even open a new tmux window
< aj> wtf
< aj> does that mean it's busy looping and using all cpu then?
< luke-jr> that shouldn't be possible unless it was setting realtime prio or something stupid
< luke-jr> trying catch (boost::thread_interrupted) { throw; } now
< kallewoof> Anyone got any hints or ideas on why appveyor is complaining here? https://ci.appveyor.com/project/DrahtBot/bitcoin/builds/31265297 (it's from #16411)
< gribble> https://github.com/bitcoin/bitcoin/issues/16411 | BIP-325: Signet support by kallewoof · Pull Request #16411 · bitcoin/bitcoin · GitHub
< kallewoof> It doesn't seem to like my RPCResult expressions, but they are identical to the other ones I see...
< cncr04s> I really miss getinfo
< luke-jr> why?
< luke-jr> bitcoin-cli -getinfo
< cncr04s> i have to type 3 api commands instead of just 1.
< luke-jr> or just use -getinfo
< cncr04s> This call was removed in version 0.16.0. Use the appropriate fields from:
< luke-jr> -
< aj> kallewoof: i think you need to rebase and update to match #17809 ?
< gribble> https://github.com/bitcoin/bitcoin/issues/17809 | rpc: Auto-format RPCResult by MarcoFalke · Pull Request #17809 · bitcoin/bitcoin · GitHub
< kallewoof> aj: Ahh! Okay, thanks, will do
< kallewoof> aj: That was it. Thanks for the nudge. Will try to remember to rebase on master next time I see a weird error like that.
< luke-jr> aj: looks like the extra catch and throw fixes it
< kallewoof> Huh. I actually didn't realize there was a -getinfo command that was not deprecated. Thanks, luke-jr
< luke-jr> np
< luke-jr> tbh, I probably opposed it, but as long as it's there, might as well use it
< kallewoof> cncr04s: in case you didn't get what he was saying, use a minus sign and it's still there.
< kallewoof> luke-jr: i never really looked into why people were against getinfo in the first place
< luke-jr> kallewoof: it did too much, took too many locks, etc and usually you only need a few things
< luke-jr> makes more sense to just batch a bunch of requests together
< kallewoof> ahh
< luke-jr> also my perspective is that the RPC is for scripts/code to use, not humans ;P
< kallewoof> luke-jr: i don't use GUI's if i can avoid it...
< luke-jr> kallewoof: someone made a curses frontend for the RPC IIRC
< kallewoof> i kinda just like the terminal experience without curses and such.
< kallewoof> command. enter. result. rinse
< bitcoin-git> [bitcoin] kallewoof opened pull request #18274: wallet: set nFeeRet to 0 to avoid garbage value upon error (master...2003-reset-nfeeret) https://github.com/bitcoin/bitcoin/pull/18274
< bitcoin-git> [bitcoin] kallewoof opened pull request #18275: wallet: error if an explicit fee rate was given but the needed fee rate differed (master...2003-wallet-error-on-feechange) https://github.com/bitcoin/bitcoin/pull/18275
< bitcoin-git> [bitcoin] yashpatel20 opened pull request #18276: doc: rpcdoc remove redundant type from description#18258 (master...issue#18258) https://github.com/bitcoin/bitcoin/pull/18276
< bitcoin-git> [bitcoin] fanquake closed pull request #18276: doc: rpcdoc remove redundant type from description#18258 (master...issue#18258) https://github.com/bitcoin/bitcoin/pull/18276
< bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/3f826598a42d...97aadf98d0b8
< bitcoin-git> bitcoin/master fa4620b MarcoFalke: util: Add UnintrruptibleSleep
< bitcoin-git> bitcoin/master fa9af06 MarcoFalke: scripted-diff: Replace MilliSleep with UninterruptibleSleep
< bitcoin-git> bitcoin/master fae86c3 MarcoFalke: util: Remove unused MilliSleep
< bitcoin-git> [bitcoin] fanquake merged pull request #16117: util: Replace boost sleep with std sleep (master...1905-noBoostUtilTime) https://github.com/bitcoin/bitcoin/pull/16117
< kallewoof> Is there a good way to kick travis when it's not even appearing as a task for a PR?
< Stealthy> does anyone know of a nodejs library that will allow to me monitor notifications of transactions or is there another notification mechanism?
< provoostenator> kallewoof: open Travis on a different pull request and check for a notification that your account was flagged for "mining bitcoin"
< kallewoof> Stealthy: zmq?
< kallewoof> provoostenator: i thought i did. will check agai
< kallewoof> provoostenator: other PR's trigger travis tho, so doubt that's it
< provoostenator> In that case force pushing something might help.
< provoostenator> Otherwise you're basically back to rain dances.
< * kallewoof> rain-dances cause he's force pushed for awhile now to no avail
< kallewoof> Maybe closing/reopening will do the trick. Sorry for spam in advance.
< bitcoin-git> [bitcoin] kallewoof closed pull request #16411: BIP-325: Signet support (master...signet) https://github.com/bitcoin/bitcoin/pull/16411
< kallewoof> O... travis appeared now
< bitcoin-git> [bitcoin] kallewoof reopened pull request #16411: BIP-325: Signet support (master...signet) https://github.com/bitcoin/bitcoin/pull/16411
< provoostenator> (an end to Github ordering commits by date)
< Stealthy> lol what a weird idea but an idea nonetheless, ty @kallewoof
< kallewoof> Stealthy: Not sure what's so weird about it. I use zmq to log txs and block hashes.
< Stealthy> why sockets, why not a plethora of (named) pipes, files, anything
< Stealthy> shared memory, databases, callbacks?
< Stealthy> :P
< Stealthy> just hoped for a nice nodejs library that will let me fully interface
< Stealthy> ie api.monitorWallet(..., callback)
< kallewoof> Stealthy: zmq works reasonably well, but i hear you. I wouldn't be surprised if there was a nodejs lib out there that does what you want, but most of us here are focused on bitcoin core, as the name of the channel implies.
< Stealthy> i see
< Stealthy> then perhaps a more down to earth option, for example the wallet daemon/rpc for Monero has a flag that you can use 'tx-notify' which can run a script or a program
< Stealthy> maybe dumb question but i literally just started orienting around 'crypto'
< Stealthy> reason i asked that before i install anything is because i just wasted 3 days on quirky monero lol
< Stealthy> figured i'd opt for a more mature coin and toolchain but i'm new
< Stealthy> i should probably figure out how to get things setup and just take it from there
< Stealthy> is there like a more general channel
< Stealthy> are there any 'full service wallets' that will provide an api of sorts?
< Stealthy> does bitcoin-qt?
< aqua42> Stealthy bitcoind has an rpc
< Stealthy> cool
< aqua42> you should head over to #bitcoin though (unless you want to improve the rpc :P), this is for bitcoin-core development
< Stealthy> ah :P
< Stealthy> alright i'll pop in there
< promag_> provoostenator: hi
< provoostenator> promag: hi
< provoostenator> _
< promag> I think should discuss here instead :D
< promag> with your PR, a client can fund with a specific utxo and ask it to be locked
< provoostenator> Context #18244
< gribble> https://github.com/bitcoin/bitcoin/issues/18244 | rpc: have lockUnspents also lock manually selected coins by Sjors · Pull Request #18244 · bitcoin/bitcoin · GitHub
< promag> y
< promag> but if that utxo was automatically locked elsewhere then you both clients are racing for it
< promag> right?
< promag> s/you//
< provoostenator> Yes
< promag> that's why I think that fund should fail if it's already locked
< promag> and it's a simple change
< promag> and a simple test
< provoostenator> Alternative it means the existing behavior is a feature, not a bug.
< provoostenator> An undocumented an scary feature :-)
< provoostenator> My original plan was to indeed just honor locks.
< promag> yeah, it's the same as saying "I don't care about being locked"
< promag> which is silly to me
< provoostenator> But then it'll be a breaking change. Maybe worth it.
< promag> if the client is asking to lock the coins then I agree with the breaking change
< provoostenator> Breaking change as in: breaking documented behavior, not just undocumented behavior
< promag> breaking documented behavior? really?
< promag> which doc?
< provoostenator> "A locked transaction output will not be chosen by automatic coin selection, when spending bitcoins."
< bitcoin-git> [bitcoin] konez2k opened pull request #18277: Ban spamnode (master...ban-spamnode) https://github.com/bitcoin/bitcoin/pull/18277
< provoostenator> Which it implies, though it doesn't litteraly say, manual _does_ get chosen.
< bitcoin-git> [bitcoin] konez2k closed pull request #18277: Ban spamnode (master...ban-spamnode) https://github.com/bitcoin/bitcoin/pull/18277
< provoostenator> So I guess the assumption was that if you use manual coin selection, you've thought through concurrency. That's a bad assumption though.
< promag> right
< provoostenator> Because our coin selection isn't amazing.
< promag> but note that RPC lockunspent already can fail with "Invalid parameter, output already locked"
< promag> it's manual locking, so that's why I think your manual funding should behave the same
< provoostenator> Ah well, looks like you wrote the original behavior :-) https://github.com/bitcoin/bitcoin/commit/f2d0944eb372838e05c666ce9b3df119d7da5594
< promag> if lockunspent option is set
< promag> ah surprise! lol didn't rememeber
< provoostenator> Merge script was borked, so we can't see which PR it was.
< provoostenator> Or maybe just Github is confused
< promag> I can find the PR
< fanquake> #7518
< gribble> https://github.com/bitcoin/bitcoin/issues/7518 | Add multiple options to fundrawtransaction by promag · Pull Request #7518 · bitcoin/bitcoin · GitHub
< fanquake> That's it
< promag> thanks captain fanquake!
< provoostenator> Thanks, always good to read original disucssion. I'll make a change.
< promag> provoostenator: well at least that's my opinion.. maybe wait for others to weight in
< promag> in any case, nice catch
< provoostenator> I keep running into "interesting" behavior while writing tests for #16378
< gribble> https://github.com/bitcoin/bitcoin/issues/16378 | The ultimate send RPC by Sjors · Pull Request #16378 · bitcoin/bitcoin · GitHub
< promag> provoostenator: only problem is that if you lock utxo1, utxo2 and fail to lock utxo3 then the others must be unlocked
< promag> or before locking, just check that all are unlocked
< provoostenator> Ooof, atomic locking?
< provoostenator> We have a lock on cs_wallet, so I guess checking if all coins are unlocked makes sense.
< promag> provoostenator: y
< provoostenator> Mmm, this does create the opposite problem: you can no longer atomically unlock and use a coin. I could add an option for that.
< provoostenator> This is how worms leave cans.
< instagibbs> who actually uses the lockunspent RPC? <_<
< instagibbs> I think anyone who *really* cares writes their own coin selection algo, or separates the utxos into different wallets. Maybe I'm projecting on uses
< provoostenator> I would like locks to be persistent, then they're actually quite useful for a individual users too.
< promag> well suppose you start with a solution based on locks and then refatocr to custom coin selection
< promag> instagibbs: ^
< promag> persistent locks -> yeah there's an issue about that
< instagibbs> I'm being glib :)
< instagibbs> (though mostly serious)
< promag> provoostenator: not following your latest use case
< promag> "you can no longer atomically unlock and use a coin"
< provoostenator> I'm starting to think that use case is undesirable anyway.
< promag> the problem with coin locks to me is that you really don't know who is locking. if a client locks a coin and then crashes, that coin is stuck
< provoostenator> I guess there's two reason why you'd want a lock with concurrency. One is seperation of funds, which is better handled with seperate wallets.
< instagibbs> what's the first use case?
< provoostenator> The other is "pending" transactions, where you lock some coins and then unlock them if you no longer need them.
< instagibbs> rephrase?
< provoostenator> So an unlock_coins options doesn't make sense.
< instagibbs> oh "reserving" funds?
< promag> instagibbs: yes that's one use case
< instagibbs> I've never really heard of that tbh... and strikes me as obscure
< provoostenator> For privacy reasons a user may want to lock (toxic) coins. But they might be beter off sending those to a seperate wallet.
< promag> so you receive some payment and then you don't want that to be used in your following sends
< instagibbs> doesn't prevent dusting(unless you can ban scriptpubkeys wholesale)
< provoostenator> Up to recently I didn't even think about the concurrency use case :-)
< provoostenator> But that's actually its reason d'etre
< provoostenator> promag: well, at least not combined with other coins. But we need a different mechanism for that.
< provoostenator> Maybe a "don't mix" flag.
< promag> provoostenator: the solution is simple use watchonly until you want to spend
< promag> anyway, up until your PR, no coin was allowed to be re-locked
< bitcoin-git> [bitcoin] ryanofsky opened pull request #18278: interfaces: Describe and follow some code conventions (master...pr/ipc-conv) https://github.com/bitcoin/bitcoin/pull/18278
< bitcoin-git> [bitcoin] bvbfan opened pull request #18279: Ensure wallet and chain tip are in sync (master...master) https://github.com/bitcoin/bitcoin/pull/18279
< bitcoin-git> [bitcoin] promag opened pull request #18280: fix: Disconnect validation interface on the queue dispacher (master...2020-03-sync-unregistervalidationinterface) https://github.com/bitcoin/bitcoin/pull/18280
< puchu> hi
< puchu> hi ryanofsky, luke-jr told me you are working on the gui hangs?
< puchu> is there somewhere a doc about the problems? and which parts need separate thread and not run in the gui thread?
< provoostenator> promag: done
< promag> I've changed my mind :D
< provoostenator> It's locked in
< promag> :D
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #18282: util: Use std::chrono for time getters (master...2003-timeChrono) https://github.com/bitcoin/bitcoin/pull/18282
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #18282: util: Use std::chrono for time getters (master...2003-timeChrono) https://github.com/bitcoin/bitcoin/pull/18282
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #18283: doc: Explain rebase policy in CONTRIBUTING.md (master...2003-docRebase) https://github.com/bitcoin/bitcoin/pull/18283
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/97aadf98d0b8...45cdcd47d99e
< bitcoin-git> bitcoin/master 259e290 practicalswift: tests: Add fuzzing harness for locale independence testing
< bitcoin-git> bitcoin/master 45cdcd4 MarcoFalke: Merge #18126: tests: Add fuzzing harness testing the locale independence o...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18126: tests: Add fuzzing harness testing the locale independence of the strencodings.h functions (master...fuzzers-locale) https://github.com/bitcoin/bitcoin/pull/18126
< bitcoin-git> [bitcoin] JeremyRubin closed pull request #18120: Change UpdateForDescendants to use Epochs (master...epoch-mempool-clean-split-updatefordescendants-pt1) https://github.com/bitcoin/bitcoin/pull/18120
< bitcoin-git> [bitcoin] JeremyRubin closed pull request #18063: Improve UpdateForDescendants by using Epochs and Removing CacheMap (master...epoch-mempool-clean-split-2) https://github.com/bitcoin/bitcoin/pull/18063
< bitcoin-git> [bitcoin] laanwj pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/45cdcd47d99e...3516a31eaa77
< bitcoin-git> bitcoin/master 306f71b Anthony Towns: scheduler: don't rely on boost interrupt on shutdown
< bitcoin-git> bitcoin/master b9c4260 Anthony Towns: sync.h: add REVERSE_LOCK
< bitcoin-git> bitcoin/master d0ebd93 Anthony Towns: scheduler: switch from boost to std
< bitcoin-git> [bitcoin] laanwj merged pull request #18234: refactor: Replace boost::mutex,condition_var,chrono with std equivalents in scheduler (master...202002-scheduler-deboost) https://github.com/bitcoin/bitcoin/pull/18234
< jeremyrubin> bitcoin 2020 is postponed to Q3
< jeremyrubin> We could coordinate having a coredev.tech then?
< luke-jr> MarcoFalke: where is mockscheduler disabled?
< MarcoFalke> luke-jr: Nevermind. It is only in master
< MarcoFalke> But 18234 was merged already
< luke-jr> right, so this is backport-only now, at most
< bitcoin-git> [bitcoin] luke-jr closed pull request #18271: scheduler: Workaround negative nsecs bug in boost's wait_until (master...wrkarnd_boost_wait_until) https://github.com/bitcoin/bitcoin/pull/18271
< bitcoin-git> [bitcoin] luke-jr opened pull request #18284: [0.19] scheduler: Workaround negative nsecs bug in boost's wait_until (0.19...wrkarnd_boost_wait_until) https://github.com/bitcoin/bitcoin/pull/18284
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #18285: test: Check that wait_until returns if time point is in the past (master...2002-debugBoost) https://github.com/bitcoin/bitcoin/pull/18285
< Stealthy> how are ListSinceBlock transactions ordered
< Stealthy> not chronological for sure
< bitcoin-git> [bitcoin] practicalswift closed pull request #17828: net: Use log categories when logging events that P2P peers can trigger arbitrarily (master...log-categories) https://github.com/bitcoin/bitcoin/pull/17828
< nothingmuch> is there a reccomended approach to creating a json compilation database? bear seems like the simplest approach but it's segfaulting for me and i'm having trouble debugging, and i'm not sure how to convince automake to add -MJ to clang in the right way so that the json files are written separately
< nothingmuch> thanks!
< fanquake> So looks like a couple of travis jobs (fuzzing) are going to continually fail until someone adds "locale" seeds to https://github.com/bitcoin-core/qa-assets/tree/master/fuzz_seed_corpus ?
< fanquake> MarcoFalke: are you are going to do that shortly given you merged #18126 ?
< gribble> https://github.com/bitcoin/bitcoin/issues/18126 | tests: Add fuzzing harness testing the locale independence of the strencodings.h functions by practicalswift · Pull Request #18126 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] fanquake pushed 13 commits to master: https://github.com/bitcoin/bitcoin/compare/3516a31eaa77...4d80274b9963
< bitcoin-git> bitcoin/master dc2d065 Karl-Johan Alm: make BlockUntilSyncedToCurrentChain() const
< bitcoin-git> bitcoin/master ddc9355 Karl-Johan Alm: wallet: make CanGenerateKeys() const
< bitcoin-git> bitcoin/master 037fa77 Karl-Johan Alm: wallet: make KeypoolCountExternalKeys() const
< bitcoin-git> [bitcoin] fanquake merged pull request #18241: wallet/refactor: refer to CWallet immutably when possible (master...2002-const-fixes) https://github.com/bitcoin/bitcoin/pull/18241
< bitcoin-git> [bitcoin] practicalswift opened pull request #18286: build: Add locale fuzzer to FUZZERS_MISSING_CORPORA (and unbreak Travis! :)) (master...unbreak-travis-sorry) https://github.com/bitcoin/bitcoin/pull/18286