< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c2c4dbaebd95...661fe5d65cc6
< bitcoin-git> bitcoin/master fa1f6f2 MarcoFalke: net: Send post-verack handshake messages at most once
< bitcoin-git> bitcoin/master 661fe5d fanquake: Merge #20146: net: Send post-verack handshake messages at most once
< bitcoin-git> [bitcoin] fanquake merged pull request #20146: net: Send post-verack handshake messages at most once (master...2010-netPostVerackHandshake) https://github.com/bitcoin/bitcoin/pull/20146
< bitcoin-git> [bitcoin] fanquake opened pull request #20150: [0.19] Backports (0.19...more_019_backports) https://github.com/bitcoin/bitcoin/pull/20150
< fanquake> ☃️ feature freeze day ☃️
< sipa> NOT YET
< aj> sipa: it's thursday even in Honolulu, so i think fanquake is right
< fanquake> meshcollider will surely tell us it's nearly over
< meshcollider> T minus 7hours
< meshcollider> It's not over til I merge sqlite wallets!
< meshcollider> And don't take that satisfaction away from me ;)
< fanquake> heh. As long as you don't merge it in the next few minutes 💥
< meshcollider> Nah don't worry I don't have my key with me, it'll be a few hours til I'm home
< meshcollider> I could just click the github "Merge" button and break everything though...
< fanquake> 🤙 I'm about to rip out some non-endomorphison
< meshcollider> 🎉
< fanquake> Gotta love patents on multiplication
< bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/661fe5d65cc6...f2e6d1443013
< bitcoin-git> bitcoin/master 52380bf Pieter Wuille: Squashed 'src/secp256k1/' changes from 8ab24e8dad..c6b6b8f1bb
< bitcoin-git> bitcoin/master 9e5626d Pieter Wuille: Update libsecp256k1 subtree to latest master
< bitcoin-git> bitcoin/master f2e6d14 fanquake: Merge #20147: Update libsecp256k1 (endomorphism, test improvements)
< bitcoin-git> [bitcoin] fanquake merged pull request #20147: Update libsecp256k1 (endomorphism, test improvements) (master...202010_secp256k1) https://github.com/bitcoin/bitcoin/pull/20147
< sipa> \o/
< meshcollider> \o/
< bitcoin-git> [bitcoin] meshcollider pushed 27 commits to master: https://github.com/bitcoin/bitcoin/compare/f2e6d1443013...8ed37f6c8497
< bitcoin-git> bitcoin/master 54729f3 Andrew Chow: Add libsqlite3
< bitcoin-git> bitcoin/master e87df82 Andrew Chow: Add sqlite to travis and depends
< bitcoin-git> bitcoin/master 7577b6e Andrew Chow: Add SQLiteDatabase and SQLiteBatch dummy classes
< bitcoin-git> [bitcoin] meshcollider merged pull request #19077: wallet: Add sqlite as an alternative wallet database and use it for new descriptor wallets (master...sqlite-wallet) https://github.com/bitcoin/bitcoin/pull/19077
< aj> \o/
< meshcollider> achow101: 🥳
< bitcoin-git> [bitcoin] laanwj pushed 20 commits to master: https://github.com/bitcoin/bitcoin/compare/8ed37f6c8497...3caee1694657
< bitcoin-git> bitcoin/master f8c099e Pieter Wuille: --- [TAPROOT] Refactors ---
< bitcoin-git> bitcoin/master 107b57d Pieter Wuille: scripted-diff: put ECDSA in name of signature functions
< bitcoin-git> bitcoin/master 8bd2b4e Pieter Wuille: refactor: rename scriptPubKey in VerifyWitnessProgram to exec_script
< bitcoin-git> [bitcoin] laanwj merged pull request #19953: Implement BIP 340-342 validation (Schnorr/taproot/tapscript) (master...taproot) https://github.com/bitcoin/bitcoin/pull/19953
< sipa> \\\o///
< jonatack> boom \o/
< wumpus> \o/
< * sipa> does the tapdance
< sipa> actually wait no, i can't dance
< wumpus> (don't let it being merged stop you from reviewing further if you were still in progress)
< * wumpus> neither
< bitcoin-git> [bitcoin] hebasto opened pull request #20152: doc: Update wallet files in files.md (master...201015-sqlite) https://github.com/bitcoin/bitcoin/pull/20152
< sipa> what is the meeting topic command?
< MarcoFalke> #proposedmeetingtopic
< MarcoFalke> Is there anything left to discuss, now that everything is merged?
< sipa> #proposedmeetingtopic taproot relay policy / activation on testnet/signet
< wumpus> also wanted to get it merged so that other pre-0.21 PRs don't make it require rebase
< wumpus> with that many ACKs
< MarcoFalke> Makes sense, and as the code is not active yet, it can still be changed freely
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/3caee1694657...3956165903cf
< bitcoin-git> bitcoin/master 6020ce3 Gregory Sanders: DecodeHexTx: Try case where txn has inputs first
< bitcoin-git> bitcoin/master 27fc6a3 Gregory Sanders: DecodeHexTx: Break out transaction decoding logic into own function
< bitcoin-git> bitcoin/master 3956165 Wladimir J. van der Laan: Merge #17775: DecodeHexTx: Try case where txn has inputs first
< bitcoin-git> [bitcoin] laanwj merged pull request #17775: DecodeHexTx: Try case where txn has inputs first (master...decode_wit_first) https://github.com/bitcoin/bitcoin/pull/17775
< kallewoof> Won't be at meeting but my 2 sats on signet and taproot activation: I don't think there's a reason to delay activation. My suggestion is to set activation for a week or so from now (long enough for a trivial pull request to get ACKs and be merged + to update the servers issuing blocks). I guess the question is whether this is affected by feature freeze or not. If it is, I suggest we activate it after 0.21 branch split in
< kallewoof> master only.
< kallewoof> If people want to try out the actual real taproot activation mechanism for activation on signet, the story changes I guess.
< sipa> kallewoof: the nice thing about signet is that really consensus rules are decided by the signers - even if the rest of the network doesn't enforce
< sipa> the reason i brought it up is that i realize that master will now relay (valid) taproot spends... which may be unexpected, and feels wrong without activation plan
< kallewoof> sipa: yeah, but p2p layer is affected... propagation can be delayed or fail unless one peer is a miner
< kallewoof> sipa: in pre-activation? i thought it policy-rejected
< sipa> kallewoof: no
< sipa> i think segwit had special rules about relay before activation, because it was also a p2p change
< kallewoof> ohh! i didn't realize that.
< aj> sipa: (if the network enforces rules prior to "real" activation, and there's a hard-fork, you need more than just signers to fix things up)
< aj> sipa: (probably no need for hard-forks in the taproot implementation now though so, whatevs)
< sipa> the last softfork before that, CSV, was implemented & activated in the same release, 0.12.1
< sipa> but i think we should disable relay for networks which have no activation defined (i.e., all but regtest and maybe signet)
< kallewoof> sipa: my vote is to keep it enabled on signet, as that means we can just flip it on whenever and it will just work™️
< bitcoin-git> [bitcoin] jonatack closed pull request #19874: cli, bugfix: degrade -getinfo gracefully for older servers (master...getinfo-handle-older-servers-gracefully) https://github.com/bitcoin/bitcoin/pull/19874
< bitcoin-git> [bitcoin] jonatack reopened pull request #19874: cli, bugfix: degrade -getinfo gracefully for older servers (master...getinfo-handle-older-servers-gracefully) https://github.com/bitcoin/bitcoin/pull/19874
< kallewoof> I get the sneaky suspicion that enum class with bit fiddling is... not the way to go. Tempted to just do const uint8_t's and skip the enum part altogether..
< bitcoin-git> [bitcoin] sipa closed pull request #19997: History for Taproot PR #19953 (master...taproot-history) https://github.com/bitcoin/bitcoin/pull/19997
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/3956165903cf...e3b474c54866
< bitcoin-git> bitcoin/master 883cea7 Pieter Wuille: Restore compatibility with old CSubNet serialization
< bitcoin-git> bitcoin/master 886be97 Pieter Wuille: Ignore incorrectly-serialized banlist.dat entries
< bitcoin-git> bitcoin/master e3b474c Wladimir J. van der Laan: Merge #20140: Restore compatibility with old CSubNet serialization
< bitcoin-git> [bitcoin] laanwj merged pull request #20140: Restore compatibility with old CSubNet serialization (master...202010_subnet_ser_compact) https://github.com/bitcoin/bitcoin/pull/20140
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/e3b474c54866...560dea9b26f7
< bitcoin-git> bitcoin/master d681a28 Luke Dashjr: RPC: getpeerinfo: Deprecate "whitelisted" field (replaced by "permissions")
< bitcoin-git> bitcoin/master 5b57dc5 Luke Dashjr: RPC: getpeerinfo: Wrap long help line for bytesrecv_per_msg
< bitcoin-git> bitcoin/master 560dea9 MarcoFalke: Merge #19770: RPC: getpeerinfo: Deprecate "whitelisted" field (replaced by...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19770: RPC: getpeerinfo: Deprecate "whitelisted" field (replaced by "permissions") (master...deprecate_whitelisted) https://github.com/bitcoin/bitcoin/pull/19770
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/560dea9b26f7...711ddce94377
< bitcoin-git> bitcoin/master faad92f MarcoFalke: test: Remove unused nVersion=1 in p2p tests
< bitcoin-git> bitcoin/master 711ddce Wladimir J. van der Laan: Merge #20131: test: Remove unused nVersion=1 in p2p tests
< bitcoin-git> [bitcoin] laanwj merged pull request #20131: test: Remove unused nVersion=1 in p2p tests (master...2010-testnVersion) https://github.com/bitcoin/bitcoin/pull/20131
< bitcoin-git> [bitcoin] S3RK opened pull request #20153: wallet: do not import a descriptor with hardened derivations into a watch-only wallet (master...importdesc_silent_fail) https://github.com/bitcoin/bitcoin/pull/20153
< jamesob> wow, big merge day. congrats sipa, achow101!
< elichai2> 🥳🥳🥳🥳
< bitcoin-git> [bitcoin] kallewoof opened pull request #20154: BIP-322 support (master...202010-bip322) https://github.com/bitcoin/bitcoin/pull/20154
< kallewoof> andytoshi: hope you didn't spend too much time on your implementation. I have begun working on a rough implementation of BIP 322 support here, FYI: https://github.com/bitcoin/bitcoin/pull/20154
< hebasto> is #20120 rtm?
< gribble> https://github.com/bitcoin/bitcoin/issues/20120 | net, rpc, test, bugfix: update GetNetworkName, GetNetworksInfo, regression tests by jonatack · Pull Request #20120 · bitcoin/bitcoin · GitHub
< andytoshi> kallewoof: no, i spent about 30 minutes on it :) the old spec was super straightforward (at least, with the existing rust-bitcoin/miniscript infrastructure i have)
< andytoshi> the new spec is bigger but i think will integrate much better with my descriptors library
< kallewoof> andytoshi: it seems to integrate really well with bitcoin core, from what i can tell so far. the old code was a split out thing of its own
< kallewoof> andytoshi: cool to hear you're working on it. feedback and such super welcome :)
< andytoshi> right, that's also what was going to happen with the rust-miniscript implementation ... de/serialization was easy but then providing a usable sign/verify API seemed pretty unnatural. i think this one will be better because i can write a function that takes a descriptor + message and converts it to a to_spend transaction
< andytoshi> (and i guess now, will also take a value ... i'm curious why you changed this this morning...i don't have strong feelings either way, i just don't understand it)
< kallewoof> andytoshi: uh... i somehow thought the sum of amounts was required in the signature, but now that you mention it, i think i was confused..
< kallewoof> andytoshi: I'll revert that one now. Thanks for pointing it out
< andytoshi> cool :) the value made it a little harder, API-wise, because it means that you need to know upfront whether you're going to use the to_spend purely as a dummy input when proving funds, or not (and you have to konw how many funds you're planning to prove)
< andytoshi> you sorta have to know this now, in choosing whether to use an OP_TRUE descriptor or a "real" one
< kallewoof> andytoshi: that makes sense -- yeah, i think i managed to convince myself that the signatures commit to the amounts, so we need to have those available and why not just stuff them in the virtual to_sign tx... but that's not how it works at all.
< luke-jr> oh blah, sqlite isn't optional? :/
< * MarcoFalke> updates all build scripts to install sqlite-dev
< MarcoFalke> This is probably the first time a dependecy has been added in years. Others were only removals.
< * luke-jr> begins on a PR to fix it optional
< * kallewoof> calls it a day at "checker.CheckECDSASignature(vchSig, vchPubKey, scriptCode, sigversion)" returning false. :) Will compare sighashes tomorrow. Maybe I should've implemented this in btcdeb first.
< andytoshi> kallewoof: sounds good, hopefully i'll have some test vectors in the next 6-8 hours we can compare
< kallewoof> andytoshi: nice!
< bitcoin-git> [bitcoin] luke-jr opened pull request #20156: Make sqlite support optional (compile-time) (master...opt_sqlite) https://github.com/bitcoin/bitcoin/pull/20156
< jamesob> anyone ever seen "/usr/bin/ld: error: [...]: <corrupt x86 property (0xc0000002) size: 0x8>" during compilation before? I'm getting a truckload of them, but compilation seems to succeed anyway. Think it has to do with having installed the debian gcc-9 package, but not sure. Google turns up nothing.
< jamesob> s/compilation/link & ar time
< yanmaani> jamesob: yeah, me too
< yanmaani> what OS?
< jamesob> Linux slug 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64 GNU/Linux
< yanmaani> I use gcc 8.3.0 @ debian (devuan)
< gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
< jamesob> I get it when compiling with gcc or clang; I think it's an issue with ld/ar
< yanmaani> Linux hostname 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64 GNU/Linux
< gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
< promag> does it make sense to support multiple -blocksdir where one is rw but the others are ro? so that older blocks can be kept on a slower disk?
< yanmaani> promag: you may be interested in overlayfs
< yanmaani> or just some caching setup
< luke-jr> promag: probably
< promag> yanmaani: yes, I though about that, but then in instead of prunning it would move blocks the the other place
< luke-jr> promag: needs some thought, though, as it also makes sense to move them automatically
< promag> luke-jr: right
< yanmaani> uh, how are you going to automatically move blocks to a RO fs?
< luke-jr> FWIW Signet may be broken on master since it lacks Taproot activation params
< promag> yanmaani: no, I mean RO as in bitcoind doesn't writes new blocks there
< yanmaani> the simple solution is to have a cronjob that checks mtime/ctime and moves+symlinks them
< yanmaani> oh, not a RO fs
< yanmaani> just do overlayfs or something IMO
< promag> not ro fs, "RO" -blocksdir
< promag> yanmaani: I understand this can be overcome out of bitcoind, but the idea would be to add a -prunestrategy=archive for instance
< luke-jr> yanmaani: for example, it can be an external drive you unplug when you leave home
< promag> just a thought..
< luke-jr> and blocks would just not prune-to-slow-storage while you're away from home
< luke-jr> when you get back, then they move
< yanmaani> luke-jr: But then you have a problem when you start bitcoind in such cases, no?
< promag> luke-jr: exactly
< luke-jr> and if you need to use (eg) a rescan RPC, you plug in the drive
< promag> it can be copy first, then delete old
< luke-jr> yanmaani: that's exactly what this would avoid
< yanmaani> I guess if you have the DB, yeah. Couldn't it just ignore missing blocks until they're needed?
< promag> yup
< yanmaani> so you can do whatever you want and bitcoind will just deal with it
< promag> this might interact with assumeutxo cc jamesob
< yanmaani> instead of re-implementing overlayfs in bitcoin core
< promag> yanmaani: overlayfs is cool if you dont care where each file is stored
< promag> and it's platform dependant
< yanmaani> you can move them around by yourself though
< yanmaani> or just set a cronjob to move+symlink
< promag> yes I could
< promag> or have it automatic
< jamesob> promag: should be compatible with assumeutxo since blocksdir access is largely unchanged; blocks have always come out of order anyway
< jamesob> well... not always, but for a while :)
< promag> jamesob: but what happens if you have to validate and a block isn't there?
< jamesob> promag: validation doesn't require access to blockfiles per se because all the data you're relying on is stored in (i) the headers chain and (ii) the utxo set
< bitcoin-git> [bitcoin] luke-jr opened pull request #20157: Bugfix: chainparams: Add missing (disabled) Taproot deployment for Signet (master...signet_taproot_fix) https://github.com/bitcoin/bitcoin/pull/20157
< provoostenator> I'd like to nominate https://github.com/bitcoin-core/gui/pull/96 for v0.21 too
< provoostenator> Also note it's impossible to create an unnamed wallet with the GUI atm
< promag> jamesob: but if blocks are available locally then this is not required right?
< promag> "this" as in ibd
< jamesob> promag: ibd is still required to make sure that the blocks on disk render into the utxo set that you expect
< jamesob> I guess that'd be more like a reindex
< promag> thanks jamesob
< jamesob> sure thing
< jamesob> man it is now amazingly hard to replicate the slew of CI errors locally
< sdaftuar> i thought it was a video game where you keep clicking the re-run button til it passes?
< * sdaftuar> ducks
< promag> sdaftuar: like go away pls
< promag> luke-jr: another approach would be -prunedir which if set it would move there instead of deleting
< luke-jr> promag: keep in mind it may be desirable to actually prune too
< luke-jr> promag: eg, keep blocks with your own txs in them in storage, but prune everything else
< promag> that requires to have wallets loaded
< luke-jr> not necessarily (see prune locks)
< promag> ah you mean #19463
< gribble> https://github.com/bitcoin/bitcoin/issues/19463 | Prune locks by luke-jr · Pull Request #19463 · bitcoin/bitcoin · GitHub
< luke-jr> promag: anyway, my point is it probably shouldn't literally hijack the pruning logic
< luke-jr> it is fundamentally different
< promag> don't want to change the logic
< promag> just want to s/delete/move
< luke-jr> #proposedmeetingtopic Getting BIP 8 logic in before freeze
< gribble> https://github.com/bitcoin/bitcoin/issues/11394 | Perform a weaker subtree check in Travis by sipa · Pull Request #11394 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] laanwj pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/711ddce94377...0d2248235375
< bitcoin-git> bitcoin/master 6df7882 Jon Atack: net: add peer network to CNodeStats
< bitcoin-git> bitcoin/master 4938a10 Jon Atack: rpc, test: expose CNodeStats network in RPC getpeerinfo
< bitcoin-git> bitcoin/master 5133fab Jon Atack: cli: simplify -netinfo using getpeerinfo network field
< bitcoin-git> [bitcoin] laanwj merged pull request #20002: net, rpc, cli: expose peer network in getpeerinfo; simplify/improve -netinfo (master...getpeerinfo-GetNetClass) https://github.com/bitcoin/bitcoin/pull/20002
< hebasto> provoostenator: agree about 0.21
< yanmaani> Do you get my posts to the bitcoin-dev list? I can see them online, but I get the "your message awaits approval" message
< provoostenator> #16546 can be dropped from the high priority list: it won't make it into 0.21 and hardware wallets already have a project
< gribble> https://github.com/bitcoin/bitcoin/issues/16546 | External signer support - Wallet Box edition by Sjors · Pull Request #16546 · bitcoin/bitcoin · GitHub
< provoostenator> That said, it now works with Sqlite!
< bitcoin-git> [bitcoin] laanwj pushed 8 commits to master: https://github.com/bitcoin/bitcoin/compare/0d2248235375...9855422e65ca
< bitcoin-git> bitcoin/master 567008d Hennadii Stepanov: p2p: Add DumpAnchors()
< bitcoin-git> bitcoin/master c29272a Hennadii Stepanov: p2p: Add ReadAnchors()
< bitcoin-git> bitcoin/master bad16af Hennadii Stepanov: p2p: Add CConnman::GetCurrentBlockRelayOnlyConns()
< bitcoin-git> [bitcoin] laanwj merged pull request #17428: p2p: Try to preserve outbound block-relay-only connections during restart (master...20191109-anchors) https://github.com/bitcoin/bitcoin/pull/17428
< phantomcircuit> sipa, can an attacker with access to the private key generate two signatures from the same private key for the same message?
< phantomcircuit> with schnorr signatures?
< phantomcircuit> i assume so
< sipa> generally you don't call someone with a private key an attacker ;)
< sdaftuar> "signer"
< sipa> but yes - the term you're looking for (i think) is a "unique signature", and no EC based signature schemes are
< phantomcircuit> sipa, if they're trying to abuse poorly written wallet software they are :P
< sdaftuar> "user"
< phantomcircuit> that's what i thought
< phantomcircuit> it's still an attacker... just not of the signature scheme itself
< jeremyrubin> I think phantomcircuit is more asking if a signing oracle will ever generate different signatures for same msg
< bitcoin-git> [bitcoin] dongcarl opened pull request #20158: tree-wide: De-globalize ChainstateManager (master...2020-06-libbitcoinruntime) https://github.com/bitcoin/bitcoin/pull/20158
< sipa> phantomcircuit: to be clear, the bip340 signing algorithm is deterministic if no auxiliary randomness is used
< phantomcircuit> jeremyrubin, not if they will, but if they can, which sipa has answered
< sipa> but nobody is required (or can be verified to) follow that algorithm
< phantomcircuit> sipa, yeah i understand now, i was confused by the bip340 language about malleability
< sipa> there is one context where we actually treat someone with a private key as an attacker in BIP340, and it's a rather unusual requirement: nobody (even those with private keys) should be able to construct a signature for which the single-sig validation and batch-validation algorithm produce a different result (with more than negligible probability)
< phantomcircuit> i thought that my original reading was unlikely so im here asking :)
< sipa> well, i don't think it should be an unusual requirement - but in practice it seems it's not part of the standard attack model for signatures
< phantomcircuit> sipa, indeed cause then you could validate a transaction that is then rejected by block validation, would be a nasty issue
< sipa> in ed25519 land, this property clearly does not hold: https://hdevalence.ca/blog/2020-10-04-its-25519am
< sipa> and it's trivial to make signatures (with private key) that validate in some implementations and not others, with tons of variants
< phantomcircuit> sipa, for most signature scheme use the cost of rejecting a signature that would be valid elsewhere is typically zero
< phantomcircuit> this is a sort of unique case in which everybody has to actually 100% agree
< phantomcircuit> sipa, do you know ballpark how many signatures are in a typical 'full' block right now?
< sipa> around 6000 txins per block, and i assume only a fraction have more than one signature
< jeremyrubin> #proposedmeetingtopic small announcement on behalf of BGIN
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/9855422e65ca...9ad7cd2887ab
< bitcoin-git> bitcoin/master 3069b56 Amiti Uttarwar: [doc] Improve help for getpeerinfo connection_type field.
< bitcoin-git> bitcoin/master 41dca08 Amiti Uttarwar: [trivial] Extract connection type doc into file where it is used.
< bitcoin-git> bitcoin/master 9ad7cd2 Wladimir J. van der Laan: Merge #20090: [doc] Tiny followups to new getpeerinfo connection type fiel...
< bitcoin-git> [bitcoin] laanwj merged pull request #20090: [doc] Tiny followups to new getpeerinfo connection type field (master...2020-09-getpeerinfo-conn-type-release-notes) https://github.com/bitcoin/bitcoin/pull/20090
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Oct 15 19:00:27 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< provoostenator> hi
< emzy> hi
< hebasto> hi
< jnewbery> hi
< luke-jr> hi
< kanzure> hi
< promag> hi
< wumpus> two proposed topics taproot relay policy / activation on testnet/signet (sipa), Getting BIP 8 logic in before freeze (luke-jr)
< luke-jr> wumpus: there was a third by jeremyrubin O.o
< luke-jr> [18:42:09] <jeremyrubin> #proposedmeetingtopic small announcement on behalf of BGIN
< jonatack> hi
< elichai2> hi
< wumpus> PSA today is the feature freeze for 0.21, it seems we managed to merge all the features on the milestone
< wumpus> luke-jr: strange, didn't see it in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
< luke-jr> wumpus: thought it was tomorrow? :x
< provoostenator> Note that the GUI repo doesn't have a milestone
< MarcoFalke> provoostenator: Right. Is there any feature we missed from the GUI?
< MarcoFalke> bugfixes can go in any time
< luke-jr> [16:22:11] <hebasto> provoostenator: https://github.com/bitcoin-core/gui/pull/96
< wumpus> there are some PRs left of course, but nothing that can be labeled feature imo https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.21.0
< wumpus> provoostenator: good point, didn't look at the gui repo at all
< luke-jr> wumpus: would be nice to get some of BIP 8 in, so there's less backported with activation
< MarcoFalke> We still have 14 days to find and fix all bugs
< luke-jr> but I'll save that for the dedicated topic
< wumpus> luke-jr: well 10-15 is today here https://github.com/bitcoin/bitcoin/issues/18947 , but does it matter, everything tagged as feature was merged
< wumpus> (except for the GUI one apparently, if it's ready for merge it should go in)
< luke-jr> wumpus: doesn't mean much when only a few people can edit tags :/
< wumpus> luke-jr: the idea is that things get proposed for the milestone in meetings, or in the channel at least
< dongcarl> hi
< luke-jr> oh well, BIP 8 isn't strictly feature anyway
< fjahr_> hi
< wumpus> #topic Pending bugfixes for 0.21
< wumpus> any bugfixes that we should get in for the release missing on the milestone?
< jonatack> i'd propose 20120, 20115, 19961, and maybe 19874
< luke-jr> I found #20157, not sure how important it is
< gribble> https://github.com/bitcoin/bitcoin/issues/20157 | Bugfix: chainparams: Add missing (disabled) Taproot deployment for Signet by luke-jr · Pull Request #20157 · bitcoin/bitcoin · GitHub
< sipa> luke-jr: should definitely be fixed before release
< sipa> #20120
< gribble> https://github.com/bitcoin/bitcoin/issues/20120 | net, rpc, test, bugfix: update GetNetworkName, GetNetworksInfo, regression tests by jonatack · Pull Request #20120 · bitcoin/bitcoin · GitHub
< luke-jr> > #20120, #20115, #19961, and maybe #19874
< gribble> https://github.com/bitcoin/bitcoin/issues/20120 | net, rpc, test, bugfix: update GetNetworkName, GetNetworksInfo, regression tests by jonatack · Pull Request #20120 · bitcoin/bitcoin · GitHub
< jonatack> plus the upcoming fix for #19543
< gribble> https://github.com/bitcoin/bitcoin/issues/20115 | cli: -netinfo quick updates/fixups and release note by jonatack · Pull Request #20115 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19961 | doc: tor.md updates by jonatack · Pull Request #19961 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19874 | cli, bugfix: degrade -getinfo gracefully for older servers by jonatack · Pull Request #19874 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19543 | Normalize fee units for RPC ("BTC/kB" and "sat/B) · Issue #19543 · bitcoin/bitcoin · GitHub
< hebasto> #20080 or #19933
< gribble> https://github.com/bitcoin/bitcoin/issues/20080 | Strip any trailing `/` in -datadir path by hebasto · Pull Request #20080 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19933 | wallet: bugfix; if datadir has a trailing / listwalletdir would strip lead char of walletname by Saibato · Pull Request #19933 · bitcoin/bitcoin · GitHub
< luke-jr> oh yes, one of those are important to get in ☺
< wumpus> jonatack: i'm not convinced #19874 is really a bugfix
< gribble> https://github.com/bitcoin/bitcoin/issues/19874 | cli, bugfix: degrade -getinfo gracefully for older servers by jonatack · Pull Request #19874 · bitcoin/bitcoin · GitHub
< luke-jr> afaik -getinfo has never worked with old servers gracefully
< ariard> hi
< jonatack> agree that it's optional. the doc/tor.md is still in draft but will open v soon
< sipa> i think documentation improvements can be done after feature freeze
< MarcoFalke> tests and docs can go in any time
< jonatack> sipa: agree, i held off on those to get the features in
< provoostenator> #18788 would be good tests to add
< gribble> https://github.com/bitcoin/bitcoin/issues/18788 | tests: Update more tests to work with descriptor wallets by achow101 · Pull Request #18788 · bitcoin/bitcoin · GitHub
< wumpus> 19543 was already tagged
< luke-jr> oh, did achow101 want to make descriptor wallets tied to sqlite? where does that stand?
< luke-jr> #20156 is IMO a bugfix
< gribble> https://github.com/bitcoin/bitcoin/issues/20156 | Make sqlite support optional (compile-time) by luke-jr · Pull Request #20156 · bitcoin/bitcoin · GitHub
< provoostenator> luke-jr: that's already merged
< wumpus> yes, that was his plan, to make it clearer that those are two different wallet formats
< meshcollider> Please can we decide which of 19933 and 20080 we want to keep and which one to close?
< luke-jr> provoostenator: tying the two together is?
< wumpus> luke-jr: i think 'return a null in a field' is graceful enough, it just shouldn't crash
< MarcoFalke> I like #20080
< gribble> https://github.com/bitcoin/bitcoin/issues/20080 | Strip any trailing `/` in -datadir path by hebasto · Pull Request #20080 · bitcoin/bitcoin · GitHub
< provoostenator> luke-jr: descriptor == sqlite for new wallet yes
< provoostenator> see my comment as well
< promag> +1 #20080
< gribble> https://github.com/bitcoin/bitcoin/issues/20080 | Strip any trailing `/` in -datadir path by hebasto · Pull Request #20080 · bitcoin/bitcoin · GitHub
< provoostenator> Unless achow101 changed his mind about that, but I think that was the point of getting it in before release
< wumpus> 20080 was already tagged right
< MarcoFalke> I promise to test 20080 soon
< wumpus> please don't repeat things
< luke-jr> wumpus: 'return a null in a field' ?
< wumpus> I'm having a lot of trouble keeping track of PRs mentioned here to add them to the milestone
< luke-jr> oh, for -getinfo; sure; or just an error even
< wumpus> luke-jr: yes
< meshcollider> Alright 20080 it is, I'll close 19933
< wumpus> meshcollider: yes makes sense
< wumpus> I think I've tagged everything mentioned, if not, please let me know
< promag> wumpus: maybe #20125
< gribble> https://github.com/bitcoin/bitcoin/issues/20125 | rpc, wallet: Expose database format in getwalletinfo by promag · Pull Request #20125 · bitcoin/bitcoin · GitHub
< luke-jr> 20080 should get 0.19.x and 0.20.x tags too I think
< wumpus> promag: sounds like a feature to me
< MarcoFalke> luke-jr: It already has
< wumpus> (though maybe a necessary one, I don't' know)
< luke-jr> o
< bitcoin-git> [bitcoin] meshcollider closed pull request #19933: wallet: bugfix; if datadir has a trailing '/' listwalletdir would strip lead char of walletname (master...wallet-fix-missing-chars-boost-1.47) https://github.com/bitcoin/bitcoin/pull/19933
< jonatack> agree with promag about 20125
< wumpus> luke-jr: let's discuss the 0.21 milestone now not other ones
< wumpus> ok adding 20125...
< promag> wumpus: not really... just adds "format" key to the rpc response
< wumpus> well it's not a bugfix at least
< wumpus> but I don't care it seems minimal enough
< promag> wumpus: right
< wumpus> that concludes the topic I guess
< luke-jr> I'm not sure it makes sense to expose that detail, but meh
< wumpus> #topic taproot relay policy / activation on testnet/signet (sipa)
< sipa> hi
< wumpus> luke-jr: especially if it's linked to descriptor wallets it seems a bit redundant, but yeah...
< promag> luke-jr: could still be rejected ;)
< sipa> there are a few aspects here
< wumpus> if it's useful for troubleshooting/diagnosis it should be in
< sipa> one is relay of v1 transaction outputs; bitcoin core will do that since #15846
< gribble> https://github.com/bitcoin/bitcoin/issues/15846 | [POLICY] Make sending to future native witness outputs standard by sipa · Pull Request #15846 · bitcoin/bitcoin · GitHub
< sipa> but since the merge of #19953, we'll also relay spends of (valid) taproot outputs
< gribble> https://github.com/bitcoin/bitcoin/issues/19953 | Implement BIP 340-342 validation (Schnorr/taproot/tapscript) by sipa · Pull Request #19953 · bitcoin/bitcoin · GitHub
< sipa> i think that's undesirable, at least until activation is defined, or even until actually activated
< * luke-jr> did suggest splitting that out of the PR a few months ago :P
< sipa> luke-jr: well, we do want it on regtest
< luke-jr> regtest supports acceptnonstdtxn, but ok
< sipa> talking to sdaftuar a bit, i think we should just reject creation and spending of v1 outputs until taproot is _active_
< sipa> as a policy rule (not through script validation, which is more invasive)
< sipa> or at least creation as soon as an activation is defined
< sipa> (so that the behavior on mainnet before an activation is defined is essentially as if it didn't exist at all)
< sipa> i can open a PR/issue and discuss further there
< sipa> but i wanted to bring this up, as it may be unexpected that master is now doing taproot validation on the mempool
< wumpus> I think that makes sense, to do that as a policy rule
< MarcoFalke> so the spends would be valid taproot spends (with witness) only?
< sipa> so right now: all v1 creation is relayed, v1 spends are relayed only if valid according to taproot rules
< ariard> is there any disadvantage of doing this?
< sipa> my proposal: v1 creation is not relayed while taproot activation is defined but not yet active; v1 spending is only relayed after being actually active
< provoostenator> Why not always relay?
< MarcoFalke> provoostenator: Someone will give away their coins, surely
< provoostenator> Doesn't seem ideal to have a bunch of nodes out there not relaying v1 transactions.
< sipa> provoostenator: they'd all start relaying as soon as activation happens
< sipa> before that point, we don't care
< ariard> sipa: so you want to hardcode the loosening policy change based on the consensus activation IIRC ?
< luke-jr> well, activation isn't in 0.21.0, so not these
< sipa> luke-jr: indeed, the only effect on 0.21.0 would be making spending of v1 non relayed
< jnewbery> sipa: what's the difference between 'not relayed while taproot activation is defined but not yet active' and 'only relayed after being actually active'
< provoostenator> Did we relay v1 to/from transactions before taproot was merged?
< sipa> jnewbery: creation would be relayed as long as no activation parameters are set (the idea being that without activation parameters, it should be treated as an unknown future upgrade that can still change)
< aj> jnewbery: 0.21.0 will be not-defined and not-active, so will always relay creation of taproot outputs, but not spends of them
< sipa> maybe this is a simpler principle: before activation is _defined_, behavior should be identical to before taproot was merged
< aj> sipa: i'm not sure it makes much sense to make it harder to spend a taproot output than to create one? creating one before activation is how you lose money?
< jeremyrubin> aj: i thought we checked outputs standardness?
< jnewbery> sipa aj: thanks
< aj> jeremyrubin: 15846
< luke-jr> aj: the spend we make harder, may be a theft
< luke-jr> you can't steal if you can't spend
< jeremyrubin> #15846
< gribble> https://github.com/bitcoin/bitcoin/issues/15846 | [POLICY] Make sending to future native witness outputs standard by sipa · Pull Request #15846 · bitcoin/bitcoin · GitHub
< aj> luke-jr: prior to activation miners can spend trivially
< luke-jr> aj: miners don't rely on others' policy
< sipa> aj: my suggestion is that relay of creation and spending only differs before activation is defined... to match pre-taproot-implemented behavior
< sipa> after activation is defined, both are disallowed until it is actually active
< luke-jr> (OT: wumpus: #19502 should probably get milestoned)
< gribble> https://github.com/bitcoin/bitcoin/issues/19502 | Bugfix: Wallet: Soft-fail exceptions within ListWalletDir file checks by luke-jr · Pull Request #19502 · bitcoin/bitcoin · GitHub
< sipa> aj: which is ultimately due to softfork safeness... if we treat taproot as subject to change still (which i think we should until activation is defined), we shouldn't permit spending it to be relayed
< wumpus> luke-jr: ok
< jeremyrubin> has that been reverted though somehow?
< sipa> jeremyrubin: what?
< jeremyrubin> looking at the current code and I'm not seeing that logic still
< aj> sipa: right, immediately after activation (supported by 0.21.1 say), you have all nodes relaying creation, but only 0.21.1 nodes relaying spends. vs having 0.21.0 and 0.21.1 nodes validating and relaying spends if we leave things as they are now
< jeremyrubin> Ah
< jeremyrubin> it went into Solver
< sipa> aj: i think permitting spends right now is bad... it's just gratuitous policy difference between 0.21 and pre-0.21 nodes
< sipa> the extra rule for suspending relay of outputs is user protection before activation
< sipa> anyway, will open an issue
< aj> sipa: the principle (no behaviour change prior to activation) makes sense, just doesn't seem like it has much benefit (people still lose money if they create outputs earlier, because miners will claim them via a non-std tx) and slight costs (will make relay slightly harder due to implementation-but-no-activation nodes not relaying)
< wumpus> 20 minutes left, we might want to move to the next topic
< sipa> aj: if their own node rejects relay, miners will never see the tx :)
< luke-jr> sipa: no reason their own node would :P
< wumpus> #topic Getting BIP 8 logic in before freeze (luke-jr)
< luke-jr> I've implemented the current BIP 8 as logic only (no activations) in #19573. This is probably not the final BIP 8 (aj's been working on some revisions), but having it merged in 0.21 means we can have a smaller diff to add Taproot activation later.
< gribble> https://github.com/bitcoin/bitcoin/issues/19573 | Replace unused BIP 9 logic with draft BIP 8 by luke-jr · Pull Request #19573 · bitcoin/bitcoin · GitHub
< luke-jr> Would be nice to get this merged before 0.21.0rc1 if possible. Anyone who wants to help review (or other) can join ##taproot-activation to help get this done quickly.
< luke-jr> Note the PR depends on #19401 and #20157. These are fairly trivial, and the former already has 2 ACKs.
< gribble> https://github.com/bitcoin/bitcoin/issues/19401 | QA: Use GBT to get block versions correct by luke-jr · Pull Request #19401 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/20157 | Bugfix: chainparams: Add missing (disabled) Taproot deployment for Signet by luke-jr · Pull Request #20157 · bitcoin/bitcoin · GitHub
< wumpus> i don't know, it does feel a bit rushed to me, to merge something (that should be a no-op otherwise) last minute just to minimize the diff later, especially when we don't even know yet if it's the final state of the BIP
< wumpus> not a small project either
< luke-jr> hmm, true
< sipa> no strong opinion... it doesn't seem very invasive, but on the other hand, this can also easily be backported along with actual activation parameters
< sipa> it also may turn out to be wasted effort
< luke-jr> not sure how it could be wasted effort
< luke-jr> sipa: your topic, you had mentioned signet/testnet activation - that might or might not be a reason to do this sooner
< jeremyrubin> i think it makes sense to wait for cleaner git history
< luke-jr> jeremyrubin: I'm assuming the two trivial PRs would be merged first as part of this process
< sipa> oh right, i didn't bring that up... do we want to define an activation on testnet?
< sipa> that's something that was done historically, but with signet i think there may be less need now
< luke-jr> I think it makes sense to test BIP 8 with testnet
< wumpus> it should activate there at some time i guess
< sipa> always possible in .1 or whatever point release too, of course
< aj> probably shouldn't activate on testnet with a different activation method than we plan on using for mainnet?
< luke-jr> sipa: true
< luke-jr> maybe that's a good solution: testnet in .1, and mainnet not until .2
< sipa> it'd be nice to see things active on signet first before suggesting testnet changes
< wumpus> sipa: right
< aj> kallewoof's not awake, but i was thinking maybe lock taproot as it stands in immediately on the default signet, and if worst comes to worst just restart the signet chain if needed
< sipa> (as in signet it can be rolled out without code changes...)
< wumpus> that's great
< luke-jr> signet doesn't even need an activation, does it?
< luke-jr> just always-active?
< MarcoFalke> wait, if spends are made non-standard, it needs conde changes for signet
< aj> sipa: (not-relaying taproot-txs if activation hasn't happened will affect the "without code changes" part a bit
< aj> luke-jr: yeah, that's what i'm thinking
< aj> luke-jr: (i mean, "always-active" is an activation)
< luke-jr> the policy changes sipa suggested are conditional on the deployment state AFAIK?
< MarcoFalke> so I guess s/without/minimal/
< aj> luke-jr: right, but *nodes* have to know the deployment state in that case, not just miners
< luke-jr> so always-active would trigger the spending policy
< sipa> i think we can flesh these things out the next few days
< aj> yep
< luke-jr> yeah, let's give jeremyrubin some minutes ☺
< jeremyrubin> i need like 1 min
< jeremyrubin> so no rush
< wumpus> #topic Small announcement on behalf of BGIN (jeremyrubin)
< jeremyrubin> Matsuo has asked me to share the following
< jeremyrubin> FYI bgin-global.org is hosting an event for core devs the first week of Nov, please fill out this form https://forms.gle/99yUnQdtAkAwt5SW7 to assist scheduling or email schwentker@bsafe.network with any questions. Goal of the event is to help core dev sustainability, so should be of interest for all here.
< luke-jr> during a pandemic? O.o
< achow101> Who's bgin?
< jeremyrubin> it's a virtual event
< luke-jr> i c
< luke-jr> "Blockchain Governance Initiative Network "
< jeremyrubin> BGIN is "Blockchain Governance Initiative Network (BGIN)"
< jeremyrubin> I'd ignore the acronym tho
< luke-jr> so this is like NY agreement in organization form? :x
< jeremyrubin> no
< aj> there's also coinbase looking to support bitcoin dev projects as of an hour or so ago https://twitter.com/coinbase/status/1316801517983334401
< jeremyrubin> it's the sort of name that you have to have to get intl participation from people in intl financial regulation
< luke-jr> jeremyrubin: lol
< jeremyrubin> so it's started by Matsuo and others
< jeremyrubin> the point being that a lot of various regulators want to chat about how Bitcoin works and how they engage, but also understanding how standards emerge
< jeremyrubin> But a part of that is they want to understand and potentiall support development through research grants
< wumpus> that sounds pretty scary tbh
< jeremyrubin> so it's maybe folk you'd rather not talk to at all depending on your preferences, but it is a good faith effort afaict
< jeremyrubin> :shrug:
< jeremyrubin> I'd encourage you to email concerns to schwentker@bsafe.network
< luke-jr> jeremyrubin: it sounds like they're just giving webinars and we'd simply watch it? O.o
< jeremyrubin> no i don't think so
< jeremyrubin> I think they want to hear from you directly
< MarcoFalke> end meeting?
< wumpus> ok, I think everything is said, thanks for the announcement
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Oct 15 20:00:46 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< luke-jr> >how they engage
< luke-jr> "don't
< luke-jr> jk, maybe should tell them to get rid of the travel rule tho ;)
< jeremyrubin> I mean, there are practical things that are relatively improtant to engage them on
< jeremyrubin> E.g., travel rule
< luke-jr> jeremyrubin: yeah, joking
< jeremyrubin> do you owe taxes on BCash
< luke-jr> not anymore
< emzy> jeremyrubin: I also find it strange. But can I as a none dev also join?
< jeremyrubin> If you had a contract denom in Bitcoin do you owe BCash and Bitcoin after a fork?
< luke-jr> emzy: who is to say you're not a dev? ;)
< achow101> luke-jr: re: sqlite and descriptors. The intention for the foreseeable future is sqlite == descriptors and descriptors == sqlite. So adjust #20156 accordingly
< gribble> https://github.com/bitcoin/bitcoin/issues/20156 | Make sqlite support optional (compile-time) by luke-jr · Pull Request #20156 · bitcoin/bitcoin · GitHub
< emzy> luke-jr: me :)
< luke-jr> achow101: what needs adjustment?
< sipa> achow101: no way to convert legacy bdb wallets to legacy sqlite ones?
< jeremyrubin> Anyways, i don't think there is malintnet but up to you to give benefit of the doubt or express concerns to them directly
< jeremyrubin> i am a mere herald
< aj> "legacy sqlite" wow, already :)
< luke-jr> wumpus: 20156 missed milestoning
< luke-jr> aj: lol
< sipa> aj: legacy meaning non-descriptor
< jeremyrubin> emzy: I think you'd be fine to join, just fill out the form
< achow101> luke-jr: to enforce that descriptor wallets can't be made of sqlite is disabled. Dunno of you already did that, still going through my email backlog
< aj> sipa: yeah :)
< emzy> jeremyrubin: I did. At least I can tell you here what happend :)
< luke-jr> achow101: I didn't remove any code enforcing it, at least
< achow101> sipa: maybe dump them createfromdump, but I'm not intending on making a migration for it
< jeremyrubin> emzy: wat?
< emzy> jeremyrubin: I submitted the form.
< sipa> achow101: well the question is if the format should be supported i think, regardless of how someone can create it
< luke-jr> error = Untranslated(strprintf("Failed to load database path '%s'. Data is not in required format.", path.string()));
< luke-jr> I guess that error could be clearer
< luke-jr> or maybe just remove descriptor support entirely
< sipa> it's ok to say non-descriptor-sqlite wallets are unsupported
< jonatack> achow101: right, the main reason for adding a db format field to getwalletinfo or -getinfo is because a bdb wallet can be descriptor
< sipa> if we don't test that
< sipa> but whatever combinations are supported should be tested
< wumpus> i'm all for not supporting too many combinations
< sipa> and those that aren't should at least get a warning
< wumpus> be careful here, anything you support for the wallet needs to be support for pretty much near forever
< sipa> (or otherwise be impossible to create)
< achow101> luke-jr: I'll have a look when I get home, but I was intending on writing a full without-bdb and without-sqlite thing that disabled legacy or descriptors respectively
< wumpus> as those files will be around for a long time
< wumpus> it's also confusing for users
< wumpus> two types of wallet is enough, avoid the combinatorial cmplexity
< sipa> yeah
< sipa> that's fair
< achow101> jonatack: I think that's useful for experts who do unsupported things, but for most users, the format should be tied to the type
< jeremyrubin> 2**256 wallets for added security
< bitcoin-git> [bitcoin] dongcarl closed pull request #20050: validation: Prune (in)direct g_chainman usage related to ::LookupBlockIndex (bundle 1) (master...2020-09-libbitcoinruntime-v4) https://github.com/bitcoin/bitcoin/pull/20050
< wumpus> heh
< achow101> sipa: I think it will be supported but not recommended, aka you had to jump through a lot of hoops to get to legacy sqlite
< sipa> yeah, ok
< luke-jr> i can use sqlite wit uncompressed pubkeys?
< luke-jr> :P
< achow101> sure
< achow101> Descriptora can have uncompressed keys
< luke-jr> :o
< luke-jr> I meant the old wallet format tho
< luke-jr> we should probably drop support for that.. it isn't actually compatible post-segwit anyway :x
< sipa> you mean sqlite non-descriptor with uncompressed keys?
< achow101> Yeah but you and Matt will complain about it
< luke-jr> lol
< luke-jr> Qt should stop using camelcase so I don't need to guess at if they did ToolTip or Tooltip
< achow101> Is actually toolTip
< luke-jr> )(%#&)#_)#
< luke-jr> (I'm actually calling SetToolTip, so it's okay)
< promag> descriptors:true wallet doesn't mean it's sqlite right?
< promag> only true starting with 0.21, at least that's my understanding
< achow101> yes
< promag> that's why I'm suggesting "format" in getwalletinfo response
< promag> nit, and maybe in the gui we could have some thing/icon/whatever for these things - like getwalletinfo
< luke-jr> promag: descriptors:true will mean sqlite in all supported configurations AIUI
< promag> luke-jr: you can still open a 0.20 descriptors wallet?
< luke-jr> promag: 0.20 doesn't support descriptors
< luke-jr> I don't think..
< promag> <.<
< promag> luke-jr: you are right
< promag> #16528
< gribble> https://github.com/bitcoin/bitcoin/issues/16528 | Native Descriptor Wallets using DescriptorScriptPubKeyMan by achow101 · Pull Request #16528 · bitcoin/bitcoin · GitHub
< promag> 0.20 has some descriptors stuff, but not the option to create descriptors wallet
< achow101> Irs only helpful for people who have descriptor wallets on old master
< promag> right
< * luke-jr> likes git-worktree
< promag> on the long run the plan is to enforce descriptors?
< promag> and as a consequence it will be sqlite?
< achow101> Yes
< promag> or we will also support non descriptor wallets in sqlite?
< achow101> It will be supported as in if you somehow make one, we won't explode
< luke-jr> will we explode on promag's bdb descriptor wallet? ;)
< achow101> But actually making one is going to be non trivial
< achow101> Same for bdb descriptor wallets
< achow101> luke-jr: I've been running the sqlite branch with 3 of the 4 combinations of format and type without any issue
< achow101> For the past 3 months or so
< promag> "non trivial" why?
< achow101> Only one I haven't run is legacy sqlite
< achow101> promag: to avoid combinatorial complexity in the migration code
< achow101> I'll open an issue that lays out the full plan and a timeline
< aj> luke-jr: git-worktree is the best. shame paths end up hardcoded so ccache stuff isn't shared across them though
< luke-jr> aj: wait, what? ccache doesn't care about paths, does it?
< sipa> your ccache cache is shared i think?
< sipa> it's in $HOME/.ccache
< luke-jr> hmm, I thought I configured my ccache to be on tmpfs tho
< luke-jr> ah yes cache directory /var/tmp/ccache-dev
< sipa> ah, or wherever you configure it to be
< aj> luke-jr: ccache doesn't directly, but the path ends up going into the preprocessed source somewhere or something which makes ccache's input different each time... not sure how though now that i look
< aj> oh, i'm wrong, ccache has a `hash_dir` flag that makes it hash the working dir, and it's -g that puts the working dir in the .o files
< sipa> still, worktrees are very useful
< sipa> i have separate ones for fuzzer builds (so i don't need to re-run ./configure with the fuzzer flags all the time)
< sipa> and sanitizer builds
< sipa> you can't checkout the same branch in two worktrees simultaneously, but you can use git checkout --detach in one to just switch to code of a branch in another
< luke-jr> aj: it being in the .o should be okay?
< luke-jr> sipa: you can checkout the same branch if you really want to :D
< sipa> luke-jr: how so?
< sipa> is there some --use-the-force option?
< luke-jr> IIRC
< luke-jr> --force
< sipa> if anyone gets this warning with gcc 9, it's a compiler bug (which just produces a bogus warning):
< sipa> src/ecmult_impl.h:496:48: warning: array subscript [1, 268435456] is outside array bounds of ‘struct secp256k1_strauss_point_state[1]’ [-Warray-bounds] 496 | secp256k1_gej tmp = a[state->ps[np].input_pos];
< bitcoin-git> [bitcoin] theStack opened pull request #20159: test: mining_getblocktemplate_longpoll.py improvements (use MiniWallet, add logging) (master...20201015-test-improve-mining_getblocktemplate_longpoll) https://github.com/bitcoin/bitcoin/pull/20159
< luke-jr> btw, why do we use "org.bitcoinfoundation.Bitcoin-Qt" on macOS?
< jb55> awkward
< phantomcircuit> luke-jr, iirc wasn't gavin the one signing the macos builds?
< phantomcircuit> probably just legacy from that
< sipa> i think changing it was brought up before, but would break compatibility with existing settings so wasn't done?
< sipa> (it's awkward that it was ever set to that - even when the foundation was actively sponsoring developers - but little that can be done about that now)
< luke-jr> sipa: it doesn't look like it would from the context :/
< sipa> there is some discussion about it in #17462
< gribble> https://github.com/bitcoin/bitcoin/issues/17462 | build: macOS fix Info.plist by RandyMcMillan · Pull Request #17462 · bitcoin/bitcoin · GitHub
< promag> achow101: is there anything preventing swaping CWallet::database in runtime? so 1) load with bdb 2) swap database 3) write all ?
< promag> *swap to sqlite
< achow101> promag: you might end up missing a few records
< achow101> I'd definitely wouldn't recommend doing that
< promag> not all records are loaded ok
< achow101> promag: all records are loaded, it's just a matter of making sure that "write all" wrote them all
< achow101> there's no existing "write all"
< promag> oh ok
< luke-jr> all records might not be loaded
< luke-jr> IIRC moves don't
< achow101> there are some records that aren't loaded because they aren't useful, just kept around for back compat. obviously back compat doesn't matter if you move to sqlite
< phantomcircuit> sipa, iirc the foundation was paying for the certificate, something about it being easier for a "foundation" to get one than for an individual
< luke-jr> achow101: uh, pretty sure we still show them
< phantomcircuit> who knows if that was true or if it was pretextual though..
< achow101> luke-jr: no? I mean things like "default key" or the original "version"
< achow101> (version is now "minversion")
< promag> don't see a reason to remove load-bdb, that way the user could just send the funds to new wallet and we wouldn't have to do the migration tool
< achow101> The surefire way to migrate format is to grab a cursor on the original db, iterate it, and write every key/value pair in the new db
< luke-jr> achow101: well, I don't think moves get loaded either
< achow101> luke-jr: moves as in the old move rpc?
< luke-jr> yes
< achow101> I thought those records just got renamed and redefined for labels
< luke-jr> what?
< promag> bdb2sqlite.py incoming
< achow101> but also, that's for back compat, and if you are going to sqlite, back compat doesn't matter
< luke-jr> achow101: I would be annoyed if migrating my wallet lost data
< luke-jr> {"account": "a", "category": "move", "time": 1296345052, "amount": 0.00100000, "otheraccount": "b", "comment": ""},
< luke-jr> this shouldn't disappear from listtransactions just because I upgrade
< achow101> luke-jr: right, which is also why I prefer the straight record-to-record migration rather than what is loaded in CWallet
< bitcoin-git> [bitcoin] sipa opened pull request #20161: Minor Taproot follow-ups (master...202010_taproot_followup) https://github.com/bitcoin/bitcoin/pull/20161
< bitcoin-git> [bitcoin] jonatack opened pull request #20162: p2p, compiler warnings: specify Announcement::m_state bitfield to be 8 bits (master...bitfield-too-small-warning) https://github.com/bitcoin/bitcoin/pull/20162
< fanquake> Yea I’m fairly certain we can’t change that MacOS string without breaking something