--- Day changed Wed May 06 2020
00:05 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-pr-reviews     
00:48 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]     
01:15 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
01:21 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]     
02:24 -!- robot-visions [~robot-vis@172.92.4.53] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
03:17 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
03:22 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds]     
03:33 -!- kristapsk___ is now known as kristapsk     
03:46 -!- AlistairMann [~am@host31-52-25-35.range31-52.btcentralplus.com] has quit [Quit: Leaving.]     
03:46 -!- AlistairMann [~am@host31-52-25-35.range31-52.btcentralplus.com] has joined #bitcoin-core-pr-reviews     
03:51 -!- as_pnn [~pierreirc@119.192.247.147] has joined #bitcoin-core-pr-reviews     
03:53 -!- as_pnn [~pierreirc@119.192.247.147] has quit [Remote host closed the connection]     
04:43 -!- brakmic [~brakmic@185.183.85.108] has quit [Remote host closed the connection]     
04:43 -!- brakmic [~brakmic@185.183.85.108] has joined #bitcoin-core-pr-reviews     
04:50 -!- jonatack_ [~jon@37.166.24.197] has joined #bitcoin-core-pr-reviews     
04:53 -!- jonatack [~jon@37.164.75.174] has quit [Ping timeout: 256 seconds]     
05:01 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
05:02 -!- jonatack_ [~jon@37.166.24.197] has quit [Quit: jonatack_]     
05:04 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 258 seconds]     
05:04 -!- brakmic_ [~brakmic@ip-176-198-41-116.hsi05.unitymediagroup.de] has joined #bitcoin-core-pr-reviews     
05:06 -!- brakmic__ [~brakmic@185.183.85.108] has joined #bitcoin-core-pr-reviews     
05:07 -!- brakmic [~brakmic@185.183.85.108] has quit [Read error: Connection reset by peer]     
05:09 -!- brakmic_ [~brakmic@ip-176-198-41-116.hsi05.unitymediagroup.de] has quit [Ping timeout: 260 seconds]     
05:15 -!- brakmic [~brakmic@ip-176-198-41-116.hsi05.unitymediagroup.de] has joined #bitcoin-core-pr-reviews     
05:17 -!- jonatack [~jon@37.166.24.197] has joined #bitcoin-core-pr-reviews     
05:18 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
05:19 -!- brakmic__ [~brakmic@185.183.85.108] has quit [Ping timeout: 256 seconds]     
05:20 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews     
05:21 -!- jonatack_ [~jon@134.19.179.195] has joined #bitcoin-core-pr-reviews     
05:21 < thomasb06> Hello. The meeting is today?
05:21 -!- jonatack [~jon@37.166.24.197] has quit [Ping timeout: 272 seconds]     
05:21 < jonatack_> thomasb06: yes, see https://bitcoincore.reviews for info
05:21 -!- jonatack_ [~jon@134.19.179.195] has quit [Client Quit]     
05:22 -!- jonatack [~jon@134.19.179.195] has joined #bitcoin-core-pr-reviews     
05:23 < thomasb06> jonatack: hey. Yep, I come from there. Thanks
05:23 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]     
05:24 < thomasb06> jnewbery: hi, I sent you an email yesterday, but maybe it landed in the spam bin...
05:53 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
05:56 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds]     
06:12 -!- brakmic_ [~brakmic@185.183.85.108] has joined #bitcoin-core-pr-reviews     
06:12 < thomasb06> If I clone the repo, it will take 200G? My disc is 60 only...
06:16 -!- brakmic [~brakmic@ip-176-198-41-116.hsi05.unitymediagroup.de] has quit [Ping timeout: 256 seconds]     
06:16 < pinheadmz> thomasb06: no the bitcoin repo itself is only a few hundred MB
06:16 < pinheadmz> the "200GB" is from downloading the mainnet blockchain
06:18 < thomasb06> this what seemed more logical, but I had to ask first... Thank you, let's go.
06:20 -!- brakmic [~brakmic@ip-176-198-41-116.hsi05.unitymediagroup.de] has joined #bitcoin-core-pr-reviews     
06:21 -!- brakmic__ [~brakmic@185.183.85.108] has joined #bitcoin-core-pr-reviews     
06:22 -!- brakmic_ [~brakmic@185.183.85.108] has quit [Read error: Connection reset by peer]     
06:24 < jonatack> 200 GB? heh, i'm seeing 293 GB just for /blocks
06:25 < jonatack> another 25 GB for /indexes and 30 GB more for testnet
06:25 -!- brakmic [~brakmic@ip-176-198-41-116.hsi05.unitymediagroup.de] has quit [Ping timeout: 264 seconds]     
06:26 < thomasb06> from a 60G point of view, 293+25+30~200...
06:26 < jonatack> .bitcoin is 381 GB in total for me
06:26 < thomasb06> you're right, though
06:32 < thomasb06> (for some time, I going to need catch up a few things before being operational...)
06:34 < thomasb06> (ToDo list: https://lab.github.com/githubtraining/introduction-to-github and https://lab.github.com/everydeveloper/introduction-to-python)
07:19 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
07:24 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds]     
07:38 < jnewbery> Hi thomasb06. Yes, I saw your email. You're doing the right thing by coming to review club. Did you review the PR already?
07:39 < thomasb06> hey, cool... It's the first time I come to the PR review
07:41 < thomasb06> but before to start to write some python code, I need get acquainted with the workflow and the tools... It's all too new
07:53 < jnewbery> you'll pick it up in no time. There are some great onboarding tips here: https://medium.com/@amitiu/onboarding-to-bitcoin-core-7c1a83b20365 and here: https://jonatack.github.io/articles/how-to-review-pull-requests-in-bitcoin-core. We were all beginners once, and review club is a great place to ask questions
07:56 < thomasb06> "Whether you tune in to the meeting and just lurk or spend time spelunking around the code ahead of time and participate, you are sure to learn a lot." -perfect-
08:00 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has joined #bitcoin-core-pr-reviews     
08:00 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has quit [Client Quit]     
08:01 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has joined #bitcoin-core-pr-reviews     
08:02 < jnewbery> happy spelunking!
08:05 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
08:08 < jnewbery> we'll get started in just under two hours
08:09 < thomasb06> (I stay before my screen)
08:11 < brikk> welcome thomasb06!
08:12 < thomasb06> Hi brikk
08:12 < thomasb06> thanks
08:15 -!- bobsmith [60e78d69@pool-96-231-141-105.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
08:15 < bobsmith> hey now
08:20 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
08:35 < thomasb06> I'm trying to do programmingbitcoin,
08:35 < thomasb06> but the command virtualenv -p python3 .venv $ . .venv/bin/activate (.venv) $ pip install -r requirements.txt
08:35 < thomasb06> returns 'zsh: unknown file attribute: v'
08:36 < thomasb06> any idea about what is going on?
08:36 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds]     
08:37 -!- bordalix [~bordalix@191.87.108.93.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews     
08:40 < raj_149> not sure but try: $pip3 install -r ./requirements.txt
08:41 < thomasb06> it says "install: invalid option -- 'r'", but thanks for the answer
08:43 < raj_149> can you see the "-r" option by doing pip3 install -h?
08:43 < thomasb06> it's the first one:
08:43 < thomasb06> Install Options:
08:43 < thomasb06>   -r, --requirement <file>    Install from the given requirements file. This option can be used
08:43 < thomasb06>                               multiple times.
08:43 < thomasb06>       
08:44 < raj_149> ya, so pip3 is working, -r should work too.
08:44 < theStack> thomasb06: looks like actually the binary 'install' is executed, and not the expected 'pip3' oO
08:45 < thomasb06> arg, my fault: I included the '$'...
08:46 < theStack> thomasb06: aah, then your shell probably interpreted the $pip3 as variable, which is empty
08:47 < thomasb06> this is the explaination
08:48 -!- brakmic__ [~brakmic@185.183.85.108] has quit []     
08:49 < thomasb06> the command 'virtualenv -p python3 .venv' must run from python3?
08:49 -!- brakmic [~brakmic@185.183.85.108] has joined #bitcoin-core-pr-reviews     
08:50 < thomasb06> (well, no...)
08:51 -!- robot-visions [~robot-vis@172.92.4.53] has joined #bitcoin-core-pr-reviews     
08:53 < thomasb06> virtualenv was not installed...
08:58 -!- shesek [~shesek@5.22.128.43] has joined #bitcoin-core-pr-reviews     
08:58 -!- shesek [~shesek@5.22.128.43] has quit [Changing host]     
08:58 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
09:01 -!- davterra [~dulyNoded@c-73-221-225-225.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds]     
09:03 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]     
09:05 -!- the_nomad [6de7c3fe@109.231.195.254] has joined #bitcoin-core-pr-reviews     
09:06 < the_nomad> hello
09:07 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews     
09:07 -!- the_nomad [6de7c3fe@109.231.195.254] has quit [Remote host closed the connection]     
09:07 -!- the_nomad [6de7c3fe@109.231.195.254] has joined #bitcoin-core-pr-reviews     
09:11 < bordalix> hi     
09:19 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
09:22 < thomasb06> what is the repository I should fork to have both the Core and the Test code on my dirk?
09:22 < thomasb06> *disk
09:22 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
09:22 -!- vasild_ is now known as vasild     
09:24 < sipa> the tests are included in the bitcoin core repository
09:24 < thomasb06> ok then
09:24 < sipa> https://github.com/bitcoin/bitcoin
09:25 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:457f:ec74:76ef:7bbe] has joined #bitcoin-core-pr-reviews     
09:25 < thomasb06> (I guessed it was this one...) thanks
09:29 < thomasb06> to build, I just run 'make Makefile.am'?
09:31 < thomasb06> (no...)
09:31 -!- bobsmith [60e78d69@pool-96-231-141-105.washdc.fios.verizon.net] has quit [Remote host closed the connection]     
09:32 < pinheadmz> thomasb06: https://github.com/bitcoin/bitcoin/blob/master/test/README.md
09:32 < pinheadmz> and https://github.com/bitcoin/bitcoin/blob/master/src/test/README.md
09:35 < thomasb06> it's not straigh away from the root, of course
09:37 -!- lightlike [~lightlike@p200300C7EF12A1002565156999F67ADA.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
09:42 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:457f:ec74:76ef:7bbe] has quit [Ping timeout: 246 seconds]     
09:44 < thomasb06> (./autogen.sh went well)
09:45 < thomasb06> arg... "error: Found Berkeley DB other than 4.8, required for portable wallets (--with-incompatible-bdb to ignore or --disable-wallet to disable wallet functionality)"
09:45 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews     
09:46 < thomasb06> I didn't even know I add Berkeley DB...
09:47 -!- hanhua [63687d99@99-104-125-153.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews     
09:48 < jonatack> thomasb06: https://jonatack.github.io/articles/how-to-compile-bitcoin-core-and-run-the-tests
09:48 < thomasb06> thanks
09:49 < jonatack> a summary on building and running the tests, it guides you through the BerkeleyDB version issue
09:49 < jonatack> recently updated with some fancy new tips from MarcoFalke :)
09:51 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
09:51 < thomasb06> (install_db4.sh running)
09:52 -!- davterra [~dulyNoded@2601:603:4f00:63d0:a00:27ff:fed5:b769] has joined #bitcoin-core-pr-reviews     
09:52 < jonatack> 👍
09:52 < thomasb06> my computer is in rolling release, maybe I should build the code on a virtual machine?
09:53 < thomasb06> "db4 build complete."
09:54 -!- handed [~handed@178.162.222.42.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
09:54 < jonatack> people do both, i think? i tend to avoid VMs, docker, etc, except for building gitian sigs, but many people use them
09:55 < sipa> jonatack: hmm, any reason why you go to the effort of building db4.8 in your writeup?
09:55 < sipa> i'd go for either --enable-incompatible-bdb if it's for development, or a depends build if you want a more production-like build
09:55 < jonatack> sipa: most devs seem to use with-incompatible-db i think
09:55 < thomasb06> (well, if I can build the code on my computer no need of a VM...)
09:56 < vasild> wen drop db4.8?
09:56 < jonatack> i just always used 4.8
09:56 < jonatack> vasild: achow101 has a pr open to extend up to BDB 5.3
09:57 < jonatack> sipa: thanks -- i should use depends builds more
09:57 < vasild> https://github.com/bitcoin/bitcoin/pull/18870
09:57 < vasild> build: Allow BDB between 4.8 and 5.3 without --with-incompatible-bdb
09:57 < MarcoFalke> This ^ (good stuff)
09:58 < jonatack> vasild: only maybe issue is it picks up the system bdb over the depends bdb iiuc
09:58 < sipa> past 5.3 is problematic anyway, due to both licensing issues and file format incompatibilities
09:58 -!- robot-visions [~robot-vis@172.92.4.53] has quit [Quit: Textual IRC Client: www.textualapp.com]     
09:58 < nehan> jonatack: those are great articles and resources! thanks for writing them up
09:58 < achow101> jonatack: that issue only happens if the depends bdb is not a valid version
09:59 -!- b10c [~b10c@2001:16b8:2eec:9500:84c3:6b41:a9b1:ca38] has joined #bitcoin-core-pr-reviews     
09:59 < sipa> achow101: since depends is a controlled environment, that shouldn't happen right? you can always guarantee the right version is present?
09:59 < jonatack> nehan: thanks! every time i look at it with fresh eyes i see something to fix :)
09:59 < sipa> (it's unexpected and should be fixed of course, but it's not a critical problem for release builds)
10:00 < jnewbery> #startmeeting
10:00 < achow101> sipa: yes. I was just testing bad versions for the expected error
10:00 < jnewbery> hi folks. Welcome to the Bitcoin Core PR Review club meeting!
10:00 < b10c> hi     
10:00 < jnewbery> feel free to say hi to let people know you're here
10:00 < bordalix> hi     
10:00 < fjahr> hi     
10:00 < pinheadmz> hi! 👋
10:00 < lightlike> hi     
10:00 < ccdle12> hi     
10:00 < raj_149> hi     
10:00 < theStack> hi     
10:00 < ariard> hi     
10:00 < nehan> hi     
10:00 < thomasb06> hi     
10:00 < jnewbery> Notes and questions are in the normal place: https://bitcoincore.reviews/18806.html
10:00 -!- r251d [~r251d@162-196-59-192.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-core-pr-reviews     
10:01 < jonatack> hi     
10:01 < vasild> hi     
10:01 < jkczyz> hi     
10:01 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:c0a2:edb0:4e2e:a5a2] has joined #bitcoin-core-pr-reviews     
10:01 < the_nomad> Hello chaps
10:01 < michaelfolkson>  Hi     
10:01 < emzy> Hi     
10:01 < willcl_ark> hi     
10:01 < r251d> hi     
10:01 < handed> hi     
10:01 < brikk> hi     
10:01 < nehan> the_nomad: we are not all chaps :)
10:01 < sipa> hi     
10:02 < jnewbery> This week we're covering quite a straightforward refactor PR. There have been a lot of new participants at these meetings the last few weeks, and recent meetings have gone quite deep into P2P and validation logic, so I though it'd be nice to look at something a bit simpler this week.
10:02 < ariard> wait isn't since 1-year bitcoin pr review club has been started ?
10:02 < andrewtoth> hi     
10:02 < nehan> happy anniversary jnewbery!
10:02 < jnewbery> it's also a great opportunity to ask more basic questions about the Bitcoin Core review process
10:03 < pinheadmz> !! !! !! 1 whole year !! !! !!
10:03 < fjahr> happy anniversary \o/
10:03 < theStack> happy anniversary also from my side!
10:03 < sipa> congrats jnewbery and all who help running this, keep going :)
10:03 < b10c> ariard: just checked. I think you are right! Happy anniversary!
10:03 < raj_149> Happy anniversary. :D
10:03 < jnewbery> happy anniversary everyone! I only host about once a month now. This club belongs to all of us!
10:03 < ariard> jnewbery: hey happy anniversary, a litte gift from people here https://gist.github.com/ariard/6a40fe158d419126a8e5b0f36d691f28 :)
10:04 < pinheadmz> woo hoo!!! HBD club <3
10:04 < jnewbery> awww thanks everyone!
10:04 < ariard> and they ots proof for onchain commitment ahah https://gist.github.com/ariard/b6014d1a887182e0c7cdd37589ec339e ;)
10:04 < amiti> :D     
10:04 < ariard> *the
10:04 < willcl_ark> handsup.gif
10:04 < lightlike> happy anniversary!
10:04 < andrewtoth> happy anniversary! thanks jnewbery!
10:05 < pinheadmz> no-one's crying! (sniff)
10:05 < sipa> i hope everyone remains committed and committed on-chain to keep doing this :p
10:05  * sipa hides
10:05 < ariard> you can do `ots verify digital_card.ots`
10:05 < jnewbery> I'm not crying, honest
10:06 < pinheadmz> ariard: great job :-) ty
10:06 < jnewbery> that's really touching. Thanks everyone!
10:06 < raj_149> Thank for the amazing work you do jnewbery. I have learned a lot from this club.
10:06 < jnewbery> ok, let's talk about Bitcoin
10:07 < ariard> yeah always talk about bitcoin
10:07 < theStack> :)     
10:07 < sipa> hey did you guys know the blockly subsidy halves next week!?
10:07 < thomasb06> I have a basic question...
10:08 < pinheadmz> sipa: 761 more blocks !
10:08 -!- kory [a2dc3ff3@162-220-63-243.static.hvvc.us] has joined #bitcoin-core-pr-reviews     
10:08 < jnewbery> The PR was merged today, but it's a good idea to still review merged PRs. https://github.com/bitcoin/bitcoin/pull/18806
10:08 < sipa> guys and non-guys
10:09 < willcl_ark> s/you guys/y'all   ;)
10:09 < jnewbery> who had a chance to review the pr? y/n
10:09 < brikk> y     
10:09 < fjahr> y     
10:09 < raj_149> y     
10:09 < pinheadmz> y     
10:09 < the_nomad> y     
10:09 < nehan> y     
10:09 < ariard> y     
10:09 < lightlike> y     
10:09 < theStack> sipa: oh yes -- unfortunately there won't be any possibility to physically participate in a halving party :/
10:09 < vasild> y     
10:09 < bordalix> y     
10:09 < andrewtoth> y     
10:09 < jnewbery> thomasb06: feel free to ask questions at any point. No need to wait
10:09 < michaelfolkson> y     
10:09 < r251d> y     
10:09 < thomasb06> Is it possible to review a PR without being able to code it?
10:09 < ccdle12> y     
10:09 -!- gzhao408 [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
10:09 < jnewbery> Wow. Lots of review. No wonder it got merged
10:10 < jonatack> happy 1st birthday to the review club everyone 🏆 🚀
10:10 < sipa> y     
10:10 < jkczyz> y     
10:10 < jnewbery> thomasb06: yes! You can still test the code and leave a comment saying what you did
10:10 < bordalix> hummmm, I review it but didn't ACK on the repo. Do that count?
10:10 < fjahr> much more y's than reviews in the PR, I think more people should post their reviews on GH :)
10:10 < thomasb06> jnewbery: cool... This was my main concern
10:10 < jonatack> fjahr: +1
10:11 < jnewbery> don't expect to fully understand everything on your first reviews. As you get more experience, you'll understand more and more
10:11 < michaelfolkson> thomasb06: Concept ACK doesn't need code review. Nor does running tests
10:11 < jonatack> thomasb06: i do hope so... i do it all the time :p
10:12 < jnewbery> fjahr: definitely. If you're reviewing but not leaving comments, then you're depriving everyone else of your knkowledge and insights
10:12 < brikk> thomasb06: I think a good start is to do what I did, checkout the branch, figure out how to build the code and run the tests
10:12 < jnewbery> ok, first question: Why was the motivation for PR 2914 not made explicit?
10:12 < thomasb06> but... michaelfolkson ok, you answered the question before I asked
10:12 < vasild> because it was a security vulnerability
10:12 < pinheadmz> jnewbery: an attacker could remotely crash bitcoind by setting a bloom filter of 0 size
10:12 < handed> jnewbery flaw could bring down nodes by exhausting resources
10:12 < raj_149> because it was a bug.
10:13 < nehan> jnewbery: code is pushed before it's deployed to the network, so someone would have seen the possible attack
10:13 < thomasb06> brikk: ok, thanks
10:13 < jnewbery> vasild pinheadmz nehan: yes!
10:13 < lightlike> i wonder if a covert fix  like this would still be possible today - someone surely would challenge the claim that this is a performance optimization and ask for benchmarks?!
10:13 -!- grunch__ [~grunch@2800:810:547:c46:25e8:a7de:f130:fe8] has joined #bitcoin-core-pr-reviews     
10:13 < jnewbery> handed: almost. It could bring down a node, but it's by a segfault, not resource exhaustion
10:13 < michaelfolkson> lightlike: You would hope so ;)
10:14 < sipa> not a segfault, a division by zero
10:14 < theStack> lightlike: interesting question, i also asked myself this quite a lot... i think the quality of reviews has increased drastically, looking at old PRs
10:14 < fjahr> lightlike: maybe the covert techniques have improved as well ;)
10:14 < jnewbery> raj_149: we fix lots of bugs overtly all the time. This was covert because of the nature and seriousness of the bug
10:14 < jnewbery> sipa: yup. Thanks
10:14 < handed> sipa isn't burning up the CPU resource exhaustion or am I not translating accurately?
10:14 < raj_149> jnewbery: The first comment of gmaxwell in 2914 gives away the motivation. So how its still a covert fix?
10:14 < vasild> lightlike: so one would also have to do some real improvement in performance + secret fix merged in one patch :-D
10:14 < michaelfolkson> So this could have knocked all v0.8 nodes off the network?
10:15 < sipa> handed: not sure what you mean by burning up the CPU; the node would just crash with a division by zero trap
10:15 < sipa> instantly, without any cpu or memory usage
10:15 < sipa> michaelfolkson: all reachable ones, yes
10:15 < handed> ok, I thought it would cause some excess computation which would cause the crash, ty for clarifying
10:15 < jnewbery> raj_149: it was claimed that the problem was resource wastage. The actual problem was instacrash
10:16 < handed> jnewbery ty for clarification
10:16 < raj_149> oh i see..
10:16 < ariard> if people are interested by cover fix, see https://github.com/bitcoin/bitcoin/pull/11397 and https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017453.html
10:16 < ariard> *covert
10:17 < jnewbery> michaelfolkson: I believe bloom filters were on by default, so I think it would be able to knock out the majority of nodes at the time
10:17 < sipa> jnewbery: i don't think it was possible to turn them off
10:17 < michaelfolkson> jnewbery: Majority of 0.8 nodes? No bloom filters pre 0.8
10:18 < jnewbery> sipa: oh interesting. Yes, I see that's explicit in BIP 111: https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki
10:18 < jonatack> ariard: thanks
10:18 < jnewbery> "BIP 37 did not specify a service bit for the bloom filter service, thus implicitly assuming that all nodes that serve peers data support it."
10:19 < jnewbery> ok, next question: Serving bloom filters is now disabled by default for full nodes. Why? What are some of the problems with BIP 37? What alternatives are there?
10:19 < michaelfolkson> There were 3 CVEs in that 0.8 release...
10:19 < theStack> by the way, pr #2914 was buggy as well and actually didn't solve the problem (a followup PR by gmaxwell followed soon after though :))
10:20 < lightlike> theStack: interesting, what was the id of the follow up?
10:20 < pinheadmz> jnewbery: server side filtering means more work for publicly acesible nodes, and neutrino offers a better privacy and security model
10:20 < michaelfolkson> Problems with BIP 37. Privacy, false positives
10:20 < theStack> lightlike: #2919
10:21 < handed> bip 37 enables amplification attacks by clients to servers of the filters
10:21 < pinheadmz> handed: how is that? whats amplified?
10:21 < jnewbery> pinheadmz michaelfolkson: yes, problems with BIP 37 are server resource usage and poor privacy
10:21 < handed> you can spam many requests to a server at very little cost and cause a disproportionaitly high amount of compute load
10:21 -!- michaelf_ [~textual@2a00:23c5:be01:b201:dd29:4702:bd8a:d24a] has joined #bitcoin-core-pr-reviews     
10:22 -!- michaelf_ [~textual@2a00:23c5:be01:b201:dd29:4702:bd8a:d24a] has quit [Client Quit]     
10:22 < andrewtoth> an alternative is compact block filters in general, neutrino is a specific implementation using them to sync I believe
10:22 -!- michaelf_ [~textual@2a00:23c5:be01:b201:dd29:4702:bd8a:d24a] has joined #bitcoin-core-pr-reviews     
10:22 < ariard> there was a a risk of disk I/O Dos, see a Poc attack https://github.com/petertodd/bloom-io-attack
10:23 < jnewbery> andrewtoth: thanks for that clarification. Neutrino is an implementation of BIP 157/158
10:24 < jnewbery> We covered the proposed BIP 157 implementation in a previous review club: https://bitcoincore.reviews/16442.html
10:25 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:c0a2:edb0:4e2e:a5a2] has quit [Ping timeout: 265 seconds]     
10:25 < theStack> one of the major advantages of server side filters is that they are deterministic, i.e. no need to maintain an individual state for each peer?
10:25 < jnewbery> Any other questions about BIP 37 or should we move on?
10:25 < jnewbery> theStack: exactly. It means they can be cached and delivered from anywhere, and a client can fetch from diverse sources
10:25 < ariard> theStack: yeah it's O(1) in CPU computation whatever the number of clients served
10:25 < handed> theStack +1
10:26 < sipa> theStack: no cpu cost per request, ability for client to compare filters from multiple nodes, ... possibility even to at some point soft fork it in so that you have an SPV-level proof of no censorship, ...
10:26 -!- michaelf_ [~textual@2a00:23c5:be01:b201:dd29:4702:bd8a:d24a] has quit [Client Quit]     
10:27 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:dd29:4702:bd8a:d24a] has joined #bitcoin-core-pr-reviews     
10:27 < jnewbery> ok. Final question (but feel free to ask anything about BIP 37 / BIP 157/158 if you think of it later)
10:27 < jnewbery> How is this PR tested? Are there any additional tests that could be added?
10:28 < pinheadmz> there was a test in https://github.com/bitcoin/bitcoin/pull/18515
10:29 < ccdle12> functional test that sends an empty nElements
10:29 < raj_149> it was tested by the p2p_filter.py functional test.
10:29 < jnewbery> pinheadmz: right, and https://github.com/bitcoin/bitcoin/pull/18672
10:29 -!- shesek [~shesek@5.22.128.43] has joined #bitcoin-core-pr-reviews     
10:29 -!- shesek [~shesek@5.22.128.43] has quit [Changing host]     
10:29 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
10:29 -!- shesek [~shesek@unaffiliated/shesek] has quit [Client Quit]     
10:30 < jnewbery> Nice approach to add a test first, and then show that the refactor doesn't change behaviour
10:30 < michaelfolkson> And a fuzz test
10:31 < andrewtoth> didn't we review the fuzz test in here a while back?
10:31 < jnewbery> ok, that was all the questions I had. I wanted this week's meeting to be a chance for people to ask more general questions about the review process, so hopefully some of you have questions.
10:31 < jonatack> it's in the PR description -> 18521
10:31 < theStack> ad server side filters: seems to be a great idea and actually seems much more logical than client side filters; one drawback though seems to be that more data has to be transferred
10:31 < jnewbery> Don't be shy if it's your first time!
10:32 < r251d> Sorry if I missed the time to ask this question, but could an empty `vData` cause a problematic modulo division by zero here? https://github.com/theStack/bitcoin/blob/1ad8ea2b73134bdd8d6b50704a019d47ad2191d8/src/bloom.cpp#L43
10:32 < theStack> jnewbery: it was not planned from me originally to refactor -- that was inspired by a recent pr review club meeting on fuzzing :)
10:32 < jnewbery> andrewtoth: we reviewed a different fuzz test: https://bitcoincore.reviews/17860.html
10:32 < sipa> r251d: that's exactly where the bug was triggered
10:32 < brikk> r251d: exactly what I was going to ask too :)
10:33 < sipa> r251d: and it's avoided by making sure that function can't be called when vData is empty
10:33 < lightlike> andrewtoth: there is a specific one src/test/fuzz/bloom_filter.cpp - we reviewed one on process_messages that indirectly also creates the msgs for the bloom if you let it run for a while
10:33 < raj_149> r251d: isn't thats what exactly the bug was?
10:33 < brikk> why is there no vData.empty() check in this method?
10:33 < theStack> also i was very unsure if this would get concept acks, as bip37 is kind of anachronistic and according to gmaxwell there were discussions about removing bloom filter support completely years ago
10:33 < brikk> doesn't that add  a risk  of another method calling it without first checking if it's empty?
10:33 < nehan> brikk: i was wondering the same thing. why not check closer to use?
10:33 < theStack> happy that i could help and that it was accepted though
10:33 < sipa> brikk: it's already too late by that point
10:34 < r251d> I see. The calling functoins all check vData.empty() and return before calling Hash()
10:34 < sipa> there is no reasonable answer the function can give
10:34 < sipa> it could contain an assert
10:34 < jnewbery> theStack. I'm glad you did. Cleaning up code so it clearly matches expectations is a worthy exercise!
10:34  * vasild afk
10:34 < nehan> or at least a comment that says that the caller of this function is responsible for making sure vData.size() is not 0
10:35 < sipa> yeah that would make a lot of sense
10:35 < jkczyz> jnewbery: Regararding testing, a unit test where CBloomFilter is constructed with nElements == 0 would also catch this
10:35 < jnewbery> jkczyz: I agree. A unit test seems like a natural place to test this.
10:36 < ccdle12> I was just wondering if CBloomFilter construction in net_processing by "vRecv >> filter" is constructed via `serialize.h` and is using those macros the preferred way to deserialize to objects in Bitcoin?
10:36 < jnewbery> I found it slightly weird that CBloomFilter has two ctors, one that is used in the product code and one that is only used in tests
10:37 < theStack> jnewbery: agreed, this ctor also confused me quite a lot when i started digging into this code... a comment like "only used for tests" would make sense here
10:37 < sipa> ccdle12: filter is constructed at the time it is defined; deserialization only fills it
10:38 < michaelfolkson> Let's say an attacker had successfully pushed all v0.8 nodes off the network. Is there anything he/she could've done other than causing havoc? Target a specfic node with sybils when it comes back up?
10:38 < nehan> question on reviewing: this was already merged. is there any benefit in leaving a comment saying it would be nice to have an assert in Hash()?
10:38 < jnewbery> net_processing only uses the constructor with no parameters
10:38 < lightlike> but would an assert help? does it matter much if the node crashes b/c of a divide by zero or bc the assert is triggered?
10:38 < sipa> lightlike: no... it might make debugging slightly easier, but that's it
10:38 < theStack> nehan: i think yes, as someone could grasp an idea for a follow-up pr
10:39 < nehan> fair point!
10:39 < handed> nehan: what's the harm, I think it's positive for people reviewing the reviews to know how people felt about the PR
10:39 < jnewbery> nehan: I think so. Even better would be to offer to open that PR
10:39 < sipa> lightlike: the main advantage of an assert is documenting the expectations
10:39 < thomasb06> Are there PRs for tests too, I'd rather review Python than C++?
10:39 < ccdle12> sipa: I see thanks that makes sense, so I guess the msg type is already validated before attempting deserialize?
10:39 < jonatack> nehan: i think post-merge review is great, either to prep a follow-up or even better, if you catch a regression!
10:39 < sipa> thomasb06: many!
10:39 < thomasb06> sipa: cool
10:40 < sipa> ccdle12: eh, i think you're confused
10:40 < theStack> lightlike: well at least one would know _where_ it crashed :)
10:40 < jnewbery> thomasb06: yes, there are lots. Look for PRs that have the Tests label: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+label%3ATests
10:40 < sipa> ccdle12: deserialization can definitely fail if the data in the stream is not a valid CBloomFilter
10:40 < sipa> in which case it will throw an exception
10:40 < handed> michaelfolkson re: attacker, if the node that submits block headers to a pool is crashed then that could create a lower effective hashrate / hmm maybe a chain split?
10:41 < thomasb06> jnewbery: thanks, that's where I need to start
10:41 < ccdle12> sipa: aah ok thanks, that's what I was wondering, looks like I'll need to dive into the serialize h file :)
10:41 -!- CryptoWorldNow [a254a393@pool-162-84-163-147.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
10:41 < jnewbery> There were a couple on twitter from @nickycutesc
10:41 < jnewbery> *couple of questions
10:42 < jnewbery> "What’s the best way to debug unit tests?
10:42 < michaelfolkson> Twitter? What is that? :)
10:42 < jnewbery> and "Favorite IDE? gdb on a terminal is....interesting."
10:43 < jonatack> fjahr: can you repost the new home for your debugging gist?
10:43 < sipa> EDLIN.COM
10:43 < thomasb06> jnewbery: what does a review consist in, read the modifications brough and if agreed acknowledge with a Concept ACK?
10:43 < michaelfolkson> handed: I think you'd need to sybil the pool. Any honest connection and the chain wouldn't split?
10:43 < jnewbery> https://github.com/fjahr/debugging_bitcoin
10:43 < fjahr> https://github.com/fjahr/debugging_bitcoin :) still need to put some more work in but should be helpful nevertheless
10:44 < jnewbery> fjahr: that's a great resource. Thanks for putting it together
10:44 < nehan> fjahr: i would like you to add equivalent linux commands :)
10:44 < raj_149> jnewbery: i have managed to debug unit tests in vscode. gdb felt little intimidating.
10:44 < nehan> fjahr: i'm happy to help if you would like it
10:44 < sipa> thomasb06: https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md
10:45 < thomasb06> sipa: thanks
10:45 < jnewbery> thomasb06: specifically the section on Decision Making Process
10:45 < jonatack> thomasb06: have a deep look at the articles mentioned on the review club home page, and spend time watching interation on github and looking at the docs and code in the repository
10:45 < emzy> sipa: the DOS program?
10:45 < fjahr> nehan: sure, it's a repo now instead of a gist so people can contribute :)
10:45 < michaelfolkson> https://jonatack.github.io/articles/how-to-review-pull-requests-in-bitcoin-core
10:45 < lightlike> i usually just add printfs for debugging
10:45 -!- CryptoWorldNow [a254a393@pool-162-84-163-147.nycmny.fios.verizon.net] has quit [Ping timeout: 245 seconds]     
10:46 < handed> michaelfolkson I'm thinking that if mining operator doesn't get a new block header from pool operator (e.g. they continue mining on old headers because their pool operator's node has crashed due to CVE) that they can create another valid block B2, A<-B1 A<-B2
10:46 < jnewbery> printf/vim for me, but I don't want to start any religious wars
10:46 < handed> i.e. they're building work on an outdated tip
10:46 < ariard> thomasb06: try to understand the code structure and how any changes may alter program behavior, and if this behavior is expected or not compare to what his claim by author
10:47 < ariard> and how can you make with ways to assert code is correct, by adding functional tests, manual testing, change few parameters like new timers
10:47 < thomasb06> ariard: ok
10:47 < ariard> also you can look about previous changes on the same code area, what kind of issues is raised generally
10:48 < ariard> like if you do look on p2p, you care a lot about DoS vectors
10:48 < michaelfolkson> handed: Ok so that impacts the miners profits but whenever they get back online that doesn't impact the rest of the network
10:48 < michaelfolkson> Those blocks they "mined" get dropped like any normal chain re-org when they come back up
10:49 < handed> michaelfolkson it delays settlement for the network, seems to me that uncrashed nodes will have to wait and say "Hmm two valid, competing blocks exist. I don't know which one miners will continue to build on, I'll need to wait"
10:49 < sipa> handed: they will prefer the one they saw first
10:49 < nehan> thomasb06: i try to convince myself the code is correct. also think about how the change might impact performance. more/fewer disk reads? memory conserved?
10:49 < jonatack> another interesting debugging resource: some of achow101's twitch coding videos... the best parts imo are when he gets into the weeds, stuff is broken, and he has to fix it.
10:50 < thomasb06> nehan: yep
10:50 < jonatack> https://www.twitch.tv/achow101
10:51 < theStack> jonatack: thanks for the link. actually an interesting idea to watch someone coding
10:51 < nehan> jonatack: i haven't seen that, thanks!
10:51 < jnewbery> When I started reviewing Bitcoin Core PRs, I did a _lot_ of manual testing. I wanted to see for myself how the behaviour changed. Even if there are automated tests, it's a good exercise to try to trigger the new behaviour yourself
10:51 < handed> sipa sure but as you point on occasionally, it's all about which block gets built on, not if your tx is in the tip (unless the point is, if the chain diverges under non adversarial txs, all txns could eventually be included)
10:51 < sipa> handed: that's why you wait for 6 confirmations :)
10:51 < sipa> (or decide not doing so is an acceptable compromise)
10:52 < handed> exactly! but do you agree that having two competing blocks decreasing certainty that "6 confirms" have occured?
10:52 < jonatack> nehan: theStack: for C and c-lightning videos, there is also Lisa Neigut: https://www.twitch.tv/niftynei/videos
10:52 < handed> maybe I'm being pedantic
10:52 < fjahr> thomasb06: I gave a talk on the functional tests (the ones in python) but it seems it's still not uploaded yet by Bitcoin Edge. At least the slides are there, maybe they are a little bit helpful https://telaviv2019.bitcoinedge.org/presentations
10:52 < sipa> handed: sure, but at the same time you generally won't know there is a competing chain
10:52 < jnewbery> and if a PR didn't have an automated test, sometimes I'd write one and offer it to the PR author
10:52 < michaelfolkson> sipa handed: I'm thinking havoc is only attacker goal unless they can control the connections to that node when it comes back up
10:54 < michaelfolkson> sipa handed: Granted we want to stop havoc from happening. But it won't damage network once bug is addressed or cause people to lose money
10:54 < handed> >"won't know there is a competing chain"   I'm rusty, does a node not relay "B2" to peers if it's seen "B1" first?
10:54 < theStack> jonatack: awesome. i wanted to take a deeper look into lightning and in particular one of its implementations for a long time, maybe this is a good start
10:54 < sipa> handed: not sure what B1 and B2 are, but nodes will generally only relay their best chain
10:55 < jnewbery> handed: a node won't relay a block that isn't on its mainchain
10:55 < handed> A<-B1 A<-B2
10:55 < sipa> handed: in that case, no they won't
10:55 < jnewbery> ok, 5 minutes left. Any final questions?
10:55 < thomasb06> fjahr: great. They are a lot helpful
10:55 < sipa> handed: it's both a fingerprinting attack, and nodes have an incentive to make the network converge towards their view of the chain
10:56 -!- michaelf_ [~textual@2a00:23c5:be01:b201:cc78:c0db:3f4d:fe88] has joined #bitcoin-core-pr-reviews     
10:56 < jnewbery> ok, in that case let's wrap it up there. One last thing before we go...
10:57 < jnewbery> I'm hoping to make some progress on getting jimpo's BIP 157 implementation merged: https://github.com/bitcoin/bitcoin/pull/18876
10:57 < handed> yeah, is your fingerprinting point: if peers can feed info to nodes and probe out information, they can gain visibility in peer topology?
10:58 < sipa> handed: yes, exactly
10:58  * handed thumbs up
10:58 < jnewbery> I've opened the first PR here: https://github.com/bitcoin/bitcoin/pull/18877. Would anyone be interested in an extra review club session on that? It'd be slightly different from the normal session because it's explicitly to try to help get the PRs into a state ready for review.
10:59 < michaelf_> Definitely. When?
10:59 < jnewbery> *ready for merge
10:59 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:dd29:4702:bd8a:d24a] has quit [Ping timeout: 240 seconds]     
10:59 < the_nomad> Y     
10:59 < fjahr> jnewbery: yes
10:59 < nehan> jnewbery: yes
10:59 < theStack> jnewbery: yes
10:59 < jonatack> jnewbery: wdym by state ready for review?
10:59 < ccdle12> jnewbery: yes
10:59 < brikk> nehan: I added a comment about the assert on the PR
10:59 < jonatack> (RFM)
10:59 < jnewbery> jonatack: sorry, ready for merge
10:59 < jkczyz> jnewbery: I plan on reviewing the 18877 today
10:59 < nehan> brikk: great!
11:00 < jnewbery> ok, same time tomorrow? We'll continue doing the normal review clubs on Wednesdays
11:00 < jonatack> jnewbery: at any rate, yes
11:00 < jnewbery> and on Thursdays try and get somewhere with BIP 157!
11:00 < jonatack> my main concern is that BIP157 remain opt-in
11:01 < jnewbery> ok, I've gotta dash. Thanks again everyone. And thanks to ariard for the card. That was very kind.
11:01 < jnewbery> jonatack: yep, it's off-by-default
11:01 < jnewbery> #endmeeting
11:01 < michaelf_> Cool, sounds good. Thanks jnewbery
11:01 < jonatack> right -- just that it stays that way :p
11:01 < emzy> Tnx. Happy first year!
11:01 < fjahr> thanks jnewbery, good job ariard!
11:01 < theStack> thanks for hosting jnewbery
11:01 < nehan> brikk: i guess we both have different github/irc handles
11:01 < andrewtoth> thanks jnewbery! thanks ariard for setting up the card!
11:02 < ariard> and yw it was fun running after irc handles through the net the past week :)
11:02 < brikk> nehan: yeah unfortunately I was late to github so it was already taken :)
11:02 < theStack> jonatack: hmm from what i read at the current mailing list discussion many are actually more concerned that it will be on-by-default somewhere in the future
11:02 < theStack> like that it could be too much of a burden for the full nodes
11:03 < sipa> ok, and then they turn it off again?
11:04 < brikk> nehan: also it makes it a bit challenging sometimes to refer to the right person, but I try my best, eventually I'll figure out who's who :)
11:04 < jonatack> theStack: yes, my concern that it remain opt-in and not on by default, unless there is an extremely compelling reason to do so that i'm unaware of yet
11:05 < nehan> brikk: yep, same! i have sometimes been very surprised to find out two handles were actually the same person
11:05 -!- the_nomad [6de7c3fe@109.231.195.254] has quit [Ping timeout: 245 seconds]     
11:05 < michaelf_> Do we have any insight into how significant defaults are? The concern would be if you have to opt-in that everyone sticks with the default
11:06 < sipa> i don't think there is much of a problem with having it default on - the resource costs are pretty low - but i also think that having it on P2P available isn't all that useful unless it's also softforked in
11:06 < sipa> michaelf_: defaults are very significant :)
11:06 < theStack> i guess default settings are always a very political decision, because most users never change them. when in general people talking about "running a full node" and what ressources it consumes they implicitely assume running it with default settings
11:06 < michaelf_> If no one serves filters that is a problem
11:07 < jonatack> sipa: will think about that, thanks
11:07 < lightlike> apart from that there also seems to be the more general, "ideological" concern whether making it easier for people not to use a full node should be supported.
11:07 < sipa> michaelf_: filter data is unverifiable, which is concerning
11:08 < sipa> so you should really only use filters from trusted peers already, which you can ask to turn it on
11:08 < jonatack> theStack: i know i'm much more conservative about ACK/merging changes that are to be on by default, as opposed to things like asmap or signet or v2 p2p
11:09 -!- kory [a2dc3ff3@162-220-63-243.static.hvvc.us] has quit [Remote host closed the connection]     
11:09 -!- shesek [~shesek@5.22.128.43] has joined #bitcoin-core-pr-reviews     
11:09 -!- shesek [~shesek@5.22.128.43] has quit [Client Quit]     
11:10 < michaelf_> sipa: Nodes can feed you filters with deliberately wrong data?! I'm going to have to revisit Neutrino.... I thought it was trustless
11:10 < michaelf_> I thought that was the whole point
11:10 < ariard> even worst, you light client may not be connected to the "right" p2p network
11:10 < sipa> michaelf_: no, the point is that the filters are identical, so you can fetch from multiple peers and compare them
11:11 < theStack> jonatack: that makes sense!
11:11 < handed> michaelf_ I think the filters have strong integrity just not validity
11:11 < sipa> but to make it (spv level) trustless, you need a softfork
11:11 < michaelf_> Ah... thanks
11:11 < theStack> sipa: hmm so light clients would need to fetch the filters from more than one random peer to decrease the probability that they got served sth wrong?
11:11 < jonatack> lightlike: i do worry about the free rider problem, as do others... incentives for full nodes, etc.
11:12 < ariard> sipa: but even committing them via a softfork, you still have to have a least one honest peer
11:12 < michaelf_> So we're back to scenario of worrying about having peers all controlled by an attacker
11:12 < ariard> if not I can starve you from filters/headers updates
11:12 < sipa> ariard: having at least one honest peer is an assumption that literally everything makes
11:12 < thomasb06> well, I have plenty of webpages to read. Next week I'll try to be back
11:12 < sipa> theStack: yes, and they do
11:12 < ariard> sipa: right, and softoforking would reduce which attack scenario exactly?
11:12 < handed> jonatack there's no free rider problem, nodes can elect to exclude serving filters (free rider problems are about non-excludable goods)
11:13 < michaelf_> Thanks for coming thomasb06! Keep at it. Progress can be slow but it is very interesting ;)
11:13 < handed> the filters make trust proofs cheaper
11:13 < jonatack> handed: good point
11:13 < sipa> ariard: if it's softforked in, and you accept the SPV security model, you can fetch from just one peer
11:13 < sipa> and know you're not lied to
11:13 < sipa> they can censor, but you'll know you're censored
11:13 < thomasb06> Thank you for your support.
11:14 < thomasb06> see you later
11:14 < sipa> as opposed to now... you need to fetch from either (a) one trusted peer or (b) multiple peers and hope at least one is honest and if they disagree who knows what to do
11:14 < ariard> sipa: this peer may steal break your security model by slowing down announcement of filters, and if your a LN client, you may be in trouble?
11:14 < thomasb06> nehan: you're a chick?
11:14 < sipa> thomasb06: wth
11:14 < handed> -_-     
11:14 < ariard> so you should have multiple peers be sure you see the chain at the "right" pace
11:14 < nehan> thomasb06: we do exist
11:14 < handed> lool
11:15 < jonatack> nehan: :D
11:15 < thomasb06> it's nice to have ladies around too
11:15 < theStack> sipa: did bip37 light clients also used to get their filters from more than one peer? (i never actually looked at an implementation)
11:15 < michaelf_> Yeah hopefully more with time. Who knows, maybe Satoshi was female
11:15 < thomasb06> sipa: what is 'wth'?
11:15 < handed> it's nice to have competent developers, I think that's what everyone is here for
11:16 < sipa> thomasb06: what the hell
11:16 < thomasb06> ok...
11:16 < sipa> ariard: you can't do better than knowing you're being censored
11:16 < thomasb06> I'm new to Irc too...
11:17 < thomasb06> got to go, see you
11:17 < jonatack> thomasb06: check out https://dci.mit.edu/team
11:19 < michaelf_> Anchor nodes seem so important. If you can locate one node you trust these worst case scenarios can't exist
11:19 < thomasb06> jonatack: I though you were giving me more material to read...
11:20 -!- lightlike [~lightlike@p200300C7EF12A1002565156999F67ADA.dip0.t-ipconnect.de] has left #bitcoin-core-pr-reviews ["Leaving"]     
11:20 < michaelf_> Hey thomasb06, unless you have specific questions can you not disrupt the chat?
11:21 < michaelf_> See you next week
11:21 < thomasb06> michaelf_: sure, apologies...
11:23 -!- michaelf_ [~textual@2a00:23c5:be01:b201:cc78:c0db:3f4d:fe88] has quit [Quit: Textual IRC Client: www.textualapp.com]     
11:24 < sipa> theStack: i wouldn't assume too much from bip37 clients in general :)
11:24 < jonatack> handed: what is your GitHub handle?
11:25 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:cc78:c0db:3f4d:fe88] has joined #bitcoin-core-pr-reviews     
11:27 < ariard> sipa: if you need to maintain censorship-resistant, softfork or not, isn't this a lower bound on knowing that someone serves you invalid filters
11:28 < ariard> and so committing wouldn't alleviate light client backend of this censorship requirement
11:29 < jnewbery> I suggest you move this conversation to #bitcoin-core-devs, since it may be of more general interest
11:30 < sipa> ariard: right now with bip157 you can't know you're being censored (literally each of your peers may be an attacker that behaves perfectly correctly when asked for block headers, but filters out the transactions you're interested in before giving you a filter)
11:30 < sipa> unless you assume a trusted peer, or at-least-one-honest-peer + fetching filters from all of them
11:30 < sipa> if it were softforked in you'd know you're censored by asking one peer
11:31 < theStack> sipa: but unlike bip37, the node doesn't actually know which transaction i'm interested in, no?
11:31 < sipa> theStack: that's a dangerous assumption :)
11:31 < sipa> you're not telling them gratuitously
11:31 < sipa> but they may still figure it out based on external knowledge, or based on which blocks you fetch, or ...
11:32 -!- NatalieVon [b29758b5@gateway/web/cgi-irc/kiwiirc.com/ip.178.151.88.181] has joined #bitcoin-core-pr-reviews     
11:32 < sipa> it's more something for #bitcoin or #bitcoin-wizards i think
11:33 < jnewbery> sipa: yep, even better. Thanks
11:33 < theStack> sipa: hmmm true true; so light clients would also need strategies to keep privacy, e.g. every now and then fetching blocks they don't actually need
11:33 < jonatack> sipa: this is very helpful, and changes my perspective on the upcoming review
11:33 < sipa> theStack: if you want perfect privacy there are only two options... just fetch every block, or using PIR cryptography
11:34 < sipa> (and the latter is very computationally expensive)
11:34 < ariard> BIP157 doesn't solve the tx-broadcast side, but not running a full-node perfectly does too
11:34 < sipa> BIP157 is *far* better in this regard than BIP37, but as long as you're selectively fetching some data, you are leaking *something*
11:35 -!- NatalieVon [b29758b5@gateway/web/cgi-irc/kiwiirc.com/ip.178.151.88.181] has quit [Client Quit]     
11:35 < ariard> it's far better on reading the chain but for writing to, like broadcasting tx, it's the same that using BIP37?
11:35 < sipa> i can't parse your sentence
11:36 < ariard> sorry, someone servicing you bip157 filters have lesser knowledge about what utxo you're interested with
11:37 < ariard> but if you broadcast to them your transaction, that's a huge privacy leak
11:37 < sipa> oh, you mean transaction origin privacy? neither BIP37 or BIP157 have anything to do with that - you need things like Tor, or other routing networks to hide that
11:38 < sipa> (and it's a genuinely hard problem in an identityless network...)
11:38 < ariard> yes that's my point and some BIP157 implementations broadcast their txn to the server servicing filters
11:39 < ariard> so it's easy for them to learn ex post what utxo you were interested with
11:39 < sipa> sure
11:39 < sipa> if you're literally telling them, nothing will fix that
11:39 < sipa> privacy is never a single technology solution
11:39 < ariard> yes transaction origin privacy shouldn't be consider when you're evaluating bip 37 against bip 157, but when you evaluate holistically light client privacy
11:40 < ariard> that something matters
11:40 < sipa> fair
11:40 < ariard> yes, even broadcasting everything over Tor is scary
11:41 < ariard> sipa: "if it were softforked in you'd know you're censored by asking one peer" isn't this the same assumption that at least one honest peer?
11:41 < theStack> talking about transaction origin privacy, what happened to dandelion aka bip 156 by the way?
11:41 < sipa> ariard: that depends on your threat model; if your goal is "not being censored", yes, nothing can go around requiring at least one honest peer
11:42 < sipa> ariard: if your goal is "knowing when i'm being censored", softforking it go from impossible to possible in the presence of no honest peers
11:42 < michaelfolkson> There hasn't even been a PR opened for dandelion has there? So even further from merging than Erlay
11:42 < sipa> i think dandelion is dead
11:42 < theStack> sipa: oh
11:42 < sipa> i don't see any solutions to its problems
11:43 < ariard> sipa: okay I see your point, "knowing when I'm being censored" is okay when you're doing onchain tx only you can just stop
11:43 < ariard> in the LN-model you have to do something, not acting is itself an issue,so you have to find at least one peer
11:44 < sipa> ariard: sure, so part of LN's security model is needing at least one honest peer - that's a tradeoff, but no technology can change that
11:44 < michaelfolkson> A resource for understanding Dandelion's problems please if there is one to hand? :)
11:44 < theStack> i gotta go, hopefully see you all tomorrow!
11:44 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has quit [Quit: leaving]     
11:44 < michaelfolkson> Conceptually it seemed to make sense
11:45 < ariard> sipa: I agree it's more being aware that if softfork, what attack vectors are still left open
11:45 < jonatack> michaelfolkson: iirc it had nigh-intractable DoS issues?
11:46 < sipa> michaelfolkson: https://bitcoin.stackexchange.com/questions/81503/what-is-the-tradeoff-between-privacy-and-implementation-complexity-of-dandelion
11:46 < michaelfolkson> Excellent, thank you sipa
11:50 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]     
11:55 -!- gzhao408 [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
11:59 -!- bordalix [~bordalix@191.87.108.93.rev.vodafone.pt] has quit [Ping timeout: 240 seconds]     
11:59 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has left #bitcoin-core-pr-reviews []     
12:06 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.5 - https://znc.in]     
12:12 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
12:37 -!- hanhua [63687d99@99-104-125-153.lightspeed.sntcca.sbcglobal.net] has quit [Remote host closed the connection]     
12:44 -!- b10c [~b10c@2001:16b8:2eec:9500:84c3:6b41:a9b1:ca38] has quit [Quit: Leaving]     
13:02 -!- ja [janus@anubis.0x90.dk] has joined #bitcoin-core-pr-reviews     
13:06 -!- lightlike [~lightlike@p200300C7EF12A1002565156999F67ADA.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
13:54 < thomasb06> how do you manage recovering the chat, I don't dare closing emacs...
13:55 < ja> thomasb06: the channel is logged, you can read the logs online. or you can use a bouncer. or you can run your irc client on a server
13:57 < lightlike> https://bitcoincore.reviews/18806.html
13:57 < thomasb06> Wow... Maybe the simpler is to read the logs online, where can I find them?
13:58 < thomasb06> Cheers
13:59 < thomasb06> And there's the links too, that's great.
13:59 < thomasb06> How do you run an irc client on a server, if it's not to difficult I'll try?
14:01 < sipa> if you have a VPS or other hosting with SSH, you can run a terminal-based IRC client like irssi in screen/tmux/...
14:02 < willcl_ark> thomasb06: if you want something a "bit more GUI" to start, I would recommend quassel: https://bugs.quassel-irc.org/projects/quassel-irc/wiki
14:02 < sipa> yeah, the terminal/ssh based solution can be daunting if you're not familiar with those things
14:03 -!- bordalix [~bordalix@191.87.108.93.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews     
14:03 < willcl_ark> If you live inside a terminal all day anyway, it makes more sense though :)
14:04 < thomasb06> arg, it takes a 24/7 PC... It's just me, myself and my computer, this solution is beyond my possibilities
14:04 < sipa> then a bouncer or some hosted solution is better
14:05 < thomasb06> a bouncer, let me search the Internet
14:05 -!- handed [~handed@178.162.222.42.adsl.inet-telecom.org] has quit [Quit: handed]     
14:05 < thomasb06> How to stay connected to IRC using a bouncer: https://geeksocket.in/blog/connect-irc-bouncer/
14:07 -!- lightlike [~lightlike@p200300C7EF12A1002565156999F67ADA.dip0.t-ipconnect.de] has left #bitcoin-core-pr-reviews ["Leaving"]     
14:07 -!- bordalix [~bordalix@191.87.108.93.rev.vodafone.pt] has quit [Ping timeout: 260 seconds]     
14:09 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:cc78:c0db:3f4d:fe88] has quit [Quit: Sleep mode]     
14:10 < emzy> I like Quassel. It is a hybrid of a bouncer and a irc client. You run the server on a vpn an can clients everywhere.
14:10 < sipa> on a vps, i think you mean
14:11 < sipa> which sounds like it isn't an option for thomasb06
14:13 < thomasb06> yep, I only have access to my desktop computer... But the bouncer solution looks perfect, I need to find to parameterize emacs and should do
14:15 < thomasb06> well, that's it for today. (my phd need to move forward too...)
14:15 < thomasb06> good night
14:16 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection]     
14:16 < ja> thomasb06: night! hope you get a bouncer working!
14:32 -!- grunch__ [~grunch@2800:810:547:c46:25e8:a7de:f130:fe8] has quit [Ping timeout: 272 seconds]     
14:35 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Quit: WeeChat 1.9.1]     
15:01 -!- brakmic [~brakmic@185.183.85.108] has quit []     
15:28 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
15:31 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]     
15:44 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:cc78:c0db:3f4d:fe88] has joined #bitcoin-core-pr-reviews     
15:51 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:cc78:c0db:3f4d:fe88] has quit [Quit: Sleep mode]     
16:24 -!- dfmb_ [~dfmb_@2001:8a0:f342:ad01:fd0c:739e:2f0a:fa58] has joined #bitcoin-core-pr-reviews     
16:29 -!- AdsoM [~AdsoM@fixed-187-189-156-76.totalplay.net] has joined #bitcoin-core-pr-reviews     
16:29 -!- AdsoM [~AdsoM@fixed-187-189-156-76.totalplay.net] has left #bitcoin-core-pr-reviews []     
16:35 -!- ElizabethCo [55e945aa@gateway/web/cgi-irc/kiwiirc.com/ip.85.233.69.170] has joined #bitcoin-core-pr-reviews     
16:37 -!- ElizabethCo [55e945aa@gateway/web/cgi-irc/kiwiirc.com/ip.85.233.69.170] has quit [Client Quit]     
16:53 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
16:54 -!- jonatack [~jon@134.19.179.195] has quit [Ping timeout: 246 seconds]     
16:55 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
16:56 -!- jonatack [~jon@37.173.38.62] has joined #bitcoin-core-pr-reviews     
16:57 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]     
16:58 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
17:02 -!- mol [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]     
17:03 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
17:07 -!- dfmb_ [~dfmb_@2001:8a0:f342:ad01:fd0c:739e:2f0a:fa58] has quit [Quit: Leaving]     
17:07 -!- bordalix [~bordalix@191.87.108.93.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews     
17:11 -!- bordalix [~bordalix@191.87.108.93.rev.vodafone.pt] has quit [Ping timeout: 240 seconds]     
17:22 -!- r251d [~r251d@162-196-59-192.lightspeed.irvnca.sbcglobal.net] has quit [Quit: r251d]     
18:39 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds]     
19:17 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
19:36 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
19:44 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds]     
20:09 -!- bordalix [~bordalix@191.87.108.93.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews     
20:14 -!- bordalix [~bordalix@191.87.108.93.rev.vodafone.pt] has quit [Ping timeout: 246 seconds]     
20:16 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
20:23 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]     
21:18 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
21:19 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
21:23 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
21:23 -!- vasild_ is now known as vasild     
21:32 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
21:35 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
21:51 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
21:54 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
21:58 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
22:02 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]     
22:03 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
22:06 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]     
22:19 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
22:27 -!- jesseposner [~jesseposn@c-67-188-220-154.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]