< 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
< 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.
< 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>
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
< 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] 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