--- Log opened Fri Feb 12 00:00:27 2021
00:22 -!- Kiminuo [~Kiminuo@141.98.103.228] has joined #bitcoin-core-dev
00:23 -!- Klox [~Klox@c-24-1-131-19.hsd1.il.comcast.net] has quit [Ping timeout: 240 seconds]
00:36 -!- binwiederhier1 [~binwieder@178.239.168.171] has quit [Remote host closed the connection]
00:41 -!- MasterGruntR75 [~MasterGru@185.163.110.108] has joined #bitcoin-core-dev
00:55 -!- asdlkfjwerpoicvx [~flack@p200300d46f24de00fea06d3df5467b42.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
00:56 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
01:04 -!- ishaqm [~ishaqm@host-92-26-31-113.as13285.net] has joined #bitcoin-core-dev
01:24 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 265 seconds]
01:24 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
01:33 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 240 seconds]
01:35 -!- mosh [~chaos@anarchy.consolegfx.com] has quit [Quit: ZNC - https://znc.in]
01:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:36 -!- mosh [~chaos@anarchy.consolegfx.com] has joined #bitcoin-core-dev
01:36 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
01:39 -!- belcher_ is now known as belcher
01:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:49 < bitcoin-git> [bitcoin] laanwj pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/937dfa839873...8d82eddee640
01:49 < bitcoin-git> bitcoin/master a1fccea Fabian Jahr: refactor: Improve encapsulation between MuHash3072 and Num3072
01:49 < bitcoin-git> bitcoin/master 2474645 Fabian Jahr: refactor: Separate hash and stats calculation in coinstats
01:49 < bitcoin-git> bitcoin/master 0d3b2f6 Fabian Jahr: rpc: Add hash_type MUHASH to gettxoutsetinfo
01:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:49 < 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
01:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:53 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 268 seconds]
01:54 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
02:04 -!- kexkey [~kexkey@static-198-54-132-89.cust.tzulo.com] has quit [Ping timeout: 264 seconds]
02:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:12 < bitcoin-git> [bitcoin] laanwj pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/8d82eddee640...54b66a6e5f26
02:12 < bitcoin-git> bitcoin/master 1624e17 fanquake: build: remove duplicate visibility attribute detection
02:12 < bitcoin-git> bitcoin/master 7cd0a69 fanquake: build: test for __declspec(dllexport) in configure
02:12 < bitcoin-git> bitcoin/master f054a08 fanquake: build: remove AX_GCC_FUNC_ATTRIBUTE test for dllimport
02:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:12 < 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
02:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:26 -!- ogo [~ogo@gateway/tor-sasl/ogo] has joined #bitcoin-core-dev
02:26 -!- ogo_ogo [~ogo@gateway/tor-sasl/ogo] has joined #bitcoin-core-dev
02:27 -!- ogo_ogo [~ogo@gateway/tor-sasl/ogo] has quit [Remote host closed the connection]
02:27 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]
02:27 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
02:27 -!- vasild_ is now known as vasild
02:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:40 < bitcoin-git> [bitcoin] laanwj pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/54b66a6e5f26...9996b1806a18
02:40 < bitcoin-git> bitcoin/master 8e55981 fanquake: refactor: replace Boost shared_mutex with std shared_mutex in cuckoocache ...
02:40 < bitcoin-git> bitcoin/master 7097add fanquake: refactor: replace Boost shared_mutex with std shared_mutex in sigcache
02:40 < bitcoin-git> bitcoin/master 06e1d7d fanquake: build: don't build or use Boost Thread
02:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:40 < 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
02:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:40 -!- narodism [~narodnik@37.223.80.136] has quit [Ping timeout: 264 seconds]
02:46 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 264 seconds]
02:47 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
02:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
02:48 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
02:49 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev
02:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:50 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9996b1806a18...e9c037ba64dd
02:50 < bitcoin-git> bitcoin/master fe3e993 Dhruv Mehta: [p2p] No delay in adding fixed seeds if -dnsseed=0 and peers.dat is empty....
02:50 < bitcoin-git> bitcoin/master e9c037b Wladimir J. van der Laan: Merge #19884: p2p: No delay in adding fixed seeds if -dnsseed=0 and peers....
02:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:50 < 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
02:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:18 -!- Blanche90Botsfor [~Blanche90@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
03:22 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has quit [Read error: Connection reset by peer]
03:23 -!- Blanche90Botsfor [~Blanche90@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 246 seconds]
03:26 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has joined #bitcoin-core-dev
03:30 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 240 seconds]
03:33 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #bitcoin-core-dev
03:34 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 272 seconds]
03:34 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
03:51 < ariard> thinking about initial transaction broadcasting, has making our own node "amnesic" already be considered ?
03:51 < ariard> by "amnesic" I mean not logging in the mempool, until it's announced back by some peer
03:52 < 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
03:53 < ariard> to assert validity of the parents, but without rebroadcasting them
03:53 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:53 < ariard> the advantage would be a privacy gain to mask a transaction origin
03:54 < wumpus> ariard: have you looked at #21061? i think it's a clever way to hide (re)broadcasts in the noise
03:54 < gribble> https://github.com/bitcoin/bitcoin/issues/21061 | [p2p] Introduce node rebroadcast module by amitiuttarwar · Pull Request #21061 · bitcoin/bitcoin · GitHub
03:56 < wumpus> instead of specific wallet broadcast we would broadcast anything that seems it should be mined
03:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
03:56 -!- jungly [~jungly@host-79-54-255-196.retail.telecomitalia.it] has quit [Ping timeout: 256 seconds]
03:56 < ariard> wumpus: ofc already reviewed the old one
03:56 < wumpus> okay
03:56 < ariard> but I don't think this approach are opposite, you might broadcast a set of transaction
03:57 < ariard> but not log it you mempool when someone query it with a getdata
03:57 < ariard> *those approaches
03:58 < ariard> ah no, that would be a fingerprint compared to the "noise" set of transaction, to not find a owned transaction in the mempool
03:58 < wumpus> i still think in practice broadcasting transactions over tor is the best approach
03:59 < ariard> yes, making one-shot connection over tor/i2p for transaction broadcast might be a really interesting approach
04:00 < 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)
04:01 < wumpus> this could tunnel the transaction over anything and would even work if bitcoin core doesn't itself use tor/i2p/etc
04:01 < aj> ariard: aren't you redescribing dandelion?
04:02 < wumpus> of course it could be better automated i never really got around to that
04:03 < ariard> wunpus: yeah I'm back working on altnet, but will start with headers-over-dns as a first integration :)
04:03 < 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
04:04 < aj> ariard: i think we can totally do that! especially with glozow's tx-package testmempoolaccept stuff
04:04 < ariard> because IIRC the blocker for dandelion was mostly an implementation concern about its DoS robustness
04:07 < sdaftuar> i think hes describing one hop dandelion which should be easy to do
04:08 < ariard> aj: you want to flood "noise" package of transaction to propagate them fast and then fallback on reconciliation for the fluff phase?
04:11 < 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
04:11 < aj> ariard: fluff/flood being normal tx propogation
04:16 -!- Mercury_Vapor [~Mercury_V@174-082-158-108.res.spectrum.com] has quit [Read error: Connection reset by peer]
04:17 -!- Mercury_Vapor [~Mercury_V@174-082-158-108.res.spectrum.com] has joined #bitcoin-core-dev
04:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:20 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
04:24 < aj> aha, i think i see what's causing #20725
04:24 < gribble> https://github.com/bitcoin/bitcoin/issues/20725 | EstimateMedianVal returns higher fee for higher confTarget · Issue #20725 · bitcoin/bitcoin · GitHub
04:24  * jonasschnelli completed his first guix build
04:25 -!- MasterGruntR75 [~MasterGru@185.163.110.108] has quit [Remote host closed the connection]
04:26 < 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?
04:26 < jonasschnelli> But there are probably some caching that could be done
04:28 < wumpus> agree caching would definitely be necessary to consider that
04:29 -!- iMast777 [~iMast777@178.239.168.171] has joined #bitcoin-core-dev
04:37 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
04:40 < wumpus> ariard: good to see that again i almost forgot about the altnet proposal!
04:41 < wumpus> (#18988)
04:41 < 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
04:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:47 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds]
04:57 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has quit [Read error: Connection reset by peer]
05:01 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has joined #bitcoin-core-dev
05:02 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 240 seconds]
05:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:03 < 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
05:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:09 -!- iMast777 [~iMast777@178.239.168.171] has quit []
05:10 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:10 < 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
05:10 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:13 < 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
05:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:17 -!- Murch [murch@gateway/shell/hashbang/x-hnduywbopvlelqpr] has quit [K-Lined]
05:24 < 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
05:25 < sdaftuar> oh no fee estimation
05:26 < sdaftuar> ok i will see what i can figure out
05:27 < aj> sdaftuar: hopefully the comments in the PR and issue should make sense at least
05:28 < aj> MarcoFalke: i am loving this vendetta against random test failures btw
05:30 < 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
05:32 < fanquake> Have to keep development exciting with the occasional “random” failure
05:35 < MarcoFalke> Right. Otherwise, how would we know the re-run button is working in the CI GUI?
05:35 -!- ogo [~ogo@gateway/tor-sasl/ogo] has quit [Ping timeout: 268 seconds]
05:36 -!- very_sneaky [~very_snea@45.67.96.36] has joined #bitcoin-core-dev
05:36 < aj> MarcoFalke: don't the CI systems themselves fail often enough to keep that button well-oiled?
05:37 < MarcoFalke> Cirrus detects if the failure was on the google cloud or in the tests and can re-run itself
05:42 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
05:48 -!- ogo [~ogo@gateway/tor-sasl/ogo] has joined #bitcoin-core-dev
05:49 < MarcoFalke> jonasschnelli: DrahtBot caches depends and the gnu store and it takes about the same time as the gitian build
05:49 < MarcoFalke> (mod whenever the guix manifest changes)
05:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:59 < 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
05:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:12 -!- brunstak [5d8439b6@dynamic-093-132-057-182.93.132.pool.telefonica.de] has joined #bitcoin-core-dev
06:13 -!- brunstak [5d8439b6@dynamic-093-132-057-182.93.132.pool.telefonica.de] has quit [Client Quit]
06:28 -!- jungly [~jungly@host-79-54-255-196.retail.telecomitalia.it] has joined #bitcoin-core-dev
06:30 -!- jungly_ [~jungly@host-79-54-255-196.retail.telecomitalia.it] has joined #bitcoin-core-dev
06:32 -!- jungly [~jungly@host-79-54-255-196.retail.telecomitalia.it] has quit [Ping timeout: 264 seconds]
06:36 -!- Terrance8Dare [~Terrance8@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
06:42 -!- othe1 [~othe@217.146.82.202] has joined #bitcoin-core-dev
06:42 -!- Kiminuo [~Kiminuo@141.98.103.228] has quit [Quit: Leaving]
06:45 -!- jonatack [~jon@37.169.23.248] has joined #bitcoin-core-dev
06:50 -!- Terrance8Dare [~Terrance8@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds]
07:09 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Remote host closed the connection]
07:10 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
07:15 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Client Quit]
07:19 -!- asdlkfjwerpoicvx [~flack@p200300d46f24de00fea06d3df5467b42.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
07:21 < vasild> jonatack: no update is pushed to #20197, just checking
07:21 < gribble> https://github.com/bitcoin/bitcoin/issues/20197 | p2p: improve onion detection in AttemptToEvictConnection() by jonatack · Pull Request #20197 · bitcoin/bitcoin · GitHub
07:24 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
07:25 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
07:25 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Remote host closed the connection]
07:25 < 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
07:26 < jonatack> to see which way is preferred
07:27 < vasild> ok
07:28 < jonatack> as the currently open one is a smaller diff. will update soon (tm)
07:30 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
07:30 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Client Quit]
07:36 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
07:37 -!- jungly_ [~jungly@host-79-54-255-196.retail.telecomitalia.it] has quit [Ping timeout: 272 seconds]
07:37 -!- jungly [~jungly@host-79-13-189-70.retail.telecomitalia.it] has joined #bitcoin-core-dev
07:57 -!- jungly [~jungly@host-79-13-189-70.retail.telecomitalia.it] has quit [Ping timeout: 246 seconds]
07:57 -!- jungly [~jungly@host-79-26-25-56.retail.telecomitalia.it] has joined #bitcoin-core-dev
08:03 -!- jungly [~jungly@host-79-26-25-56.retail.telecomitalia.it] has quit [Ping timeout: 246 seconds]
08:03 -!- jungly [~jungly@host-79-32-192-5.retail.telecomitalia.it] has joined #bitcoin-core-dev
08:17 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has quit [Read error: Connection reset by peer]
08:17 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Remote host closed the connection]
08:17 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
08:20 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has joined #bitcoin-core-dev
08:58 -!- ishaqm [~ishaqm@host-92-26-31-113.as13285.net] has quit [Ping timeout: 264 seconds]
09:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:16 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #21164: test: Use proper mocktime for uptime (master...2102-mockTimeInit) https://github.com/bitcoin/bitcoin/pull/21164
09:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:21 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 268 seconds]
09:22 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
09:26 < ariard> ryanofsky: as with #19160 we start to use libmultiprocess for real, should we move the library under bitcoin-core/ ?
09:26 < gribble> https://github.com/bitcoin/bitcoin/issues/19160 | multiprocess: Add basic spawn and IPC support by ryanofsky · Pull Request #19160 · bitcoin/bitcoin · GitHub
09:26 < ariard> maybe a topic for next meeting?
09:28 -!- Murch [murch@gateway/shell/hashbang/x-vmabeawmbexmblgo] has joined #bitcoin-core-dev
09:30 -!- ishaqm [~ishaqm@host-92-26-31-113.as13285.net] has joined #bitcoin-core-dev
09:35 < luke-jr> ariard: why?
09:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:39 < 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
09:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:40 -!- dunk [sid16@gateway/web/irccloud.com/x-paudpalitsiwpdmg] has joined #bitcoin-core-dev
09:41 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Read error: Connection reset by peer]
09:45 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev
09:45 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host]
09:45 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
09:48 -!- tannakar_ [~kartikeyt@2409:4055:292:b961:e44d:f38b:d562:a074] has joined #bitcoin-core-dev
09:52 -!- nckx [~nckx@tobias.gr] has quit [Ping timeout: 264 seconds]
09:52 -!- tannakar_ [~kartikeyt@2409:4055:292:b961:e44d:f38b:d562:a074] has quit [Remote host closed the connection]
10:01 -!- Mark007 [48c1ea51@ip72-193-234-81.lv.lv.cox.net] has joined #bitcoin-core-dev
10:04 < ariard> luke-jr: as a dependency it might get more eyes on it if it's under bitcoin-core/ than under chaincodlabs/?
10:04 -!- sr_gi [~sr_gi@static-125-62-230-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
10:04 -!- sr_gi [~sr_gi@static-125-62-230-77.ipcom.comunitel.net] has joined #bitcoin-core-dev
10:04  * luke-jr shrugs
10:20 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Remote host closed the connection]
10:21 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
10:23 -!- Mark007 [48c1ea51@ip72-193-234-81.lv.lv.cox.net] has quit [Quit: Connection closed]
10:34 -!- overthesea [579c22dc@p579c22dc.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
10:35 -!- nckx [~nckx@tobias.gr] has joined #bitcoin-core-dev
10:39 -!- overthesea [579c22dc@p579c22dc.dip0.t-ipconnect.de] has quit [Quit: Ping timeout (120 seconds)]
10:39 -!- jonatack [~jon@37.169.23.248] has quit [Ping timeout: 256 seconds]
10:41 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined #bitcoin-core-dev
10:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
10:51 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 240 seconds]
10:53 -!- jonatack [~jon@37.169.23.248] has joined #bitcoin-core-dev
11:00 < meshcollider> #startmeeting
11:00 < 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.
11:00 < core-meetingbot> Available commands: action commands idea info link nick
11:00 < 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 
11:00 < meshcollider> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
11:00 < achow101> hi
11:00 < S3RK> hi
11:00 < meshcollider> Hi everyone :) 
11:00 < meshcollider> Topics today?
11:01 < achow101> We should try to get #16546 for 22.0
11:01 < 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
11:01 < gribble> https://github.com/bitcoin/bitcoin/issues/16546 | External signer support - Wallet Box edition by Sjors · Pull Request #16546 · bitcoin/bitcoin · GitHub
11:01 -!- roconnor [~roconnor@host-104-157-194-235.dyn.295.ca] has quit [Remote host closed the connection]
11:02 < meshcollider> 100% agree andrew
11:02 -!- roconnor [~roconnor@host-104-157-194-235.dyn.295.ca] has joined #bitcoin-core-dev
11:02 < meshcollider> sipa: awesome!
11:02 < meshcollider> Something showable = a branch, or a PR?
11:03 -!- overthesea [579c22dc@p579c22dc.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
11:04 < sipa> meshcollider: branch is here: https://github.com/sipa/bitcoin/commits/202102_taproot_sign
11:04 < sipa> it can derive addresses with inner key, and arbitrary merkle trees of scripts (but the scripts can only be pk(...))
11:05 < sipa> i may PR some of the refactorings to descriptors needed first
11:05 < sipa> but the exact notation for the descriptors is probably something that needs discussion anyway
11:07 < achow101> looking forward to that
11:08 < meshcollider> Why can the scripts only be pk?
11:08 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 258 seconds]
11:08 < meshcollider> Just WIP?
11:08 < sipa> well, because multi doesn't exist in bip342 (no OP_CHECKMULTISIG due to not batch verifiable)
11:09 < 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)
11:09 < sipa> and those are, without miniscript, the only raw scripts descriptors have for now
11:10 < meshcollider> ah yes
11:11 < meshcollider> What's happening with miniscript at the moment?
11:11 < meshcollider> #16800 has had no activity for nearly a year
11:11 < sipa> nobody is working on getting it in bitcoin core atm
11:12 < gribble> https://github.com/bitcoin/bitcoin/issues/16800 | Basic Miniscript support in output descriptors by sipa · Pull Request #16800 · bitcoin/bitcoin · GitHub
11:12 < sipa> sanket1729 said he was interested in picking it up at some point
11:12 < meshcollider> I guess we should make that higher priority soon then
11:12 < sipa> i'm also interested in that of course, but it's hard without more people working on it
11:12 < meshcollider> Oh cool
11:12 < meshcollider> Yep
11:13 < jonatack> hi
11:14 < meshcollider> Any other topics before we end?
11:16 < meshcollider> #endmeeting
11:16 < 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
11:16 < core-meetingbot> Meeting ended Fri Feb 12 19:16:02 2021 UTC.  
11:16 < core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-02-12-19.00.moin.txt
11:18 -!- overthesea [579c22dc@p579c22dc.dip0.t-ipconnect.de] has quit [Quit: Ping timeout (120 seconds)]
11:19 < 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)
11:19 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
11:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:21 < 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
11:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:22 < jonatack> though i'm fine with continuing to test and review others' projects and helping them move forward
11:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:30 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #21164: test: Use proper mocktime for uptime (master...2102-mockTimeInit) https://github.com/bitcoin/bitcoin/pull/21164
11:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:35 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/e9c037ba64dd...bf3189eda65d
11:35 < bitcoin-git> bitcoin/master 015637d Dhruv Mehta: [refactor] Correct log message in net.cpp
11:35 < bitcoin-git> bitcoin/master d4187e4 Dhruv Mehta: [test] Use mocktime in test_seed_peers()
11:35 < bitcoin-git> bitcoin/master bf3189e MarcoFalke: Merge #21165: test: Use mocktime in test_seed_peers
11:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:35 < 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
11:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:54 -!- nullptr| [~nullptr|@ip-94-112-13-119.net.upcbroadband.cz] has quit [Quit: ZNC - http://znc.in]
11:56 -!- nullptr| [~nullptr|@ip-94-112-13-119.net.upcbroadband.cz] has joined #bitcoin-core-dev
12:25 -!- jungly [~jungly@host-79-32-192-5.retail.telecomitalia.it] has quit [Ping timeout: 246 seconds]
12:36 -!- l3g1on [5d964348@net-93-150-67-72.cust.vodafonedsl.it] has joined #bitcoin-core-dev
12:37 -!- l3g1on [5d964348@net-93-150-67-72.cust.vodafonedsl.it] has quit [Client Quit]
12:38 -!- OWO [bc676b15@dslb-188-103-107-021.188.103.pools.vodafone-ip.de] has joined #bitcoin-core-dev
12:41 -!- OWO [bc676b15@dslb-188-103-107-021.188.103.pools.vodafone-ip.de] has quit [Client Quit]
12:41 -!- OWO [bc676b15@dslb-188-103-107-021.188.103.pools.vodafone-ip.de] has joined #bitcoin-core-dev
12:46 -!- OWO [bc676b15@dslb-188-103-107-021.188.103.pools.vodafone-ip.de] has quit [Client Quit]
12:47 < 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?
12:47 < glozow> and separate from that, all initial broadcasts with a temporary i2p/tor connection + dandelion if possible?
12:51 -!- jungly [~jungly@host-79-32-192-5.retail.telecomitalia.it] has joined #bitcoin-core-dev
13:16 -!- kvaciral_ [~kvaciral@212.8.251.11] has left #bitcoin-core-dev []
13:16 -!- kvaciral [~kvaciral@212.8.251.11] has joined #bitcoin-core-dev
13:17 -!- dermoth_ [~dermoth@unaffiliated/dermoth] has joined #bitcoin-core-dev
13:17 -!- dermoth [~dermoth@unaffiliated/dermoth] has quit [Disconnected by services]
13:18 -!- dermoth_ is now known as dermoth
13:19 -!- jonatack [~jon@37.169.23.248] has quit [Read error: Connection reset by peer]
13:21 -!- jonatack [~jon@37.169.23.248] has joined #bitcoin-core-dev
13:24 -!- ishaqm [~ishaqm@host-92-26-31-113.as13285.net] has quit [Remote host closed the connection]
13:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
13:57 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
14:27 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]
14:27 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
14:27 -!- vasild_ is now known as vasild
14:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:39 < 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
14:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:45 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Remote host closed the connection]
14:56 -!- Setherson [~Setherson@108-255-110-61.lightspeed.tukrga.sbcglobal.net] has quit [Remote host closed the connection]
15:18 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
15:28 < 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
15:28 < ariard> testmempoolaccept can be used to evaluate stuff, which if valid will be cached in a stempoool
15:29 -!- jungly [~jungly@host-79-32-192-5.retail.telecomitalia.it] has quit [Ping timeout: 240 seconds]
15:30 < 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?
15:30 -!- tynes [~tynes@30.50.237.35.bc.googleusercontent.com] has quit [Quit: ZNC 1.7.2+deb1+cosmic0 - https://znc.in]
15:33 < ariard> and maybe if we start to have this notion of strategic outbound peers with erlay map our stem paths on them?
15:34 < sipa> as far as i know, there are no known solutions to dandelion's dos issues
15:34 < sipa> so i'm not sure what you're talking about
15:36 < ariard> this https://bitcoin.stackexchange.com/questions/81503/what-is-the-tradeoff-between-privacy-and-implementation-complexity-of-dandelion?
15:37 < sipa> yes
15:39 < ariard> I think aj point is actually to testmempoolaccet those stem transactions and further you can allocate per-peer resources by limiting their announcements?
15:40 < sipa> that
15:40 < sipa> ah, i haven't seen that
15:42 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Ping timeout: 272 seconds]
15:42 < 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
15:43 < 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 
15:43 < sipa> first to the second)
15:44 < 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
15:44 < ariard> but sounds fairly complex I admit
15:44 < ariard> what about a rate limit based on near-confirmation txn?
15:44 < sipa> what does that mean?
15:45 < ariard> I accept your stem transactions only if its feerate is a good candidate for near-inclusion in a block
15:45 < ariard> though an attacker might have broadcast a conflicting transation on the rest of the network 
15:46 < sipa> right, but the problem is you have to make that decision independently of any other stem transaction you've seen
15:47 < 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
15:47 < 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?
15:47 < sipa> if the transaction was unique, the sender can easily see that you never relayed theirs to the network
15:47 < ariard> *at least make inobservable
15:48 < sipa> but just observing it not appearing
15:48 < sipa> *by
15:48 < ariard> if you have a multi hop stem path, the drop might have happen anywhere on the path?
15:49 < ariard> and we assume the stem path to be unknown to the initial-broadcaster?
15:49 < sipa> yeah, perhaps
15:49 < sipa> it feels icky,
15:49 < ariard> yeah I agree it's complex
15:50 -!- jonatack_ [~jon@37.166.60.165] has joined #bitcoin-core-dev
15:50 < 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
15:50 < sipa> but that's obviously terrible for resource usage
15:51 < ariard> you just dup the mempool?
15:51 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 264 seconds]
15:51 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
15:51 < sipa> well, the mempool is shared in this model
15:51 < sipa> but the stempools are all distinct
15:52 < ariard> also about conflicting transactions if we care about masking transaction origin, it's up to the utxo owner to not produce conflicting transactions
15:52 < sipa> oh sure
15:53 < sipa> but we also have to make sure conflicting transactions don't result in connection graph leaks
15:53 -!- jonatack [~jon@37.169.23.248] has quit [Ping timeout: 240 seconds]
15:53 < sipa> which is another form of privacy
15:53 < sipa> (or at least, don't worsen it significantly; it's hard to make any guarantees about it in the first place0
15:53 < ariard> what do you mean by connection graph ? your topology of tx-relay peers?
15:53 < sipa> yeah
15:53 < sipa> the ability to infer two peers of yours are connected, for example
15:54 < ariard> yeah sadly I think on that point it's more about not making it worst
15:54 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
15:56 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Ping timeout: 246 seconds]
15:58 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev
16:02 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
16:08 < aj> sipa: why wouldn't you solve per-per dandelion DoS by just round-robining between peers proposing dandelion txs? (and limiting the per-peer incoming dandelion queue)
16:08 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Read error: Connection reset by peer]
16:09 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
16:12 < sipa> aj: elaborate?
16:13 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Ping timeout: 256 seconds]
16:22 < aj> sipa: incoming dandelion tx goes into a per-peer queue, that's capped by size. pick a rate limit for outgoing dandelion txs, use poisson delays to do outgoing dandelion txs at most at that rate limit. when sending an outgoing dandelion tx, pick your own tx if you have one to send, otherwise send peer X's earliest dandelion tx and increment X so you use the next peer next time.
16:23 < aj> (or use peer Y's oldest dandelion tx where Y has a dandelion tx and no peer Z, X <= Z < Y, has a dandelion tx)
16:23 < sipa> and if the queue overflows, just convert into a real tx?
16:24 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
16:24 < aj> if the queue overflows, fluff the oldest entry in the queue? maybe?
16:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
16:27 < sipa> aj: interesting, i think that could work
16:27 < aj> \o/
16:28 < glozow> dumb question, can u rate limit by sigops?
16:28 < sipa> glozow: sigops are (for the purposes of fee estimation/standardness) converted to vsize
16:29 < sipa> a transaction's effective vsize is max(real vsize, 20*sigops)
16:29 < glozow> ohhh right 🧠
16:30 < sdaftuar> sipa: aj: just getting caught up here. its been a while since i've thought about this but i think anything that uses a rate limit can be trivially attacked, to force worst case behavior--
16:31 < sipa> sdaftuar: yeah, that's also what i remember from thinking about it earlier
16:31 < sdaftuar> and it seems to be that worst case behavior is just one-hop dandelion. one-hop dandelion is probably still pretty good (would be nicce to see a writeup on that), but if that's all we can guarantee, it might be a lot easier to just implement one-hope dandelion and all it a day
16:32 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Remote host closed the connection]
16:32 < sipa> but in this design, if you have a few peers that constantly send you stem txn at max rate, they'll just cause their own queue to overflow, and not affect relay of other peer's stems i think?
16:32 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
16:32 < glozow> what’s one-hop dandelion? like only 1 stem?
16:33 < sipa> glozow: "when you have a new tx, only send it to one peer, and don't add it to your own mempool (except after a delay)"
16:33 < glozow> mm, thanks sipa
16:33 < sdaftuar> with dandelion you take all your inbound transactions and funnel them to 1 or 2 outbounds, so i think you could cause your outbound peers to fluff all your ransactions even if none of your inbounds are exceeding the rate limit
16:34 < sipa> need to think more about this
16:34 < aj> i think if average dandelion stem length is 10, and there's 10k publicly reachable nodes, then the average node only stems 1/1000th of the number of tx's it sees flooded, so if you set the dandelion rate limit to 10% of your tx rate limit, and only have 100 tx-relay peers, no honest peer will hit the rate limit?
16:35 < aj> (i think the bip's proposed 10% odds of fluffing gives an average path length of ~10)
16:36 < sdaftuar> sipa: aj: did i ever share a writeup of the issues i found with dandelion with you guys? i know i analyzed this at some length a couple years ago, but i need to find my notes
16:36 < aj> sdaftuar: "one-hope dandelion" is a great typo :)
16:37 < sdaftuar> lol
16:37 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Remote host closed the connection]
16:37 < sipa> sdaftuar: i only know of your bitcoin SE answer
16:37 < aj> sdaftuar: pretty sure i wasn't paying attention in depth at that time
16:37 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
16:38 < sdaftuar> i remember writing up something more detailed explaining why i thought we needed to double the mempool (ie, allocate stempool memory equal to the mempool) to immplement dandelion without introducing DoS vectors
16:38 < sdaftuar> but i need to find that again
16:38 < aj> sdaftuar: i think one-hop dandelion would already solve all the protocol work; so upgrading to n-hop dandelion would be a per-node "relay-policy" update after that too
16:39 < sipa> one-hope dandelion could even be done without any protocol changes (if we expect the peer to always convert a stempool tx to a real one, just send it as a normal one)
16:39 < aj> aww
16:40 < sdaftuar> one of things i remember discussing with morcos was that we could implement a modified version of dandelion where we fall back to fluffing everything if any kind of DoS scenario seemed to be happening... his suggestion (if i remember right) is that such an outcome would strictly be better than what we do today
16:40 < sipa> i remember that too, and i remember not being convinced it's worth the implemention complexity in that case
16:40 < sdaftuar> my concern was that i didn't like the idea of advertising that we implement Dandelion (as described in the paper) but in practice we get behavior worse than that whenever adversarial conditions strike, which is something that is likely unobservable
16:41 < sdaftuar> but if we just implemented one-hop dandelion, i think that's pretty trivial -- it's basically just a wallet behavior
16:41 < aj> it's changing RelayTransactions to have a flag to only pick a couple of outbound nodes, instead of everyone?
16:41 < sdaftuar> the only downside to that is there's no writeup of how that improves privacy
16:41 < sdaftuar> but it probably does
16:42 < sdaftuar> aj: yeah something like that, and not accepting the transaction to our own mempool
16:42 < sipa> sdaftuar: i remember talking to giulia fanti at FC about this; she mentioned a paper on one-hop dandelion (or some other simplified version), but never saw anything of it
16:42 < sdaftuar> on some timer
16:42 < sdaftuar> sipa: yes i recall discussing the same with her. i was hoping we'd get an analysis :)
16:43 < sdaftuar> ok here's a gist i wrote up in 2018 on this, no idea if this will make sense because i haven't re-read it: https://gist.github.com/sdaftuar/152812f1e862559e2afdcc8135498e2c
16:50 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Ping timeout: 272 seconds]
16:51 < aj> there's no actual value to spamming dandelion, it's just a DoS, right? (spamming the mempool by comparison lets you use it as distributed storage or a broadcast medium)
16:51 < sdaftuar> yeah free relay (use network bandwidth for free)
16:54 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
16:54 < sipa> and possibly it may reduce the privacy of those legitimately trying to use dandelion
16:54 < sipa> not sure if you would call that "value"
16:55 < sdaftuar> sipa: right, depending on what we do in response
16:55 < aj> but stemming doesn't let you choose who it gets relayed to?
16:56 < sdaftuar> it's hard to discuss without a specific proposal but i think if there's a scenario where (say) exceeding a rate limit causes everything to be fluffed, we probably should assume that an attacker will find a way to exceed the rate limit whenever they care to deanonymize other transactions
16:56 < aj> i guess if you control 2% of the network, you've got 20% chance of your msg hitting a node you control, and that's only 220 nodes
16:58 < sdaftuar> i think morcos' point to me was that we still get *some* benefit in that scenario, but i figure we might as well just code up and promise what we can actually deliver -- if it's just one-hop dandelion, that's pretty simple too
17:00 < sipa> (very much brainstorming) if the issues with dandelion are purely due to its funneling effect... would it make sense of an alternative that doesn't have that (e.g. define a random routing network between all your peer, but keep it bijective)
17:00 < aj> funneling effect?
17:01 < sdaftuar> aj: at any given moment, a small fraction of nodes will fluff most of the transactions
17:02 < sipa> funneling = the fact that it maps many input peers to few output peers
17:03 < sipa> which is what i think interferes with setting rate limits, because whatever rate limit you are willing to accept on your inputs will be lower than what you may be producing as output 
17:03 < sipa> even under honest conditions
17:08 < aj> is that true after the first hop? the only nodes receiving stems are reachable nodes, but for a reachable node, the number of incoming connections from reachable nodes on average should be less than the number of outgoing connections?
17:10 < aj> mmm
17:11 < aj> seems like the best idea is to resurrect the sims, see how one hop dandelion performs, and then re-sim more complicated things?
17:11 < sdaftuar> aj: the reason dandelion achieves privacy is because we assume that fluffing is the observable behavior (and the stem phase is mostly unobservable), and so the only way we can get privacy is by having a small fraction of nodes fluff more than their fair share of transactions (otherwise, an attacker could try to learn the mapping of origin node to fluff node, roughly)
17:12 < aj> aha, "dandelion-lite" was the one-hop variant, and https://github.com/gfanti/dandelion-simulations/commit/598cf93eb77e65c635be932010f9b762311da95f looks like the sim code for it
17:13 < aj> sdaftuar: hmm, i thought the argument (at least for n-hop dandelion) was that the mapping between source node and fluff node was unpredictable and changed regularly
17:14 < sdaftuar> i think if there was just a bijection of input node to output node, that an attacker could just learn the network by connecting to all the listenign nodes and relaying one transaction and seeing where it came out?
17:14 < sdaftuar> you'd have to repeat it as peers cycled, but seems like not too hard to learn
17:15 -!- rc_423_ [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
17:15 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Ping timeout: 246 seconds]
17:16 < sdaftuar> i think multiple input to one output is how you make observed transactions indistinguishable (as far as source goes)
17:17 -!- rc_423_ [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Read error: Connection reset by peer]
17:18 -!- rc_423_ [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
17:54 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds]
17:58 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
18:02 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]
18:09 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 268 seconds]
18:11 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev
18:26 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
18:30 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 246 seconds]
18:32 -!- subatuba21 [18049855@c-24-4-152-85.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
18:44 -!- subatuba21 [18049855@c-24-4-152-85.hsd1.ca.comcast.net] has quit [Quit: Connection closed]
19:36 -!- jonatack_ [~jon@37.166.60.165] has quit [Ping timeout: 246 seconds]
20:11 -!- dood [63a15fe8@99-161-95-232.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev
20:17 -!- dood [63a15fe8@99-161-95-232.lightspeed.tukrga.sbcglobal.net] has quit [Quit: Connection closed]
20:36 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
21:28 -!- tralfaz [uid458765@gateway/web/irccloud.com/x-xtskxctxchzulvoa] has joined #bitcoin-core-dev
21:43 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has quit [Ping timeout: 240 seconds]
21:45 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev
22:47 -!- mekster [~mekster@139.180.192.79] has quit [Quit: mekster]
22:47 -!- mekster [~mekster@139.180.192.79] has joined #bitcoin-core-dev
23:56 -!- tralfaz [uid458765@gateway/web/irccloud.com/x-xtskxctxchzulvoa] has quit [Quit: Connection closed for inactivity]
--- Log closed Sat Feb 13 00:00:27 2021