< fanquake> wumpus could you swap the default branch for the bitcoin-core/leveldb repo from "bitcoin-fork" to "bitcoin-fork-new" ?
< sipa> or create a new bitcoin-fork-old branch, and swap with it
< luke-jr> sipa: if it's not a fast-forward, it may make git complain when pulling
< bitcoin-git> [bitcoin] gitwdel opened pull request #18381: Create ccpp.yml (master...master) https://github.com/bitcoin/bitcoin/pull/18381
< bitcoin-git> [bitcoin] fanquake closed pull request #18381: Create ccpp.yml (master...master) https://github.com/bitcoin/bitcoin/pull/18381
< mryandao> -
< sipa> +
< luke-jr> %
< kallewoof> ※
< fanquake> That's a bit fancy
< luke-jr> does C++20 allow unicode operators?
< sipa> like?
< sipa> c++ doesn't allow defining your own operators (outside of a fixed set), so i don't think that's a relevant question?
< luke-jr> like when will the fixed set include operator× ?
< luke-jr> or operator≤
< luke-jr> ≤ might just get inferred perhaps
< luke-jr> but more useful is ≤ working with int etc
< sipa> c++20 already added the <=> operator
< sipa> that's already a once in a decade event probably
< luke-jr> hardly an example of Unicdoe :p
< sipa> < = and > are all valid Unicode characters :D
< hadjiszs> you can do this kind of stuff https://github.com/klmr/named-operator
< hadjiszs> seems to work even with emoji name then :p
< hadjiszs> last time I tried emoji unicode, only icpc was ok to compile though
< wumpus> fanquake: sounds good to me
< wumpus> renaming the branch would be somewhat more elegant but would also give all kinds of weird conflicts for people doing 'git pull' next time, don't know what's best here I'll just change the default branch for now
< wumpus> haskell can also do unicode operators, that said it's not great for typing
< wumpus> I mean having to define weird key sequences or ctrl-shift-U XXXX all the time
< wumpus> a possibly preferable approach that some editors have is that they can *show* certain sequences of characters as a more compact unicode character, e.g. <= as ≤, vim can do this using conceal, for example
< vasild> Allowing custom unicode operators would bring the obsuscated c code contest https://www.ioccc.org/ to a whole new level!
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/a421e0a22f12...67de1ee8bc18
< bitcoin-git> bitcoin/master a3ad645 Pieter Wuille: Simplify bn2vch using int.to_bytes
< bitcoin-git> bitcoin/master a733ad5 Pieter Wuille: Add bn2vch test to functional tests
< bitcoin-git> bitcoin/master 67de1ee Wladimir J. van der Laan: Merge #18378: Bugfix & simplify bn2vch using int.to_bytes
< bitcoin-git> [bitcoin] laanwj merged pull request #18378: Bugfix & simplify bn2vch using int.to_bytes (master...202003_simple_bn2vch) https://github.com/bitcoin/bitcoin/pull/18378
< elichai2> `unknown location(0): fatal error: in "arith_uint256_tests/basics": std::runtime_error: locale::facet::_S_create_c_locale name not valid` what's going on?
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #16995: Fix gcc 9 warnings (master...2019_09_resolve_gcc_warnings) https://github.com/bitcoin/bitcoin/pull/16995
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #16995: Fix gcc 9 warnings (master...2019_09_resolve_gcc_warnings) https://github.com/bitcoin/bitcoin/pull/16995
< elichai2> I guess it's locale again :/ need better error
< MarcoFalke> elichai2: you need to export an utf8 or C LC_ALL
< elichai2> yeah and it seems to be failing really really early, so I think i'll give up on adding some meaningful error
< MarcoFalke> export LC_ALL=C.UTF-8
< MarcoFalke> or
< MarcoFalke> export LC_ALL=C
< MarcoFalke> should fix it
< elichai2> yeah it did. thanks. was just trying to figure out if I can find the source and get it to print a meaningful error
< bitcoin-git> [bitcoin] vasild opened pull request #18382: doc: note the costs of fetching all pull requests (master...note_fetch_all_cost) https://github.com/bitcoin/bitcoin/pull/18382
< fanquake> elichai2: looks the same as #17379
< gribble> https://github.com/bitcoin/bitcoin/issues/17379 | Segfault running master on NetBSD · Issue #17379 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] elichai opened pull request #18383: Check for overflow when calculating sum of outputs in a transaction (master...2020-03-value-overflow) https://github.com/bitcoin/bitcoin/pull/18383
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/67de1ee8bc18...3d3d834324f3
< bitcoin-git> bitcoin/master e90e3e6 fanquake: build: fix sysctl() detection on macOS
< bitcoin-git> bitcoin/master 3d3d834 Wladimir J. van der Laan: Merge #18359: build: fix sysctl() detection on macOS
< bitcoin-git> [bitcoin] laanwj merged pull request #18359: build: fix sysctl() detection on macOS (master...macos_sysctl) https://github.com/bitcoin/bitcoin/pull/18359
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3d3d834324f3...527c3989e746
< bitcoin-git> bitcoin/master 84a46a9 emu: doc: mention MAKE=gmake workaround when building on a BSD
< bitcoin-git> bitcoin/master 527c398 Wladimir J. van der Laan: Merge #18340: doc: mention MAKE=gmake workaround when building on a BSD
< bitcoin-git> [bitcoin] laanwj merged pull request #18340: doc: mention MAKE=gmake workaround when building on a BSD (master...fixup_18129) https://github.com/bitcoin/bitcoin/pull/18340
< MarcoFalke> #proposedmeetingtopic PGP is dead
< vasild> elichai2: MarcoFalke: what overflow are we talking about in #18383? If it is an overflow of int64_t (= CAmount), then it is not possible because both numbers are checked by MoneyRange() for being less than 21M (MAX_MONEY). If it is an overflow of MAX_MONEY, then it is possible, but then shouldn't the patch use MAX_MONEY instead of std::numeric_limits<CAmount>?
< gribble> https://github.com/bitcoin/bitcoin/issues/18383 | Check for overflow when calculating sum of outputs in a transaction by elichai · Pull Request #18383 · bitcoin/bitcoin · GitHub
< MarcoFalke> vasild: It is an overflow in a result that is never read when it overflows
< MarcoFalke> The only way you can trigger this is by enabling sanitizers
< MarcoFalke> Compilers are smart these days, so without sanizitzers enabled, it probably will be optimized out/reorderd and thus won't overflow
< vasild> Ah, now I see!
< sipa> MarcoFalke: || short circuits; the right half is not evaluated if the first half is true
< sipa> so i don't understand how this can trigger
< sipa> it has nothing to do with reordering; any optimization a compiler performs must be indistinguishable from the correct semantics
< MarcoFalke> sipa: nValueOut += tx_out.nValue; is always executed
< MarcoFalke> it is not under a condition
< sipa> oh!
< sipa> i was misreading
< sipa> thanks
< vasild> kallewoof: btw, what happens if we receive some out-of-order blocks, store them in blk files, flush finalize etc and later we receive alternative blocks for those heights with higher POW, so the new guys get connected. Do we leave the first ones on disk forever, orphaned?
< kallewoof> vasild: i believe the new blocks will go into the newer block files. when connected, the undo data for THOSE will go into the corresponding rev files like normal
< kallewoof> i could be wrong though. definitely worth looking into, but nowadays, reorgs are rare :)
< vasild> yes, I am wondering if we ever clean up the old ones
< kallewoof> old block or old rev?
< kallewoof> either way, i don't really know, myself. others may be able to answer though.. (sipa?)
< sipa> we clean up the old ones only when pruning
< sipa> in which case entire files are deleted
< vasild> actually POW is not relevant here. For example: we receive block 5, write it to disk, then we receive block 7, write it to disk (it refers an imaginary parent block 6). Then we receive block 6' and decide to connect it to block 5, so block 7 is useless.
< sipa> correct
< vasild> sipa: I see, so we will not go to clean up block 7 "in place" inside the blk / rev files or something crazy like that which would complicate stuff even more
< sipa> indeed
< sipa> note that 7 would only be downloaded if we at least had a valid header for its parent
< vasild> ah, that answers my question before I asked it - could somebody feed us a huge pile of useless blocks to fill up our disk ;)
< vasild> Thanks!
< sipa> you can ask the same question about headers, though
< vasild> could somebody feed us a huge pile of useless headers to fill up our disk?
< sipa> and the answer for that is the old checkpoint we have, making crearing fake headers pretty expensive as they have to branch off after the last checkpoint
< sipa> actually, let me check, there may be more protections now
< vasild> if we check that the ids of the blocks from the headers match the expected difficulty, then creating one useless header would require the same amount of work as mining a legit block. So not worth doing in order to fill somebody's disk. Right?
< bitcoin-git> [bitcoin] laanwj pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/527c3989e746...312d27b11cea
< bitcoin-git> bitcoin/master 1168394 John Newbery: [wallet] Notify conflicted transactions in TransactionRemovedFromMempool
< bitcoin-git> bitcoin/master cdb8934 John Newbery: [validation interface] Remove vtxConflicted from BlockConnected
< bitcoin-git> bitcoin/master 5613f98 John Newbery: [validation] Remove conflictedTxs from PerBlockConnectTrace
< sipa> vasild: right
< bitcoin-git> [bitcoin] laanwj merged pull request #17477: Remove the mempool's NotifyEntryAdded and NotifyEntryRemoved signals (master...2019-11-remove-mempool-signals2) https://github.com/bitcoin/bitcoin/pull/17477
< vasild> Thanks!
< sipa> vasild: full blocks are also only downloaded for header chains that exceed our current best tip's total work
< elichai2> MarcoFalke: but it will return the "over flown" value which the caller can use/read.
< elichai2> In practice I think all callers check other stuff before calling this. I was in the middle of checking it but had to go
< MarcoFalke> no it doesn't return it?!
< elichai2> Oh you're right. It will throw
< bitcoin-git> [bitcoin] gzhao408 closed pull request #18339: wip [test] multiple reject reasons in v0_outputs_not_spendable (master...test_witness_block-multiple-reasons) https://github.com/bitcoin/bitcoin/pull/18339
< bitcoin-git> [bitcoin] gzhao408 opened pull request #18384: [test] more specific feature_segwit test error message (master...segwit-test-errormsg) https://github.com/bitcoin/bitcoin/pull/18384
< ariard> amiti: around? I see for the privacy win in #18038, it's only make it easier for a spying node assuming it connects after initial-broadcast and in between you didn't receive any GETDATA from your honest peers
< gribble> https://github.com/bitcoin/bitcoin/issues/18038 | P2P: Mempool tracks locally submitted transactions to improve wallet privacy by amitiuttarwar · Pull Request #18038 · bitcoin/bitcoin · GitHub
< ariard> (and if your honest peers don't reply between REATTEMPT_BROADCAST_INTERVAL you may have bigger issues, like they're not honest)
< ariard> but still before merge you may need coordination with wtxid-relay
< amiti> 👋
< amiti> you're saying you understand the privacy benefit?
< amiti> agree that I need to better understand / think through the interactions with wtxid-relay. thanks for pointing out
< ariard> yeah, will let a comment on the PR to make it clearer
< amiti> cool!
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Mar 19 19:00:48 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.
< sipa> hi
< emilengler> hi
< jnewbery> hi
< amiti> hi
< aj> hi
< jonatack> hi
< luke-jr> hi
< jkczyz> hi
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
< wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55
< ariard> hi
< hebasto> hi
< wumpus> one proposed topic by MarcoFalke (PGP is dead)
< MarcoFalke> hi
< wumpus> any last minute topics for today?
< achow101> hi
< fjahr> hi
< meshcollider> hi
< wumpus> #topic High priority for review
< MarcoFalke> I'd like to add #18247 :pray:
< gribble> https://github.com/bitcoin/bitcoin/issues/18247 | test: Wait for both veracks in add_p2p_connection by MarcoFalke · Pull Request #18247 · bitcoin/bitcoin · GitHub
< wumpus> 6 blockers, 1` bugfix, 6 chasing concept ACK
< achow101> #16528 for hi prio
< gribble> https://github.com/bitcoin/bitcoin/issues/16528 | Native Descriptor Wallets using DescriptorScriptPubKeyMan by achow101 · Pull Request #16528 · bitcoin/bitcoin · GitHub
< wumpus> MarcoFalke: added
< MarcoFalke> thx
< ariard> both #17737/#17954 are pretty mature, just need few more reviews
< gribble> https://github.com/bitcoin/bitcoin/issues/17737 | Add ChainstateManager, remove BlockManager global by jamesob · Pull Request #17737 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/17954 | wallet: Remove calls to Chain::Lock methods by ryanofsky · Pull Request #17954 · bitcoin/bitcoin · GitHub
< MarcoFalke> Pretty much only bugfixes for 0.20 should be high prio right now (until end of month). Also refactors that are not risky can go in. Other than that, features have to wait
< kanzure> hi
< MarcoFalke> Features can be in high prio, but they can't be merged right now
< ariard> Okay so maybe only #17954, that's a non-risky refacto?
< wumpus> MarcoFalke: yes good point I guess, though on the other hand if people want to review features now that's ok, they just can't be merged until the split-off
< gribble> https://github.com/bitcoin/bitcoin/issues/17954 | wallet: Remove calls to Chain::Lock methods by ryanofsky · Pull Request #17954 · bitcoin/bitcoin · GitHub
< wumpus> right
< wumpus> wait,17954 is already on there?
< MarcoFalke> It used to be on there
< ariard> yes, it's already on high-prio, just raising awareness for reviewers
< aj> yeah, both the ones ariard mentioned are on there?
< wumpus> okay
< wumpus> #topic PGP is dead (MarcoFalke)
< MarcoFalke> So the pgp keyservers that syncronize against each other had a ton of publicly known DOS vectors
< MarcoFalke> Last year they got attacked and to the best of my knowledge they are all disfunctional righ tnow
< MarcoFalke> (Bitcoin Core uses pgp to sign commits and releases)
< wumpus> so we should start hosting our own public keys?
< MarcoFalke> That sounds like a lot of pain
< emilengler> MarcoFalke: Why
< emilengler> Only updating might be hard
< aj> just hosting a static keyring is pretty easy?
< luke-jr> at least one was up a month ago..
< MarcoFalke> The public keys are in constant flux (expiry bump, new sigs, ...)
< MarcoFalke> aj: Doesn't work with expiry
< cfields> anecodatal data: I fetched achow101's keys yesterday with no trouble.
< MarcoFalke> Can you fetch mine?
< MarcoFalke> With the latest expiry dates?
< emilengler> In the docs keyserver.ubuntu.com is provided as the only keyserver that is used AFAIK
< emilengler> Therefore keys should be at least up to date on that keyserver
< wumpus> I could fetch your new expiration date key a while ago, yes
< luke-jr> gpg: key BD02942421F4889F: public key "Luke Dashjr <luke@dashjr.org>" imported
< luke-jr> gpg: key 3648A882F4316B9B: public key "Marco Falke <marco.falke@tum.de>" imported
< achow101> I haven't had any issues pushing to or fetching from keyservers in the past few months
< luke-jr> looks expired, but that just means ou need to update it
< achow101> had to push recently to update my key expriation, and fetch recently for new gitian builder keys
< wumpus> also travis constantly fetches the keys IIRC and that works fine for checking merge commits
< MarcoFalke> wumpus: It doesn't . The check fails
< wumpus> oh, okay
< cfields> MarcoFalke: ok, fair point, seems to not be working today.
< wumpus> did you push your key to the ubuntu server after changing the expiration date?
< sipa> can someone send me the log i missed?
< MarcoFalke> I can't push it anymore
< luke-jr> sipa: see topic?
< MarcoFalke> Has anyone seen this: https://keys.openpgp.org/about/news#2019-06-12-launch
< gribble> https://github.com/bitcoin/bitcoin/issues/2019 | update bitcoinstrings.cpp and bitcoin_en.ts by Diapolo · Pull Request #2019 · bitcoin/bitcoin · GitHub
< MarcoFalke> It seems a response to the DOS attacks
< wumpus> MarcoFalke: that's about openpgp's keyserver, not ubuntu's
< wumpus> sipa: sure min
< MarcoFalke> Their idea is that you need to click a link in your email if you want to add a pgp user-id
< MarcoFalke> So I think they solved the DOS issue
< MarcoFalke> And the backend is written in rust, called hagrid
< MarcoFalke> I could upload my key to them, so I'd suggest to use them as backup server
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #18385: contrib: Add keys.openpgp.org as backup server (master...2003-contribPGPBackupServer) https://github.com/bitcoin/bitcoin/pull/18385
< sipa> thanks
< MarcoFalke> An alternative solution is keybase, but they require an account
< wumpus> MarcoFalke: adding a backup server SGTM
< sipa> MarcoFalke: i'd be very sad if we need to rely on a shitcoin-promoting system like that...
< achow101> MarcoFalke: do they sync with the other keyservers? or does everyone need to upload their keys again
< MarcoFalke> sipa: Me too
< luke-jr> where's the altcoin promotion? :x
< MarcoFalke> achow101: They don't sync, which is the only downside
< cfields> Ideally c-i's would run their own keyservers as caches, similar to debian/ubuntu packages.
< MarcoFalke> achow101: Because of the verify step by email
< luke-jr> MarcoFalke: sounds like a pretty big downside :x
< cfields> ah, it's some handwavy email identity-based-encryption thingy?
< MarcoFalke> luke-jr: At least they are not DOSable
< luke-jr> everything is DOSable
< sipa> apparently the old gpg server code that was used was written in OCaml, with nobody knowing how it worked...
< MarcoFalke> in the same sense that the historic infrastructure was DOSable
< luke-jr> sipa: the annoying bits are the GDPR stuff
< MarcoFalke> The new one seems at least maintained
< luke-jr> which I doubt is actually compliant
< emilengler> why can't we host/mirror the keys at bitcoincore.org
< wumpus> emilengler:too much work to maintain it
< MarcoFalke> emilengler: They need to be updated all the time
< luke-jr> emilengler: what's the gain?
< wumpus> (at least for all the gitian keys; just a keyring with the maintainer keys wouldn't be too bad)
< luke-jr> non-sync bitcoincore.org key hosting isn't much better than non-sync keys.openpgp.org ?
< emilengler> luke-jr: We could directly manage it if it gets down or something
< luke-jr> then just point a DNS record at random third-party servers for now?
< luke-jr> keys.bitcoincore.org CNAME ubuntu domain
< luke-jr> and if that's down for a long while, we can point it elsewhere
< emilengler> that's a cool idea
< wumpus> it could be changed faster than the keyserver in the repository at least (esp all the branches)
< cfields> That shifts control from submitting a pull request to pinging somebody personally...
< cfields> Though I guess a cname could also always be changed with a pull request.
< MarcoFalke> Ideally we wouldn't have to change anything
< achow101> is there any keyserver software that can just sync/cache a whitelist of keys?
< wumpus> ideally yes, maybe it's a temporary problem and we can get the ubuntu keyserver to accept pushes again somehow
< wumpus> I understand if they want to protect against DoS but it can't be intentional to not allow updates at all anymore
< wumpus> https://keyserver.ubuntu.com/ also has a form to submit keys through the web interface FWIW
< sipa> and does that interface work?
< MarcoFalke> That failed for me
< MarcoFalke> Would people (or maybe maintainers) object if I upload the keys to keys.openpgp.org as a backup and then request a confirmation email on their behalf?
< wumpus> oh, you trid that too?
< wumpus> no, of course not, though it's annoying that we have to keep changing keyservers, I don't think we've been using the ubuntu one for that long
< MarcoFalke> jup
< luke-jr> fine with me
< cfields> Several folks offered to help out by "running a Hagrid server instance". We very much appreciate the offer, but we will probably never have an "open" federation model like SKS, where everyone can run an instance and become part of a "pool"
< cfields> I don't understand what this is attempting to accomplish.
< MarcoFalke> Yes, I changed to the ubuntu one last March, because the previous was down
< MarcoFalke> cfields: There a no pools anymore, it is just one point/website for the keystorage
< wumpus> if the ubuntu keyserver isn't fixed, we're all going to have this problem when we need to update our key expiration
< MarcoFalke> What's the number for the ubuntu keyserver costumer support?
< wumpus> their statistics still show updated keys https://keyserver.ubuntu.com/pks/lookup?op=stats
< wumpus> oh wait there's a gap from 2020-01-06 to... today
< wumpus> any other topics?
< sipa> short question: are we in feature freeze now?
< fanquake> Yea
< wumpus> yes
< sipa> ok!
< wumpus> this is also marked in #17432 FWIW
< gribble> https://github.com/bitcoin/bitcoin/issues/17432 | Release schedule for 0.20.0 · Issue #17432 · bitcoin/bitcoin · GitHub
< fanquake> Guess we should move the release notes to the wiki soon as well
< wumpus> good idea!
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Mar 19 19:43:57 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< fanquake> wumpus: great
< bitcoin-git> [bitcoin] laanwj opened pull request #18386: doc: Temporary note that release notes should be edited in wiki (master...2020_03_relnot) https://github.com/bitcoin/bitcoin/pull/18386
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/312d27b11cea...5bf45fe2a964
< bitcoin-git> bitcoin/master b492684 Wladimir J. van der Laan: doc: Temporary note that release notes should be edited in wiki
< bitcoin-git> bitcoin/master 5bf45fe MarcoFalke: Merge #18386: doc: Temporary note that release notes should be edited in w...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18386: doc: Temporary note that release notes should be edited in wiki (master...2020_03_relnot) https://github.com/bitcoin/bitcoin/pull/18386
< bitcoin-git> [bitcoin] jnewbery reopened pull request #17562: WIP: Validation: Remove ConnectTrace and PerBlockConnectTrace (master...2019-11-remove-connect-trace) https://github.com/bitcoin/bitcoin/pull/17562
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #17562: WIP: Validation: Remove ConnectTrace and PerBlockConnectTrace (master...2019-11-remove-connect-trace) https://github.com/bitcoin/bitcoin/pull/17562
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #17562: WIP: Validation: Remove ConnectTrace and PerBlockConnectTrace (master...2019-11-remove-connect-trace) https://github.com/bitcoin/bitcoin/pull/17562
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #17562: WIP: Validation: Remove ConnectTrace and PerBlockConnectTrace (master...2019-11-remove-connect-trace) https://github.com/bitcoin/bitcoin/pull/17562
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #17562: WIP: Validation: Remove ConnectTrace and PerBlockConnectTrace (master...2019-11-remove-connect-trace) https://github.com/bitcoin/bitcoin/pull/17562
< bitcoin-git> [bitcoin] hebasto opened pull request #18387: qt: Fix segfault for loading and immediately unloading wallet (master...20200319-fix-modelwallet-segfault) https://github.com/bitcoin/bitcoin/pull/18387
< bitcoin-git> [bitcoin] sipa opened pull request #18388: Make VerifyWitnessProgram use a Span stack (master...202003_span_witstack) https://github.com/bitcoin/bitcoin/pull/18388
< fanquake> wumpus / sipa can you block bee22193
< sipa> fanquake: on it
< sipa> done
< fanquake> sipa: thanks
< sipa> fanquake: entering his spam into google translate gives some disturbind results
< fanquake> Yea I had a quick look
< ysangkok> nickler: are you planning to change the musig API a lot?