--- Log opened Fri Mar 29 00:00:29 2019
00:31 -!- Krellan [~Krellan@2601:640:4000:a876:7538:8576:93c4:25d5] has joined #bitcoin-core-dev
00:36 -!- Krellan [~Krellan@2601:640:4000:a876:7538:8576:93c4:25d5] has quit [Ping timeout: 250 seconds]
00:41 -!- rex4539 [~rex4539@ppp-2-84-169-44.home.otenet.gr] has quit [Quit: rex4539]
01:10 -!- zhangzf [~zhangzf@106.38.157.147] has quit [Read error: Connection reset by peer]
01:10 -!- zhangzf [~zhangzf@106.38.157.147] has joined #bitcoin-core-dev
01:14 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Quit: quit]
01:14 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-core-dev
01:20 -!- niska [~niska@68.ip-149-56-14.net] has quit [Quit: Leaving]
01:26 -!- rex4539 [~rex4539@ppp-2-84-169-44.home.otenet.gr] has joined #bitcoin-core-dev
01:30 -!- niska [~niska@68.ip-149-56-14.net] has joined #bitcoin-core-dev
02:02 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
02:20 -!- darosior [~darosior@193-141-190-109.dsl.ovh.fr] has joined #bitcoin-core-dev
02:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:23 < bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9e7dc682e0f6...edc68d40e968
02:23 < bitcoin-git> bitcoin/master f6ee177 practicalswift: Remove unused AES-128 code
02:23 < bitcoin-git> bitcoin/master edc68d4 Jonas Schnelli: Merge #15663: crypto: Remove unused AES-128 code
02:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:23 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
02:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:23 < bitcoin-git> [bitcoin] jonasschnelli merged pull request #15663: crypto: Remove unused AES-128 code (master...aes-128) https://github.com/bitcoin/bitcoin/pull/15663
02:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:39 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
03:07 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
03:07 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
03:18 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
03:24 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
03:42 -!- rex4539 [~rex4539@ppp-2-84-169-44.home.otenet.gr] has quit [Quit: rex4539]
03:45 -!- internetworm is now known as badcc
03:45 -!- badcc is now known as badccvoid
03:47 -!- badccvoid [~internetw@hyphovy.net] has left #bitcoin-core-dev []
03:48 -!- badccvoid [~internetw@unaffiliated/dav] has joined #bitcoin-core-dev
03:58 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
04:08 -!- zhangzf [~zhangzf@106.38.157.147] has quit [Remote host closed the connection]
04:29 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
04:29 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
04:45 -!- jonatack [6d0d4c36@gateway/web/freenode/ip.109.13.76.54] has joined #bitcoin-core-dev
04:52 -!- darosior [~darosior@193-141-190-109.dsl.ovh.fr] has quit [Remote host closed the connection]
04:59 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev
05:14 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Ping timeout: 245 seconds]
05:15 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 272 seconds]
05:24 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
05:27 -!- zhangzf [~zhangzf@223.72.40.79] has joined #bitcoin-core-dev
05:31 -!- zhangzf [~zhangzf@223.72.40.79] has quit [Remote host closed the connection]
05:38 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
05:39 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
05:41 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #bitcoin-core-dev
05:42 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 246 seconds]
05:45 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
05:46 -!- rex4539 [~rex4539@ppp-2-84-169-44.home.otenet.gr] has joined #bitcoin-core-dev
05:46 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Read error: Connection reset by peer]
05:55 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev
06:09 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 245 seconds]
06:22 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev
06:24 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
06:24 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
06:27 -!- Bullitje [~Bullit01@042-236-158-163.dynamic.caiway.nl] has quit [Read error: Connection reset by peer]
06:30 -!- zhangzf [~zhangzf@120.244.109.76] has joined #bitcoin-core-dev
07:04 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
07:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
07:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
07:23 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Remote host closed the connection]
07:23 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
07:28 -!- badccvoid is now known as asimo3089
07:28 -!- asimo3089 is now known as badcc
07:28 -!- badcc is now known as badccvoid
07:34 -!- saks [~saks@88-117-107-15.adsl.highway.telekom.at] has joined #bitcoin-core-dev
07:41 -!- shesek [~shesek@2.55.17.49] has joined #bitcoin-core-dev
07:41 -!- shesek [~shesek@2.55.17.49] has quit [Changing host]
07:41 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
07:42 < gkrizek> Could I get perhaps get another review on #15255. It's just a CI fix, but could probably use another look
07:42 < gribble> https://github.com/bitcoin/bitcoin/issues/15255 | [tests] Remove travis_wait from lint script by gkrizek · Pull Request #15255 · bitcoin/bitcoin · GitHub
07:49 -!- zhangzf [~zhangzf@120.244.109.76] has quit [Remote host closed the connection]
07:53 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 250 seconds]
07:54 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
07:55 -!- jonatack [6d0d4c36@gateway/web/freenode/ip.109.13.76.54] has quit []
07:59 -!- badccvoid is now known as badccv
07:59 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev
08:08 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection]
08:13 -!- Deadhand [~deadhand@kntaon1614w-grc-11-76-66-96-100.dsl.bell.ca] has quit [Ping timeout: 268 seconds]
08:14 -!- Deadhand [~deadhand@kntaon1614w-grc-07-174-92-71-233.dsl.bell.ca] has joined #bitcoin-core-dev
08:22 -!- farmerwampum_ [~wampum@162.219.179.34] has joined #bitcoin-core-dev
08:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
08:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
08:24 -!- MarcoFalke [~none@198.12.116.246] has quit [Ping timeout: 246 seconds]
08:24 -!- spinza [~spin@155.93.246.187] has quit [Ping timeout: 255 seconds]
08:24 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-dev
08:24 -!- Ll1i1lL [~Ll1iiii1l@108-243-84-79.lightspeed.bcvloh.sbcglobal.net] has quit [Ping timeout: 246 seconds]
08:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:25 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/edc68d40e968...904129b35dd6
08:25 < bitcoin-git> bitcoin/master 8b8d8ee Graham Krizek: Remove travis_wait from lint script
08:25 < bitcoin-git> bitcoin/master 904129b MarcoFalke: Merge #15255: [tests] Remove travis_wait from lint script
08:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:25 -!- farmerwampum__ [~wampum@162.219.179.34] has quit [Ping timeout: 255 seconds]
08:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 255 seconds]
08:25 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
08:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:25 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15255: [tests] Remove travis_wait from lint script (master...remove-travis_wait) https://github.com/bitcoin/bitcoin/pull/15255
08:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
08:27 -!- Ll1i1lL [~Ll1iiii1l@108-243-84-79.lightspeed.bcvloh.sbcglobal.net] has joined #bitcoin-core-dev
08:27 -!- badccv [~internetw@unaffiliated/dav] has quit [K-Lined]
08:28 < gkrizek> Thanks MarcoFalke
08:31 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
08:36 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 256 seconds]
08:44 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev
08:49 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev
08:52 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
08:54 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Ping timeout: 246 seconds]
08:57 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Excess Flood]
08:57 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev
09:00 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev
09:16 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds]
09:18 -!- Urgo [~Urgo@cpe-107-15-142-254.nc.res.rr.com] has joined #bitcoin-core-dev
09:27 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
09:44 -!- qu4ku [~qu4ku@2a01:110f:d06:bd00:4d4d:705a:ed50:ec97] has joined #bitcoin-core-dev
10:00 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 250 seconds]
10:01 -!- adiabat [~adiabat@63.209.32.102] has quit [Remote host closed the connection]
10:04 -!- adiabat [~adiabat@63.209.32.102] has joined #bitcoin-core-dev
10:05 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev
10:20 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 268 seconds]
10:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:21 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/904129b35dd6...dc5c2e440746
10:21 < bitcoin-git> bitcoin/master 1c29ac4 John Newbery: [tests] style fixes in feature_pruning.py
10:21 < bitcoin-git> bitcoin/master 03d6d23 John Newbery: [tests] make pruning test faster
10:21 < bitcoin-git> bitcoin/master dc5c2e4 MarcoFalke: Merge #15686: [tests] make pruning test faster
10:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
10:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:22 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15686: [tests] make pruning test faster (master...2019_03_faster_pruning_test) https://github.com/bitcoin/bitcoin/pull/15686
10:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
10:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:23 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/dc5c2e440746...0baf4b1f9663
10:23 < bitcoin-git> bitcoin/master 2a1408c Peter Bushnell: Comment for seemingly duplicate LIBBITCOIN_SERVER
10:23 < bitcoin-git> bitcoin/master 0baf4b1 MarcoFalke: Merge #15683: Comment for seemingly duplicate LIBBITCOIN_SERVER
10:23 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 246 seconds]
10:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:24 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15683: Comment for seemingly duplicate LIBBITCOIN_SERVER (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15683
10:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:27 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #15696: [qa] test_runner: Move feature_pruning to base tests (master...1904-qaPruning) https://github.com/bitcoin/bitcoin/pull/15696
10:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:27 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Quit: leaving]
10:28 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
10:31 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
10:32 -!- linksxxx [~linksxxx@78.30.21.144] has joined #bitcoin-core-dev
10:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:41 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #15697: qa: Make swap_magic_bytes in p2p_invalid_messages atomic (master...1904-qaMagicAtomic) https://github.com/bitcoin/bitcoin/pull/15697
10:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:06 -!- Sentineo [~Undefined@unaffiliated/sentineo] has quit [Quit: drdb sucks sometimes]
11:13 -!- obsrver [~quassel@p5DE86041.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
11:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
11:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
11:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:29 < bitcoin-git> [bitcoin] practicalswift opened pull request #15699: Remove no-op CClientUIInterface::[signal_name]_disconnect. Disconnect BlockNotifyGenesisWait and RPCNotifyBlockChange properly. (master...remove-CClientUIInterface-signal_name_disconnect) https://github.com/bitcoin/bitcoin/pull/15699
11:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:31 < meshcollider> Apologies, I'm travelling to Portugal for ICPC at the moment so my timezone is completely messed up, I missed the meeting yesterday and will have to miss the wallet meeting today too if its on
11:32 < meshcollider> Do people have topics they want to discuss? It should start in half an hour if my calculation is right, anyone who wants to can chair it 
11:38 -!- qu4ku [~qu4ku@2a01:110f:d06:bd00:4d4d:705a:ed50:ec97] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
11:50 -!- jimmysong_ [~jimmysong@72-48-253-51.dyn.grandenetworks.net] has quit [Ping timeout: 245 seconds]
12:02 < MarcoFalke> Doesn't seem like it :)
12:02 < achow101> I have a topic, but not at computer now. Give me a few minutes
12:03 -!- andcoisqu [8e70b9af@gateway/web/freenode/ip.142.112.185.175] has quit [Ping timeout: 256 seconds]
12:04 < jnewbery> hi! I had a small topic.
12:05 < jnewbery> shall I wait until achow101 is back?
12:05 < sipa> i'm here, but don't have anything
12:05 < sipa> let's wait
12:10 < achow101> here now
12:10 < jnewbery> sipa: care to chair?
12:10 < sipa> #startmeeting
12:10 < lightningbot> Meeting started Fri Mar 29 19:10:38 2019 UTC.  The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:10 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:10 < sipa> yow, topics?
12:10 < jnewbery> suggested topic: rebroadcast behaviour
12:10 < instagibbs> hmm calendar is off by a week, here
12:11 < jnewbery> instagibbs: it was delayed by a week during FC and didn't revert
12:12 < achow101> suggested topic: non-hardened derivation paths
12:12 < sipa> #topic rebroadcast behaviour
12:12 < instagibbs> I see we finally have rebroadcast tests :)
12:13 < jnewbery> I've been looking at wallet rebroadcasts. The current behaviour is: set a timer for random (0, 30). When it pops rebroadcast all unconfirmed wallet txs. Set timer again.
12:13 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
12:13 < sipa> but only if there has been a new block since the previous rebroadcast?
12:13 < jnewbery> (it's not quite as bad as that because each peer has a bloom filter so we won't actually rebroadcast until it's been purged from there)
12:13 < jnewbery> ah yes, as long as there's been a block
12:13 < jnewbery> I have a couple of suggested changes
12:14 < jnewbery> 1. separate the scheduling, so each tx is on its own timer, instead of sending them all at once
12:14 < jnewbery> 2. have the wallet remember some number of random txs it sees from the mempool, and add those to its rebroadcast list as decoys
12:14 < jnewbery> wanted to get some concept feedback on those before I started coding up
12:15 < sipa> so (1) is problematic if there are interdependent unconfirmed transactions in your wallet
12:15 < sipa> as you may end up sending a child to a different peer than the parent
12:15 < sipa> gmaxwell: opinions? ^
12:16 < jnewbery> in (1), I'd think we'd still send each tx to all peers
12:16 < sipa> oh!
12:16 < jnewbery> just not all at the same time
12:16 < instagibbs> trickle rather than flood
12:16 < sipa> right, but you may send the child before the parent
12:16 < sipa> (they get sorted in the broadcast buffer before actual sending, but that's just a few-seconds timer)
12:17 < sipa> i don't know whether the rebroadcast mechanism in the wallet currently actually cares about that
12:17 < jnewbery> I think it doesn't, but I'd have to recheck
12:17 < sipa> yeah, but if it sends all unconfirmed txn, they'll get sorted before broadcast
12:18 < jnewbery> oh, where does that happen?
12:18 < sipa> sendmessages
12:19 < sipa> there's a poisson distributed per-peer timer (but simultaneous for all inbound connections) that flushes a buffer of to-be-broadcast txn
12:20 < jnewbery> yeah, I see it now
12:20 < sipa> and it sorted first by dependency order and then lexicographically 
12:20 < sipa> *sorts
12:20 < sipa> so if you announce an txid within a few seconds of each other, there's a high chance they'll end up being sorted correctly before actual broadcast
12:20 < jnewbery>  // Topologically and fee-rate sort the inventory we send for privacy and priority reasons.
12:20 < sipa> yeah, that
12:21 < sipa> oh yes, feerate; not lexicographically
12:21 < gmaxwell> (1) could consider only the deepest ancestors and announce all the parents at once.
12:21 < gmaxwell> ignoring the details (1) sounds like a very important improvement.
12:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
12:22 < jnewbery> is the wallet aware of dependencies in its transactions?
12:22 < sipa> yes
12:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
12:22 < gmaxwell> er only the deepest children.
12:24 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Remote host closed the connection]
12:24 < gmaxwell> (2) I don't have a problem with but I think the benefit is a bit dubious, like random txn by itself very likely provides no privacy improvement, because only the real sender or recipent will send txn for all of a single address/linked address consistently.   It's sometimes hard to tell where the line is between snake oil that just adds complexity to the codebase for no protection against an 
12:24 < gmaxwell> even slightly incompetent attacker, vs fuzzing things up in a way that provides incremental privacy even though far from perfect
12:24 < sipa> jnewbery: mapTxSpends
12:24 -!- Sentineo [~Undefined@unaffiliated/sentineo] has joined #bitcoin-core-dev
12:24 < gmaxwell> I would think though that matching random addresses would be a lot better than random txn.
12:25 < gmaxwell> I think a (3) avoiding pointles retransmissions would be more helpful.  But I would happily review an implementation of (2), reservations aside.
12:25 < jnewbery> Do we know what percentage of txs are re-used addresses? And what number of those re-used addresses have multiple unconfirmed txs at the same time?
12:25 < gmaxwell> jnewbery: 'most' (I expect sipa will provide some numbers) But it's not just a same time question:
12:26 < sipa> jnewbery: also, poisson distributed rebroadcast events are probably more private than uniform distributed ones
12:26 < gmaxwell> what I think it should do is per node pick a random value (e.g. the addr man randomizer) and use that to consistently select some small portion of addresses to rebroadcast.
12:26 < gmaxwell> so that over months of time we're consisently rebroadcasting the same other addresses.
12:26 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev
12:26 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Remote host closed the connection]
12:26 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Quit: Leaving]
12:27 < gmaxwell> Yeah uniform leaks information that possion doesn't, possion is the distribution you get from memoryless processes.
12:27 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev
12:27 < jnewbery> if you're talking about months of time, then presumably you'd need to save this to disk
12:28 < sipa> the addrman randomizer is stored on disk
12:28 < gmaxwell> Thats why I specified that one.
12:28 < jnewbery> So you're saying this behaviour should live in the node rather than the wallet?
12:28 < sipa> wallet is easier i think
12:29 < gmaxwell> also if you wipe out your peers.day because you're trying to avoid addrman based fingerprinting then you'll also wipe rebroadcast fingerprinting.
12:29 < jnewbery> the wallet isn't aware of peers
12:29 < gmaxwell> I think nodes without wallets should d this too.
12:29 < sipa> but it would possibly result in identifiable behavior that can be detected if a wallet file moves to another node
12:29 < gmaxwell> because there are many walletless nodes that would provide cover...
12:29 < gmaxwell> maybe thats not realistic for engineering reasons. ::shrugs:: I'm just talking spherical cows here.
12:30 < gmaxwell> In any case, if it isn't consistent like this, it's really obvious to me how attackers will filter it out. Monitor, and look for dispositive failures to rebroadcast. The real source won't have them, the fake sources will.
12:30 < jnewbery> I think the implementation can be quite minimal if the wallet just keeps its own list of txs and doesn't try to distinguish behaviour between peers
12:30 < gmaxwell> and given someone that already has network wide monitoring that filtering is probably only a dozen lines of code/query.
12:31 < jnewbery> are you saying genuine wallet rebroadcasts should also be to only one peer?
12:31 < jnewbery> because if its to all peers that's different behaviour than decoy rebroadcasts and would be easy to spot
12:32 < gmaxwell> no, both should be to all peers.
12:32 < jnewbery> then I've misunderstood your 'per node' comment above
12:33 < gmaxwell> jnewbery: my node being different from yours.
12:33 < jnewbery> ok
12:33 < gmaxwell> I prefer to rebroadcast 1apple you prefer to rebroadcast 1spatula.
12:33 < jnewbery> yep
12:33 < gmaxwell> and if I restart I still prefer 1apple.
12:33 < gmaxwell> so an attacker can't tell if I like 1apple's addresses because of my random number or because I am 1apple.
12:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:34 < bitcoin-git> [bitcoin] promag opened pull request #15700: rfc: Synchronize validation interface registration (master...2019-03-sync-validation-interface-registration) https://github.com/bitcoin/bitcoin/pull/15700
12:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:34 < sipa> so what if the address you pick for rebroadcasts suddenly gets a ton of transactions
12:34 < gmaxwell> sipa: well you're going to relay them on the network regardless.
12:35 < gmaxwell> So I don't think thats actually a major cost?
12:35 < sipa> ah right, if it's per node they'd just be broadcast from the mempool directly; no need to copy/store them elsewhere
12:36 < sipa> though you do need to keep track of txn that spend outputs assigned to the addresses you've chosen
12:36 < sipa> but that could just be a boolean per-tx i guess
12:37 < gmaxwell> right. all these considerations is why I'm a little dubious. I think the simplest version does little to nothing. And I'm not sure of the bound of the complexity on an effort to really be indistinguishable. I mean mean one way would be to effectively importaddress on random addresses you see with a flag to hide them in the wallet but implemented that way would have too many DOS potentials.
12:38 < gmaxwell> it would, however, have a pretty strong guarentee that you'd treat them the same, making them very hard to distinguish.
12:38 < gmaxwell> though it would also only work if you have a wallet.
12:38 < jnewbery> I think just selecting random txs is surely better than little to nothing
12:39 < sipa> another approach is having the rebroadcast mechanism be purely in the node, and have it mark some subset of transactions... but then have the wallet forcibly set that mark on its own transactions too
12:39 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 246 seconds]
12:39 < sipa> but the wallet doesn't do the rebroadcasting
12:40 < gmaxwell> jnewbery: I think any existing deanon attackers can filter out random tx rebroadcasts fairly reliably with a line of code, maybe its still worth doing. We have other paper thin privacy mechenisms (e.g. most of the node anti-fingerprinting).
12:41 < jnewbery> but if they're random, some of them will be for addresses that aren't re-used. How would the attacked filter those out?
12:41 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
12:42 < gmaxwell> jnewbery: A couple ways: for rebroadcast purposes every coin that isn't lost is reused, since senders and recipents both rebroadcast. Also even when addresses aren't reused, they're co-used in inputs with other transactions. So broadcasting of the complete address cluster is also a fairly strong hurestic.
12:43 < gmaxwell> I think you've convinced me that in at least some cases it would be indistinguishable.
12:43 < jnewbery> Many txs don't get rebroadcast at all and are confirmed in the next block
12:43 < gmaxwell> e.g. one side of send/recieve doesn't need any rebroadcast, no reuse, no useful information from clustering.
12:44 < jnewbery> Right. An attacker can't tell if you would have rebroadcast
12:44 < gmaxwell> (thats also, aside, a reason rebroadcasts should be possion timed)
12:45 < sipa> maybe we should move to achow101's topic?
12:45 -!- saks [~saks@88-117-107-15.adsl.highway.telekom.at] has quit [Quit: Leaving]
12:45 < jnewbery> I don't think I need anything else on this for now. Thanks for the input!
12:45 < achow101> I've started working native descriptor wallets and I just wanted some opinions on some parts of the design.
12:46 < sipa> cool
12:46 < sipa> #topic non-hardened derivation paths
12:46 < achow101> right now I have the wallet make 6 descriptors, in pairs of 3. each pair has an internal and external descriptor, and each pair for each of the address types
12:47 < sipa> makes sense
12:47 < achow101> it uses derivation paths that we currently use in the wallet, but I think it would be better if we used bip 44/49/89
12:47 < achow101> thoughts? it would mean that we use non-hardened derivation paths
12:47 < sipa> i think using non-hardened derivation paths is fine if there is no way to export the individual private keys
12:48 < gmaxwell> I think it's necessary to disable key export on anything non-hardened.
12:48 < achow101> as it is now, we need to have a new seed for each address type or we'll end up using keys accidentally
12:48 < achow101> I think that the only export that will be possible is exporting the entire private descriptor itself
12:48 < sipa> achow101: you would certainly use distinct paths for each of the address types
12:49 < sipa> achow101: agree
12:49 < gmaxwell> Also, I don't think we should be defaulting to using non-hardened unless we're actually making real use of its abilityies (like to cogenerate addresses with an external signer).
12:49 < achow101> i'll be disabling dumpprivkey and all of the imports for descriptor wallets
12:50 < sipa> gmaxwell: it also has the advantage of not needing to decrypt the wallet to generate more addresses
12:50 < gmaxwell> so generate 100,000 addresses the first go. :)
12:50 < gmaxwell> it's a lot of fragility to save a megabyte of file size. :P
12:50 < achow101> gmaxwell: it has the advantage of making the wallet file extremely small
12:51 < gmaxwell> the wallet file grows from transactions regardless. if you're actually using addresses it'll get big.
12:51 < sipa> anyway, i think it certainly makes sense to support nonhardened derivation
12:51 < gmaxwell> Sure.
12:52 < achow101> right now the thing I don't like is that it needs 3 different seeds, one for each address type
12:52 < sipa> achow101: that shouldn't be needed; you can use distinct derivation paths even when using hardened?
12:52 < gmaxwell> as far as making wallets small, that I think is mostly interesting for backups, and for that it might be best to have tools/rpcs that strips wallets for backup purposes. 
12:52 < achow101> sipa: yes, but I don't really like having to introduce yet another set of derivation paths that people have to consider
12:53 < achow101> vs. using existing standards
12:53 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection]
12:53 < sipa> achow101: that's why you encode it as a descriptor; it's universal :)
12:53 < sipa> but sure- i agree at a high level it's unnecessary to introduce new standards when existing ones exist
12:54 < sipa> the question is whether hardened or unhardened is more desirable - i don't know, and it may depend on the situation
12:54 < gmaxwell> This is just broken.
12:54 < achow101> ?
12:54 < gmaxwell> 'existing standards' were made by people considering entirely different use cases and deployment enviroments (hardware wallets)
12:55 < gmaxwell> and with a different focus on security (a lot closer to 'who cares')
12:55 < sipa> well when we'd use a nonhardened derivation (for external reasons) it makes sense to follow those standards
12:55 < sipa> the question remains whether or not to use hardened or not
12:55 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
12:56 < gmaxwell> sipa: it might, if it is otherwise fine and would actually result in some kind of useful compatibility.
12:56 < gmaxwell> like we'll never be compatible with electrum (say) by using the same path, simply because we generate parllel native and compatibility addresses.
12:56 < achow101> gmaxwell: the plan for descriptor wallets is not generate them in parallel
12:57 < achow101> each address type will have it's own derivation path base
12:57 < sipa> yeah, so your bitcoin core wallet will correspond to a union of several things that are (possibly) compatible with an electrum wallet individually
12:58 < gmaxwell> a wallet where you can recover part of the funds and the rest are just invisibly lost isn't compatible though, if anything its a liability.
12:59 < sipa> right
13:00 < achow101> anywys, it seems like the preference is to use hardened
13:01 < gmaxwell> Generally thats my strong preference, except in cases where there is a 'application layer' gain from otherwise.
13:01 < gmaxwell> Not just some 'its easier to write this way' or 'wallet file is somewhat smaller for unspecified benenfits'
13:02 < sipa> seems we're out of time
13:03 < gmaxwell> I really regret ever coming up with public derrivation and wish I could take it back,  The original application I had for it is still unavailable to people (so your web server could securely generate fresh addresses for you) in practice... and it gets applied *everywhere* simply because reusing a key is simpler to implement. 
13:03 < achow101> well that's all I had for today. there was something else I wanted to discuss, but I don't remember what that was
13:03 < achow101> so clearly it wasn't very important
13:04 < gmaxwell> .. and its resulted in funds loss, and it also results in expectations we won't be able to support for post ECC keys. 
13:04 < sipa> #endmeeting
13:04 < lightningbot> Meeting ended Fri Mar 29 20:04:46 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:04 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-29-19.10.html
13:04 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-29-19.10.txt
13:04 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-29-19.10.log.html
13:05 < achow101> gmaxwell: well it's been useful for hardwre wallets. asking a hardware wallet for a few thousand keys is not exactly a fun time
13:06 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
13:07 < gmaxwell> achow101: yes, though really that isn't at all fundimental.
13:07 < gmaxwell> like if it didn't exist, hardware wallets would just cost $5 have a 10x faster cpu, and a faster interface, and no one would notice otherwise.
13:07 < gmaxwell> (or alternatively they'd just support a single address... :P)
13:07 < gmaxwell> er cost $5 more
13:08 < gmaxwell> I also agree that they're not terribly bad for the hardware wallet case.  That isn't really all that different from the orignal 'webserver' usecase, except your wallet is the webserver.
13:09 < gwillen> this is more generally the "not having to expose your private key in more places than necessary" usecase, which seems laudable
13:10 < gmaxwell> though also the security of generating addresse on an untrusted device is kinda dubious. eventually the bad guys will have taken all the low hanging fruit and the next set of attacks will just be to make createnewaddress like interfaces return attacker addresses. :P
13:10 < gwillen> although due to not trusting software, these days I always check new addresses against each other on both machines anyway
13:10 < gwillen> yeah
13:10 < gwillen> you could very well generate new addresses independently in parallel on multiple devices and check them that way
13:10 < gwillen> with none of them being the private device
13:10 < gwillen> but ain't nobody got time for that
13:11 < gmaxwell> gwillen: there are goals in conflict, "reuse private keys" = bad. "use keys too much" =bad.  Essentially all non-hardened keys share the same private key, so it's reuse of a private key. 
13:11 < gmaxwell> gwillen: indeed. 
13:13 < gwillen> reuse of private keys being bad seems very implementation- and UX-specific somehow
13:14 < gwillen> like, if you treat it as "a series of addresses generated by a single master key, there are no separate individual keys and the software will never give you such a thing" then you mitigate the user-confusion issue
13:20 -!- jonatack [58aba822@gateway/web/freenode/ip.88.171.168.34] has joined #bitcoin-core-dev
13:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
13:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
13:22 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
13:38 -!- StopAndDecrypt [~StopAndDe@184.75.220.202] has joined #bitcoin-core-dev
13:38 -!- StopAndDecrypt [~StopAndDe@184.75.220.202] has quit [Changing host]
13:38 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev
13:38 -!- StopAndDecrypt_ [~StopAndDe@184.75.220.202] has quit [Ping timeout: 250 seconds]
13:39 -!- obsrver [~quassel@p5DE86041.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
13:49 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.4]
13:54 -!- harrymm [~harrymm@43.249.37.7] has joined #bitcoin-core-dev
14:17 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 244 seconds]
14:18 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Quit: quit]
14:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
14:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
14:23 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-core-dev
14:38 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
14:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:43 < bitcoin-git> [bitcoin] jnewbery closed pull request #15010: [wallet] Fix getbalance with minconf (master...fix_getbalance_with_minconf) https://github.com/bitcoin/bitcoin/pull/15010
14:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:43 -!- mn94958851 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has joined #bitcoin-core-dev
14:43 -!- mn94958856 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has joined #bitcoin-core-dev
14:43 -!- mn9495882 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has joined #bitcoin-core-dev
14:47 -!- mn9495881 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has quit [Ping timeout: 245 seconds]
14:47 -!- mn94958855 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has quit [Ping timeout: 244 seconds]
14:47 -!- mn949588 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has quit [Ping timeout: 250 seconds]
14:54 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
15:04 -!- zivl [~zivl@unaffiliated/zivl] has joined #bitcoin-core-dev
15:06 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
15:17 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
15:20 < achow101> sipa: how come ExpandFromCache returns ExpandHelper(..) == 0 ? Seems like a bug to me
15:21 < achow101> oh, nvm. I misread part of it
15:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
15:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
15:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
15:25 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0baf4b1f9663...00ca24b68fc4
15:26 < bitcoin-git> bitcoin/master 1111f07 MarcoFalke: test: .style.yapf: Set column_limit=160
15:26 < bitcoin-git> bitcoin/master 00ca24b MarcoFalke: Merge #15533: test: .style.yapf: Set column_limit=160
15:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
15:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
15:26 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15533: test: .style.yapf: Set column_limit=160 (master...1903-testNoPep8Collim) https://github.com/bitcoin/bitcoin/pull/15533
15:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
15:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
15:28 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/00ca24b68fc4...79c345a0114c
15:28 < bitcoin-git> bitcoin/master afc06fc Torkel Rogstad: rpc: Fix help text for signtransactionwithXXX
15:28 < bitcoin-git> bitcoin/master 79c345a MarcoFalke: Merge #15669: rpc: Fix help text for signtransactionwithXXX
15:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
15:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
15:28 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15669: rpc: Fix help text for signtransactionwithXXX (master...signrawtx-rpc-help) https://github.com/bitcoin/bitcoin/pull/15669
15:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
15:29 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 250 seconds]
15:36 -!- dqx__ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
15:38 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 250 seconds]
15:43 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
15:49 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
15:58 -!- passedpawn [32ecbdea@gateway/web/freenode/ip.50.236.189.234] has joined #bitcoin-core-dev
16:02 -!- passedpawn [32ecbdea@gateway/web/freenode/ip.50.236.189.234] has quit [Ping timeout: 256 seconds]
16:03 -!- ctrlbreak_MAD [~ctrlbreak@142.162.20.53] has joined #bitcoin-core-dev
16:07 -!- ctrlbreak [~ctrlbreak@142.162.20.53] has quit [Ping timeout: 246 seconds]
16:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
16:22 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
16:23 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Remote host closed the connection]
16:24 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit []
16:28 -!- tryphe_000 [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
16:31 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 246 seconds]
16:41 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
16:42 -!- tryphe_000 [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 245 seconds]
16:46 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 245 seconds]
16:48 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
17:22 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Quit: WeeChat 2.4]
17:24 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev
17:45 -!- zhangzf [~zhangzf@223.72.40.79] has joined #bitcoin-core-dev
17:47 -!- zhangzf [~zhangzf@223.72.40.79] has quit [Remote host closed the connection]
17:56 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
17:56 -!- Urgo [~Urgo@cpe-107-15-142-254.nc.res.rr.com] has quit [Quit: Leaving]
18:02 -!- jarthur [~jarthur@207.114.244.5] has quit []
18:17 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
18:17 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
18:44 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
18:45 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
18:50 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 250 seconds]
18:56 -!- zhangzf [~zhangzf@106.38.157.147] has joined #bitcoin-core-dev
19:27 -!- makey40 [~jodie@24.215.123.241] has quit [Ping timeout: 255 seconds]
19:28 -!- makey40 [~jodie@24.215.123.241] has joined #bitcoin-core-dev
19:32 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
19:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
19:32 < bitcoin-git> [bitcoin] sipa opened pull request #15703: Update secp256k1 subtree to latest upstream (master...201903_secp256k1) https://github.com/bitcoin/bitcoin/pull/15703
19:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
19:32 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
19:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
20:53 -!- qu4ku [~qu4ku@2a01:110f:d06:bd00:1976:82f7:b3be:b328] has joined #bitcoin-core-dev
21:20 -!- qu4ku [~qu4ku@2a01:110f:d06:bd00:1976:82f7:b3be:b328] has quit [Quit: Textual IRC Client: www.textualapp.com]
21:40 -!- ccdle12 [~ccdle12@223.197.182.203] has joined #bitcoin-core-dev
22:42 -!- Krellan [~Krellan@2601:640:4000:a876:64c7:7936:f70c:ef57] has joined #bitcoin-core-dev
23:03 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Quit: leaving]
23:13 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
23:27 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev
--- Log closed Sat Mar 30 00:00:30 2019