< kallewoof>
Should btcdeb be moved into the bitcoin github repo?
< luke-jr>
kallewoof: we're trying to move things out, not in.. why? :p
< kallewoof>
luke-jr: oh, okay. i thought there was talk about moving btcdeb into the bitcoin org at one point. feels like that might encourage contributors and would make it easier to provide binaries too
< luke-jr>
kallewoof: maybe it would make sense to move it to the bitcoin-core org as a new repo, but we're also trying to keep stuff off the bitcoin org now IIRC
< kallewoof>
okay
< bitcoin-git>
[bitcoin] Crypt-iQ opened pull request #19672: build: make clean removes .gcda and .gcno files from fuzz directory (master...fuzz_cov_cleanup_0806) https://github.com/bitcoin/bitcoin/pull/19672
< jeremyrubin>
Question Of The Day: empty scriptpubkeys are valid but not standard, correct? Is an empty p2sh script also valid? Can I satisfy it with OP_1 {}?
< sipa>
yes, yes (as far as i remember)
< jeremyrubin>
This is also true in segwit v0 and v1?
< sipa>
i believe so
< jeremyrubin>
TIL
< sipa>
did you know that a zero-of-zero checkmultisig is valid?
< jeremyrubin>
that I think I did know, and makes more sense?
< gribble>
https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
< jnewbery>
(just going by the tags)
< sdaftuar>
#19620 is not high priority, but i would like it to be (though really it's ready for merge, i think)
< sdaftuar>
because once it's merged i'll be backporting
< wumpus>
sdaftuar: will add
< sdaftuar>
thank you!
< jnewbery>
wumpus: just merge it. It has 5 ACKs :)
< wumpus>
jnewbery: ok, after the meeting :)
< hebasto>
is #11082 compatible with merged #15935 ?
< wumpus>
jonasschnelli fjahr luke-jr anyone of you here?
< gribble>
https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
< sipa>
ah, i guess bitcoin_rw is for changing config options through UI etc, while settings.json is for other things like bans?
< wumpus>
I'm not exactly sure what is the difference either
< wumpus>
I guess one is for persisting the other is for changing it through RPC?
< hebasto>
I thought they were two alternatives
< jnewbery>
I think settings.json can be used for changing config options through GUI or RPC. The idea is to keep dynamic config in sync between bitcoind and bitcoin-qt
< achow101>
my understanding was that bitcoin_rw was to let users also change the options
< achow101>
and settings.json is only for bitcoind/bitcoin-qt
< achow101>
I always viewed it as bitcoin_rw.conf was to supersede bitcoin.conf
< sipa>
ah yes _rw would be accessible by bitcoin-cli etc as well
< fjahr>
wumpus: will do, just wanted to answer your question as well at the same time
< wumpus>
this doesn't add two separate settings mechanisms I hope?
< jnewbery>
achow101: I don't think it makes sense to have yet another config source. How many do we have now?
< wumpus>
jnewbery: hehe right
< achow101>
jnewbery: 3. bitcoin.conf, settings.json, and QSettings
< wumpus>
bitcoin-qt is a maze of different config sources already
< achow101>
settings.json and QSettings are supposed to be combined I think
< achow101>
but not yet
< wumpus>
it's really subtle in which order they need to be interpreted to not break any existing things
< sipa>
and command line
< jnewbery>
and command line, and overrides in the source
< wumpus>
right
< sipa>
well i think we need ryanofsky and luke-jr to discuss this properly
< jnewbery>
After settings.json, QSettings should only be used for QT GUI configuration (eg window size/location)
< * jeremyrubin>
maybe a setting to let you pick which settings you are using
< wumpus>
I understand the long-term goal is to drop qsettings for everything but the datadir path
< wumpus>
oh and that
< wumpus>
but that doesn't overlap with bitcoin.conf so isn't an issue :)
< achow101>
wumpus: I think datadir path would want to be in settings.json
< wumpus>
achow101: that creates a chicken egg problem !
< sipa>
we should go back to storing settings in wallet.dat
< * sipa>
hides
< sdaftuar>
sipa: i was going to add an environment variable for enabling such behavior
< wumpus>
e.g. on windows, QSettings is in the registry, on linux it's in the standard ~/.config path, it's the only root-of-settings really
< achow101>
wumpus: i suppose it does, but it unifies qt and bitcoind datadir paths
< wumpus>
I won't pretent to understand it anymore, sorry
< achow101>
well conf always overrides qt anyways
< achow101>
I think
< sdaftuar>
perhaps a good first contributor project would be to document this somewhere, eg on our wiki
< wumpus>
heh, yes
< achow101>
i'm not sure a first contributor would be able to figure out this mess
< sdaftuar>
achow101: fair point!
< wumpus>
I'm terrified by that code in bitcoin-qt
< wumpus>
took me a lot of work to get it exactly right so be careful
< wumpus>
we don't have any tests for it because that's hard for GUI stuff
< wumpus>
and yes, conf overrides qt except the initial datadir
< sipa>
another reason to aim to move things out of qsettings
< sipa>
as it unifies testing across bitcoind and bitcoin-qtr
< wumpus>
yes
< wumpus>
but on inital use of the GUI, it asks you to select a data directory, it needs to store this somewhere that is not in the data drectory
< sipa>
indeed
< wumpus>
I'm okay with this being somewhere else than QSettings but I'm not sure where :)
< wumpus>
#topic what to do about zapwallettxes (achow101)
< achow101>
Since we have abandontransaction, I think ditching it is the way to go
< wumpus>
I think abandontransaction is superior *if* it can replace all uses
< achow101>
unless people used it for anything other than trying to RBF transactions
< wumpus>
as it's more granular
< wumpus>
if you don't need a sledgehammer you shouldn't use one
< wumpus>
with abandontransaction you can remove any conflicted or non-confirmed transaction?
< wumpus>
I don't think it's useful for transactions that are already in a block
< achow101>
wumpus: so long as they are not confirmed and not in the mempool, I believe so
< wumpus>
ok, right, makes sense
< sipa>
abandontransaction only works for things that aren't in the mempool
< achow101>
well they remain in history
< jeremyrubin>
Shouldn't we deprecate and then remove something like this?
< wumpus>
yes, well with zapwalettx you need to nuke the mempool too
< jeremyrubin>
Is there any reason to remove all at once?
< achow101>
but we also have removeprunedfunds which actually removes them from the wallet I think
< wumpus>
jeremyrubin: it's not a RPC
< wumpus>
yet
< achow101>
to go the full abandontransaction route, we might need to add an rpc to clear the mempool, or at least evict a particular transaction from it
< wumpus>
it's not an option someone would normally use except for recoery so there's no need to go through a deprecation cycle
< achow101>
but that might not be desirable
< sipa>
all of these things are recovery sledgehammers
< sipa>
some just smaller than others
< sdaftuar>
it strikes me as dangerous to encourage people to manually remove a tx from the mempool so that abandontransaction could be called on it
< achow101>
sdaftuar: me too
< sipa>
but anything that requires evicting things from the mempool shouldn't be needed on a regular basis
< sipa>
sdaftuar: exactly
< wumpus>
well if it's less dangerous to remove *all* transactions from the wallet?
< jeremyrubin>
wumpus: i just don't want to give anyone reason to not upgrade, but it's probably fine in this case
< wumpus>
that's what zapwallettx does
< achow101>
also, RBF is on by default anyways, so none of these things should matter today
< wumpus>
in any case my initial proposal was to move it to the wallet tool
< wumpus>
which is intended for maintenance and recovery like this
< sdaftuar>
wumpus: that sounds very reasonable
< sipa>
yeah, it may be that the only use for zapwallettx is for completely corrupted scenarios, where you should be using savagewallet instead...
< wumpus>
only if *no one* needs it, ever, we can just remove it
< sdaftuar>
l
< achow101>
wumpus: the main concern I have about that is zapwallettxes requires a rescan afterwards
< sipa>
sdaftuar: i know ;)
< achow101>
and the wallettol isn't going to do that
< wumpus>
do it on next start ?
< wumpus>
set the current block of the wallet to 0
< sdaftuar>
jeremyrubin: salvagewallet
< jeremyrubin>
fair.
< jnewbery>
achow101: can't the wallet tool reset the wallet's best block to force a rescan?
< wumpus>
right
< achow101>
sure
< wumpus>
it should
< sipa>
it doesn't already?
< wumpus>
as that information is unknown from there on
< achow101>
startup rescan is always unfun though
< wumpus>
zapwallettx rescan is not unfun?
< sipa>
yes, just making the rescan automatic doesn't mean it goes away
< wumpus>
it's the same IIRC
< achow101>
I seem to remember that -rescan on qt stuck you at the splashscreen until it finished
< wumpus>
I mean the current zapwallettx already forces a rescan at startup rght?
< wumpus>
so this would not make it worse
< wumpus>
it's for rare recovery operations
< wumpus>
not for fun
< achow101>
right
< jeremyrubin>
wumpus: maybe it should have had a less fun name
< sipa>
right
< wumpus>
it sounds too much fun
< wumpus>
jeremyrubin: exactly!
< sipa>
jeremyrubin: fun draw transaction?
< sdaftuar>
sipa: that confused me for so long
< * jeremyrubin>
pew pew tx go bye
< sipa>
also gcc -fun roll loops
< achow101>
i'm still not convinved that zapwallettxes is actually useful though
< wumpus>
abandontransaction is more fun in that regard, you could make an UI that allows zapping transactions one by one in a space invaders game :')
< achow101>
We have CWallet::ZapSelectTx :)
< achow101>
for removeprunedfunds
< wumpus>
achow101: me netiher, but how to we find out
< jeremyrubin>
Are there other topics?
< wumpus>
like the biggest risk for these kind of things is that it's documented on a wiki somewhere and people try it as a random sledgehammer to fix wallet issues
< wumpus>
no, I don't think so
< jnewbery>
I was going to propose a time for the p2p meeting
< achow101>
wumpus: either way whatever is documented won't work when we remove the startup option anyways
< wumpus>
#topic P2P meeting (jnewbery)
< jnewbery>
Thanks wumpus
< wumpus>
achow101: right!
< jnewbery>
I suggest 17:00 UTC on alternate Tuesdays, starting next week (Aug 11)
< wumpus>
sgtm
< moneyball>
yay p2p meeting
< wumpus>
so it's two hours earlier than this meeting
< jnewbery>
that's 2 hours before now (10am west coast, 1pm east coast, 6pm UK, 7pm most of europe)
< jnewbery>
I'll make a gist with meeting time and suggested topics and post a link here
< sdaftuar>
jnewbery: would be great to talk about people's sense of how we should prioritize all the PRs that are open right now
< jnewbery>
sdaftuar: right. That's the first topic. Everyone gets to share what they're working on and what their prioirities are.
< sdaftuar>
my hope is that people with opinions will make a case for particular PRs/areas of the code getting broader focus!
< sdaftuar>
not sure i'll have any strong opinions, as i try to wrap my head around all the open PRs, but i'd be most interested in contributing to areas that several other people have agreed would be helpful for all of us to focus on