--- Day changed Thu Jun 28 2018
00:09 < provoostenator> I'm getting crashes during IBD of a pruned node on one of my ARM devices. It tends to happen during later prune events (e.g. 2015). I set a fairly high dbcache, but during those events dbcache is << RAM (and there's a swap).
00:09 < provoostenator> Worse, it sometimes tells me to reindex.
00:10 < provoostenator> Log shows no indication of why it crashed, but my SSH connection to the machine tends to die when it happens, which does suggest OOM?
00:12 < provoostenator> Perhaps it's just crappy hardware, but given the weird behavior with pruned nodes and large dbcache in IBD I saw in #12404, might indicate some subtle bug.
00:13 < gribble> https://github.com/bitcoin/bitcoin/issues/12404 | Prune more aggressively during IBD by Sjors · Pull Request #12404 · bitcoin/bitcoin · GitHub
00:15 -!- Squidicuz [~squid@pool-173-48-82-37.bstnma.fios.verizon.net] has quit [Quit: Oh no, not again]     
00:18 -!- Krellan [~Krellan@2601:640:4000:9258:944c:3f21:861a:26f9] has quit [Read error: Connection reset by peer]     
00:19 -!- Krellan [~Krellan@2601:640:4000:9258:f522:bef6:c340:592] has joined #bitcoin-core-dev     
00:26 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 256 seconds]     
00:49 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.]     
01:02 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 264 seconds]     
01:04 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
01:04 -!- adam3us [~adam3us@unaffiliated/adam3us] has quit [Ping timeout: 248 seconds]     
01:04 -!- warren [~warren@fedora/wombat/warren] has quit [Ping timeout: 248 seconds]     
01:06 -!- adam3us [~adam3us@unaffiliated/adam3us] has joined #bitcoin-core-dev     
01:06 -!- warren [~warren@fedora/wombat/warren] has joined #bitcoin-core-dev     
01:07 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Read error: Connection reset by peer]     
01:12 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
01:13 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
01:20 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
01:23 < bitcoin-git> [bitcoin] Empact closed pull request #13560: WIP: Drop unused serialization support from CAddresss (master...caddress-serialization) https://github.com/bitcoin/bitcoin/pull/13560
01:24 -!- Krellan [~Krellan@2601:640:4000:9258:f522:bef6:c340:592] has quit [Ping timeout: 260 seconds]     
01:26 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Read error: Connection reset by peer]     
01:31 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
01:33 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
01:57 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
02:13 < bitcoin-git> [bitcoin] droark opened pull request #13561: Qt: Remove unnecessary image buffer for Mac dock icon (master...rm_icon_buffer) https://github.com/bitcoin/bitcoin/pull/13561
02:16 -!- laurentmt [~Thunderbi@185.94.189.190] has joined #bitcoin-core-dev     
02:17 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-ousphcxwzteoczwe] has quit [Quit: Connection closed for inactivity]     
02:27 -!- laurentmt [~Thunderbi@185.94.189.190] has quit [Quit: laurentmt]     
02:28 -!- Sentineo [~Undefined@unaffiliated/sentineo] has joined #bitcoin-core-dev     
02:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:37 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
02:39 -!- Aaronva__ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:42 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 250 seconds]     
02:43 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
02:47 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
02:53 < jonasschnelli> Anyone willing to pre-review a BIP proposal for encrypted wallet seeds https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991? gmaxwell, sipa, roasbeef
02:58 -!- ExtraCrispy [~ExtraCris@185.9.18.150] has joined #bitcoin-core-dev     
03:09 -!- jtimon [~quassel@40.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
03:17 -!- quer [~quer@unaffiliated/quer] has joined #bitcoin-core-dev     
03:18 -!- dbt [~dbt@61.6.133.245] has left #bitcoin-core-dev []     
03:25 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #13562: travis: Switch back to trusty for now (master...Mf1806-qaTravisTrusty) https://github.com/bitcoin/bitcoin/pull/13562
03:31 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
03:32 < promag> mac build in travis uses qt5.7.1?
03:34 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has joined #bitcoin-core-dev     
03:41 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 265 seconds]     
03:51 < bitcoin-git> [bitcoin] promag opened pull request #13563: bench: Simplify CoinSelection (master...2018-08-bench-coinselection) https://github.com/bitcoin/bitcoin/pull/13563
03:53 < promag> MarcoFalke: is that what you mean?
04:05 -!- unholymachine [~quassel@2601:8c:c003:9f16:c5ce:b647:6280:f03d] has joined #bitcoin-core-dev     
04:13 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev     
04:22 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 260 seconds]     
04:37 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev     
04:42 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 260 seconds]     
04:43 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev     
04:48 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 256 seconds]     
05:07 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d96bdd78307b...2328039bfc49
05:07 < bitcoin-git> bitcoin/master fa103a5 MarcoFalke: [qa] wallet_basic: Specify minimum required amount for listunspent
05:07 < bitcoin-git> bitcoin/master 2328039 MarcoFalke: Merge #13535: [qa] wallet_basic: Specify minimum required amount for listunspent...
05:08 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13535: [qa] wallet_basic: Specify minimum required amount for listunspent (master...Mf1806-qaWalletBasic) https://github.com/bitcoin/bitcoin/pull/13535
05:10 -!- Aaronva__ is now known as AaronvanW     
05:11 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2328039bfc49...c93c360eec4d
05:11 < bitcoin-git> bitcoin/master ea49e06 practicalswift: tests: Fix incorrect documentation for test case cuckoocache_hit_rate_ok
05:11 < bitcoin-git> bitcoin/master c93c360 MarcoFalke: Merge #13551: tests: Fix incorrect documentation for test case cuckoocache_hit_rate_ok...
05:11 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13551: tests: Fix incorrect documentation for test case cuckoocache_hit_rate_ok (master...truth-in-advertising) https://github.com/bitcoin/bitcoin/pull/13551
05:22 -!- BoxerJack3 [~BoxerJack@4.16.216.161] has joined #bitcoin-core-dev     
05:25 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev     
05:26 -!- quer [~quer@unaffiliated/quer] has quit [Ping timeout: 240 seconds]     
05:27 -!- quer [~quer@unaffiliated/quer] has joined #bitcoin-core-dev     
05:31 -!- quer [~quer@unaffiliated/quer] has quit [Read error: Connection reset by peer]     
05:31 -!- quer_ [~quer@unaffiliated/quer] has joined #bitcoin-core-dev     
05:32 -!- BoxerJack3 [~BoxerJack@4.16.216.161] has quit [Remote host closed the connection]     
05:32 -!- BoxerJack3 [~BoxerJack@4.16.216.161] has joined #bitcoin-core-dev     
05:32 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 250 seconds]     
05:36 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
05:38 -!- BoxerJack3 [~BoxerJack@4.16.216.161] has quit [Quit: Leaving]     
05:40 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 264 seconds]     
05:42 -!- schnerchi123 [~schnerchi@p5DCB4D4F.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
06:15 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
06:16 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
06:18 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev     
06:22 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 240 seconds]     
06:25 -!- bedo [~bedo@93-34-14-66.ip47.fastwebnet.it] has joined #bitcoin-core-dev     
06:34 < promag> qt: funny thing, connect(..., &Foo::foo) doesn't work if foo is a private slot, BUT connect(..., SLOT(foo()) works..
06:35 < bedo> Hi all, it's only me or the testnet are generating crazy amount of block? 
06:44 < jonasschnelli> bedo: yes. Someone mining with an ASIC farm I guess
06:44 < jonasschnelli> 4-5 seconds interval between blocks. :)
06:46 < bedo> jonasschnelli: today is hard day for develop over bitcoin
06:47 < jonasschnelli> bedo: use regtest. :)
06:47 -!- Lightblock_ [b32baa93@gateway/web/freenode/ip.179.43.170.147] has joined #bitcoin-core-dev     
06:48 < Lightblock_> Hi     
06:48 < Lightblock_> happy to be here
06:48 -!- Lightblock__ [b32baa93@gateway/web/freenode/ip.179.43.170.147] has joined #bitcoin-core-dev     
06:48 -!- Lightblock__ [b32baa93@gateway/web/freenode/ip.179.43.170.147] has quit [Client Quit]     
06:49 < Lightblock_> sorry if silly question, could anyone please suggest a proper way to the bitcoin transaction ID given that I know the blockheight txindex and outputindex ?
06:50 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: https://quanto.ga/]     
06:52 < Lightblock_> sorry, seems like I have put in the worng channel
06:52 < Lightblock_> nevermind, asked in the #bitcoin already
06:53 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev     
06:53 < bedo> jonasschnelli: yep, is the only way,  will see you at BOB?
06:54 < jonasschnelli> bedo: Yes. Sure!
06:56 < bedo> jonasschnelli: perfect ;)
07:14 -!- piootr [cebdd21b@gateway/web/freenode/ip.206.189.210.27] has joined #bitcoin-core-dev     
07:28 -!- Lightblock_ [b32baa93@gateway/web/freenode/ip.179.43.170.147] has quit [Ping timeout: 260 seconds]     
07:28 -!- echonaut8 [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
07:28 -!- echonaut [~echonaut@46.101.192.134] has quit [Read error: Connection reset by peer]     
07:30 -!- unholymachine [~quassel@2601:8c:c003:9f16:c5ce:b647:6280:f03d] has quit [Remote host closed the connection]     
07:31 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
07:34 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev     
07:54 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
07:59 -!- infernix [nix@unaffiliated/infernix] has quit [Ping timeout: 260 seconds]     
08:00 -!- rex4539 [~textual@2002:5363:c54e:10:6d2c:5c7d:40d5:ebd4] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
08:01 -!- m8tion [~Agence@abo-134-110-68.mrs.modulonet.fr] has joined #bitcoin-core-dev     
08:07 -!- piootr [cebdd21b@gateway/web/freenode/ip.206.189.210.27] has quit [Ping timeout: 260 seconds]     
08:19 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has quit [Remote host closed the connection]     
08:21 -!- infernix [nix@unaffiliated/infernix] has joined #bitcoin-core-dev     
08:38 -!- bedo [~bedo@93-34-14-66.ip47.fastwebnet.it] has quit [Remote host closed the connection]     
08:39 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 276 seconds]     
08:47 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev     
08:52 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 260 seconds]     
08:57 -!- m8tion [~Agence@abo-134-110-68.mrs.modulonet.fr] has quit [Remote host closed the connection]     
08:58 -!- m8tion [~Agence@abo-134-110-68.mrs.modulonet.fr] has joined #bitcoin-core-dev     
08:59 -!- anthis [~anthis@31.207.58.213] has quit [Ping timeout: 276 seconds]     
09:00 -!- anthis [~anthis@31.207.58.221] has joined #bitcoin-core-dev     
09:01 -!- jtimon [~quassel@40.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 265 seconds]     
09:08 -!- opdenkamp [~opdenkamp@kodi/staff/dushmaniac] has quit [Quit: ZNC 1.6.5+deb1 - http://znc.in]     
09:15 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev     
09:20 -!- Krellan [~Krellan@2601:640:4000:9258:f522:bef6:c340:592] has joined #bitcoin-core-dev     
09:20 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 240 seconds]     
09:27 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
09:30 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
09:31 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:33 -!- unholymachine [~quassel@2601:8c:c003:9f16:c5ce:b647:6280:f03d] has joined #bitcoin-core-dev     
09:39 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev     
09:41 -!- promag [~promag@83.223.250.97] has joined #bitcoin-core-dev     
09:48 -!- m8tion [~Agence@abo-134-110-68.mrs.modulonet.fr] has quit [Remote host closed the connection]     
09:50 -!- m8tion [~Agence@abo-134-110-68.mrs.modulonet.fr] has joined #bitcoin-core-dev     
09:51 -!- opdenkamp [~opdenkamp@kodi/staff/dushmaniac] has joined #bitcoin-core-dev     
09:52 -!- rex4539 [~textual@2002:5363:c54e:10:24db:ad1:ac5e:b52e] has joined #bitcoin-core-dev     
09:57 -!- Lightblock [c20eb3a3@gateway/web/freenode/ip.194.14.179.163] has joined #bitcoin-core-dev     
10:02 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev     
10:13 -!- Lightblock [c20eb3a3@gateway/web/freenode/ip.194.14.179.163] has quit [Ping timeout: 260 seconds]     
10:17 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
10:17 -!- Krellan [~Krellan@2601:640:4000:9258:f522:bef6:c340:592] has quit [Remote host closed the connection]     
10:18 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
10:20 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 264 seconds]     
10:21 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has joined #bitcoin-core-dev     
10:25 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev     
10:28 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
10:29 -!- promag [~promag@83.223.250.97] has quit [Read error: Connection reset by peer]     
10:32 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
10:37 < bitcoin-git> [bitcoin] jnewbery opened pull request #13564: [wallet] loadwallet shouldn't create new wallets. (master...dont_load_nonexistent_wallet) https://github.com/bitcoin/bitcoin/pull/13564
10:40 -!- jtimon [~quassel@40.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
10:43 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev     
10:45 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 240 seconds]     
10:47 -!- Alexandra [~canaima@200.84.62.164] has joined #bitcoin-core-dev     
10:48 < Alexandra> Holaaa
10:48 -!- Alexandra [~canaima@200.84.62.164] has left #bitcoin-core-dev []     
10:51 -!- laurentmt [~Thunderbi@185.94.189.190] has joined #bitcoin-core-dev     
10:52 -!- laurentmt [~Thunderbi@185.94.189.190] has quit [Client Quit]     
10:54 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev     
11:07 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
11:07 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 240 seconds]     
11:08 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
11:13 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev     
11:18 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 264 seconds]     
11:19 -!- m8tion [~Agence@abo-134-110-68.mrs.modulonet.fr] has quit [Read error: Connection reset by peer]     
11:39 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
11:40 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #13461: Wallet: correctly deprecate accounts in getbalance, re-add minconf / include-watch-only (master...2018/06/watch_only_balance) https://github.com/bitcoin/bitcoin/pull/13461
11:41 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has joined #bitcoin-core-dev     
11:43 < bitcoin-git> [bitcoin] Empact opened pull request #13565: Fix AreInputsStandard test to reference the proper scriptPubKey (master...p2sh-tests-pub-key) https://github.com/bitcoin/bitcoin/pull/13565
11:46 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
11:48 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
11:50 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
11:51 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]     
11:58 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Jun 28 19:00:56 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:01 < achow101> hi     
12:01 < sipa> hi     
12:01 < jonasschnelli> hi     
12:01 < cfields> hi     
12:01 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
12:02 < promag> hi     
12:02 < kanzure> hi.     
12:02 < instagibbs> hi     
12:02 < jnewbery> half a hi. May be a little distracted for the next ~45 minutes
12:02 < wumpus> I've had a really crappy week so haven't been able to do much, sorry for that
12:02 < sipa> sorry to hear that
12:02 < wumpus> #topic high priority for review
12:03 < sipa> Currently on the list: #13425 #12196 #13062
12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/13425 | Moving final scriptSig construction from CombineSignatures to ProduceSignature (PSBT signer logic) by achow101 · Pull Request #13425 · bitcoin/bitcoin · GitHub
12:03 < cfields> wumpus: :(
12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
12:03 < wumpus> only three PRs!
12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
12:04 < jonasschnelli> For 12196, I'm not sure if it make sense to adopt sipas output scripts descriptors in the PR itself (or later)
12:04 < sipa> i'd like to bring up an idea i've been working on for future wallet design/ismine logic, which may interact with #12196
12:04 < jonasschnelli> (since it already has some reviews/acks)
12:04 < gribble> https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
12:05 < wumpus> jonasschnelli: I think it makes sense to merge something, as you say it has a lot of ACKs, further improvements can be done later unless the current state is really unacceptable
12:05 < bitcoin-git> [bitcoin] jnewbery opened pull request #13566: Fix get balance (master...fix_get_balance) https://github.com/bitcoin/bitcoin/pull/13566
12:05 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-avzqsjlevhfuefdx] has joined #bitcoin-core-dev     
12:05 < sipa> wumpus: it's more so that we create something that remains compatible with future APIs
12:05 < meshcollider> Hi     
12:06 < wumpus> sipa: the API will have to be finalized before the 0.17 release
12:06 < sipa> (but i understand the desire to merge something; my comment would only apply to the xpub functionality)
12:06 < wumpus> so FWIW feature freeze for 0.17 is 2018-07-16, if the PR is already merged by then then improvement can be considered a bugfix
12:06 < sipa> perhaps i should clarify the scope
12:06 < jonasschnelli> Yes. Please
12:07 < sipa> my idea for output descriptors is here: https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82
12:07 < sipa> i also have a prototype implementation for most of it
12:07 < wumpus> nice!
12:07 < jonasschnelli> Yes. I really like it.
12:07 < promag> wumpus: for 0.17, dyn multi-wallet in the UI is required?
12:07 < sipa> it is a general language that encodes all information about how to spend a whole set of keys with associated addresses/scripts/private keys/.... into one string, including support for multisig etc
12:07 < wumpus> promag: why?
12:08 < promag> it's a question
12:08 < wumpus> promag: we want toh ave things consistent before a release, at least, apart from that it's simply a matter of what makes it in
12:08 < sipa> my desire is that the entire wallet moves to something like that (so it's an implementation of my wallet descriptor rant i wrote a while ago: https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2)
12:08 < wumpus> I recognized it :)
12:09 < cfields> sipa: +1, that makes a ton of sense
12:09 < sipa> so import/export would operate at the level of those descriptors, instead of individual keys/scripts/pubkeys/hdchains/...
12:09 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]     
12:09 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
12:09 < sipa> importmulti is already compatible with that design, for a large extent
12:10 < sipa> the entirety of that idea is certainly not for 0.17, however
12:10 < sipa> but that doesn't mean it can't be used already in relatively small scoped things already
12:10 < sipa> and scanutxoset is one of those
12:10 < jonasschnelli> what API changes would you propose for scantxoutset so we can migrate towards the output descriptors in the same cycle as migrating importmulti?
12:11 < wumpus> that would be very last minute, but at least using it as a guideline to be compatible with the current stuff makes sense
12:11 < sipa> jonasschnelli: you may not like this, but what about just dropping xpub support from the PR right now
12:11 < jonasschnelli> sipa: this makes the PR pretty useless... :(
12:11 < sipa> and then i'll PR the descriptor language, together with integration into scanutxoset
12:12 < sipa> jonasschnelli: i understand
12:12 < sipa> feel free to disagree
12:12 < wumpus> it makes sense to divide it up like that
12:12 < jonasschnelli> But if the API break would be complex and painful, we can do that.
12:12 < wumpus> makes tha change smaller and less complex
12:12 < jonasschnelli> I don't disagree... :)
12:12 < wumpus> (besides sipa's point of course)
12:13 < sipa> if your concern is that it may not make it in for 0.17, you can still PR the (already written) xpub support as is later, before feature freeze?
12:13 < jonasschnelli> Sure... I guess its also not utterly bad if the xpub will be in 0.18.
12:13 < jonasschnelli> Okay. Will remove the xpub stuff
12:14 < sipa> thank you. i promise i'll work on having a PRable implementation soon
12:14 < jonasschnelli> The question of a gap limit came up recently (related to the xpub situation) but this concept seems not to work with utxo based scans..
12:14 < jonasschnelli> So a fixed lookup window makes more sense IMO
12:15 < sipa> agree
12:15 < sipa> jonasschnelli: that's actually a good point against having a gap limit inside the descriptor language
12:15 < sipa> (as a gap limit is not relevant for all use cases)
12:16 < jonasschnelli> gap limit is a broken concept IMO
12:16 < jonasschnelli> I would not use it in the descriptors... 
12:18 < sipa> in the context of high priority PRs that's all i have to say about it; but we can discuss this idea in more detail as a separate topic if there's interest
12:18 < jonasschnelli> Thanks for working on this sipa. will give more feedback soon.
12:18 < wumpus> any proposals for adding high-priority PRs, or rmaoving them?
12:18 < wumpus> heh I already considered doing a #topic change
12:19 < jonasschnelli> I have two topic requests: a) Cipherseed, b) Cores BIP32 derivation "standard"
12:19 < promag> wumpus: I'll complete #13100 soon and it could go to hp list
12:19 < gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add menu entry to open wallet by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
12:20 < wumpus> let's add it whwen it's ready then
12:20 < promag> once ready
12:20 < promag> yes     
12:20 < wumpus> #topic cipherseed
12:20 < jonasschnelli> I have a specification draft for a new seed format similar to BIP39 with some neat properties and – before sending to the ML – would appreciate feedback.
12:20 < jonasschnelli> https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991
12:21 < jonasschnelli> (its more an announcement then a topic, sry)
12:22 < wumpus> #link https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991
12:22 < wumpus> thanks for letting us know, will have a look
12:22 < wumpus> right, as no one has read it, I don't think there's much to discuss now
12:22 < wumpus> #topic cores BIP32 derivation "standard"
12:22 < jonasschnelli> It came up today in a discussion: Cores BIP32 derivation scheme is not specified in a BIP
12:23 < jonasschnelli> Some people think its vanilla/native BIP32... but its not... while other do native BIP32
12:23 < jonasschnelli> I'm not sure if we should define a standard for out derivation scheme...
12:23 < jonasschnelli> (would be a very short proposal)
12:23 < wumpus> agree ti would be good if the difference would be documented somewhere
12:23 < sipa> jonasschnelli: my thinking is that with output descriptors we can pretty much freely change it
12:23 < jonasschnelli> The BIP32 based derivation scheme has that security risk
12:24 < sipa> (including unhardened etc)
12:24 < jonasschnelli> Changing the scheme is one point,... but there are wallets out there following a derivation scheme that is not specified in word
12:24 < jonasschnelli> *words
12:25 < luke-jr> how does it affect other implementations?
12:25 < sipa> we could have a doc in our source tree that describes it
12:25 < wumpus> luke-jr: only in the sense that other implementations might want to replicate it
12:25 < sipa> i don't think it needs to be a bip; there's no real desire to convince others to adopt the same, i think?
12:25 < jonasschnelli> luke-jr: in case someone wants to import Cores xprivs... 
12:25 < luke-jr> wumpus: why?
12:25 < wumpus> luke-jr: I don't know
12:25 < luke-jr> jonasschnelli: but not import a proper wallet in entirety?
12:26 < jonasschnelli> I precautionally wrote a tiny BIP,... but could also be used as an internal document: https://gist.github.com/jonasschnelli/0d383888ac51d5120540571173e35451 
12:26 < luke-jr> (if there were a BIP, I would think it should cover the whole wallet format, not *just* derivation)
12:26 < sipa> luke-jr: saw my descriptor proposal above? :)
12:26 < achow101> just documnting the derivation in the docs repo is sufficient imo
12:26 < jonasschnelli> I think following BIP32 for "hot" wallets with private key export options is not ideal... Electrum does that as example
12:27 < sipa> my point is that i don't think our scheme is particularly an improvement over alternatives, or has all that much design we want to convince others about
12:28 < sipa> it's just one of many choices, and the one we made
12:28 < jonasschnelli> Agree with that. Yes.
12:28 < sipa> so we should just document it
12:28 < jonasschnelli> ack     
12:28 < achow101> +1     
12:28 < gmaxwell> Seems good.
12:29 < wumpus> agree
12:30 < wumpus> I think this leaves sipa's topic, but I think that's more or less discussed already?
12:31 < sipa> yeah, probably needs people reading the idea first to discuss more; can be done offline
12:31 < wumpus> right
12:31 < jonasschnelli> sipa: how would it interact with the keypool, flexible keypath?
12:31 < jonasschnelli> and a xpub
12:31 < sipa> jonasschnelli: keypool goes away
12:32 < wumpus> good riddance
12:32 < sipa> there is ephemeral data in the wallet associated with the descriptor (which is a black box, and descriptor specific), but in practice contains the expanded pubkeys
12:32 < sipa> that takes the place of the keypool- but those things don't all translate to independent keys in the wallet
12:33 < sipa> there would just be a single private key in your wallet, for example
12:33 < sipa> (or none at all; it can be in a hardware device too)
12:33 < sipa> flexible keypath... the descriptor just contains the path
12:34 < sipa> you can change it to whatever you like (but default wallets would of course pick some standard scheme)
12:34 < sipa> or rather you can import things with whatever path you like
12:36 < wumpus> makes sense
12:36 < jonasschnelli> Would it make sense that the descriptor support pkh(d34db33f/44'/0'/0':<seed>/1/i). (seed along with xpriv)?
12:36 < jonasschnelli> for backward compatibility
12:36 < sipa> jonasschnelli: i've thought about that, but that makes descriptors non-canonical
12:37 < sipa> (as in: you can't convert them to "public" form and back, and retain all information)
12:37 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Read error: Connection reset by peer]     
12:37 < sipa> i'm unsure how to deal with that; my thinking is initially no
12:38 < sipa> you can always implement it as an extra utility that converts from seed based format
12:38 < jonasschnelli> There is always the option of externally converting the seed to an xpriv, yes
12:39 < jonasschnelli> we can encode seeds into xprivs *duck*
12:39 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
12:39 < gmaxwell> Not to hijack, but has there been any progress towards implementing P2P link ephemeral encryption lately?  I know we were kinda waiting for some other networking refactors.
12:40 < sipa> cfields: ping?
12:40 < wumpus> #topic  P2Plink ephemeral encryptio
12:40 < jonasschnelli> I'm ready to pick that up any moment but was under the impression that sipa had plans to implement it
12:40 < jonasschnelli> I started with the implementation but halted at some point...
12:40 < jonasschnelli> I'm also not sure if we should delay it further more for "refactors"
12:40 < gmaxwell> I believed sipa did too, but asformentioned delays.
12:41 < cfields> heh, I was waiting on it to firm up. Guess we were waiting in circles :)
12:41 < wumpus> hehe
12:41 < cfields> jonasschnelli: for sure
12:41 < jonasschnelli> BTW: armory has implemented it and has plans to PR it to Core
12:41 < gmaxwell> Sipa and I made some major advances in the authentication part but the encryption doesn't need to wait on that.
12:41 < jonasschnelli> (not sure how soon and in what quality)
12:41 < sipa> cfields: waiting for encryption proposal to firm up before implementing it? or before continuing with network refactors?
12:41 < wumpus> jonasschnelli: oh wow
12:42 < jonasschnelli> Agree with gmaxwell. Authentication can be added later.
12:42 < cfields> sipa: i've had to put the net stuff on the backburner for now, so certainly don't wait for that.
12:42 < sipa> cfields: cool
12:43 < jonasschnelli> cfields: I think BIP151 is almost final (there is some issues with the version handshake)... the only thing that was holding me back where possible network refactors to first wait for
12:43 < cfields> I'm happy to help with the implementation. I was thinking we were waiting on the auth stuff.
12:43 < luke-jr> jonasschnelli: it can't be Final until it is adopted..
12:43 < gmaxwell> no, they're designed to operated independantly.
12:43 < jonasschnelli> Auth is additional and implementation wise it comes after 151
12:43 < sipa> we can implement 151 without 150
12:43 < gmaxwell> I would rather not use the prior auth design, we have better ones now.
12:43 < jonasschnelli> Yes. 150 can also be replaced (coexist) with other auth proposals
12:43 < sipa> fair
12:44 < jonasschnelli> Agree with that.
12:44 < jonasschnelli> sipas prework is here AFAIK: https://gist.github.com/sipa/29118d3fcfac69f9930d57433316c039
12:44 < sipa> i need to pick that up again
12:44 < gmaxwell> but right, there is no need delay 151 on auth-- it's completely oblivious to auth.
12:45 < jonasschnelli> I guess it uses some non-standard crypto stuff though
12:45 < sipa> jonasschnelli: no, https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b
12:45 < jonasschnelli> Oh. Mistaken your gist. Thansk
12:45 < jonasschnelli> *thanks
12:45 < sipa> the other link is just some cool trick, not a serious proposal
12:46 < jonasschnelli> Okay. If no one else wants to work on the implementation, I will continue then with BIP151 impl.
12:47 < gmaxwell> Basically there was an open question of if we wanted the encryption handshake to operate in such a way that there are no fixed bytes for easy blocking/detection.  But I think we thought the benefits were too dubious.
12:47 < gmaxwell> Esp since traffic patterns will identify bitcoin p2p links very clearly.
12:47 < cfields> too dubious? you mean foiled by dpi anyway?
12:47 < gmaxwell> And so probably better to just stick to something simple.
12:47 < jonasschnelli> Agree
12:47 < wumpus> hiding what kind of connection something is is very difficult
12:48 < gmaxwell> cfields: foiled by traffic analysis or smarer DPI (that does EC operations to match traffic)
12:48 < gmaxwell> smarter*
12:48 < gmaxwell> People can always carry bitcoin over other transports in any case, ... ones that can do things like pad out to a constant bitrate...
12:48 < gmaxwell> but we're certantly not going to make BIP151 do that. :P
12:48 < cfields> mm, that's a good point
12:49 < wumpus> which is why tor went with pluggable obfuscation layers, this for example: https://arxiv.org/pdf/1305.3199.pdf
12:49 < wumpus> might be creeping the scope a bit too much
12:50 < gmaxwell> in any case, changing the handshake to be harder to detect was the only 'maybe' design change that I'm aware of any of us considering.
12:50 < gmaxwell> For 151.
12:51 < jonasschnelli> You mean an obfuscation of the encryption handshake?
12:51 < gmaxwell> So I think we're good to implement, and the only changes that might be proposed would be ones that arose as a side effect of implementing and benchmarking.
12:51 < gmaxwell> jonasschnelli: yes.
12:52 < jonasschnelli> Yes. I think there is freedom to change the specs during implementation...
12:52 < gmaxwell> And my view is that it's not worthwhile because without other more complex obfscuation (which will be bandwidth costly) it'll still be pretty detectable.
12:52 < jonasschnelli> It's not really deployed on the network yet
12:52 < gmaxwell> right.
12:53 < jonasschnelli> Yes. Better not obscure and put efforts in a long term solutions (stuff like the ScrambleSuit)
12:54 < cfields> my only complaint was that it required message parsing to complete the handshake, but it's been a while since I looked, so I'm not sure if that's still the case. I also got the impression that nobody else seemed all that bothered by that anyway.
12:55 < jonasschnelli> can you elaborate a bit more on " it required message parsing to complete the handshak"?
12:55 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
12:56 < cfields> jonasschnelli: we can discuss after the meeting, I need to take a look at the current spec
12:56 < jonasschnelli> sure. Thanks cfields 
12:59 < wumpus> #endmeeting
12:59 < lightningbot> Meeting ended Thu Jun 28 19:59:47 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:59 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-28-19.00.html
12:59 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-28-19.00.txt
12:59 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-28-19.00.log.html
13:00 < sipa> lunch?
13:01 < BlueMatt> sounds good
13:01 < BlueMatt> wait, no, already did that
13:01 < instagibbs> like 3 hours ago
13:02 < jonasschnelli> irclunch?
13:10 < cfields> jonasschnelli: If the first 32bytes over the wire are a pubkey, the network layer can do the handshake and notify us of a new connection only after it's done. The message processor wouldn't have to know or care about encryption, it just pushes messages, and the network layer handles the rest automatically.
13:10 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c93c360eec4d...b330f3fdd56b
13:10 < bitcoin-git> bitcoin/master c2e4fc8 João Barbosa: bench: Simplify CoinSelection
13:10 < bitcoin-git> bitcoin/master b330f3f MarcoFalke: Merge #13563: bench: Simplify CoinSelection...
13:10 < cfields> If, however, messages have to be parsed before doing the handshake, the net layer has to be told to switch to encryption, which imo is awkward.
13:11 < jonasschnelli> Yes. I think your right...
13:11 < jonasschnelli> We should probably do a dummy handshake in advance... what would you think about that cfields?
13:11 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13563: bench: Simplify CoinSelection (master...2018-08-bench-coinselection) https://github.com/bitcoin/bitcoin/pull/13563
13:11 < cfields> (I'm assuming that encryption would be handled at the net layer, I suppose doing it at the message processing layer is an option is well, but that feels like a step in the wrong direction)
13:12 < cfields> jonasschnelli: dummy handshake?
13:12 < jonasschnelli> cfields: we do a normal unencrypted version/verack handshake, .. then p2p initiator sends encinit
13:12 < cfields> i only bring it up because it seems avoidable, not because it's really a big deal
13:13 < jonasschnelli> A... I guess now I understand your point...
13:13  * jonasschnelli thinking
13:13 < cfields> jonasschnelli: i'm not following. Net would still have to be told to switch to encryption.
13:13 < jonasschnelli> Yes. It's another issue...
13:14 < jonasschnelli> Wouldn't it be a problem for some clients if the first package would be a pubkey?
13:14 < jonasschnelli> Also,.. how would you know if the other side supports encryption?
13:14 < cfields> jonasschnelli: yea, I trivialized that part for the sake of the example :)
13:14 < jonasschnelli> Heh... yes.
13:15 < jonasschnelli> I guess leaving out the message processor is probably hard,...
13:15 < jonasschnelli> eventually we need to look at the protocol version in the handshake and only send an encinit message if the protocol version signals support
13:15 < jonasschnelli> Assuming that non-supported message types are just ignore may be a fragile concept
13:16 < jonasschnelli> (though unsure,... its probably okay)
13:16 < cfields> jonasschnelli: could just send some magic before the pubkey, which would signal support and require no parsing other than an equality check.
13:18 < jonasschnelli> But if you connect to a peer and send magic+33b-pubkey+cipertype, woudln't you get disconnected straight away? 
13:18 < jonasschnelli> (if non BIP151 supporting peer)
13:21 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
13:21 < cfields> uhmm.. IIRC we allow more than one chance for the initial message? checking.
13:22 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
13:22 < jonasschnelli> Also,.. not sure if we should respect other implementations.
13:22 < jonasschnelli> (libbitcoin / btcd / bcoin)
13:23 < luke-jr> jonasschnelli: that's a disturbing thing to say.
13:24 < jonasschnelli> luke-jr: I'm only saying since there are no clear protocol specification for this
13:24 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
13:24 < jonasschnelli> (is it allow to send data before the version/verack handshake)
13:24 < luke-jr> oh, I misinterpreted you I think
13:24 < jonasschnelli> (then s/allowed/tolerated)
13:25 < jonasschnelli> I mean ethically, we should respect them. :)
13:25 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Client Quit]     
13:25 < cfields> haha :)
13:25 < jonasschnelli> But we where talking on possible encinit p2p encryption disconnets
13:27 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
13:27 < cfields> jonasschnelli: ok, looks like we can send before version as long as the magic is correct.
13:27 < cfields> but yes, that's very much an implementation detail. No clue how other clients handle it.
13:28 < jonasschnelli> Yes. That sound a bit fragile... 
13:29 < jonasschnelli> But we could reconnect once we got disconnected after that pre-handshake encryption request and try without encryption (if unencrypted connections are allowed)
13:30 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
13:33 -!- rex4539 [~textual@2002:5363:c54e:10:24db:ad1:ac5e:b52e] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
13:35 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
13:39 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
13:39 < cfields> jonasschnelli: mm, it's not worth going that far I think
13:40 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
13:46 -!- Alexandra [~canaima@200.84.62.164] has joined #bitcoin-core-dev     
13:46 < Alexandra> holaaaaa?
13:50 -!- Alexandra [~canaima@200.84.62.164] has left #bitcoin-core-dev []     
13:52 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
13:52 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
14:05 < gmaxwell> jonasschnelli: we can coordinate if there is some incompatiblity.
14:06 < gmaxwell> And we should avoid gratitiously breaking, where its possible without significant harm.
14:07 < gmaxwell> But if at the end of the day an implementation which is almost non-existant on the public network needs updates to work right with sensible behavior, ... well then it is what it is. To be kind we could offer patches.
14:07 -!- cbt [b9912d13@gateway/web/freenode/ip.185.145.45.19] has joined #bitcoin-core-dev     
14:10 < gmaxwell> I'm really not a fan of the "try then retry if it fails" behavior, being stateful makes it more complex and have more ways to fail.
14:10 < gmaxwell> E.g. say the remote party is almost out of sockets, first try fails due to crypto snafu, second try just doesn't connect due to socket exhaustion.
14:14 < echeveria> jonasschnelli: gmaxwell: cfields: personally I'd do something a little more interesting. bind a new socket, say 8383 and *only* accept encrypted connections there. older implementations explicitly avoid non-standard ports, and it gives the option to selectively only use bip151.  
14:14 < gmaxwell> echeveria: the downside there is that now everyone's firewall deployments need to change. :(
14:14 < echeveria> there's already logic for multiple bind interfaces with different properties (ie, whitebind). all this means is you gossip both of your ports. 
14:15 < gmaxwell> one thing we could do in a slower migration is support two ports, one is legacy or encrypted, the other is encrypted only.
14:15 < gmaxwell> but I'm still skeptical that it's worth doing that.
14:15 < cfields> yea, I've considered that as well. But I was afraid that we'd get too much backlash from network admin
14:15 < cfields> ^^ what gmaxwell said
14:16 < gmaxwell> one could, on the legacy port, hang up whenever encryption isn't used.
14:16 < cfields> also, we currently penalize non-8333 I believe.
14:16 < gmaxwell> that sounds silly now, but in two years when 99% of everything has BIP151 it'll be reasonable.
14:16 < echeveria> cfields: that's sort of why it's ideal. 
14:16 < echeveria> cfields: bitcoin nodes won't ever reasonably connect to a non 8333 rumored port. 
14:16 < gmaxwell> the idea there being that old peers won't rumor or connect to the encrypted ones...
14:17 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
14:17 < cfields> hmm. well I'd be all for it if we could get an idea of how many people it would piss off
14:18 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
14:18 < gmaxwell> echeveria: so what really does that gain over just the disconnection approach?  I think only that old peers will waste less time trying to connect to encrypted only nodes.
14:18 < cfields> also makes me curious about the reasoning for the historical http/https 80/443 split. I actually have no idea how that unfolded initially.
14:19 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
14:19 < gmaxwell> But I think there is relatively little reason to run encrypted-only for inbound. (for outbound connections, you don't need another port, service flags are sufficient)
14:19 < echeveria> gmaxwell: I like moving away from 8333 that's shared with bcash, and being able to be selectively restrictive about the type of traffic without necessarily inspecting it is nice. to me it's just easier to reason about, but that's possibly personal preference. 
14:20 < gmaxwell> effectively, I think echeveria's proposal is to abuse the port number to create an implicit "old nodes don't connect here please" flag.
14:20 < echeveria> yup.
14:20 < cfields> yea. which I guess is exactly the net-level signal that I'm after.
14:21 < gmaxwell> Probably that idea should get incorporated in wumpus' new addr message proposal.  e.g. define some set of service flags where if you don't know their meaning you avoid connecting.
14:21 < gmaxwell> doesn't help old peers, but we'll probably have this desire in the future.
14:21 < cfields> gmaxwell: lol, we could use 18333 :)
14:22 < gmaxwell> Also, I'd rather bother network admins just once when we add a UDP based transport in the future. :)
14:22 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
14:22 < cfields> (not a serious suggestion, but it would make life a bit easier on the routing side)
14:23 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
14:24 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
14:27 < gmaxwell> I dunno if pieter has talked to y'all about what we came up with for authentication, it's pretty awesome.  We gain the property that an active MITM cannot detect if authentication is actually in use or not, so he can't monitor anyone at all or takes the risk that his interception is detected.  This is a major advance over auth everywhere else where an active MITM can detect users using auth and 
14:27 < gmaxwell> just sever the link (like an innocent network failure) and stop MITMing between that user pair.
14:33 < sipa> i have
14:34 < sipa> though the best we have is something that only supports one pubkey and one privkey afaik
14:35 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-avzqsjlevhfuefdx] has quit [Quit: Connection closed for inactivity]     
14:43 < cfields> gmaxwell: yes, that's very cool.
14:46 < cfields> sipa: thoughts on echeveria's suggestion to use a separate port?
14:48 < sipa> cfields: seems a nice and easy solution, but i see the possible administrative issues
14:49 < sipa> i also don't think there is that much of a problem with reconnecting
14:50 < gmaxwell> I think the only thing a new port would buy is avoiding old peers attempting to connect to us if we were only going to accept encrypted connections on inbound. Or am I missing some other benefit?
14:51 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
14:52 < sipa> well there are 3 approaches suggested (a) new port (b) reconnect on same port with wholly different protocol after learning peer supports encryption (c) upgrade the connection in flight
14:53 < cfields> gmaxwell: that's it, but it makes traffic significantly easier to handle imo
14:54 < gmaxwell> cfields: how so?
14:54 < cfields> sipa: (bi) always plan to reconnect to upgrade (bii) only do it if they boot us for trying
14:57 < gmaxwell> I think I'm confused. AFAIK the 'boot us for trying' isn't a real problem.
14:57 < cfields> gmaxwell: as described, bip151 would require us to send the first bytes up for parsing, then have the message handler tell the net handler to deal with encryption from that point on. If encryption could be assumed, net could just handle it transparently.
14:58 < gmaxwell> This is perhaps a sign that our layering is faulty. :P
14:58 < cfields> and this is me trying to avoid falling in the same trap again :)
14:59 < gmaxwell> but okay, I see that. I think forcing onto another port due to software layering in the networking is more than a little ugly.
14:59 < cfields> er... I say "net layer" and "message processing layer", but I mean those conceptually. Not our specific implementation.
14:59 < gmaxwell> if encryption must be on another port, rather than optionally on another port then we'd get a massive deployment loss due to users needing to punch new firewall holes.
15:00 < gmaxwell> E.g. I was thinking of echeveria's proposal as 8333 becomes legacy OR encrypted, and 8334 is encrypted only.
15:01 < cfields> Ah, ok.
15:01 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
15:03 < cfields> well, I suppose we could do that as well. Introduce the round-trip layer violation for 8333, and hope for some future that's nearly all 8334, and un-encrypted 8333 could be dropped at that point.
15:03 < cfields> I guess that doesn't provide much motivation to switch, though.
15:04 < sipa> echo $'\x3d\x20\x53\xd7\xff\x00\x00\x00' | base64
15:04 < sipa> PSBT1/8K
15:04 < sipa> echo $'\x3d\x20\x53\xd7\xff\xff\xff\xff' | base64
15:04 < cfields> blehk, and that would suck to rumor
15:04 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
15:04 < sipa> PSBT1/////8K
15:04 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
15:05 < sipa> so if the PSBT magic bytes are 0x3d 0x20 0x53 0xd7 0xff, the base64 encoding will always begin with "PSBT1/"
15:10 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
15:11 < sipa> or {a6 c6 ed fb ff} to encode as "psbt+/"
15:16 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
15:25 -!- cbt [b9912d13@gateway/web/freenode/ip.185.145.45.19] has quit [Quit: Page closed]     
15:30 -!- booyah [~bb@193.25.1.157] has quit [Ping timeout: 245 seconds]     
15:41 -!- Dizzle [~dizzle@108.171.182.16] has quit [Ping timeout: 260 seconds]     
15:50 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Quit: drexl]     
15:52 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev     
15:53 -!- Squidicuz [~squid@pool-173-48-82-37.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
16:14 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Ping timeout: 264 seconds]     
16:15 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
16:17 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
16:29 -!- zautomata [~zautomata@41.232.219.134] has joined #bitcoin-core-dev     
17:22 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
17:25 -!- instagibbs [~instagibb@pool-100-15-128-78.washdc.fios.verizon.net] has quit [Ping timeout: 256 seconds]     
17:35 -!- instagibbs [~instagibb@pool-100-15-128-78.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
17:51 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 268 seconds]     
17:53 -!- jk [~jk@218.64.17.83] has joined #bitcoin-core-dev     
17:54 -!- jk is now known as Guest25620     
17:58 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
18:15 -!- wordchat [~Instantbi@115.164.74.63] has joined #bitcoin-core-dev     
18:17 -!- Guest25620 [~jk@218.64.17.83] has quit [Ping timeout: 240 seconds]     
18:25 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
18:26 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
18:31 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
19:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
19:21 -!- instagibbs [~instagibb@pool-100-15-128-78.washdc.fios.verizon.net] has quit [Ping timeout: 264 seconds]     
19:29 -!- instagibbs [~instagibb@pool-100-15-128-78.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
19:34 -!- instagibbs [~instagibb@pool-100-15-128-78.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds]     
20:03 -!- instagibbs [~instagibb@pool-100-15-128-78.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
20:57 -!- rex4539 [~textual@2002:5363:c54e:10:9562:8a20:f6bf:c448] has joined #bitcoin-core-dev     
20:59 -!- schnerch_ [~schnerchi@p5DCB4CBA.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
21:02 -!- schnerchi123 [~schnerchi@p5DCB4D4F.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]     
21:11 -!- Guest25620 [~jk@218.64.17.83] has joined #bitcoin-core-dev     
21:21 -!- Guest25620 [~jk@218.64.17.83] has quit [Ping timeout: 268 seconds]     
21:21 -!- jtimon [~quassel@40.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
21:23 -!- rex4539 [~textual@2002:5363:c54e:10:9562:8a20:f6bf:c448] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
21:25 -!- zxzzt [~prod@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Ping timeout: 245 seconds]     
21:26 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has quit [Ping timeout: 260 seconds]     
21:27 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
21:37 -!- wordchat [~Instantbi@115.164.74.63] has left #bitcoin-core-dev []     
21:42 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev     
21:44 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 240 seconds]     
21:45 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev     
21:50 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 260 seconds]     
21:58 -!- rex4539 [~textual@balticom-197-78.balticom.lv] has joined #bitcoin-core-dev     
21:59 -!- unholymachine [~quassel@2601:8c:c003:9f16:c5ce:b647:6280:f03d] has quit [Remote host closed the connection]     
22:43 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Ping timeout: 255 seconds]     
22:46 -!- propumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev     
22:57 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
22:58 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
23:07 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev     
23:27 -!- echonaut8 [~echonaut@46.101.192.134] has quit [Read error: Connection reset by peer]     
23:27 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
23:28 -!- Squidicuz [~squid@pool-173-48-82-37.bstnma.fios.verizon.net] has quit [Read error: Connection reset by peer]     
23:29 -!- Squidicuz [~squid@pool-173-48-82-37.bstnma.fios.verizon.net] has joined #bitcoin-core-dev