< bitcoin-git> [bitcoin] fanquake pushed 2 commits to 0.21: https://github.com/bitcoin/bitcoin/compare/997e528a3418...52778f42452d
< bitcoin-git> bitcoin/0.21 080b47d Pavol Rusnak: rpc: reset scantxoutset progress on finish
< bitcoin-git> bitcoin/0.21 52778f4 fanquake: Merge bitcoin/bitcoin#22580: [0.21] Backport: Reset scantxoutset progress ...
< bitcoin-git> [bitcoin] fanquake merged pull request #22580: [0.21] Backport: Reset scantxoutset progress before inferring descriptors (0.21...backport_19362) https://github.com/bitcoin/bitcoin/pull/22580
< bitcoin-git> [bitcoin] fanquake closed pull request #22529: contrib/seeds: bump MIN_BLOCKS = 687249 & update (master...contrib-seeds-height-687249) https://github.com/bitcoin/bitcoin/pull/22529
< fanquake> Could someone have a look at the backports in #22578? Would like to merge that to cleanup the CI issues we're seeing on the 0.21 branch.
<@gribble> https://github.com/bitcoin/bitcoin/issues/22578 | [0.21] Additional backports by fanquake · Pull Request #22578 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] NikhilBartwal closed pull request #22565: [script] signet's getcoins.py improvements (master...update_signet_getcoins) https://github.com/bitcoin/bitcoin/pull/22565
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d23570098cd1...9c9939ce54d8
< bitcoin-git> bitcoin/master fa86528 MarcoFalke: test: Add temporary sanitizer suppression implicit-signed-integer-truncati...
< bitcoin-git> bitcoin/master 9c9939c MarcoFalke: Merge bitcoin/bitcoin#22584: test: Add temporary sanitizer suppression imp...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22584: test: Add temporary sanitizer suppression implicit-signed-integer-truncation:netaddress.cpp (master...2107-testSupp) https://github.com/bitcoin/bitcoin/pull/22584
< bitcoin-git> [bitcoin] NikhilBartwal reopened pull request #22565: [script] signet's getcoins.py improvements (master...update_signet_getcoins) https://github.com/bitcoin/bitcoin/pull/22565
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to 0.21: https://github.com/bitcoin/bitcoin/compare/52778f42452d...068ac69b56d6
< bitcoin-git> bitcoin/0.21 89426c4 Hennadii Stepanov: ci: Fix macOS brew install command
< bitcoin-git> bitcoin/0.21 681f728 Hennadii Stepanov: ci: Build with --enable-werror by default, and document exceptions
< bitcoin-git> bitcoin/0.21 55e941f MarcoFalke: test: Fix intermittent feature_taproot issue
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22578: [0.21] Additional backports (0.21...0_21_fix_macOS_ci) https://github.com/bitcoin/bitcoin/pull/22578
< vasild> Looking at a CI fuzzer output: https://cirrus-ci.com/task/5466383543697408?logs=ci#L2794
< vasild> how could I reproduce that failure?
< vasild> running with the same seed on the same corpus does not reproduce for some reason :/
< vasild> is there a way to retrieve ./crash-0671aac15e619e99522e2119487eaa9cc97e5a34 from the CI machine?
< vasild> when the fuzzer fails locally it prints the file name and also its contents in base64, but the CI log does not contain the base64 dump of the file, any idea why?
< vasild> MarcoFalke: ^
< bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/9c9939ce54d8...b6c3fceed6b9
< bitcoin-git> bitcoin/master 0a9129c Jon Atack: test: assert on the value of getblockchaininfo#time
< bitcoin-git> bitcoin/master 78c3610 Jon Atack: test: assert on mediantime in getblockheader and getblockchaininfo
< bitcoin-git> bitcoin/master d548dc7 Jon Atack: test: replace magic values by constants in rpc_blockchain.py
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22520: test: improve rpc_blockchain.py tests and assert on time and mediantime (master...getblockchaininfo-time-tests) https://github.com/bitcoin/bitcoin/pull/22520
< bitcoin-git> [bitcoin] jonatack opened pull request #22589: net, doc: update I2P hardcoded seeds and docs for 22.0 (master...i2p-seeds-and-doc-updates) https://github.com/bitcoin/bitcoin/pull/22589
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b6c3fceed6b9...78f040a6b350
< bitcoin-git> bitcoin/master 8ca51af Martin Zumsande: test: Disable automatic connections by default
< bitcoin-git> bitcoin/master 78f040a MarcoFalke: Merge bitcoin/bitcoin#22490: test: Disable automatic connections per defau...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22490: test: Disable automatic connections per default in the functional tests (master...202107_test_noautoconnect) https://github.com/bitcoin/bitcoin/pull/22490
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/78f040a6b350...da1c0c64fd09
< bitcoin-git> bitcoin/master 84c8747 Sebastian Falbesoner: test: remove unneeded initialization code in feature_rbf.py
< bitcoin-git> bitcoin/master a3f6397 Sebastian Falbesoner: test: feature_rbf.py: make MiniWallet instance available for all sub-tests...
< bitcoin-git> bitcoin/master aa02c64 Sebastian Falbesoner: test: use MiniWallet for simple doublespend test in feature_rbf.py
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22330: test: use MiniWallet for simple doublespend sub-test in feature_rbf.py (master...202106-test-feature_rbf_use_miniwallet_for_doublespend) https://github.com/bitcoin/bitcoin/pull/22330
< bitcoin-git> [bitcoin] tylerchambers opened pull request #22590: Don't overwrite settings.json if it exists but can't be read. (master...fix-22571) https://github.com/bitcoin/bitcoin/pull/22590
< bitcoin-git> [bitcoin] tylerchambers closed pull request #22590: Util: don't overwrite existing but unreadable settings.json (master...fix-22571) https://github.com/bitcoin/bitcoin/pull/22590
< bitcoin-git> [bitcoin] tylerchambers opened pull request #22591: Util: error if settings.json exists, but is unreadable. (master...fix-22571) https://github.com/bitcoin/bitcoin/pull/22591
< achow101> #startmeeting
< core-meetingbot> Meeting started Fri Jul 30 19:04:00 2021 UTC. The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
< core-meetingbot> Available commands: action commands idea info link nick
< michaelfolkson> hi
< achow101> #bitcoin-core-dev Wallet Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd
< achow101> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
< S3RK> hi
< sipa> hi
< achow101> any topics to discuss?
< kvaciral[m]> hi
< michaelfolkson> I'll ask a couple of questions if there are no topics
< achow101> michaelfolkson: go ahead
< michaelfolkson> So there are a couple of PRs #22364 and #19602 making Taproot, bech32m the defaults (and intended to be merged after activation)
<@gribble> https://github.com/bitcoin/bitcoin/issues/22364 | wallet: Make a tr() descriptor by default by achow101 · Pull Request #22364 · bitcoin/bitcoin · GitHub
<@gribble> https://github.com/bitcoin/bitcoin/issues/19602 | wallet: Migrate legacy wallets to descriptor wallets by achow101 · Pull Request #19602 · bitcoin/bitcoin · GitHub
< michaelfolkson> These are intended to a version post activation (from what I can understand)
< S3RK> I believe 19602 is unrelated to taproot, no?
< achow101> 19602 is unrelated to taproot
< michaelfolkson> Are these dependent on whether other wallets in the ecosystem support Taproot?
< michaelfolkson> Oh sorry got wrong PR number, Sjors PR to make bech32m default was supposed to be
< achow101> michaelfolkson: no. the default address type will remain bech32
< achow101> so p2wpkh will be the default address type
< michaelfolkson> #22260 it should have been
<@gribble> https://github.com/bitcoin/bitcoin/issues/22260 | Make bech32m the default, except where needed. Update GUI checkbox. by Sjors · Pull Request #22260 · bitcoin/bitcoin · GitHub
< achow101> 22260 would be dependent on the rest of the ecosystem being able to accept bech32m addresses
< michaelfolkson> Right. And #22364 is in same boat?
<@gribble> https://github.com/bitcoin/bitcoin/issues/22364 | wallet: Make a tr() descriptor by default by achow101 · Pull Request #22364 · bitcoin/bitcoin · GitHub
< michaelfolkson> Wallets in ecosystem would need to be able to send to P2TR (which hopefully they will)
< achow101> no, 22364 just needs activation
< sipa> no, that just enables the wallet to construct p2tr addresses
< sipa> it won't create them unless asked to
< achow101> 22364 give the option for users to make p2tr addresses, but do not give them out by default
< sipa> right now, you need to manually import a tr() descriptor before you can construct p2tr addresses
< S3RK> I have a related question. What's the path to add tr descriptor to an exisitng wallet?
< sipa> with 22364, such a tr() descriptor will be created by default
< achow101> with 22364 should also need an option in the GUI which I think can be taken from 22260
< achow101> S3RK: currently the only way is to use importdescriptors
< michaelfolkson> Ohh ok. I thought that was making the default descriptor a Taproot descriptor. That is just allowing you to make a Taproot descriptor, gotcha
< achow101> but I think we should add something (maybe to upgradewallet) that can generate a tr descriptor for the wallet
< S3RK> achow101: yes, I was thinking the same
< S3RK> manually constructing tr based on your existing master key is a bit tedious
< sipa> michaelfolkson: there is no "default descriptor"
< sipa> michaelfolkson: there is a default descriptor per address type
< sipa> right now, no default bech32m descriptor is created, so no bech32m addresses can be requested
< sipa> with 22364, a default bech32m descriptor will be created
< sipa> (but there will also still be default bech32 and legacy descriptors)
< michaelfolkson> Ok thanks
< michaelfolkson> Then a question on Miniscript (that we discussed at the last wallet meeting)
< S3RK> achow101: do you have any toughts on how a new command might work? we don't want a command just for the taproot, do we?
< michaelfolkson> But I'll wait for above to finish
< achow101> S3RK: I'm thinking maybe a new RPC for generating descriptors in general
< S3RK> what's the input for it would look like?
< achow101> generatedescriptor bech32m
< achow101> ?
< S3RK> michaelfolkson: sorry for hijacking your quesitons
< prayank> getnewdescriptor -tr ?
< michaelfolkson> No it is fine, I'm not only one here :)
< achow101> I think the argument would be the address type, and the descriptor generated depends on whatever the default for the address type we choose
< achow101> this would change with future descriptors though
< achow101> there's also some issues with sharing the same master private key as other descriptors (or rather lack of)
< sipa> achow101: how would it know what key to use?
< S3RK> good question
< achow101> sipa: generate a new one?
< S3RK> meh..
< S3RK> now when I create new wallet don't I have one master key for all descriptors?
< sipa> achow101: i'm mostly asking because i wonder if it could be extended later to help with a multisig workflow
< achow101> S3RK: yes
< S3RK> it's really nice to have one master key I think. I'd like to keep that
< achow101> sipa: how would that work?
< sipa> achow101: i don't really know...
< achow101> S3RK: after a wallet is created, there isn't really a concept of "the wallet's master private key"
< achow101> especially if people import things afterwards
< S3RK> yeah, I understand. But I that was the promise of HD
< achow101> the promise of descriptors is also that it doesn't matter
< achow101> since the key is in the descriptor
< gene> hi
< S3RK> I kind of agree, but harder to backup and interropability is worse
< achow101> S3RK: there could be a second argument that gives the address type to take the master privkey from
< sipa> S3RK: well you need to backup either the wallet file, or the descriptors individually
< sipa> just having the key is not enough in any case
< achow101> e.g. "generatedescriptor bech32m bech32" would mean "make a descriptor that makes bech32m addresses using the master key from the current active external bech32 descriptor"
< sipa> but with a different derivation path?
< achow101> yes
< sipa> how would it figure out what path to use?
< S3RK> sipa: yes and there is also limited amount of derivations paths. I can just generate descriptors for all of them
< sipa> S3RK: i really dislike that notion :)
< sipa> especially if multisig becomes more common, with individual signers participating possibly in multiple multisigs, you can't just assume you can iterate over all possible derivation paths
< achow101> sipa: I think it would just use the default derivation path. for tr that's in BIP 86
< S3RK> yes, multisig makes everything more complicated
< sipa> achow101: right, fair; perhaps it could check if that some other descriptor already uses that default derivation path
< achow101> if we wanted to be more specific about which descriptor to take things from, we do have a descriptor id thing
< achow101> but we might want to formalize descriptor ids before using them
< gene> does the concept of domain separation apply to descriptors?
< S3RK> gene: what do you mean by domain separation?
< gene> having a specific prefix for derivation paths specific to the use-case
< achow101> gene: the point of descriptors is that we can move away from doing that because the derivation paths are explicit in the descriptor
< S3RK> there is a notion of an "account" in the derivation path. not sure if that's what you want
< gene> not account, more like all tr addrs use m/45' where all normal use m/44'
< prayank> Do we have any transaction on Testnet that has P2TR outputs? If someone tried and has transaction id, please share. I want to check few things in my node, different explorers.
< achow101> sipa: we could also make the derivation path be overridden by the user
< michaelfolkson> prayank: We do, I'll find you a link
< achow101> gene: that exists already, see BIPs 44/49/84/86
< gene> achow101: thanks +1
< S3RK> sipa achow101: thanks for you ideas. we don't have to solve it now. Let's think about it and check back later
< achow101> right, we still have time
< achow101> michaelfolkson: you had somehing else?
< michaelfolkson> Right on Miniscript...
< michaelfolkson> I know nothing ever is final, final but is Miniscript considered "final" now. Time for a BIP etc?
< michaelfolkson> There are still small changes being made every now and again
< michaelfolkson> It seems gnarly getting these libraries into Core (Minisketch, Miniscript etc) when Core can change, the PR can change and the external library can change
< michaelfolkson> Presumably the libsecp approach of keeping it as an external library rather than a subset of it being merged into Core isn't viable
< achow101> looking briefly at rust-miniscript, it seems like changes aren't really being made to miniscript itself but rather to the specific implementation
< michaelfolkson> And this would be final like Miniscript version 1, obviously Miniscript would change with Taproot etc
< sipa> i don't tyink the current spec will change anymore
< achow101> I think the same can be said of sipa's c++ miniscript implementation
< sipa> but the c++ miniscript repo isn"t even up to date with that spec i think
< sipa> of course more extensions can be added
< michaelfolkson> There are a few issues and open PRs on sipa's C++ implementation
< michaelfolkson> (I think... from memory)
< achow101> sipa: is your website still the up to date spec?
< sipa> there has been some.more activity recently, so i think we'll be able to make.progress there soonish
< sipa> achow101: i don't remember
< sipa> too swapped out...
< sipa> (afk)
< prayank> michaelfolkson: Thanks :) you can share here. I will check in logs if my IRC app disconnects.
< michaelfolkson> James' Python implementation has been sitting there for a similar time so it would nice to get a "
< michaelfolkson> "final" BIP spec
< achow101> I can ask sanket or andytoshi if either of them would like to write a BIP
< michaelfolkson> Happy to help (and not be named as a co-author on the BIP)
< michaelfolkson> If needed
< achow101> (I expect the only person who is actually fully up to date on all of the particulars is sanket)
< michaelfolkson> Ok cool, that was my question having glanced over the open Miniscript PR earlier
< achow101> anything else to discuss?
< S3RK> I have one more small question
< michaelfolkson> And ideally not 10 BIPs for Miniscript :)
< * michaelfolkson> ducks
< S3RK> how do we decide whether make listing private descriptors a separate RPC? #21500
<@gribble> https://github.com/bitcoin/bitcoin/issues/21500 | wallet, rpc: add an option to list private descriptors by S3RK · Pull Request #21500 · bitcoin/bitcoin · GitHub
< achow101> S3RK: I think that's a personal preference type of thing
< achow101> I don't particularly care either way, but it makes sense to continue to just add an option to the existing RPC
< S3RK> me too. should I solicit more opinions?
< achow101> I don't think many people care
< S3RK> ok. oh.. one more thing
< S3RK> do we want to consider a CI setup without BDB?
< gene> adding a separate RPC could increase security by allowing people to disable it
< achow101> S3RK: that would probably be a good idea
< achow101> gene: There's currently no way to disable specific RPCs
< gene> oh...
< gene> guessing no way to disable RPC options then either?
< achow101> that's correct
< gene> may look into how much work it would be to add that feature
< achow101> anything else?
< S3RK> nope
< michaelfolkson> Nope
< achow101> #endmeeting
< core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
< core-meetingbot> Meeting ended Fri Jul 30 19:50:18 2021 UTC.
< michaelfolkson> Thanks achow101 et al
< achow101> I'll probably prototype some possible upgrade methods on monday
< gene> thanks :3
< prayank> gene: option to disable RPCs sounds interesting. Although I doubt many people would agree to add it.
< gene> why?
< S3RK> achow101: you mean adding tr descriptor to exsting wallet?
< achow101> S3RK: yeah
< S3RK> achow101: ping me if when you have something to share
< achow101> sure
< gene> my general impression of bitcoin devs is a high respect and concern for security. adding a feature that increases the ability of users to secure themselves seems like it fits
< achow101> gene: I think there have been some ideas around multiple RPC users and permissions for those users
< michaelfolkson> prayank: Just interested in testnet, not mainnet or signet? 0xB10C is the guru here
< achow101> It would probably be better to do something related to that rather than disabling RPCs.
< achow101> but generally our protection against unauthorized exports of wallet privkeys is to enable wallet encryption
< achow101> and not expose RPCs publicly
< michaelfolkson> prayank: I'm guessing you saw this https://b10c.me/blog/007-spending-p2tr-pre-activation/
< prayank> michaelfolkson: Only testnet. Not sure if it's possible to do it on mainnet safely before activation.
< gene> right, but what if I (as theoretical user) want to expose an RPC to get current block height, but not query addresses?
< prayank> Reading the link now
< michaelfolkson> prayank: Oh it isn't. If you read that blog post 0xB10C effectively "stole" the funds at the Taproot outputs on mainnet
< S3RK> gener: I also wonder how is it solved in the industry right now
< achow101> gene: you might be interested in the discussion in #12248
<@gribble> https://github.com/bitcoin/bitcoin/issues/12248 | RPC Whitelist Files · Issue #12248 · bitcoin/bitcoin · GitHub
< gene> the separation of users is a good idea, too. accounts (user credentials) can be hacked, though. so, think that disabling the RPC as the ultimate way to secure against an attack on public node
< achow101> oh, perhaps #12763 already implements some of this?
<@gribble> https://github.com/bitcoin/bitcoin/issues/12763 | Add RPC Whitelist Feature from #12248 by JeremyRubin · Pull Request #12763 · bitcoin/bitcoin · GitHub
< S3RK> here we go :)
< gene> will look at those, thanks for the links
< gene> 12248 looks like exactly what I was thinking about
< gene> plus more
< _aj_> "there's currently no way to disable specific RPCs" -- doesn't #12763 provide that?
<@gribble> https://github.com/bitcoin/bitcoin/issues/12763 | Add RPC Whitelist Feature from #12248 by JeremyRubin · Pull Request #12763 · bitcoin/bitcoin · GitHub
< _aj_> ah, should've spent less time scrolled back
< blkncd> prayank: here are testnet spends https://twitter.com/0xB10C/status/1415697704726978570 and corresponding P2TR outputs
< michaelfolkson> prayank: You can't search for tb1p addresses on blockstream.info it appears. Need the full address
< prayank> Awesome. Those links will be helpful. Still reading the first one. Thanks michaelfolkson and blkncd