< bitcoin-git> [bitcoin] fanquake opened pull request #21159: test: fix sign comparison warning in socket tests (master...sign_compare_sock_tests) https://github.com/bitcoin/bitcoin/pull/21159
< bitcoin-git> [bitcoin] laanwj pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/937dfa839873...8d82eddee640
< bitcoin-git> bitcoin/master a1fccea Fabian Jahr: refactor: Improve encapsulation between MuHash3072 and Num3072
< bitcoin-git> bitcoin/master 2474645 Fabian Jahr: refactor: Separate hash and stats calculation in coinstats
< bitcoin-git> bitcoin/master 0d3b2f6 Fabian Jahr: rpc: Add hash_type MUHASH to gettxoutsetinfo
< bitcoin-git> [bitcoin] laanwj merged pull request #19145: Add hash_type MUHASH for gettxoutsetinfo (master...csi-3-muhash-rpc) https://github.com/bitcoin/bitcoin/pull/19145
< bitcoin-git> [bitcoin] laanwj pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/8d82eddee640...54b66a6e5f26
< bitcoin-git> bitcoin/master 1624e17 fanquake: build: remove duplicate visibility attribute detection
< bitcoin-git> bitcoin/master 7cd0a69 fanquake: build: test for __declspec(dllexport) in configure
< bitcoin-git> bitcoin/master f054a08 fanquake: build: remove AX_GCC_FUNC_ATTRIBUTE test for dllimport
< bitcoin-git> [bitcoin] laanwj merged pull request #19522: build: fix building libconsensus with reduced exports for Darwin targets (master...libconsensus_visibility_clang) https://github.com/bitcoin/bitcoin/pull/19522
< bitcoin-git> [bitcoin] laanwj pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/54b66a6e5f26...9996b1806a18
< bitcoin-git> bitcoin/master 8e55981 fanquake: refactor: replace Boost shared_mutex with std shared_mutex in cuckoocache ...
< bitcoin-git> bitcoin/master 7097add fanquake: refactor: replace Boost shared_mutex with std shared_mutex in sigcache
< bitcoin-git> bitcoin/master 06e1d7d fanquake: build: don't build or use Boost Thread
< bitcoin-git> [bitcoin] laanwj merged pull request #21064: refactor: use std::shared_mutex & remove Boost Thread (master...use_std_shared_mutex) https://github.com/bitcoin/bitcoin/pull/21064
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9996b1806a18...e9c037ba64dd
< bitcoin-git> bitcoin/master fe3e993 Dhruv Mehta: [p2p] No delay in adding fixed seeds if -dnsseed=0 and peers.dat is empty....
< bitcoin-git> bitcoin/master e9c037b Wladimir J. van der Laan: Merge #19884: p2p: No delay in adding fixed seeds if -dnsseed=0 and peers....
< bitcoin-git> [bitcoin] laanwj merged pull request #19884: p2p: No delay in adding fixed seeds if -dnsseed=0 and peers.dat is empty (master...no-delay-fixed-peer-seeds) https://github.com/bitcoin/bitcoin/pull/19884
< ariard> thinking about initial transaction broadcasting, has making our own node "amnesic" already be considered ?
< ariard> by "amnesic" I mean not logging in the mempool, until it's announced back by some peer
< ariard> I think it would be a worry rn when you broadcast chain of unconfirmed txns but with the upcoming package testmempoolaccept you might call sendrawtransaction with the whole chain
< ariard> to assert validity of the parents, but without rebroadcasting them
< ariard> the advantage would be a privacy gain to mask a transaction origin
< wumpus> ariard: have you looked at #21061? i think it's a clever way to hide (re)broadcasts in the noise
< gribble> https://github.com/bitcoin/bitcoin/issues/21061 | [p2p] Introduce node rebroadcast module by amitiuttarwar · Pull Request #21061 · bitcoin/bitcoin · GitHub
< wumpus> instead of specific wallet broadcast we would broadcast anything that seems it should be mined
< ariard> wumpus: ofc already reviewed the old one
< wumpus> okay
< ariard> but I don't think this approach are opposite, you might broadcast a set of transaction
< ariard> but not log it you mempool when someone query it with a getdata
< ariard> *those approaches
< ariard> ah no, that would be a fingerprint compared to the "noise" set of transaction, to not find a owned transaction in the mempool
< wumpus> i still think in practice broadcasting transactions over tor is the best approach
< ariard> yes, making one-shot connection over tor/i2p for transaction broadcast might be a really interesting approach
< wumpus> right—one of the reasons we added -walletbroadcast=0 is to make it possible to do so with an external script (e.g. it was my idea with https://github.com/laanwj/bitcoin-submittx)
< wumpus> this could tunnel the transaction over anything and would even work if bitcoin core doesn't itself use tor/i2p/etc
< aj> ariard: aren't you redescribing dandelion?
< wumpus> of course it could be better automated i never really got around to that
< ariard> wunpus: yeah I'm back working on altnet, but will start with headers-over-dns as a first integration :)
< ariard> aj: hmmmm but I'm thinking with all the refactoring around tx-requester and likely the ones around tx-announcement for erlay if we can't rework a lightweight version of dandelion
< aj> ariard: i think we can totally do that! especially with glozow's tx-package testmempoolaccept stuff
< ariard> because IIRC the blocker for dandelion was mostly an implementation concern about its DoS robustness
< sdaftuar> i think hes describing one hop dandelion which should be easy to do
< ariard> aj: you want to flood "noise" package of transaction to propagate them fast and then fallback on reconciliation for the fluff phase?
< aj> ariard: do stem phase by making a new i2p/tor connection, sending 1-n tx's with a "testmempoolaccept this, then stem it to a neighbour immediately, then fluff/flood it later" semantics, then closing the connection -- seems like it might be workable to me
< aj> ariard: fluff/flood being normal tx propogation
< aj> aha, i think i see what's causing #20725
< gribble> https://github.com/bitcoin/bitcoin/issues/20725 | EstimateMedianVal returns higher fee for higher confTarget · Issue #20725 · bitcoin/bitcoin · GitHub
< * jonasschnelli> completed his first guix build
< jonasschnelli> As for adding guix to bitcoinbuilds.org/CI, I would be worried about the consumed time. I haven't measured the time required for a complete guix build. But during a "mergefull" day, it could easly consume the system entierly?
< jonasschnelli> But there are probably some caching that could be done
< wumpus> agree caching would definitely be necessary to consider that
< wumpus> ariard: good to see that again i almost forgot about the altnet proposal!
< wumpus> (#18988)
< gribble> https://github.com/bitcoin/bitcoin/issues/18988 | RFC: Introducing AltNet, a pluggable framework for alternative transports by ariard · Pull Request #18988 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] jnewbery opened pull request #21160: Net/Net processing: Move tx inventory into net_processing (master...2021-02-tx-in-peer) https://github.com/bitcoin/bitcoin/pull/21160
< bitcoin-git> [bitcoin] ajtowns opened pull request #21161: Fee estimation: don't extend bucket ranges (master...202102-fee-bug-medianval) https://github.com/bitcoin/bitcoin/pull/21161
< bitcoin-git> [bitcoin] jnewbery opened pull request #21162: Net Processing: Move RelayTransaction() into PeerManager (master...2021-02-relay-transactions-peer-manager) https://github.com/bitcoin/bitcoin/pull/21162
< aj> sdaftuar: 21161 above could use your wisdom; i kind of took a hatchet to the code and may have made a mess of things, but hopefully you can make sense of it
< sdaftuar> oh no fee estimation
< sdaftuar> ok i will see what i can figure out
< aj> sdaftuar: hopefully the comments in the PR and issue should make sense at least
< aj> MarcoFalke: i am loving this vendetta against random test failures btw
< MarcoFalke> aj: It's been going on for years now, and I am unsure if there is progress, but at least we are trying, heh
< fanquake> Have to keep development exciting with the occasional “random” failure
< MarcoFalke> Right. Otherwise, how would we know the re-run button is working in the CI GUI?
< aj> MarcoFalke: don't the CI systems themselves fail often enough to keep that button well-oiled?
< MarcoFalke> Cirrus detects if the failure was on the google cloud or in the tests and can re-run itself
< MarcoFalke> jonasschnelli: DrahtBot caches depends and the gnu store and it takes about the same time as the gitian build
< MarcoFalke> (mod whenever the guix manifest changes)
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21163: doc: Guix is shipped in Debian and Ubuntu (master...2102-docGuix) https://github.com/bitcoin/bitcoin/pull/21163
< vasild> jonatack: no update is pushed to #20197, just checking
< gribble> https://github.com/bitcoin/bitcoin/issues/20197 | p2p: improve onion detection in AttemptToEvictConnection() by jonatack · Pull Request #20197 · bitcoin/bitcoin · GitHub
< jonatack> vasild: thanks for checking. i'm thinking of opening an altenative pull that does more (takes a jnewbery feedback to make m_inbound_onion public, does the refactoring we discussed and refactoring to add unit test coverage) and leaving the current pull as-is, for the simpler version
< jonatack> to see which way is preferred
< vasild> ok
< jonatack> as the currently open one is a smaller diff. will update soon (tm)
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21164: test: Use proper mocktime for uptime (master...2102-mockTimeInit) https://github.com/bitcoin/bitcoin/pull/21164
< ariard> ryanofsky: as with #19160 we start to use libmultiprocess for real, should we move the library under bitcoin-core/ ?
< gribble> https://github.com/bitcoin/bitcoin/issues/19160 | multiprocess: Add basic spawn and IPC support by ryanofsky · Pull Request #19160 · bitcoin/bitcoin · GitHub
< ariard> maybe a topic for next meeting?
< luke-jr> ariard: why?
< bitcoin-git> [bitcoin] dhruv opened pull request #21165: test: Use mocktime in test_seed_peers (master...fix-for-19884) https://github.com/bitcoin/bitcoin/pull/21165
< ariard> luke-jr: as a dependency it might get more eyes on it if it's under bitcoin-core/ than under chaincodlabs/?
< * luke-jr> shrugs
< meshcollider> #startmeeting
< core-meetingbot> Meeting started Fri Feb 12 19:00:12 2021 UTC. The chair is meshcollider. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
< core-meetingbot> Available commands: action commands idea info link nick
< meshcollider> #bitcoin-core-dev Wallet Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd
< meshcollider> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
< achow101> hi
< S3RK> hi
< meshcollider> Hi everyone :)
< meshcollider> Topics today?
< achow101> We should try to get #16546 for 22.0
< sipa> not much of a topic, but i've been working on adding taproot descriptor support (and, hopefully, signing); hopefully i have something showable next week
< gribble> https://github.com/bitcoin/bitcoin/issues/16546 | External signer support - Wallet Box edition by Sjors · Pull Request #16546 · bitcoin/bitcoin · GitHub
< meshcollider> 100% agree andrew
< meshcollider> sipa: awesome!
< meshcollider> Something showable = a branch, or a PR?
< sipa> it can derive addresses with inner key, and arbitrary merkle trees of scripts (but the scripts can only be pk(...))
< sipa> i may PR some of the refactorings to descriptors needed first
< sipa> but the exact notation for the descriptors is probably something that needs discussion anyway
< achow101> looking forward to that
< meshcollider> Why can the scripts only be pk?
< meshcollider> Just WIP?
< sipa> well, because multi doesn't exist in bip342 (no OP_CHECKMULTISIG due to not batch verifiable)
< sipa> pkh could work, but i'm not sure that it should (160-bit hash is a bad idea of the key can be an aggregate)
< sipa> and those are, without miniscript, the only raw scripts descriptors have for now
< meshcollider> ah yes
< meshcollider> What's happening with miniscript at the moment?
< meshcollider> #16800 has had no activity for nearly a year
< sipa> nobody is working on getting it in bitcoin core atm
< gribble> https://github.com/bitcoin/bitcoin/issues/16800 | Basic Miniscript support in output descriptors by sipa · Pull Request #16800 · bitcoin/bitcoin · GitHub
< sipa> sanket1729 said he was interested in picking it up at some point
< meshcollider> I guess we should make that higher priority soon then
< sipa> i'm also interested in that of course, but it's hard without more people working on it
< meshcollider> Oh cool
< meshcollider> Yep
< jonatack> hi
< meshcollider> Any other topics before we end?
< meshcollider> #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 Feb 12 19:16:02 2021 UTC.
< jonatack> as it were, i've never had a "project" and could be in the market for one (as long as people want to see it done enough to review it)
< bitcoin-git> [bitcoin] achow101 opened pull request #21166: Pass through SignatureExtractorChecker methods to base (master...fix-sig-extractor-checker) https://github.com/bitcoin/bitcoin/pull/21166
< jonatack> though i'm fine with continuing to test and review others' projects and helping them move forward
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #21164: test: Use proper mocktime for uptime (master...2102-mockTimeInit) https://github.com/bitcoin/bitcoin/pull/21164
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/e9c037ba64dd...bf3189eda65d
< bitcoin-git> bitcoin/master 015637d Dhruv Mehta: [refactor] Correct log message in net.cpp
< bitcoin-git> bitcoin/master d4187e4 Dhruv Mehta: [test] Use mocktime in test_seed_peers()
< bitcoin-git> bitcoin/master bf3189e MarcoFalke: Merge #21165: test: Use mocktime in test_seed_peers
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21165: test: Use mocktime in test_seed_peers (master...fix-for-19884) https://github.com/bitcoin/bitcoin/pull/21165
< glozow> ariard aj: unfamiliar with dandelion but trying to catch up on what was said earlier. you're imagining a dandelion where instead of a stempool, you testmempoolaccept to verify it's correct (you'd need all parents ofc), maybe cache wtxid and some info, and relay? with some probability stem / some probability fluff?
< glozow> and separate from that, all initial broadcasts with a temporary i2p/tor connection + dandelion if possible?
< bitcoin-git> [bitcoin] jonatack opened pull request #21167: net: make CNode::m_inbound_onion public, initialize explicitly (master...m_inbound_onion-make-public-and-explicit) https://github.com/bitcoin/bitcoin/pull/21167
< ariard> glozow: what I'm thinking of is with all the ongoing refactors around tx-relay/mempool it'll be become easier to allocate per-peer dandelion "bandwidth", either to relay solo tx or package
< ariard> testmempoolaccept can be used to evaluate stuff, which if valid will be cached in a stempoool
< ariard> and yes doing initial broadcast on a single-shot connection modulo are tor folks going to be happy if we redirect that much traffic on their infra?
< ariard> and maybe if we start to have this notion of strategic outbound peers with erlay map our stem paths on them?
< sipa> as far as i know, there are no known solutions to dandelion's dos issues
< sipa> so i'm not sure what you're talking about
< sipa> yes
< ariard> I think aj point is actually to testmempoolaccet those stem transactions and further you can allocate per-peer resources by limiting their announcements?
< sipa> that
< sipa> ah, i haven't seen that
< sipa> but per-peer resources generally don't work i think, as dandelion has a natural funnel effect (and nodes don't know where in the funnel they are), so if i send to a node a stream of stem transaction equal to the rate limit (and thus occupying all of that node's outbound rate limit as well) i can successfully prevent anyone else from using that node as a router
< sipa> also, it's really hard to decide what that rate limit should be... the mempool has a natural rate limit because it can assume that transactions relayed through it will confirm and thus pay its fee, you can't make the same assumption about stem transactions (if you receive two conflicting stem transactions from two distinct nodes, you must relay them both, or otherwise you leak the existence of the
< sipa> first to the second)
< ariard> yeah I did hit the same limit when I worked on my package relay a while back, it was about caching the package ids to save bandwidth, the solution I thought about was round-robin incoming announcements on the outgoing
< ariard> but sounds fairly complex I admit
< ariard> what about a rate limit based on near-confirmation txn?
< sipa> what does that mean?
< ariard> I accept your stem transactions only if its feerate is a good candidate for near-inclusion in a block
< ariard> though an attacker might have broadcast a conflicting transation on the rest of the network
< sipa> right, but the problem is you have to make that decision independently of any other stem transaction you've seen
< sipa> so if you have 100 peers, they can all send you distinct conflicting stem transactions... and even if they're all individually good feerate, only one will confirm
< ariard> "you must relay them both, or otherwise you leak the exsitence of the first to the second" can you silently drop one or at least inobservable what's your relay decision was?
< sipa> if the transaction was unique, the sender can easily see that you never relayed theirs to the network
< ariard> *at least make inobservable
< sipa> but just observing it not appearing
< sipa> *by
< ariard> if you have a multi hop stem path, the drop might have happen anywhere on the path?
< ariard> and we assume the stem path to be unknown to the initial-broadcaster?
< sipa> yeah, perhaps
< sipa> it feels icky,
< ariard> yeah I agree it's complex
< sipa> like the obvious solution is to give each node their own separate stempool, which is kept consistent with the real mempool, but not consistent with other stempools
< sipa> but that's obviously terrible for resource usage
< ariard> you just dup the mempool?
< sipa> well, the mempool is shared in this model
< sipa> but the stempools are all distinct
< ariard> also about conflicting transactions if we care about masking transaction origin, it's up to the utxo owner to not produce conflicting transactions
< sipa> oh sure
< sipa> but we also have to make sure conflicting transactions don't result in connection graph leaks
< sipa> which is another form of privacy
< sipa> (or at least, don't worsen it significantly; it's hard to make any guarantees about it in the first place0
< ariard> what do you mean by connection graph ? your topology of tx-relay peers?
< sipa> yeah
< sipa> the ability to infer two peers of yours are connected, for example
< ariard> yeah sadly I think on that point it's more about not making it worst