--- Log opened Thu Mar 07 00:00:08 2019
00:02 -!- bluelee [2d3e3426@gateway/web/freenode/ip.45.62.52.38] has joined #bitcoin-core-dev
00:10 -!- bluelee [2d3e3426@gateway/web/freenode/ip.45.62.52.38] has quit [Quit: Page closed]
00:18 -!- jungly [~quassel@79.8.200.97] has joined #bitcoin-core-dev
00:35 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
01:09 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
01:17 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
01:29 -!- Guest20 [~textual@m83-176-207-138.cust.tele2.lt] has joined #bitcoin-core-dev
01:31 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit []
01:31 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev
01:33 -!- promag [~promag@195.54.168.134] has joined #bitcoin-core-dev
01:46 -!- jonatack [58aba822@gateway/web/freenode/ip.88.171.168.34] has quit []
01:51 -!- Guest20 [~textual@m83-176-207-138.cust.tele2.lt] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
01:54 -!- CoffeeElixir [~CoffeeEli@m83-176-207-138.cust.tele2.lt] has joined #bitcoin-core-dev
02:02 -!- kexkey [~kexkey@68.168.122.228] has quit [Read error: Connection reset by peer]
02:10 < fanquake> Looks like we've got 6 sets of signed sigs for macOS and Windows rc1 builds.
02:10 < fanquake> No "new" builders yet
02:11 -!- rex4539 [~rex4539@ppp-2-84-160-62.home.otenet.gr] has joined #bitcoin-core-dev
02:20 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
02:27 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
02:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:30 < bitcoin-git> [bitcoin] cisba opened pull request #15554: docs: binary tar improvement (master...improve-tar) https://github.com/bitcoin/bitcoin/pull/15554
02:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:37 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
02:45 -!- IGHOR [~quassel@93.178.216.72] has quit [Read error: Connection reset by peer]
02:46 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev
02:50 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
02:52 -!- zhangzf [~zhangzf@106.38.157.147] has quit [Remote host closed the connection]
02:52 -!- zhangzf [~zhangzf@106.38.157.147] has joined #bitcoin-core-dev
02:52 -!- zhangzf [~zhangzf@106.38.157.147] has quit [Remote host closed the connection]
02:52 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
02:57 -!- jonatack_ [d598a185@gateway/web/freenode/ip.213.152.161.133] has joined #bitcoin-core-dev
02:59 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection]
02:59 < CoffeeElixir> Hi, where can I find the changelog of 0.18.0? 
03:01 < wumpus> PSA 0.18.0rc1 binaries up https://bitcoincore.org/bin/bitcoin-core-0.18.0/test.rc1/
03:02 < wumpus> CoffeeElixir: preliminary changelog is at https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.18.0-Release-Notes-Draft
03:03 < CoffeeElixir> wumpus thank you!
03:04 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
03:23 < wumpus> yw
03:25 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
03:42 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
03:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:52 < wumpus> whoa at least the wumpus-announce list (i mean, bitcoin-core-dev) is still working
03:55 < luke-jr> wumpus: the main one seems to be as well for the moment
03:55 < wumpus> oh nice!
04:08 -!- zhangzf [~zhangzf@223.72.36.178] has joined #bitcoin-core-dev
04:14 -!- CoffeeElixir [~CoffeeEli@m83-176-207-138.cust.tele2.lt] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
04:28 -!- jonatack_ [d598a185@gateway/web/freenode/ip.213.152.161.133] has quit [Ping timeout: 256 seconds]
04:40 -!- keymone [~keymone@ip1f10c1a7.dynamic.kabel-deutschland.de] has quit [Ping timeout: 245 seconds]
04:45 -!- keymone [~keymone@ip1f10c1a7.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev
04:53 -!- b10c [~b10c@200116b82a904c0011b5097ab3ae6972.dip.versatel-1u1.de] has joined #bitcoin-core-dev
05:06 -!- promag [~promag@195.54.168.134] has quit [Remote host closed the connection]
05:09 -!- zhangzf [~zhangzf@223.72.36.178] has quit [Remote host closed the connection]
05:12 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit []
05:34 -!- CoffeeElixir [~CoffeeEli@m83-176-207-138.cust.tele2.lt] has joined #bitcoin-core-dev
05:44 -!- CoffeeElixir [~CoffeeEli@m83-176-207-138.cust.tele2.lt] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
05:50 -!- zhangzf [~zhangzf@223.72.38.93] has joined #bitcoin-core-dev
06:03 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has joined #bitcoin-core-dev
06:05 -!- promag [~promag@a89-153-67-150.cpe.netcabo.pt] has joined #bitcoin-core-dev
06:10 -!- CoffeeElixir [~CoffeeEli@m83-176-207-138.cust.tele2.lt] has joined #bitcoin-core-dev
06:10 -!- promag [~promag@a89-153-67-150.cpe.netcabo.pt] has quit [Ping timeout: 268 seconds]
06:26 -!- Deinogalerix21 [~Deinogale@cpc93832-hari18-2-0-cust876.20-2.cable.virginm.net] has joined #bitcoin-core-dev
06:30 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev
06:33 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev
06:33 -!- Bullit [~Bullit01@042-236-158-163.dynamic.caiway.nl] has quit [Remote host closed the connection]
06:34 -!- Bullit [~Bullit01@042-236-158-163.dynamic.caiway.nl] has joined #bitcoin-core-dev
06:35 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 256 seconds]
06:37 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has quit [Ping timeout: 255 seconds]
06:41 -!- Deinogalerix21 [~Deinogale@cpc93832-hari18-2-0-cust876.20-2.cable.virginm.net] has quit [Quit: WeeChat 2.4]
06:41 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Read error: Connection timed out]
06:41 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
06:42 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev
06:59 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
07:08 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has quit [Quit: leaving]
07:08 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has joined #bitcoin-core-dev
07:11 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
07:23 -!- d_t [~d_t@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
07:27 -!- zhangzf [~zhangzf@223.72.38.93] has quit [Remote host closed the connection]
07:34 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
07:41 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev
07:46 < promag> please give your ack/nak in #15493
07:46 < gribble> https://github.com/bitcoin/bitcoin/issues/15493 | rfc: Add -printconfig arg to bitcoind by promag · Pull Request #15493 · bitcoin/bitcoin · GitHub
07:51 -!- CoffeeElixir [~CoffeeEli@m83-176-207-138.cust.tele2.lt] has quit [Ping timeout: 255 seconds]
07:52 < wumpus> heh everyone is retweeting the 0.18.0 rc1 announcement, thought i was sneaky enough to only post it on the ML and mastodon... well hope that people realize it's for testing and not a final release
07:53 -!- b10c [~b10c@200116b82a904c0011b5097ab3ae6972.dip.versatel-1u1.de] has quit [Ping timeout: 240 seconds]
07:54 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has quit [Remote host closed the connection]
07:54 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev
07:56 -!- b10c [~b10c@200116b82a904c0011b5097ab3ae6972.dip.versatel-1u1.de] has joined #bitcoin-core-dev
07:57 -!- b10c [~b10c@200116b82a904c0011b5097ab3ae6972.dip.versatel-1u1.de] has quit [Client Quit]
08:14 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
08:16 -!- shesek [~shesek@5.22.134.245] has joined #bitcoin-core-dev
08:16 -!- shesek [~shesek@5.22.134.245] has quit [Changing host]
08:16 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
08:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:18 < bitcoin-git> [bitcoin] laanwj closed pull request #15549: gitian: Improve error handling (master...2019_03_gitian_error_handling) https://github.com/bitcoin/bitcoin/pull/15549
08:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:19 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev
08:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:20 < bitcoin-git> [bitcoin] laanwj reopened pull request #15549: gitian: Improve error handling (master...2019_03_gitian_error_handling) https://github.com/bitcoin/bitcoin/pull/15549
08:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:27 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
08:31 -!- kexkey [~kexkey@68.168.122.228] has joined #bitcoin-core-dev
08:35 -!- jarthur [~jarthur@2605:6000:1019:41ab:954e:eb7c:412b:c83b] has joined #bitcoin-core-dev
08:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:35 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3515612e069e...726d0668ff78
08:35 < bitcoin-git> bitcoin/master faebd2e MarcoFalke: doc: Move wallet lock annotations to header
08:35 < bitcoin-git> bitcoin/master 726d066 MarcoFalke: Merge #15530: doc: Move wallet lock annotations to header
08:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:36 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15530: doc: Move wallet lock annotations to header (master...Mf1902-walletLocks) https://github.com/bitcoin/bitcoin/pull/15530
08:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:41 < bitcoin-git> [bitcoin] laanwj pushed 12 commits to master: https://github.com/bitcoin/bitcoin/compare/726d0668ff78...3db0cc394730
08:41 < bitcoin-git> bitcoin/master 9d6dcc5 Pieter Wuille: Abstract EraseBlockData out of RewindBlockIndex
08:41 < bitcoin-git> bitcoin/master 32b2696 Pieter Wuille: Move erasure of non-active blocks to a separate loop in RewindBlockIndex
08:41 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection]
08:41 < bitcoin-git> bitcoin/master 1d34287 Pieter Wuille: Merge the disconnection and erasing loops in RewindBlockIndex
08:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:42 < bitcoin-git> [bitcoin] laanwj merged pull request #15402: Granular invalidateblock and RewindBlockIndex (master...201902_limitrewindinvalidate) https://github.com/bitcoin/bitcoin/pull/15402
08:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:42 < bitcoin-git> [bitcoin] laanwj pushed 12 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/71ac4ebe4893...0fd3632868e2
08:42 < bitcoin-git> bitcoin/0.18 9d6dcc5 Pieter Wuille: Abstract EraseBlockData out of RewindBlockIndex
08:42 < bitcoin-git> bitcoin/0.18 32b2696 Pieter Wuille: Move erasure of non-active blocks to a separate loop in RewindBlockIndex
08:42 < bitcoin-git> bitcoin/0.18 1d34287 Pieter Wuille: Merge the disconnection and erasing loops in RewindBlockIndex
08:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:42 < bitcoin-git> [bitcoin] laanwj merged pull request #15552: 0.18: Granular invalidateblock and RewindBlockIndex (0.18...201902_limitrewindinvalidate) https://github.com/bitcoin/bitcoin/pull/15552
08:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:48 < michagogo> Quick question: was looking at the release notes and saw this: you need to expose RPC in order to use a tool like Docker, ensure you only bind RPC to your localhost, e.g. docker run [...] -p 127.0.0.1:8332:8332 (this is an extra :8332 over the normal Docker port specification).
08:48 < michagogo> Isn’t the normal port specification “-p 8332:8332”?
08:49 < michagogo> If you’re looking to bind to localhost, what you’re adding is the address
08:49 -!- jonatack [58aba822@gateway/web/freenode/ip.88.171.168.34] has joined #bitcoin-core-dev
08:52 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
08:58 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
09:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
09:02 -!- anome [~anome@unaffiliated/anome] has quit []
09:03 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev
09:06 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
09:06 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
09:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:12 < bitcoin-git> [bitcoin] Empact opened pull request #15556:  build: Optionally enable -Wthread-safety-attributes (master...wthread-safety-attributes) https://github.com/bitcoin/bitcoin/pull/15556
09:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:19 < DeanWeen> michagogo: where are these release notes?
09:19 -!- hebasto [~hebasto@95.164.65.194] has quit [Read error: Connection reset by peer]
09:28 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
09:35 -!- jungly [~quassel@79.8.200.97] has quit [Remote host closed the connection]
09:40 -!- Aaronvan_ is now known as AaronvanW
09:40 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
09:42 < instagibbs> can someone remind me the current Core restriction on rbf input sourcing? ie can a transaction rbf another transaction with unconfirmed inputs?
09:44 < instagibbs> ah, got it I think "replacement-adds-unconfirmed" error
09:52 -!- anome [~anome@unaffiliated/anome] has quit []
09:59 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev
10:07 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Remote host closed the connection]
10:08 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 252 seconds]
10:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:12 < bitcoin-git> [bitcoin] instagibbs opened pull request #15557: Enhance `bumpfee` to include inputs when targeting a feerate (master...bumpall) https://github.com/bitcoin/bitcoin/pull/15557
10:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:16 < michagogo> DeanWeen: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.18.0-Release-Notes-Draft
10:18 < instagibbs> 15557 should be of interest to some people ^ 
10:19 < instagibbs> finally sat down and just did it, very few loc, and I could delete a bunch more if we get rid of totalFee option for bumping :P
10:19 < promag> what's total fee?
10:21 < gmaxwell> <3
10:23 < instagibbs> promag, you say how much more, in satoshis, you want to give the tx
10:23 < instagibbs> it's... questionable imo
10:23 < instagibbs> but hey no need to delete :) 
10:23 < promag> what is the reason to create a separate function?
10:23 < instagibbs> i found the previous one very hard to read tbh
10:23 < instagibbs> the flow is completely different
10:24 < instagibbs> it's doing manual surgery based on introspection of the old tx, rather than just trying to make a new tx
10:25 < instagibbs> *very manual*
10:27 < promag> maybe you should move the if (totalFee > 0) {} else {} to a function in feebumper.h?
10:28 < promag> otherwise you have the same check in interfaces/wallet and rpcwallet
10:28 < gmaxwell> I think the absolute fee bump amount wasn't well considered and could go away...
10:29 < gmaxwell> esp as part of an improvement that made bump much more useful... 
10:29 < promag> gmaxwell: you suggest removing that in a different pr first?
10:30 < gmaxwell> no well, I'm suggesting that if someone making bumpfee better wants to remove it, then they should be empowered to make that call.
10:31 < gmaxwell> I don't think we should feel too obligated by prior decisions there-- as it stands bumpfee's usability is kinda so/so.
10:31 < dongcarl> cfields_ phantomcircuit: You guys online? Let's talk about libevent for node socket handling
10:31 < gmaxwell> why?
10:31 < promag> dongcarl: wanna ditch libevent?
10:32 < dongcarl> Mostly thinking about picking up #11227 again
10:32 < gribble> https://github.com/bitcoin/bitcoin/issues/11227 | WIP: switch to libevent for node socket handling by theuni · Pull Request #11227 · bitcoin/bitcoin · GitHub
10:33 < dongcarl> promag: It seems that we rely on libevent for torcontrol and httpserver correct?
10:33 < promag> dongcarl: yes
10:35 < phantomcircuit> dongcarl, yes
10:35 < dongcarl> Well I think we should use it for node socket handling as well, and wanted to talk about what people's thoughts are on that
10:35 < instagibbs> gmaxwell, the type of power-user can can use the totalFee option can already probably do it manually using pythong
10:35 < instagibbs> python* heh
10:36 < phantomcircuit> so one thing to consider, we currently do one connection at a time in another thread, there should be an fConnected flag so that doesn't need special handling
10:36 < dongcarl> phantomcircuit: fConnected flag on CNode?
10:37 < dongcarl> Could you point me to code?
10:40 < phantomcircuit> dongcarl, most of the stuff in netbase.{h,cpp}
10:40 < phantomcircuit> specifically ConnectSocketDirectly
10:40 < phantomcircuit> the annoying thing is is means building a SOCKS5 state machine
10:41 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
10:41 < dongcarl> phantomcircuit: oooof that doesn't sound great
10:41  * dongcarl reading
10:42 < cfields_> dongcarl: sorry, screwed up time zones
10:43 < dongcarl> Haha hey no worries
10:43 < dongcarl> Glad you're here
10:43 < cfields_> dongcarl: After wrestling with about 20 different rewrites of the net code with libevent, it's hard to recommend...
10:43 < cfields_> You definitely end up fighting it more than using it.
10:44 < dongcarl> cfields_: Really? What kind of fights are you talking about?
10:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
10:45 < cfields_> contexts, mainly. It expects you to feed a single pointer in for callbacks. C style. But you almost always want a callback into a function instance, meaning that you have to make weird 2xpointer mallocs all over the place
10:45 < cfields_> The threading model is also non-intuitive and error-prone
10:46 < cfields_> I'm happy to point you to the rewrites, I have lots of em :)
10:46 < phantomcircuit> cfields_, function instance?
10:46 < cfields_> phantomcircuit: sorry, class function
10:46 -!- gkrizek [~gkrizek@ip98-164-15-79.ks.ks.cox.net] has quit [Ping timeout: 245 seconds]
10:46 < phantomcircuit> cfields_, iirc all the libevent callbacks have a user data field basically for that purpose
10:46 < cfields_> All that said, I obviously wouldn't be opposed to someone else giving it a try.
10:47 < cfields_> phantomcircuit: yes, a single field.
10:47 < echeveria> dongcarl: #11227
10:47 < gribble> https://github.com/bitcoin/bitcoin/issues/11227 | WIP: switch to libevent for node socket handling by theuni · Pull Request #11227 · bitcoin/bitcoin · GitHub
10:47  * dongcarl taking notes
10:47 < cfields_> I also wrote an abstraction layer around libevent with the intention of plugging it into bitcoind
10:47 < cfields_> sec
10:47 < echeveria> #10285
10:47 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
10:47 < gmaxwell> we've already held back improvmenets of the p2p protocol for years because of vaguely motivated aspirational rewrites.
10:47 < gribble> https://github.com/bitcoin/bitcoin/issues/10285 | net: refactor the connection process. moving towards async connections. by theuni · Pull Request #10285 · bitcoin/bitcoin · GitHub
10:48 < cfields_> dongcarl: https://github.com/theuni/libbtcnet
10:49 < cfields_> yeah, 10285 does a good job of showing how awkward it is imo. I struggled to come up with something reviewable, without too much spaghetti. And since it wasn't merged, apparently I didn't do so great :)
10:49 < dongcarl> cfields_: I haven't dove fully into it, but I know that libev is a lot simpler than libevent (~1 order of magnitude LOC) and claims to have a good interface
10:49 < dongcarl> http://software.schmorp.de/pkg/libev.html
10:50 < cfields_> dongcarl: Last time I looked, IIRC I decided that libev would've been a better choice. But grass is always greener. And it'd be a new dep. So I didn't go down that path.
10:51 < gmaxwell> What problem is any of this supposted to be solving?
10:52 < dongcarl> gmaxwell: "These changes remove our old select() loop for socket handling in favor of libevent, which uses epoll/kqueue/etc. as a back-end. In addition to being faster and more efficient, this allows us to drop some annoying restrictions, namely that select can only handle 1024 sockets in practice on most systems."
10:52 < cfields_> gmaxwell: more async, and more performant due to epoll/kqueue/etc.
10:53 < gmaxwell> dongcarl: we no longer have the 1024 socket restriction, because we switched to using poll.
10:54 < gmaxwell> (when finally people were convinced to stop waiting for a rewrite.)
10:56 < dongcarl> Do non-Linux kernels have the 1024 socket restriction? Or does poll solve it for all the ones we support? (genuinely asking)
10:56 < gmaxwell> dongcarl: windows select doesn't have a 1024 restriction (at it uses a linked list instead of a bitmap)
10:56 < cfields_> 1024 is an issue with select()
10:56 < wumpus> 1024 restriction is specific to UNIX implementations of select()
10:56 < wumpus> not only Linux
10:56 < cfields_> and not always 1024 :)
10:57 < gmaxwell> cfields_: more performant in what measuresable respect?  At most we handle just hundreds of waiting sockets and benchmarks I've seen show essentially equivilent (fast) performance beween all alternatives at this level: https://monkey.org/~provos/libevent/libevent-benchmark2.jpg
10:57  * rafalcpp screams in Finnish
10:57 < wumpus> poll() doesn't have any such restriction on any (AFAIK) OS
10:57 < dongcarl> We enable poll for BSD?
10:57 < cfields_> gmaxwell: we've had this discussion endless times.
10:57 < wumpus> yes, only not on windows
10:57 < gmaxwell> cfields_: yes, and it screwed the protocol development for years. 
10:58 < cfields_> gmaxwell: guess you were right, then.
10:59 < phantomcircuit> so my interest is in doing very small changes
10:59 < phantomcircuit> i think the issue we've had in the past was having a grand plan
10:59 < gmaxwell> The cost right now to going back on this would likely be to delay development of p2p encryption/authentication for another year plus. If thats the case I think it would be an awful tradeoff.
10:59 < phantomcircuit> instead of doing smaller fixes
11:00 < sipa> gmaxwell: i think we indeed had an instance a while ago where some 
11:00 < phantomcircuit> i brought up the connect stuff cause that did actually slow me down on changing  poll()
11:00 < sipa> gmaxwell: i think we indeed had an instance a while ago where some things were delayed because of an upcoming refactor which didn't happen
11:00 < wumpus> gmaxwell: I tend to agree at this point, years ago it was differnt but makes sense to prioritize BIP150/151 now
11:01 < wumpus> I doubt the main performance wins at this point are in the polling implementation, but in improving the protocol
11:01 < gmaxwell> We had many networking refactors which did happen too. And it has also taken a long time to restabalize the networking after changing it.
11:01 < wumpus> and implementation
11:01 -!- gkrizek [~gkrizek@ip98-164-15-79.ks.ks.cox.net] has joined #bitcoin-core-dev
11:01 < instagibbs> meeting time?
11:01 < dongcarl> meeting time.
11:01 < wumpus> the network code has to be *super optimized* for the bottleneck to be at the low level event level
11:01 < wumpus> #startmeeting
11:01 < lightningbot> Meeting started Thu Mar  7 19:01:56 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:01 < provoostenator> hi
11:02 < jonasschnelli> Hi
11:02 < gmaxwell> I'd love to be using epoll/kqueue where available, -- but  compared to many other possible improvements, I think these things would just be nice to have changes that make the system prettier and more technically perfect.
11:02 < achow101> hi
11:02 < meshcollider> hi
11:02 < jonasschnelli> topic proposal: txindex and prune
11:02 < jonasschnelli> (for later)
11:02 < wumpus> this is true for, say, simple HTTP servers that can handle connections at network-bound speed, we're definitely CPU bound in many cases
11:02 < 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
11:02 < cfields_> At this point I obviously agree with all of the above.
11:02 < sipa> gmaxwell: i think people looking into integrating these (through libevent based network code or elsewhere) is useful; we just shouldn't let it stand in the way of protocol improvements
11:03 < gmaxwell> cfields_: it's not that I was right, hell I didn't know it would go out the way it did. :) I just don't want to repeat what happened before, and I can't see how (right now) that sort of change should be a priority worth delaying anything.
11:03 < wumpus> #topic P2P networking
11:03 < gmaxwell> sipa: sure, though I'm sure most people would prefer to work on suff that is going to get integrated soon! :P
11:04 < sipa> of course
11:04 < jonasschnelli> In case anyone wants to review the new v2 protocol (BIP151), including the new special ChaCha20Poly1305@bitcoin AEAD,... its here -> https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52
11:04 < gmaxwell> oh interesting, cool. Will do.
11:05 < sipa> jonasschnelli: interesting; this is the born-encrypted design, rather than upgrade-existing-connection one?
11:05 < jonasschnelli> yes. The born encrypted
11:05 < phantomcircuit> hi
11:06 < jonasschnelli> with NODE_ENCRYPTED and the 32byte key exchange before everything else
11:06 < jonasschnelli> but fallback to a version message
11:06 < wumpus> #topic BIP151
11:06 < echeveria> jonasschnelli: (minor, why is the command still possible to be null padded ASCII?)
11:06 < sipa> at this point it may be worth having it as a separate bip
11:06 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev
11:07 < jonasschnelli> echeveria: in v2 its a varstring or a short varint
11:07 < jonasschnelli> no padding
11:07 < echeveria> ok, same question. 
11:07 < jonasschnelli> sipa: what as a seperate BIP? the handshake, or the NODE_ENCRYPTED?
11:08 < sipa> jonasschnelli: it looks like you plan to overwrite BIP151... given that it already has a bip number, and you're substantially changing the design, maybe it should be a separate one
11:08 < sipa> (and abandon bip151)
11:08 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-snnyzdhfdapadlki] has joined #bitcoin-core-dev
11:08 < jonasschnelli> Yes. I thought the same...
11:08 < gmaxwell> +1
11:08 < jonasschnelli> Though we must discourage to use BIP151
11:09 < gmaxwell> Sure.
11:09 < phantomcircuit> jonasschnelli, why is the command ascii and not just a integer?
11:09 < jonasschnelli> Also, there is a BIP150 weakness if used with plain (old) BIP151
11:09 < jonasschnelli> phantomcircuit: it is
11:09 < jonasschnelli> read the BIP linked above
11:09 < echeveria> from the BIP. "1-13 	encrypted command 	variable 	ASCII command (or one byte short command ID)"
11:09 < wumpus> phantomcircuit: extensibility I guess, names are much easier to work on on parallel instead of having to reserve small integers
11:10 < jonasschnelli> ASCII commands are still possible
11:10 < gmaxwell> Basically for extensibility, the existing normal commands get short IDs but then its possible to have longer ones for new/infrequent commands.
11:10 < wumpus> right
11:10 < sipa> this is probably not the place to discuss the details of the bip
11:10 < jonasschnelli> yes. Will move it to the ML
11:10 < gmaxwell> if you only have a small integer you end up with an allocation problem.
11:11 < jonasschnelli> I will rebase and overhaul the implementation #14032 asap
11:11 < gribble> https://github.com/bitcoin/bitcoin/issues/14032 | Add p2p layer encryption with ECDH/ChaCha20Poly1305 by jonasschnelli · Pull Request #14032 · bitcoin/bitcoin · GitHub
11:11 < jonasschnelli> In the meantime, reviews welcome for the puzzles required for the p2p enc. -> #15512, #15519, #14047, #14049
11:11 < gribble> https://github.com/bitcoin/bitcoin/issues/15512 | Add ChaCha20 encryption option (XOR) by jonasschnelli · Pull Request #15512 · bitcoin/bitcoin · GitHub
11:11 < gribble> https://github.com/bitcoin/bitcoin/issues/15519 | Add Poly1305 implementation by jonasschnelli · Pull Request #15519 · bitcoin/bitcoin · GitHub
11:11 < gribble> https://github.com/bitcoin/bitcoin/issues/14047 | Add HKDF_HMAC256_L32 and method to negate a private key by jonasschnelli · Pull Request #14047 · bitcoin/bitcoin · GitHub
11:11 < gribble> https://github.com/bitcoin/bitcoin/issues/14049 | Enable libsecp256k1 ecdh module, add ECDH function to CKey by jonasschnelli · Pull Request #14049 · bitcoin/bitcoin · GitHub
11:11 < jonasschnelli> (sry for the wall)
11:12 < gmaxwell> We should talk about a meta issue here. Whats our position on e.g. voskuil opposing any encryption?  My view is that he's free to not implement it, but we shouldn't let generalized opposition stand in the way of doing something like that.
11:12 < jonasschnelli> voskuil seems to be okay with the new BIP since its now fully backward comp.
11:12 < instagibbs> Is it authentication or encryption he has issues with?
11:13 < jonasschnelli> Auth. is BIP150 which is still in discussion
11:13 < gmaxwell> It was always backwards compatible... but okay...
11:13 < sipa> instagibbs: his position is that authentication without encryption is pointless (i agree, it mostly is), and that authentication of bitcoin connections is a slippery slope
11:13 < jonasschnelli> BIP151 (or the new #) is opportunistic encryption
11:13 < gmaxwell> instagibbs: he argued that encryption was pointless without authentication and authentication was bad.
11:13 < gmaxwell> what sipa says.
11:13 < gmaxwell> but if thats changed. fine!
11:14 < sipa> eh, encryption without authentication
11:14 < gmaxwell> I'd just ask that if we move discussion to the ML we not let stupid debates mire it down. 
11:14 < instagibbs> sipa, yeah i figured :) 
11:14 < wumpus> I... don't understand why such a high-level discussion of the desirability of those things comes now, while BIP150/151 have existed for ages
11:14 < jonasschnelli> I think there are basic benefits of encryption without authentication... but of course, with autrhentication there are more possibilities,... but we need to create puzzle piece by puzzle piece
11:15 < provoostenator> I like being able to detect when my ISP starts messing with my Bitcoin P2P traffic :-)
11:15 < jonasschnelli> indeed
11:15 < wumpus> would need to be a really good reason it's bad to stop now
11:15 < jonasschnelli> I like that my ISP(s) know that I can detect in case they want mess my p2p traffic
11:15 < sipa> jonasschnelli: fwiw, i do have a writeup on countersign (which allows authentication without a MitM knowing it was even attempted); it turns out to be fairly hard for multiple keys simultaneously, but for one key it's pretty simple; https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b
11:15 < gmaxwell> yes yes, we're all in agreement here.
11:16 < sipa> jonasschnelli: also, hasn't had thorough review yet
11:16 < jonasschnelli> sipa: thanks... i'll look at it in a free minute
11:16 < gmaxwell> I was assumping sipa and I would advance countersign once the oppturnistic encryption was in. 
11:16 < jonasschnelli> Yes. There is the possibility of multiple authentication shemes
11:16 < jonasschnelli> *schemes
11:17 < wumpus> I could see how a "connect only to authenticated, known peers" becoming general could be problematic, though, but I don't think it was ever to be the only option?
11:17 < sipa> jonasschnelli: the idea behind countersign is that you'd always use it; even when no authentication is desired (in which case you'd run it with a random pubkey)
11:18 < sipa> but a MitM can't tell whether it's for a real key or not
11:18 < gmaxwell> So that a MitM can't only selectively tamper with unauthenticated links.
11:18 < jonasschnelli> We currently authenticate peers by ips IPv4/IPv6... so..
11:18 < sipa> haha yes
11:18 < jonasschnelli> (addnode / connect)
11:19 < gmaxwell> So anyone using authentication creates a halo of protection against MitM for everyone.
11:19 < jonasschnelli> We don't change the uses cases
11:19 < jonasschnelli> Authentication just makes things more secure and reliable that are already possible
11:20 < gmaxwell> Indeed, we're clear on this. I only raised the concern in the context of the mailing list because of bad expirences before discussing this.
11:20 < sipa> preaching to the choir :)
11:21 < gmaxwell> I think if the industry (or other implementers) opposes the idea in general: we don't care, obviously we'll continue to support the old procol so long as it's needed, and obviously we'd hear out any concerns. But fundimentally P2P is non-consensus, we can implement any additional protocol we want and still interpo wih anyone who doesn't want to implement it.
11:21 < wumpus> right
11:22 < gmaxwell> So someone showing up demanding we don't implement crypto at all or use TLS can just be told after we hear their case, sorry, this project isn't interested in that.
11:22 < gmaxwell> jonasschnelli: the particular thing about countersign is that it makes it less attractive to MitM anyone, even people not actually using it. Though to get that benefit it has to be 'on' all the time, even when not used.
11:24 -!- jonatack [58aba822@gateway/web/freenode/ip.88.171.168.34] has quit [Ping timeout: 256 seconds]
11:25 < gmaxwell> I think that covers it? jonasschnelli's new writup needs review.
11:25 < wumpus> next topic I guess
11:25 < jonasschnelli> yes
11:25 < wumpus> #topic txindex and prune (jonasschnelli)
11:25 < gmaxwell> (and people might want to look at sipa's countersign writeup)
11:25 < jonasschnelli> I think there is demand to rund the txindex on pruned peers....
11:26 < jonasschnelli> *run
11:26 < jonasschnelli> I know its for development purposed only..
11:26 < gmaxwell> I don't understand how that makes logical sense?
11:26 < gmaxwell> txindex works by accessing the blocks, so what exactly would txindex+prune mean?
11:26 < jonasschnelli> Users running low cost devices (with pruning) may want to look up txids on their own system rather then use a blockexplorer
11:26 < gmaxwell> just returning errors on inaccessible blocks?
11:27 < achow101> jonasschnelli: I feel like people who want to do that have a fundamental misunderstanding of what pruning and txindex do
11:27 < jonasschnelli> The idea is that the index points to a blockhash, position (in the end)
11:27 < sipa> in a manual pruning it may make sense; some client applications knows how far it needs blocks, prunes them, but still expects to be able to lookup transactions in the unpruned one
11:27 < instagibbs> with manual pruning it can make sense
11:27 < jonasschnelli> So you can fetch it via p2p on pruned peers
11:27 < instagibbs> jynx sipa 
11:27 < jonasschnelli> Its not efficient, its not fast... but it works for pesonal debug uses cases
11:27 < gmaxwell> ugh, fetching blocks in response to queries sounds kind of abusive on he network.
11:27 < gmaxwell> s/he/the/
11:27 < sipa> jonasschnelli: i don't understand the p2p side of things here
11:28 < provoostenator> That used to be useful for Lightning, but now there's a proposal to add SPV proofs to gossip, it's probably no longer useful for that.
11:28 < gmaxwell> sipa: he is suggesting you resolve missing blocks by fetching the block.
11:28 < sipa> provoostenator: oh that's great to hear
11:28 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has joined #bitcoin-core-dev
11:28 < jonasschnelli> sipa: well,.. if the txindex resolves to blockhash/pos, one may want to fetch the tx, and since blocks are not available, fetch a single block in order to decompose and display the tx
11:29 < provoostenator> It's mentioned in the Lightning 1.1 meeting docs, not sure if anyone implemented it, but that's really useful for running Lightning on pruned nodes.
11:29 < gmaxwell> jonasschnelli: I suspect that if people start doing this, it would probably hasten the future where there are few to no non-limited peers on the future.
11:29 < sipa> jonasschnelli: so you expect the txindex to cover even the pruned blocks?
11:29 < gmaxwell> provoostenator: if you have a pruned node, why doesn't it just check the channel against the utxo set?
11:30 < jonasschnelli> sipa: initially, allow to move the index from disk pos to blockhash/pos to allow to resolve to something that is useful if you have the blocks _not_ on disl
11:30 < gmaxwell> Txindex being able to return txes or a "pruned error" when it hits a pruned block seems like an obvious +1 to me if it would actually be useful to anyone.. (though I do have a little doubt since we didn't really like 'probablistic' RPCs in the past)
11:30 < sipa> jonasschnelli: meh
11:30 < sipa> jonasschnelli: i think a txindex that just covers the blocks you have may make sense if there's a use case
11:31 < instagibbs> gmaxwell, gettxout is a bit weird in some uses.
11:31 < provoostenator> gmaxwell: I believe Lightning gossip messages don't contain the full transaction id, they use a short notation block height + part of tx id
11:31 < instagibbs> sipa, liquid could have used it(we rolled our own instead)
11:31 < gmaxwell> provoostenator: oy
11:31 < sipa> jonasschnelli: but if the txindex must cover all of history, it breaks the advantage that pruning was supposed to give
11:31 < jonasschnelli> sipa: I think the diskpos approach is great for non pruned peers,.. I don't propose to change this,.. just allow an alternative index value of hash/pos
11:31 < provoostenator> gmaxwell: https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#requirements
11:32 < gmaxwell> provoostenator: that sounds like a protocol flaw in lightning. (and an example of the kind of design damage txindex does.. :P )
11:32 < jonasschnelli> Right now, pruned peers have no possibility to securily fetch a transaction by its ID,... they need to switch to a centralized API
11:32 < instagibbs> merkle proofs should fix that eh?
11:32 < jonasschnelli> and they did verify the blocks
11:33 < jonasschnelli> allowing the alternative blockhash/pos instead of diskpos would give the an opportunity to lookup a txid
11:34 < jonasschnelli> And its just so that users still want to fetch transactions not indexed by the wallet for semi-experimental purposes like lightning, etc.
11:34 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has quit [Read error: Connection reset by peer]
11:35 < gmaxwell> that seems like it would just prolong eventually fatal but avoidable design flaws... like assuming you have a txindex.
11:35 < jonasschnelli> I agree for productive systems,... 
11:35 < gmaxwell> txindex = eventually rely on a centeralized service, -- we've always known this.  By twiddling this or that you can change when you have to give up on not using a centeralized service...
11:36 < gmaxwell> Expecting random peers to serve up random blocks to you just to fetch a transaction is a pretty costly way to forestall the inevitable.
11:36 < jonasschnelli> IMO its already done on the p2p network... 
11:36 < jonasschnelli> Also, compact block filters are pretty much the same
11:37 < gmaxwell> Yes, they make the data available but if people start using it, it'll eventually have to go away.
11:37 < gmaxwell> jonasschnelli: yes, which have been problematic, though disuse of them has limited the amount of problems they cause.
11:37 < provoostenator> (by the way, we skipped high prioirity issues and 0.18 release topics)
11:38 < wumpus> provoostenator: yea because everyone was already discussing things when the meeting started, if you have anything to discuss re: 0.18 please let us know
11:38 < jonasschnelli> I see all implications and somehow I think adding the p2p part could be done in a second step. Allowing the txindex to be hash/pos based would give pruned peer alternatives (not only the p2p fetch method). But I agree about the "meh",... but I personally see the usefulness 
11:38 < gmaxwell> jonasschnelli: just your figures the other day were showing that >90% of your bandwidth is already expended serviging historic blocks.
11:38 < provoostenator> wumpus: I don't have anything
11:39 < jonasschnelli> gmaxwell: fair point
11:39 < wumpus> PSA: 0.18.0rc1 binaries were uploaded today and release announcement posted
11:39 < gmaxwell> jonasschnelli: it doesn't need to be hash based, fwiw, it could just be a reference into the blockindex I think, that would avoid bloating it.
11:39 < midnightmagic> \o/
11:39 < jonasschnelli> gmaxwell: yes. I think it has to to keep it compact. Was simplifying it for discussion purposes 
11:40 < jonasschnelli> It would be more or less the same diskspace (for the index),.. also same database structure (reuse of existing fields)
11:40 < jonasschnelli> but I accept the "meh" but won't stop bother about it. :)
11:41 < gmaxwell> So there are two possibilties for pruned + txindex = whole tx index but returns "in pruned block X" when pruned, or just a txindex of the unpruned portion.  The former will radically increase disk usage, since it undermines pruning.  The latter seems easily viable, I'm not sure is actually useful to anyone (has anyone asked for something like that?)
11:42 < wumpus> re: "high priority for review" we haven't discussed that in the meeting for a while because around the 0.18.0 release, the obvious high-priority PRs are the ones tagged with that, but maybe now after the branch-off and rc1 is the time to start again (or next week)
11:42 < jonasschnelli> The main driver behind this are plug-n-play nodes (CasaHODL like consumer devices) 
11:42 < gmaxwell> Either are better than the current "you just cant' combine these options", but dunno how important the improvement would be.
11:42 < gmaxwell> jonasschnelli: that _is_ production...
11:43 < provoostenator> jonasschnelli: I'm not convinced these plug-n-play nodes needs indexes.
11:43 < jonasschnelli> gmaxwell: its a debug option in a production device
11:43 < jonasschnelli> gmaxwell: thanks for the "in pruned block X" thought,... let me follow this a bit..
11:43 < jonasschnelli> I think there are other topics
11:43 < gmaxwell> (aside, CasaHODL has a 1TB drive.)
11:43 < gmaxwell> jonasschnelli: k
11:44 < jonasschnelli> gmaxwell: yes. But its a lame device,... I think we will see a bunch of fast devices with <64GB SSDs
11:44 < wumpus> are there other topics?
11:45 < gmaxwell> I would like to leave for lunch. :P
11:45 < jonasschnelli> ack
11:45  * sipa is generally in favor of food
11:45 < wumpus> ok :D
11:45 < wumpus> #endmeeting
11:45 < lightningbot> Meeting ended Thu Mar  7 19:45:40 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
11:45 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-07-19.01.html
11:45 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-07-19.01.txt
11:45 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-07-19.01.log.html
11:45 < sipa> also, yay for 0.18.0rc1
11:46 < gmaxwell> \O/
11:46 < gwillen> sipa: countersign seems need to me, but the identity protection for the responder seems only good against relatively casual threats, if I'm understanding this right
11:46 < meshcollider> \o/
11:46 < wumpus> \o/
11:46 < gwillen> since a logarithmic number of sessions will break it
11:46 < jonasschnelli> gmaxwell: I think SSDs are a must for devices with lower end CPUs. And if one shipts a plug-n-play node, 1TB is already small
11:46 < gwillen> (much in the same way that one can break cloaks on freenode with a ~logarithmic amount of effort)
11:46 < sipa> gwillen: logarithmic?
11:46 < jonasschnelli> So pruning on such devices is more or less a must
11:46 < jonasschnelli> and not supporting txid lookups is not understandable for users
11:47 < gwillen> sipa: do a session with them where I accept half the identities I suspect they might be
11:47 < gmaxwell> gwillen: only if you have some database directory of identities.
11:47 < gwillen> sure, yeah
11:47 < gwillen> logarithmic in the size of the suspect-set
11:47 < gmaxwell> gwillen: what you can't do is just track random nodes around when you have no idea about identities.
11:47 < gwillen> hmmmmmmmmm okay that's a really good point
11:47 < sipa> jonasschnelli: what do users need txid lookups for?
11:47 < gwillen> if you've never seen a given pubkey before you can't track that person
11:47 < gmaxwell> it also protects you against checking against old transcripts even if you later learn some candidate identities.
11:47 < jonasschnelli> sipa: Various... ask youself the next time when you lookup a txid. :)
11:48 < gwillen> I am mostly responding to "Responder privacy also implies that C does not learn which of its acceptable public keys R's private key corresponded to. To see why this may be useful, note that the anti-surveillance property from the previous paragraph breaks down whenever C can run many instances of the protocol with separate acceptable keys, for a large set of (e.g. leaked) keys that may include R's public key. In order to combat this, R can 
11:48 < gmaxwell> gwillen: right which is a problem in many protocols. 
11:48 < jonasschnelli> And I bet you do that also often
11:48 < gwillen> I think it is infeasible for R to limit the number of independent protocol runs to a useful degree
11:48 < gwillen> but I still agree that there are useful privacy properties we get
11:48 < sipa> gwillen: the idea of the multiparty version is that you'd also only allow one per connection... though of course you can assume that connecting multiple times to the same IP will give you the same participant
11:48 < gwillen> right
11:49 < gmaxwell> Yes, though the responder isn't initiating the connection in that case.
11:49 < sipa> gwillen: in any case, i agree that it's hard to put guarantees on the non-leaking of identities of some large set of pubkeys to track
11:49 < gwillen> I need no more than a couple dozen connections to disambuguate you
11:49 < promag_> jonasschnelli: low hang fruit 15464
11:49 < gmaxwell> Though for the kind of usage we imagine there is no database.
11:49 < sipa> gwillen: my favor is just implementing the 1 key version, and running it multiple times
11:50 < midnightmagic> (gwillen: your IRC client isn't splitting lines properly.. I think?)
11:50 < jonasschnelli> promag_: thanks... will take a look (merge)
11:50 < gmaxwell> In the 'wallet server'  'wallet client'  model the multiple way use is essentially just a semi-honest protocol. Doesn't leak the identity of the user, if the server doesn't actively try.
11:50 < gwillen> midnightmagic: the IRC protocol does not include any provision for splitting lines
11:50 < gwillen> midnightmagic: I guess my paste was over the maximum length
11:50 < sipa> gwillen: irssi has a nice plugin to split too long lines :)
11:50 < gwillen> (there are some clients that will auto-split, mine does not)
11:50 < gwillen> yeah, I don't have it installed
11:51 < gmaxwell> Probably we wouldn't propose implementing the multi-key version for bitcoin, but we had to feel out the design to figure out if it would be useful or not.
11:51 < midnightmagic> (gwillen: older irssi used to do that. if you upgrade, FYI OTR has been implemented directly in mainline.)
11:51 < sipa> jonasschnelli: sure, but for recent transactions an index into unpruned blocks is sufficient
11:51 < midnightmagic> (a non-segfaulting one, too)
11:51 < sipa> jonasschnelli: and a full index of the chain is already 20 GB or so
11:52 < jonasschnelli> sipa: Yes. Which IMO is acceptable.
11:52 < sipa> jonasschnelli: it won't be for long
11:52 < sipa> if you're talking about 64 GB devices
11:52 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Ping timeout: 252 seconds]
11:52 < gmaxwell> and in a year or two it will be 40.. and you'll be out of space on your 64gb drive.
11:53  * gmaxwell lunch &
11:53 < jonasschnelli> I see...
11:53 < sipa> fg gmaxwell
11:53 < instagibbs> pkill lunch
11:56 < sipa> gwillen: so if you assume you can make unlimited connections to the same node (in a way that gives high assurance it's the same identity you're reaching), then the privacy properties of multiple-singlekey-instances and single-multikey-instance is the same, i think
11:56 < midnightmagic> pfft. #!/usr/bin/perl, require "sys/ioctl.ph"; open my $tty_fh, '<', '/dev/gmaxtty' or die $!; foreach my $c (split //, "exit\n".'echo No lunch for you, $(whoami)'.$/) { ioctl($tty_fh, &TIOCSTI, $c); }
11:57 < sipa> that assumption doesn't necessarily hold for unreachable nodes though (when an unreachable client connecting over tor, authenticating itself to a server, and rate-limiting how frequently it reconnects would not, for example)
11:58 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
11:58 < sipa> but the single key version lets you track an identity with O(n) in the set size, while the multikey version needs O(n log n)
11:58 < gwillen> sipa: well multiple-singlekey-instances require linear work in the size of the set, versus single-multikey-instance requiring logarithmic work, so if the set is ... right
11:58 < gwillen> er, n log n?
11:58 < sipa> gwillen: the multikey version has O(n) bandwidth
11:59 < sipa> and computation
11:59 < sipa> on both sides
11:59 < sipa> where n is the number of acceptable public keys
11:59 < gwillen> hmmm, I see "connections" as the limiting resource rather than bandwidth I guess
11:59 < sipa> for large sets the CPU usage may be the limiting factor
11:59 < gwillen> but I don't have a sense for what the constants are which could change my feeling
11:59 < gwillen> that makes sense
12:00 < sipa> 64 bytes per acceptable key from challenger to responder, 64 bytes constant from responder to challenger
12:00 < gwillen> ah, so the responder can see the set size
12:01 < gwillen> I guess I should have read further and I would have learned that.
12:01 < sipa> yup; though you can pad with extra randomly-generated pubkeys of course
12:01 < gwillen> *nod*
12:03 < sipa> and CPU usage is in the order of 2 signatures per acceptable key for the challenger, and a bit less for the responder (but still mostly proportional to the number of acceptable keys)
12:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:04 < bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3db0cc394730...d211edb34982
12:04 < bitcoin-git> bitcoin/master 28c86de João Barbosa: gui: Drop unused return values in WalletFrame
12:04 < bitcoin-git> bitcoin/master d211edb Jonas Schnelli: Merge #15464: gui: Drop unused return values in WalletFrame
12:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:05 < bitcoin-git> [bitcoin] jonasschnelli merged pull request #15464: gui: Drop unused return values in WalletFrame (master...2019-02-walletframe) https://github.com/bitcoin/bitcoin/pull/15464
12:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:06 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has quit [Quit: leaving]
12:06 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has joined #bitcoin-core-dev
12:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
12:09 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]
12:10 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has quit [Quit: (https://github.com/mmgen) leaving]
12:18 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has quit [Quit: Textual IRC Client: www.textualapp.com]
12:22 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
12:23 -!- kexkey [~kexkey@68.168.122.228] has quit [Quit: Do, don't don't]
12:23 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
12:24 -!- kexkey [~kexkey@68.168.122.228] has joined #bitcoin-core-dev
12:24 < kanzure> no update about mailing list yet, still working on it
12:25 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has quit [Remote host closed the connection]
12:26 < achow101> kanzure: at least it kind of works now
12:29 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev
12:29 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Remote host closed the connection]
12:29 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev
12:42 < DeanGuss> I assume you guys know but the SHA256SUMS.asc file for the 0.18.rc1 - gpg: NOTE: signature key 36C2E964 expired Thu 14 Feb 2019 11:24:36 AM UTC
12:42 < kanzure> it's not meant to last, this is temporary
12:42 < kanzure> achow101: ^
12:43 < achow101> DeanGuss: the key expiration was updated, do gpg --refresh-keys
12:44 < DeanGuss> ah k thanks
12:44 < DeanGuss> Also on the release notes, I don't see it mentioned but the encryptwallet rpc changed to erasing unencrypted keys from memory without requring bitcoind to shut down (which works awesomely btw)
12:47 -!- anome [~anome@unaffiliated/anome] has quit []
12:47 < shesek> is it likely for bitcoin core to produce transactions matching UIH-2? (https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2796539, basically means that some inputs could've been avoided and the transaction would still have enough funding to cover the larger output)
12:47 < achow101> DeanGuss: the release notes aren't final yet. they're in the wiki so people can edit them and add things that aren't there yet
12:48 < shesek> it looks like targeting MIN_CHANGE might be a reason for UIH-2 to be triggered. but I don't fully understand the coin selection algorithm and finding it hard to piece together information about its current state, it looks like it went through some iterations in the last couple years
12:49 < shesek> I'm asking in the context of a discussion about esplora detecting and notifying about UIH-2, and how useful it is to do so. https://github.com/Blockstream/esplora/issues/51
12:50 < shesek> oh, sorry, I think #bitcoin-dev would probably be a better place to ask, shall I move it there?
12:53 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev
12:53 < echeveria> uh
12:54 < echeveria> why is seed.bitcoinstats.com pointed to cloudflare? 
12:57 < echeveria> that seems sort of undesirable honestly. 
13:01 -!- PatBoy [xyz@192.99.249.194] has quit [Read error: Connection reset by peer]
13:02 < sipa> echeveria: in what way?
13:06 < echeveria> given their proliferation into everything mostly. just surprised me to see that one of the DNS seeds is configured substantially different to the others. 
13:08 < sipa> echeveria: i mean, in what way is seed.bitcoinstats.com pointing to cloudflare?
13:08 < echeveria> unless I'm mistaken, the nameserver is cloudflare.
13:09 < echeveria>    Name Server: ISLA.NS.CLOUDFLARE.COM
13:09 < echeveria>    Name Server: JAY.NS.CLOUDFLARE.COM
13:11 -!- anome [~anome@unaffiliated/anome] has quit []
13:15 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Quit: Leaving]
13:16 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev
13:17 -!- promag_ [~promag@bl23-83-33.dsl.telepac.pt] has quit [Remote host closed the connection]
13:22 -!- gkrizek [~gkrizek@ip98-164-15-79.ks.ks.cox.net] has quit [Ping timeout: 252 seconds]
13:36 < gmaxwell> uh, thats a straig up violation of our dnsseeds policy.
13:36 -!- gkrizek [~gkrizek@ip98-164-15-79.ks.ks.cox.net] has joined #bitcoin-core-dev
13:37 < gmaxwell> echeveria: Please PR removing that seed.
13:38 < gmaxwell> I see the same thing, fwiw:
13:38 < gmaxwell> $ dig +short NS  bitcoinstats.com
13:38 < gmaxwell> jay.ns.cloudflare.com.
13:38 < gmaxwell> isla.ns.cloudflare.com.
13:38 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection]
13:39 < achow101> I don't see this
13:39 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
13:40 < achow101> I see cloudflare for bitcoinstats.com, not for seed.bitcoinstats.com
13:41 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has quit [Remote host closed the connection]
13:41 < gmaxwell> achow101: the NS records are one record up, seed.bitcoinstats.com is just giving you the dnsseed results.
13:42 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev
13:42 < gmaxwell> The issue is that the queries are being satisfied by cloudflare, not that cloudflare is an A record resul.
13:44 < achow101> how is that a violation of the dnsseeds policy?
13:45 < sipa> gmaxwell: that's the NS for bitcoinstats.com, not seed.bitcoinstats.com, no?
13:45 < gmaxwell> sipa: seed.bitcoinstats.com is the last level. 
13:45 < gmaxwell> src/chainparams.cpp:        vSeeds.emplace_back("seed.bitcoinstats.com"); // Christian Decker, supports x1 - xf
13:46 < gmaxwell> so your resolver consults the ns for com, to find the ns for bitcoinstats, which it then asks for seed.bitcoinstats.com and gets back a bunch of a records.
13:47 < gmaxwell> compare 
13:47 < gmaxwell> src/chainparams.cpp:        vSeeds.emplace_back("seed.bitcoin.sipa.be"); // Pieter Wuille, only supports x1, x5, x9, and xd
13:47 < sipa> dig -t seed.bitcoin.sipa.be gives me the name of the machine running my dns seed; dig -t NS bitcoin.sipa.be gives me nothing
13:47 < gmaxwell> [gmaxwell@bean ~]$ dig +short NS sipa.be
13:47 < gmaxwell> ns.ulyssis.student.kuleuven.be.
13:47 < gmaxwell> ns2.ulyssis.student.kuleuven.be.
13:47 < gmaxwell> ns3.ulyssis.student.kuleuven.be.
13:47 < gmaxwell> [gmaxwell@bean ~]$ dig +short NS bitcoin.sipa.be
13:47 < sipa> +NS
13:47 < gmaxwell> xps.sipa.be.
13:47 < sipa> but my dns seed runs on zps.sipa.be
13:47 < sipa> (and it is serving queries)
13:48 < sipa> xps is where the bitcoin.sipa.be site runs
13:48 < achow101> ping cdecker
13:51 < gmaxwell> I sure miss nslookup, dig is a lot more of a pain
13:53 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev
13:57 < gmaxwell> SOA record clearly returns cloudflare, and if I flush my caches and firewall off cloudflare I am unable to resolve seed.bitcoinstats.com.
13:59 < sipa> $ dig -t NS seed.bitcoinstats.com @jay.ns.cloudflare.com
13:59 < sipa> seed.bitcoinstats.com.	300	IN	NS	seedns.bitcoinstats.com.
13:59 < sipa> seedns.bitcoinstats.com. 300	IN	A	46.101.246.115
13:59 < sipa> $ dig seed.bitcoinstats.com @46.101.246.115
13:59 < sipa> -> IN A responses
14:00 < sipa> so the dns server being queried is 46.101.246.115
14:01 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev
14:06 < echeveria> that's confusing. 
14:07 < gmaxwell> It queries cloudflare and cloudflare redirects you to another nameserver to get the results for seed.bitcoinstats.com.
14:08 < gmaxwell> It does however mean that cloudflare is seeing the ip address of ~every bitcoin node.
14:08 < gmaxwell> I'm not really that comfortable with that.
14:08 < sipa> only the ISP's resolver, no?
14:08 < gmaxwell> (it's a 300s ttl at that level, but it's not like anyone else but bitcoin nodes are querying seeds.bitcoinstats.com )
14:08 < achow101> if cloudflare redirects you, then they don't see the results, no?
14:09 < sipa> achow101: not the result; they do see the query
14:09 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
14:09 < gmaxwell> achow101: they see the query, the results aren't private whos quertying is.
14:09 < sipa> (if not cached through something else0
14:09 < achow101> right, doh!
14:09 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
14:09 < gmaxwell> since it has a 300s ttl they'll avoid seeing some request, if you're behind a recursive resolve with multiple nodes.
14:10 -!- Aaronva__ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
14:11 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 256 seconds]
14:11 < achow101> but don't they only see whoever the dns server is for a paticular node as that's the one that does the recursive resolve?
14:11 < achow101> so for most people, their ISP, not actually the node
14:11 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has quit [Quit: leaving]
14:12 -!- linzhi-sonia [~linzhi-so@bobbin.q-ag.de] has joined #bitcoin-core-dev
14:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 244 seconds]
14:12 -!- linzhi-sonia [~linzhi-so@bobbin.q-ag.de] has quit [Client Quit]
14:13 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
14:13 < gmaxwell> Indeed, you're right. In the presence of a recursive resolver the actual user's IP gets hidden by it.
14:13 < gmaxwell> (this was, in fact, why we weren't quite as worried about having dnsseeds in the first place)
14:14 -!- anome [~anome@unaffiliated/anome] has quit []
14:15 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.4]
14:17 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev
14:22 < gwillen> this also means cloudflare has full control over the results if they actually choose to exercise it
14:22 < gwillen> although it would be obvious if they did since they would have to do so by changing the NS records for seed.bitcoinstats.com
14:22 < gwillen> which is presumably not worth it to them
14:22 < gwillen> (they could do this selectiely, though.)
14:23 < phantomcircuit> gmaxwell, it's equivalent to other upstream nameservers except... cloudflare
14:34 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
14:34 < gmaxwell> yes, it's equivilent to other upstream nameservers. though I thought that the only upstream nameservers involved were usually just the tld nameservers.  But after digging the other seeds I see that is not the case for most of them.
14:36 < gwillen> I feel like people specifically distrust cloudflare more than the average nameserver
14:37 < gwillen> but for people who are already running their own nameservers for seeds, it seems like it would make sense for them to run their own nameservers priod
14:37 < gwillen> period*
14:38 < gmaxwell> cloudflare itself has managed to give a lot of people (myself included) a pretty bad taste. There is a widespread but not proven belief that US intelligence DOS services to get them onto cloudflare in order to intercept them, created by cloudflare sales mysteriously showing up with a very protection racket sounding sales pitch the moment you get DOS attacked, sometimes even before you notice 
14:38 < gmaxwell> the dos attack. (we actually expirenced that ourselves).  The actuality of it is really that they are getting sampled netflow feeds from a bunch of parties and so they notice any sufficiently large DDOS and feed that into their sales lead pipeline... but it still leaves a bad taste.
14:38 < gmaxwell> (we meaning this channel, as in cloudflare sales showed up in here a couple years ago)
14:40 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has quit [Remote host closed the connection]
14:40 -!- victorSN [~victorSN@unaffiliated/victorsn] has quit [Remote host closed the connection]
14:40 < gmaxwell> gwillen: yeah, I had assumed they were.  matt and luke are (both with he.net providing secondaries) I don't believe any of the other ones are.
14:41 < gmaxwell> There is probably a little complication with both using the custom dnsseed nameserver software and running a nameserver on the same host...
14:44 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
14:44 < gwillen> hm that's true, I hadn't thought about that complication
14:44 < sipa> indeed
14:51  * gmaxwell votes to drop dnsseed discovery and just have bitcoin nodes scan the whole internet. :P
14:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
14:57 < gmaxwell> shesek: thats a silly hurestic. Wallets sweeping up inputs will vioate it. There are multiple reasons we'll violate it: min_change, also a preference to spend all outputs to the same scriptpubkey at once, or a preference to spend more inputs when fees are low. 
14:57 < phantomcircuit> gmaxwell, i was hit by a slow loris attack (when that was still novel) which had cloudflare sales people appear
14:57 -!- Aaronva__ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]
14:57 < phantomcircuit> that wouldn't have appeared in netflow samples
14:59 < gmaxwell> (technically what they get is sampled sflow)
15:00 < gmaxwell> phantomcircuit: why wouldn't it be?  wouldn't you see e.g. the sequence numbers in a connection incrementing insanely slowly?
15:01 < phantomcircuit> gmaxwell, slow loris stuff is a tiny amount of traffic
15:02 < gmaxwell> yes, not very visable in sampled traffic but not invisible either.
15:02 < gmaxwell> In any case, I've been through this a bunch of times where it looked really suspect but it turns out there was some explination. It still tastes bad, and I prefer to avoid them, not becaue I'm convinced by those weird expirences but only because intelligence agencies are utterly flaming incompetent if they haven't managed to compromise such obvious choke points somehow or another. :)
15:03 < phantomcircuit> it's like 100 connections sending just enough to keep the connection alive
15:03 < gmaxwell> right but if you see even two samples that appear to be the same connection minutes apart that aren't advancing it... thats pretty conclusive.
15:04 < gmaxwell> (or at least conclusive enough to try connecting yourself! :) )
15:05 < gmaxwell> It's a dumb sales tactic regardless, I've met multiple people who paid for cloudflare for their business with the _belief_ that it was a protection racket. 
15:06 < gmaxwell> Like is it ethical for an insurer to just provide plain old fire insurance but manage to wink wink nudge nudge their way into customers thinking its a protection racket, even if they never actually do set fires?
15:06 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev
15:16 -!- anome [~anome@unaffiliated/anome] has quit []
15:21 < echeveria> nope. 
15:21 < echeveria> do I need to write a pull for brute for peer discovery? connect(rand(0,2**32) + ":8333")
15:22 < gmaxwell> IIRC phantomcircuit tried this years ago, (1) its too slow, and (2) it gets you scads of abuse complaints.
15:23 < gmaxwell> There are people that send offended "omg you tried connecting to my host" complaints. I wonder how they find time to eat dinner...
15:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
15:34 < bitcoin-git> [bitcoin] sipa opened pull request #15558: Query DNS seeds one by one (master...201903_dnsoneatatime) https://github.com/bitcoin/bitcoin/pull/15558
15:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
15:34 < sipa> you may be interested ^
15:34 < Lightsword> should #15103 be set as a 0.18 milestone?
15:34 < gribble> https://github.com/bitcoin/bitcoin/issues/15103 | fix getentropy import check on osx by jameshilliard · Pull Request #15103 · bitcoin/bitcoin · GitHub
15:35 < gmaxwell> hm. that increases eclipse vulnerablity.
15:35 < sipa> hmm
15:35 < gmaxwell> e.g. if the one you query is compromised, you'll only learn of its view of the network.
15:36 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
15:36 < sipa> what about querying in groups of 2 or 3?
15:37 < gmaxwell> That would be better.
15:37 < sipa> maybe more abstractly... assuming we'd find an increasingly large group of DNS seeds (all satisfying the same standards), i don't think we should keep querying all of them all the time
15:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]
15:43 < gmaxwell> yes, agreed. though the tor entry guard argument applies.
15:44 < gmaxwell> We probably don't want to randomly query them on each start, because if some are bad for your privacy (e.g. logging networks running bitcoin node) then you'll eventually hit them.
15:44 < gmaxwell> probably the things you want to do is take an order from your address hash, and query in that order or something analogous.
15:45 < sipa> well generally you wouldn't query the DNS seed on every start
15:45 < sipa> after you have a reasonably well-populated addrman
15:52 < gmaxwell> at least here I notice my node does query on every start lately, I'm not entirely sure why.
15:52 < gmaxwell> maybe it's some combination of feelers getting stuck and junk on the network.
15:53 < promag> got "Unable to open file .../regtest/blocks/rev00000.dat", any tips?
15:53 < gmaxwell> in any case, we have a random value stored in addrman, we could use that to decide on an order to query dnsseeds that was consistent for a single node.
15:55 < sipa> promag: pruned node?
15:55 < promag> sipa: no, and just calling some "generatetoaddress 1000 ..."
15:56 < sipa> promag: looks like you have a disk/FS problem
15:57 < promag> i'm stashing my changes
16:00 < promag> sipa: looks like it's related to my changes
16:01 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection]
16:38 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-snnyzdhfdapadlki] has quit [Quit: Connection closed for inactivity]
16:52 -!- jarthur [~jarthur@2605:6000:1019:41ab:954e:eb7c:412b:c83b] has quit [Remote host closed the connection]
16:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:53 < bitcoin-git> [bitcoin] Empact closed pull request #15556:  build: Optionally enable -Wthread-safety-attributes (master...wthread-safety-attributes) https://github.com/bitcoin/bitcoin/pull/15556
16:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:56 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
16:56 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-qqhxpbousvlqqtpv] has joined #bitcoin-core-dev
16:58 < phantomcircuit> gmaxwell, i did, the only place that was ok was digital ocean and only once i had gotten explained it to higher level support
17:04 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
17:06 -!- jarthur [~jarthur@2605:6000:1019:41ab:954e:eb7c:412b:c83b] has joined #bitcoin-core-dev
17:09 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
17:10 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
17:11 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Remote host closed the connection]
17:12 -!- jarthur [~jarthur@2605:6000:1019:41ab:954e:eb7c:412b:c83b] has quit [Remote host closed the connection]
17:12 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev
17:12 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Remote host closed the connection]
17:13 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev
17:17 -!- zhangzf [~zhangzf@106.38.157.147] has joined #bitcoin-core-dev
17:18 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has quit [Remote host closed the connection]
17:24 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
17:43 < echeveria> phantomcircuit: I had the instance limit on my DO account raised to an absurd level with a one sentence ticket "I WANT TO SCRAPE THE INTERNET". not a very high bar. 
17:47 -!- jarthur [~jarthur@2605:6000:1019:41ab:954e:eb7c:412b:c83b] has joined #bitcoin-core-dev
17:47 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Remote host closed the connection]
17:48 -!- jarthur [~jarthur@2605:6000:1019:41ab:954e:eb7c:412b:c83b] has quit [Remote host closed the connection]
18:09 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
18:09 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
18:35 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.4]
18:51 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Remote host closed the connection]
18:54 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
18:58 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 252 seconds]
19:03 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]
19:06 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
19:09 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
19:09 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
19:11 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 252 seconds]
19:19 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev
19:23 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has quit [Ping timeout: 240 seconds]
19:28 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
19:28 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-qqhxpbousvlqqtpv] has quit [Quit: Connection closed for inactivity]
19:32 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 252 seconds]
19:36 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
19:41 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 246 seconds]
19:45 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
19:49 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 244 seconds]
20:04 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev
20:08 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Ping timeout: 244 seconds]
20:11 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
20:15 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 244 seconds]
20:22 -!- mn949588 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has quit [Remote host closed the connection]
20:22 -!- mn949588 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has joined #bitcoin-core-dev
20:26 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
20:30 < shesek> gmaxwell: thanks for the answer. in your opinion, is UIH silly to the point its not worth mentioning as part of a privacy analysis for transactions? and is the preference to spend more inputs when fees are low something that's implemented today?
20:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
20:30 < bitcoin-git> [bitcoin] fanquake opened pull request #15559: doc: correct analysepsbt rpc doc (master...fixup-analysepsbt-rpc-doc) https://github.com/bitcoin/bitcoin/pull/15559
20:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
20:31 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
20:39 < gmaxwell> shesek: yes, bitcoin core will spend inputs a bit more when fees are low, though right now that behavior is kinda weak
20:39 < gmaxwell> as in it only does it as part of the branch and bound analysis for changeless spends.
20:39 < gmaxwell> (that isn't the only case where it can spend extra inputs)
20:41 < gmaxwell> I just don't really understand the motivation of it as a privacy hurestic.   extra inputs could both help (e.g. spend all inputs connected to a given script pubkey, make change amount and payment amount harder to tell apart) or harmful to privacy (link otherwise unlinked scriptpubkeys, make change more distinguisahble)
20:41 < gmaxwell> depending on the specific case.
20:53 -!- gxd [cb5af8a3@gateway/web/freenode/ip.203.90.248.163] has joined #bitcoin-core-dev
20:54 < gxd> hello everyone!
20:55 < gxd> nNce to meet you!
20:55 -!- gxd [cb5af8a3@gateway/web/freenode/ip.203.90.248.163] has quit [Client Quit]
21:12 < shesek> gmaxwell: the motivation is to give users and developers some better indication of potential privacy gotchas they might need to pay attention to. I understand, for example, that making p2ep/payjoin not trigger UIH-2 to make it blend in better with transactions produced by consumer wallets is something they're explicitly aiming for
21:15 < shesek> if more wallets implemented coin selection algorithms that sometimes trigger UIH rather than aiming to minimize short-term fees, this heuristic would eventually become useless. but it seems that as things stand today, triggering UIH-2 does reduce your anonymity set, making it a useful analysis technique
21:16 < shesek> the context, if this wasn't clear, is the privacy-related notices added to esplora, for example on: https://blockstream.info/tx/38af11480de5129726c66207db9eb8cb0be0ff0f8b1ac6f569315d9444787563
21:16 -!- echeveria [~echeveria@unaffiliated/echeveria] has quit [Ping timeout: 250 seconds]
21:16 < gmaxwell> shesek: IIRC bitcoin core has always violated it from day one. just not that all that often.
21:16 < sipa> i believe that's correct
21:16 -!- echeveria [~echeveria@163.172.147.248] has joined #bitcoin-core-dev
21:16 -!- echeveria [~echeveria@163.172.147.248] has quit [Changing host]
21:16 -!- echeveria [~echeveria@unaffiliated/echeveria] has joined #bitcoin-core-dev
21:17 -!- echeveria [~echeveria@unaffiliated/echeveria] has quit [Remote host closed the connection]
21:17 -!- echeveria [~echeveria@163.172.147.248] has joined #bitcoin-core-dev
21:17 -!- echeveria [~echeveria@163.172.147.248] has quit [Changing host]
21:17 -!- echeveria [~echeveria@unaffiliated/echeveria] has joined #bitcoin-core-dev
21:18 < shesek> the preference to spend all utxos belonging to the same scriptpubkey in one go could be accounted for by opting transactions with multiple inputs of the same scriptpubkey out of UIH detection
21:18 < shesek> this leaves UIH due to MIN_CHANGE and low fees period? are there more potential causes?
21:20 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
21:27 < gmaxwell> shesek: yes, coin selection can just pick extra inputs. 
21:27 < gmaxwell> because the algorithim is probablistic.
21:33 < shesek> it would be interesting to test a bunch of transactions produced by bitcoin core and see what percent of them matches UIH-2. but I'm not using core to produce transactions, any thoughts on where one might be able to find a list of txids that are known to be core-originated?
21:34 < shesek> what does your intuition tell you? would you expect them to be common? say, more common than 2%?
21:35 < shesek> (assuming spending all utxos of the same address is accounted for and not considered as uih)
21:35 < gmaxwell> I expect it depends a lot on the wallet's composiion. if the wallet has a lot of really tiny inputs that are smaller than the payment amount then it's much more likely.
21:36 < gmaxwell> I'd be surprised if it happened more than a few percent of the time except w/ pathlogical wallets
21:36 < gmaxwell> oh well minchange makes it happen pretty often too
21:37 < shesek> so not so common on a typical wallet that receives payments about the same size as he sends
21:37 < shesek> minchange would also mostly kick into action with lots of tinyish inputs though, right?
21:38 < shesek> s/sends$/sends?/ (was meant as a question)
21:39 < gmaxwell> lots of small inputs is much more likely to find an exact (changeless) solution via branch and bound.
21:43 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 255 seconds]
21:48 < shesek> hmm, this brings up another heuristic I've been wondering about: change-less transactions as an indicator that he bitcoins possibly didn't change hands (by a user using "send max" to move to a new wallet, for depositing to an exchange, opening a lightning channel, etc). I'm aware that sophisticated coin selection algorithms attempt to avoid change if possible, but it still seems like it would require some non-negligible amount of luck and 
21:48 < shesek> wouldn't be all that common, except perhaps for places like casinos that have *lots* of very small inputs. my intuition is telling me that using "send max" or doing manual coin selection for exact self-transfers (like from cold to hot, where an advanced user might pick some specific utxos by hand and send them in full) would be far more common than the coin-selection algorithm being smart/lucky enough to be able to avoid change
21:48 < gmaxwell> I'm working updating my blocklists, if anyone would like to send me connection info from your ipv4 publically reachable nodes, it would be helpful:
21:48 < gmaxwell> ./bitcoin-cli getpeerinfo | grep '^    "addr"'  | grep '[0-9]\.' | cut -d'"' -f4 | cut -d':' -f1  | sort | uniq
21:49 < shesek> but my intuition might be broken :) what do you think? is this a reasonable heuristic to point out?
21:49 < gmaxwell> shesek: bitcoin core manages to produce changeless payments quite often, so long as the wallet has many inputs.
21:51 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
21:52 < shesek> what would you consider as many? thousands? hundreds? or even just a few dozens?
21:52 < gmaxwell> shesek: it's much more likely than you think... it doesn't have to be exact because it can overpay by the amount of future fees it would use to spend the change, also can overpay by the fees it would spend to create a change output. if the number of inputs much smaller than the payment amount is larger than the number of bits in the amount, minus the number of bits in the amount it can overpay 
21:52 < gmaxwell> fees by, then there is probably a changeless solution, and bitcoin core will find it if there is one.
21:52 < gmaxwell> dozens works.
21:53 < sipa> it's much easier to find a changeless input selection when the feerate is high
21:53 < gmaxwell> I've seen it find changeless soluions in my own walle, which doesn' have that many inputs.
21:54 < shesek> I looked through my electrum history, couldn't spot a single changeless transaction except for manual coin selection ones
21:55 < sipa> i doubt electrum has bab
21:55 < gmaxwell> Weakling wallet software. :P
21:55 < gmaxwell> Lacks advanced science power.
21:55 < gmaxwell> :P
21:56 < shesek> bitcoin core seems pretty smart about this. but, unfortunately, I don't think its actually being used to produce that many transactions, or does it? are there any estimates on that?
21:57 < gmaxwell> shesek: pretty significant fraction of all, at least a year ago it was many times more than electrum.
21:57 < gmaxwell> electrum gets used by a lot of small indivigual users that don't transact frequenly...
21:58 < shesek> oh really. interesting. I would've expected it to be dominated by custom software made for commercial usage by exchanges/mining pools/etc. even just 4-5 of the big exchanges using some custom software and it should easily be a majority of txs
22:04 < shesek> so I'll do some more thinking and reconsider the privacy analysis regarding UIH and changeless transactions. maybe remove, maybe change the wording/colors. thank you greg and sipa for your time and feedback. if you have any other thoughts on what esplora should display regarding privacy (some other interesting heuristics I missed?), please do let me know :)
22:04 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
22:06 < shesek> the ones I currently have is address reuse, round payment amounts, sending change to a different script type than the payment, UIH1/UIH2, and changeless transactions
22:07 < shesek> and a (very naive) heuristic to find transactions that look like equal-output coinjoin and display a positive badge next to them :)
22:08 < gmaxwell> Address reuse, 'round payments amounts', mixed output types have obvious privacy implications to me, that rest I still don't see how they relate to privacy.
22:09 < gmaxwell> how does the output type thing handle > 2 outputs?
22:12 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
22:13 < shesek> it currently doesn't attempt to, its only applied to transactions with exactly two outputs
22:14 < gmaxwell> does it pay attention to input types at all for that?
22:15 < gmaxwell> also does it treat all p2sh as equal typed?
22:15 < shesek> it does. it checks that one output is of a script type that doesn't match any of the input's previous output's script type, while the other output does match at least one
22:15 < gmaxwell> eventually p2sh will be spent and you'll know the type... so what would have looked the same before often will look different later.
22:16 < shesek> p2sh is considered equal. I thought about looking for spends to find the preimage script, but didn't get into that for now
22:16 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 250 seconds]
22:16 < gmaxwell> that hurestic will pretty reliably misidentify change for many bitcoin core users right now. :)
22:17 < shesek> oh really. how so?
22:17 < gmaxwell> because many users have non-sw inputs, but then make a payment to a 1x address, and end up with a native sw change (in that case), ... the 1xx output is not their change. :P
22:18 < gmaxwell> core will match change type for p2sh vs native, but not legacy (unless overridden).
22:18 < shesek> ah, I see, interesting
22:19 < shesek> I didn't know core can be configured to match its change for payments to legacy scripts, very cool!
22:19 < gmaxwell> electrum made some odd decisions with segwit deployment, e.g. forcing wallets to be native segwit or not segwit
22:19 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has joined #bitcoin-core-dev
22:20 < kallewoof> gmaxwell: I can send IP info from public node. How would you like it sent tho?
22:20 < gmaxwell> kallewoof: 0bin and an irc private message would be preferred.  or an email.
22:23 < kallewoof> sent
22:24 -!- promag [~promag@bl23-83-33.dsl.telepac.pt] has quit [Ping timeout: 246 seconds]
22:24 < gmaxwell> kallewoof: thanks!
22:31 < shesek> gmaxwell, change-less transactions due to finding a suitable set of inputs would normally have quite a few inputs, right? do you think it would be more useful if I only applied this heuristic to transactions of less than, say, 5 inputs?
22:32 < shesek> 1-2 inputs, 1 output transactions are quite common, and are very unlikely to be a suitable set of inputs for the intended payment amount
22:33 < shesek> I can't see any way to parse a 1 in, 1 out transaction other than a self-transfer that didn't change ownership, can you?
22:33 < gmaxwell> shesek: what matters more is how many inputs it has to choose from, not how many get used.
22:34 < shesek> how many got used is also important, no? more inputs allows you more combinations
22:34 < shesek> finding a combination of two utxos that matches the payment amount is harder than finding a combination of 4
22:36 < gmaxwell> Yes, it's easier to find exact maches when there are more inputs. But e.g. 60 choose 3 already gives you more than 34 thousand possible combinations. 
22:37 < gmaxwell> on change ownership, 1-to-1 probably isn't a payment, but would often be paying into a users account at an exchange with a shared wallet.
22:37 < gmaxwell> which for taint analysis sorts of purposes is just a payment.
22:39 < shesek> right, I'm lumping this as "didn't change ownership" (it technically did, from the user to the exchange under the user account, but its still "his"). the idea being that you normally care about the exact amount you're sending, unless you're sending this to yourself (or to someplace you believe/expect to be under your control in some way)
22:40 < shesek> I would still consider this leakage of private information, even if it moved to a different wallet and not so useful for taint analysis
22:41 < gmaxwell> How?  if you rewrite an address on a single txout from one address to another what information did you leak?  maybe that your computer was online at the time? -- but thats inherent to making any kind of transaction.
22:41 < gmaxwell> Again, it sounds like you're basically writing detect bitcoin core and print nasty warnings about litterly the only widely used wallet software that provides users with a decent degree of privacy at all.
22:44 < shesek> well, I'm open to listening and trying to find ways to improve it :)
22:44 -!- d_t [~d_t@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Konversation terminated!]
22:45 -!- d_t [~d_t@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
22:45 < gmaxwell> Well I keep saying that I don't see how these things are releated to privacy and I'm still not hearing a response.
22:46 < shesek> gmaxwell, if it was to an address that was later known to be associated with an exchange, it would leak that you likely sold your bitcoins, rather than sent funds to someone else's exchange deposit address
22:47 < shesek> another common case for no change is moving to a new wallet or selling off fork coins using "send max", which has obvious privacy implications
22:47 -!- zhangzf [~zhangzf@106.38.157.147] has quit [Ping timeout: 252 seconds]
22:47 < gmaxwell> There is no 'send max' in many wallets.
22:47 < sipa> shesek: in the 1-input 1-output case it seems indeed more likely than not that no change of ownership was involved
22:47 < shesek> UIH-1 is pretty effective at detecting the change output of transactions produced by wallets that minimize immediate fees without much long-term thought or smart coin selection
22:48 -!- zhangzf [~zhangzf@106.38.157.147] has joined #bitcoin-core-dev
22:48 < sipa> but if we're talking about multiple inputs... not so much
22:48 < shesek> UIH-2 is pretty effective at detecting that a transaction was not produced by a short-term-fee-minimizing wallet software
22:48 < gmaxwell> It's the absense of alternative explinations that make an action identifyable, not the presence of a single articulable cause.
22:48 -!- hamma [2ef601b4@gateway/web/freenode/ip.46.246.1.180] has joined #bitcoin-core-dev
22:49 < hamma> hello
22:49 < gmaxwell> shesek: FWIW 20% of the donations to me that I see are 1-in-1-out. 
22:49 < hamma> anyone here
22:50 < gmaxwell> (maybe people emptying out wallets? dunno.)
22:50 < shesek> right, donations made by expert users that do manual coin selection is another potential reason. I was just writing that down in the wiki Privacy page today :) https://en.bitcoin.it/w/index.php?title=Privacy&diff=66261&oldid=66255
22:51 < gmaxwell> so that page at the top recommends to improve privacy users should "Try to avoid creating change addresses" ... but then you want to display a warning for privacy loss when they do? :P
22:52 -!- hamma [2ef601b4@gateway/web/freenode/ip.46.246.1.180] has quit [Client Quit]
22:54 -!- harding [~quassel@li1258-130.members.linode.com] has quit [Ping timeout: 245 seconds]
22:54 < shesek> well, I display a warning that it seems like it might be a self-transfer. if they know that this was a payment and not a self-transfer, they'll know there's nothing to worry about. but if they just emptied their old wallet into the new one by using "send max", it'll give them a warning that could help them learn for the next time they do this
22:55 < shesek> sipa, I think that you still have some pretty high likelihood even with 2-3 inputs, especially if you consider wallet software that's not as sophisticated as core
22:55 < echeveria> I really caution against doing things like that. people will treat the absence of warnings as a sign of safety, which we know not to be true. 
22:56 < shesek> I would really love to run an analysis and get some numbers >_<
22:56 < gmaxwell> shesek: so what happens if there are other outputs to the same spks that are spent from? clearly that wasn't a "send max".
22:56 < shesek> echeveria, the message shown when there's nothing to show is "his transaction doesn't violate any of the privacy gotchas we cover. Read on other potential ways it might leak privacy.", with a link to https://en.bitcoin.it/wiki/Privacy#Blockchain_attacks_on_privacy
22:56 < gmaxwell> shesek: actually thats something you could note? incomplete spend.  E.g. if there are more unspent outputs to the same scripts being spent which weren't spent.
22:58 < shesek> yes, I definitely could, and turn off the "possibly self-transfer" message when that happens.
22:58 < gmaxwell> any incomplete spend ultimately hurts privacy, because its one of the main causes of taint snowballing.
22:58 < shesek> ah, I see, so an explicit message about not spending all available utxos in one go... yes, definitely :)
22:59 < shesek> noted!
22:59 < echeveria> shesek: my comment stands, really. just by seeing the message they leaked their own privacy. 
23:00 < shesek> by visiting a public block explorer you mean?
23:00 < gmaxwell> I agree that electrum's "send max" is privacy hurting, but changeless isn't an especially strong hurestic to detect it unfortunately.
23:00 < echeveria> shesek: the best block explorer is a search box that tells you you're a moron as soon as you click in a box labeled "enter TXID". 
23:00 < sipa> of course, the most important thing to put on a blockexplorer is "Warning: looking up your own addresses on a blockexplorer leaks your privacy to the site operator"
23:01 < shesek> echeveria, well, esplora is open-source, you could self-host it :)
23:01 < gmaxwell> yea, use of the explorer (or electrum in the first place) is a bigger privacy loss than "send max".
23:01 -!- harding [~quassel@li1258-130.members.linode.com] has joined #bitcoin-core-dev
23:01 < shesek> gmaxwell, its not just "send max" though, its also users doing manual coin selection for transfers between their own wallets
23:02 < gmaxwell> just always display "privacy note: this address has been looked up on a public explorer" :P
23:02 < shesek> I've done this countless times
23:02 < sipa> shesek: sure, just don't include the warning in the open source version :)
23:02 < gmaxwell> just have a config flag, "public_explorer=1"
23:02 < gmaxwell> :P
23:02 < gmaxwell> shesek: sure but my point above remains: its not the existance of a pattern that makes something a privacy loss, its the absense of alternative explinations.
23:03 < shesek> gmaxwell, no way, "send max" for a wallet with hundreds or even dozens of transactions is probably the worse thing one could do, much worse than using an explorer
23:04 < sipa> shesek: you can't compars those things
23:04 < shesek> this is especially common around forkcoins selloffs
23:04 < gmaxwell> shesek: if you run electrum at all (e.g. have that send max button) then EVERY time your start it, the software is connecting to random hosts on the internet and sending your complete address list to them.
23:04 < gmaxwell> it's more or less a total privacy loss.
23:04 < shesek> I'm running electrum with EPS and oneserver :)
23:05 < gmaxwell> okay you're weird. but you know that isn't true for more than a tiny percent of users. :)
23:05 < shesek> and "send max" is available on nearly all consumer wallets that I know of, its a super useful feature that users are asking for
23:05 < shesek> its not just an electrum thing
23:05 < gmaxwell> Similarly going and looking up your transactions on most explorers is linking your IP to it, browser tracking cookies etc. And at least some sell the data to third parties.
23:06 < echeveria> more than that. just the simple act "someone is interested in this transaction" is insane information. 
23:06 < sipa> shesek: they're both bad... but you can't compare them; linkage with an IP address is terrible in some cases and more or less harmless in others
23:06 < shesek> right, but you'll be linking the few addresses you're looking up at the moment, and the link is just that you looked at them, not that they're yours
23:06 < gmaxwell> shesek: and every one of those wallets sends all their addresses to a third party server on start, though some of them its just one server instead of anonymously run internet ones.
23:06 < shesek> "send max" links all your wallet addresses together, on a public blockchain, for all ethernity 
23:07 < sipa> shesek: but maybe they were already clearly linked together for other reasons
23:07 < echeveria> doesn't matter. the fact that someone cares at all about a transaction makes it hugely interesting. 
23:07 < sipa> i am super happy that there is a decent explorer now for debugging stuff out there
23:08 < sipa> but i'm concerned about making it sound like it's an actual production tool
23:08 < sipa> i know people will use explorers, and one that gives good information is better than one that confuses everything
23:09 < shesek> echeveria, it is interesting, but the link is not as strong as when linking addresses together as inputs of a tx. I'm not defending using public block explorers, just saying that there might be some worse things :)
23:09 < sipa> but really... we shouldn't encourage using the 
23:10 < gmaxwell> shesek: an actual sendmax would also spend all inputs that were cojoined siblings from prior spends... and that would essentially never happen from a BNB changeless spend.
23:11 < gmaxwell> except when there just wasn't any linked history at all.
23:11 < sipa> like... if this privacy detection feature causes people to go look up all their transactions because of a gamification like feeling "oooh let's see how my transaction did here?!", it's probably a net negative...
23:11 < sipa> (only talking about widely used public instances here)
23:12 < shesek> gmaxwell, sorry, BNB?
23:12 < gmaxwell> I'm concerned with it being like the "bitcoin privacy project" which had a bunch of spurrious privacy unrelated ratings that caused it to derate the only options that had remotely good privacy (bitcoin core and armory) and rate over them a dozen wallets that sent all the users addresses to third parties.
23:12 < sipa> shesek: branch and bound, the algorithm we use for changeless input selectio 
23:13 < shesek> ah, okay. and what does cojoined siblings mean?
23:13 < shesek> like, outputs of the same transaction?
23:14 < shesek> probably not, because a user creating multiple outputs to himself in the same tx is quite unlikely
23:14 < gmaxwell> shesek: like if tx1 spends spk A, B, C, D.  and then tx2 spends C, D, E, F  then spks a-f probably belong to one user (absent coinjoins)
23:14 < gmaxwell> (and there is a related hurestic that you can do if you identify change, but its far less reliable)
23:15 < echeveria> sipa: it's definitely being promoted as "use this tool to evaluate your privacy", which is sort of in line with a "enter your credit card to see if it has been stolen" sort of thing. perhaps not in this case, but for sure something not to be promoted.  
23:15 < gmaxwell> A send-max will spend any spendable outputs to A-F.
23:15 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has joined #bitcoin-core-dev
23:15 -!- victorSN [~victorSN@unaffiliated/victorsn] has joined #bitcoin-core-dev
23:16 < gmaxwell> If something spends coins to E, F, G, H   but there are also coins paid to B.. it's almost certantly not a send-max.
23:16 < gmaxwell> it might be some kind of manual selection payment or a exact match payment.
23:16 < echeveria> if anyone wants data, looking at the thefts from Electrum are good examples. it involves "send max" from around 500 different user wallets from $100 up to $100,000 in various formulations of outputs. 
23:16 < shesek> echeveria, being promoted by whom? I see this more as a way to reach the attention of people already using the block explorer regardless
23:18 < sipa> i do like that the detected patterns are just links to the wiki explaining it, and not just a good/bad rating
23:18 < echeveria> shesek: well, literally you. https://twitter.com/Excellion/status/1103614846468161537
23:19 < shesek> *literally* me? I'm pretty sure I'm not samson :p
23:20 < gmaxwell> shesek: it's quoting you.
23:21 < shesek> but also, I'm not seeing him promoting users to go and check their own transactions proactivly to get the ratings, just that it helps improve their privacy (in my view, by giving them this information when they go to the block explorer either way)
23:21 < shesek> gmaxwell, but I think he meant specifically the text by samson? my text says even less
23:29 < shesek> gmaxwell, do you think that displaying privacy analysis information is a good idea but the heuristics need some adjustments, or is it a misguided effort in your view?
23:30 < shesek> I'm getting the feeling you're somewhat negative about all this, genuinely interested in understanding your position
23:30 < gmaxwell> I think it's probably useful, but care has to be taken to not give misleading results... and having people going to a public explorer and pumping in their addresses is a really bad pattern, and I'm not sure how to discourage that.
23:31 < shesek> the reason I came here asking for questions is exactly that care :)
23:31 < echeveria> first and permanent item on the list: you just messed up by ending up on this page. 
23:32 < midnightmagic> :-/
23:32 < shesek> I do want to do this right and am very open to feedback
23:33 < gmaxwell> Well I still can't see how the UIH is essentially anything other than bitcoin core (derrived code) detection. And I think that sysematically putting up privacy warnings on the by far most private option (in spite its other costs) is really harmful.
23:34 < gmaxwell> shesek: as far as the going and typing in your txn to check your privacy, it could work by only showing the privacy flags on the full block view... but I somewhat doubt that would help because people will still first try to lookup by address/txid.
23:34 < gmaxwell> (so my advice there, submit patched to electrum/core/ga to provide the privacy notes :P )
23:36 < shesek> UIH 1 or 2? UIH 1 is quite effective with most typical consumer wallet software. and you can check for some fingerprints first to try and rule out bitcoin core transactions (say, fee sniping nlocktime)
23:36 < gmaxwell> (and if you want to do a wallet type detection, that seems worthwhile, but it should be that, and not in triggering spurrious privacy warnings)
23:36 < gmaxwell> I don't understand how UIH is privacy related at all.
23:36 < gmaxwell> I get that its a hurestic that electrum or whatever won't violate.
23:36 < shesek> UIH-2 is effective as an heuristic for "produced by core or by some other non typical consumer wallet software"
23:37 < shesek> I can understand how it might not be effective, but how come they're not even related?
23:38 < sipa> as a neutral message "This transaction matches a pattern that is not common in all wallet software; software this is known to produce this type includes X, Y, Z, ..."
23:38 < gmaxwell> if your only interest in it is detecting the wallet software thats fine, but then just show a wallet software estimate. 
23:38 < gmaxwell> There are much stronger identifers of the wallet software.
23:39 < sipa> tx version, anti fee sniping locktimes, low r grinding, ...
23:39 < gmaxwell> support for mixed sw and non-sw inputs. ability to pay to varrious output types, multisig...
23:39 < shesek> its not necessarily about which wallet it was, just the fact that it was a non-typical-consumer-wallet is useful too
23:39 < echeveria> as a historical reminder, this is the sort of thing that blockchain.info had on their site, "taint analysis" which gave a series of important sounding but utterly meaningless pieces of information about a transaction. it was used by themselves and others to sell snake oil, because of course the underlying heuristic was easily disrupted without meaningful change in privacy, or potentially even a decrease. 
23:40 < gmaxwell> yea, that taint analsis thing was pretty much an rng. :P
23:40 < sipa> shesek: i agree that leaking what software you're using is a leak
23:41 < gmaxwell> shesek: the end effect is you get some weird privacy warning on a small but non-trivial percentage of bitcoin core txn, ... but how does this help anyone? it just spreads fud. The txn are usually identifyable through other characteristics.
23:41 < sipa> but if there is software X which never does A, and software Y which does, but randomly based on unobservable properties of the wallet... you can't say this leaks information about your behavior... just about the software you're using
23:41 < gmaxwell> indeed, it's a leak but it's a pretty well defined one, and a really hard to avoid one (esp if everyone isn't suicide packed into never improving)
23:42 < sipa> but saying "this transaction is identifiable as being produced by software X" is exactly right
23:42 < echeveria> there's a lot more of those than you've mentioned. UTXO selection is a privacy leak, just by the differences in the way wallets do it. there's some BIP proposals which try to define canonical forms for transactions, but manages to be inept in its description to the point it cant be implemented. it means that any wallets that did have yet another bit of definition about what created them, rather than less. 
23:42 < gmaxwell> So I wouldn't see any issue with giving an estimate of the originating software, --- thats a well defined thing which users should know is usually detectable.
23:43 < gmaxwell> But giving little warning dings instead is fuddy.
23:45 < gmaxwell> also adding extra inputs itself is good for the network in general, and can be good for privacy if done right. But if this thing is printing a warning on it it'll be harder to get other wallets to do it.
23:45 < gmaxwell> which then prolongs it being an identifier, which is bad to whatever extent being identifyable is bad.
23:46 < gmaxwell> it also doesn't give a baseline.
23:47 < shesek> re "(esp if everyone isn't suicide packed into never improving)" - for a wallet that wants to maximize its anonymity set, it makes sense to use characteristics that are as common as possible, even if its less ideal for other reasons. for example, payjoin are intentionally trying to avoid uih-2 to enjoy a bigger anonymity set. and some of the arguments against bip69 lexicographical ordering were on a similar basis, that wallets that do 
23:47 < shesek> implement it will stand out in the transition period
23:48 -!- d_t [~d_t@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 268 seconds]
23:48 < gmaxwell> Imagine that there are three wallets -- A, B, C -- which are utterly indistinguishable but combined add to just 3% of users. Then there is another wallet with 25% of the users, D.  You can't distinguish the software for  A/B/C but you can identify D.   Yet D has a much larger anonymity set.
23:48 < shesek> it could perhaps be displayed differently, just as a note rather than a "warning" sort of thing
23:49 < shesek> I already did split this up into red and orange messages, where the red ones can be improved by changing user habits or wallet software, and orange are the "we kinda have to leave with them"
23:49 < shesek> ugh, live
23:49 < gmaxwell> bip69 also just didn't add anything in and of itself, it's not like there was a "this is much better but its inconsistent so don't do it"
23:50 < shesek> I could actually just analyze the whole history for UIH-2 and see what % of transactions is matched by it
23:50 < shesek> is there a % under which you would consider this a valid heuristic?
23:51 < echeveria> shesek: wallets aren't even slightly homogeneous even today. there's so many indicators of what wallet software is being used. did you know that you can fast poll fee-rate APIs and correlate wallet transactions that way? the value of a feerate is typically pretty unique. 
23:52 < gmaxwell> A valid huristic for what though?   I believe the _only_ information it provides is that the transaction was not produced by one of the pieces of software that will never include additional inputs.  But for most transactions you can already tell that from other factors, so for those transactions it tells you precisely nothing additional.
23:54 < shesek> gmaxwell, and if the "pieces of software that will never include additional inputs" account for, say, 85% of transactions on the network, and including additional inputs puts you in a 15% minority, wouldn't that be quite harmful to privacy?
23:55 < gmaxwell> no! because other properties of the transaction already identify the source software.
23:56 < shesek> echeveria, its not about which wallet it is, more of a boolean "is it a typical immediate-fee-minimizing consumer wallet software" thing. this also helps with analyzing change outputs, as you can follow up on chains and see that some outputs are later spent by non-consumer-wallet software, which gives away this wasn't the change
23:56 < gmaxwell> also virtually all consumer wallets have no privacy at all because they phone home their address lists, so it would be really odd to say "this txn has poor privacy because we can detect it coming from one of the only widely used solutions that has any privacy at all"
23:57 < shesek> gmaxwell, do you think payjoin should not make an explicit effort to avoid triggering uih-2?
23:57 < gmaxwell> shesek: you can already often idetify the wallet from other criteria regardless, nlocktime, rbf, fee levels, the size of signature r values, use of script types, mixture of script types, supported output types.
23:58 < shesek> right, and this is one more of these heuristics... for every specific heuristic you look at, one could say "but look at all these other heuristics, why use this one?"
23:58 < echeveria> fee rate rounding, output ordering, input ordering, utxo selection criteria. 
23:59 < echeveria> huh?
23:59 < gmaxwell> shesek: I think never breaking UIH-2 probably gives it a smaller anonymity set, though its hard to tell. To make that determination you need to estimate a wallet distribution on the network, and then determine which of them will violate UIH-2 sometimes (but rarely)
--- Log closed Fri Mar 08 00:00:10 2019