--- Day changed Thu Oct 13 2016
00:01 -!- kadoban_ is now known as kadoban     
00:18 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:31 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 250 seconds]     
00:32 -!- cheese_ [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]     
00:34 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
00:47 -!- laurentmt [~Thunderbi@80.215.138.193] has joined #bitcoin-core-dev     
00:53 -!- laurentmt [~Thunderbi@80.215.138.193] has quit [Quit: laurentmt]     
00:53 -!- laurentmt [~Thunderbi@80.215.138.193] has joined #bitcoin-core-dev     
00:53 -!- laurentmt [~Thunderbi@80.215.138.193] has quit [Client Quit]     
01:01 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
01:06 -!- so [~so@unaffiliated/so] has joined #bitcoin-core-dev     
01:08 -!- murch [~murch@p4FDB6B7F.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
01:14 -!- whphhg [whphhg@gateway/vpn/mullvad/x-cjknjtqntqvqfzvo] has joined #bitcoin-core-dev     
01:22 < GitHub157> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d0754799698d...d270c30d5530
01:22 < GitHub157> bitcoin/master 3f92bc9 Wladimir J. van der Laan: doc: Add build instructions for FreeBSD
01:22 < GitHub157> bitcoin/master d270c30 Wladimir J. van der Laan: Merge #8892: doc: Add build instructions for FreeBSD...
01:22 < GitHub150> [bitcoin] laanwj closed pull request #8892: doc: Add build instructions for FreeBSD (master...2016_10_freebsd_build) https://github.com/bitcoin/bitcoin/pull/8892
01:27 -!- stan_ [~stan@LAubervilliers-656-1-238-191.w193-248.abo.wanadoo.fr] has joined #bitcoin-core-dev     
01:31 < GitHub5> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d270c30d5530...8d46429c83ec
01:31 < GitHub5> bitcoin/master 8aed5f6 Wladimir J. van der Laan: qt: Translate all files, even if wallet disabled...
01:31 < GitHub5> bitcoin/master 8d46429 Wladimir J. van der Laan: Merge #8911: qt: Translate all files, even if wallet disabled...
01:31 < GitHub129> [bitcoin] laanwj closed pull request #8911: qt: Translate all files, even if wallet disabled (master...2016_10_qt_translations_wallet2) https://github.com/bitcoin/bitcoin/pull/8911
01:38 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 268 seconds]     
01:41 -!- harrymm [~wayne@104.222.140.64] has left #bitcoin-core-dev []     
01:43 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
01:45 -!- harrymm [~wayne@104.222.140.105] has joined #bitcoin-core-dev     
02:08 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
02:17 -!- Netsplit *.net <-> *.split quits: so, jl2012, baldur
02:17 -!- Netsplit *.net <-> *.split quits: GreenIsMyPepper, AaronvanW
02:18 -!- Netsplit *.net <-> *.split quits: Guyver2, harrymm
02:18 -!- Netsplit *.net <-> *.split quits: mkarrer, cjcj, gijensen
02:19 -!- Netsplit *.net <-> *.split quits: dgenr8, Arnavion
02:19 -!- Netsplit *.net <-> *.split quits: isis
02:20 -!- Netsplit *.net <-> *.split quits: haakonn, xiangfu
02:20 -!- Netsplit *.net <-> *.split quits: adiabat
02:20 -!- Netsplit *.net <-> *.split quits: afk11
02:21 -!- Netsplit *.net <-> *.split quits: Alina-malina
02:21 -!- Netsplit *.net <-> *.split quits: stan_
02:22 -!- Netsplit *.net <-> *.split quits: PaulCape_, nsh, jonasschnelli, michagogo, lclc, Yogh_, jouke_, luke-jr
--- Log closed Thu Oct 13 02:22:22 2016
--- Log opened Thu Oct 13 02:27:33 2016
02:27 -!- kanzure [~kanzure@bryan.fairlystable.org] has joined #bitcoin-core-dev     
02:27 -!- Irssi: #bitcoin-core-dev: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal]     
02:37 < GitHub35> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/7634d8eac4a5a727b77b4a7e2521bc2b95f53e5a
02:37 < GitHub35> bitcoin/0.13 7634d8e Wladimir J. van der Laan: qt: Translate all files, even if wallet disabled...
02:38 -!- Irssi: Join to #bitcoin-core-dev was synced in 638 secs
--- Log closed Thu Oct 13 03:07:11 2016
--- Log opened Thu Oct 13 03:07:23 2016
03:07 -!- kanzure [~kanzure@bryan.fairlystable.org] has joined #bitcoin-core-dev     
03:07 -!- Irssi: #bitcoin-core-dev: Total of 10 nicks [0 ops, 0 halfops, 0 voices, 10 normal]     
03:10 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
03:17 -!- Irssi: Join to #bitcoin-core-dev was synced in 635 secs
--- Log closed Thu Oct 13 03:28:44 2016
--- Log opened Thu Oct 13 03:29:14 2016
03:29 -!- kanzure [~kanzure@bryan.fairlystable.org] has joined #bitcoin-core-dev     
03:29 -!- Irssi: #bitcoin-core-dev: Total of 88 nicks [0 ops, 0 halfops, 0 voices, 88 normal]     
03:31 -!- murch [~murch@p4FDB6B7F.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
03:31 -!- luke-jr [~luke-jr@adsl-98-70-231-167.gnv.bellsouth.net] has joined #bitcoin-core-dev     
03:31 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
03:31 -!- harrymm [~wayne@104.222.140.105] has joined #bitcoin-core-dev     
03:31 -!- mkarrer [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
03:31 -!- gijensen [~gijensen@gijensen.xyz] has joined #bitcoin-core-dev     
03:32 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:32 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has joined #bitcoin-core-dev     
03:32 -!- Alina-malina [~Alina-mal@37.157.216.181] has quit [Max SendQ exceeded]     
03:33 -!- cjcj [d4555899@gateway/web/freenode/ip.212.85.88.153] has joined #bitcoin-core-dev     
03:33 -!- Alina-malina [~Alina-mal@37.157.216.181] has joined #bitcoin-core-dev     
03:34 -!- whphhg [whphhg@gateway/vpn/mullvad/x-cjknjtqntqvqfzvo] has joined #bitcoin-core-dev     
03:34 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
03:34 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
03:34 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev     
03:34 -!- Taek42 [~quassel@2001:41d0:1:472e::] has joined #bitcoin-core-dev     
03:34 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
03:34 -!- Expanse [sid146237@gateway/web/irccloud.com/x-dewotxnwzfmiqwii] has joined #bitcoin-core-dev     
03:34 -!- Naphex [~naphex@unaffiliated/naphex] has joined #bitcoin-core-dev     
03:34 -!- cfields [~quassel@unaffiliated/cfields] has joined #bitcoin-core-dev     
03:34 -!- zmanian___ [sid113594@gateway/web/irccloud.com/x-asuogvrszimwzshj] has joined #bitcoin-core-dev     
03:34 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-uqfxcnbniycjqxvg] has joined #bitcoin-core-dev     
03:34 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev     
03:34 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev     
03:34 -!- neha [~narula@tbilisi.csail.mit.edu] has joined #bitcoin-core-dev     
03:34 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev     
03:34 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev     
03:34 -!- BonyM [~BonyM-I@ua-83-227-211-4.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev     
03:34 -!- shaiguitar [~rosenfs@shairosenfeld.com] has joined #bitcoin-core-dev     
03:34 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-kvkuikrcdatzjhbj] has joined #bitcoin-core-dev     
03:34 -!- jyap [~jyap@unaffiliated/jyap] has joined #bitcoin-core-dev     
03:34 -!- BCBot [~BCBot@46.101.246.115] has joined #bitcoin-core-dev     
03:36 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
03:36 -!- 7F1AAEYE0 [~kanzure@bryan.fairlystable.org] has joined #bitcoin-core-dev     
03:36 -!- mr_burdell [~mr_burdel@bounce.cryptolabs.net] has joined #bitcoin-core-dev     
03:36 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev     
03:36 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev     
03:36 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev     
03:36 -!- isis [~isis@abulafia.patternsinthevoid.net] has joined #bitcoin-core-dev     
03:36 -!- xiangfu [~xiangfu@223.223.187.142] has joined #bitcoin-core-dev     
03:36 -!- haakonn [~haakonn@pdpc/supporter/active/haakonn] has joined #bitcoin-core-dev     
03:36 -!- adiabat [~adiabat@159.203.193.74] has joined #bitcoin-core-dev     
03:36 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev     
03:39 -!- limpkin_ [sid20909@gateway/web/irccloud.com/x-gwoatmpugvodpsqj] has joined #bitcoin-core-dev     
03:39 -!- Madars [~null@contents-vnder-pressvre.mit.edu] has joined #bitcoin-core-dev     
03:39 -!- stan_ [~stan@LAubervilliers-656-1-238-191.w193-248.abo.wanadoo.fr] has joined #bitcoin-core-dev     
03:39 -!- nsh [~lol@wikipedia/nsh] has joined #bitcoin-core-dev     
03:39 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev     
03:39 -!- PaulCape_ [~PaulCapes@2604:5500:17:2ea:44e5:3a07:a6f7:62d9] has joined #bitcoin-core-dev     
03:39 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev     
03:39 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev     
03:39 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev     
03:39 -!- Yogh_ [~Yogh@f36186.upc-f.chello.nl] has joined #bitcoin-core-dev     
03:39 -!- jouke_ [~jouke@a83-163-42-163.adsl.xs4all.nl] has joined #bitcoin-core-dev     
03:39 -!- Anduck [~Anduck@unaffiliated/anduck] has joined #bitcoin-core-dev     
03:39 -!- _mn3monic [~guido@176.9.68.68] has joined #bitcoin-core-dev     
03:39 -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-core-dev     
03:39 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-qhhgwhmscdkvqvnn] has joined #bitcoin-core-dev     
03:39 -!- binns [sid105317@21/bitcoin/binns] has joined #bitcoin-core-dev     
03:39 -!- helo [~helo@unaffiliated/helo] has joined #bitcoin-core-dev     
03:39 -!- roasbeef [~root@104.131.26.124] has joined #bitcoin-core-dev     
03:39 -!- mturquette [sid66043@gateway/web/irccloud.com/x-kwozoarfryepycva] has joined #bitcoin-core-dev     
03:40 -!- baldur [~baldur@209.95.50.163] has joined #bitcoin-core-dev     
03:40 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-esevveyphvvmyxqo] has joined #bitcoin-core-dev     
03:40 -!- 7F1AAEYE0 [~kanzure@bryan.fairlystable.org] has quit [Max SendQ exceeded]     
03:41 -!- kinlo [peter@panda.pfoe.be] has quit [Changing host]     
03:41 -!- kinlo [peter@unaffiliated/kinlo] has joined #bitcoin-core-dev     
03:42 -!- Alina-malina [~Alina-mal@37.157.216.181] has quit [Remote host closed the connection]     
03:42 -!- PaulCape_ [~PaulCapes@2604:5500:17:2ea:44e5:3a07:a6f7:62d9] has quit [Max SendQ exceeded]     
03:42 -!- Alina-malina [~Alina-mal@37.157.216.181] has joined #bitcoin-core-dev     
03:42 -!- luke-jr is now known as Guest88054     
03:42 -!- mr_burdell is now known as Guest13412     
03:42 -!- Madars is now known as Guest20119     
03:42 -!- Alina-malina [~Alina-mal@37.157.216.181] has quit [Changing host]     
03:42 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
03:42 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Max SendQ exceeded]     
03:42 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:f937:6aa9:cf81:7247] has joined #bitcoin-core-dev     
03:42 < GitHub12> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/633c4a1f3690152bdda4b0ac7bcfde22c237183e
03:42 < GitHub12> bitcoin/0.13 633c4a1 Wladimir J. van der Laan: qt: Periodic translations update...
03:42 -!- wallet42 [sid154231@gateway/web/irccloud.com/session] has quit [Changing host]     
03:42 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-rbnwkvytkdboeyno] has joined #bitcoin-core-dev     
03:42 -!- mappum [sid43795@gateway/web/irccloud.com/session] has quit [Changing host]     
03:42 -!- mappum [sid43795@gateway/web/irccloud.com/x-zvjorajymvtumfjl] has joined #bitcoin-core-dev     
03:42 -!- Alina-malina [~Alina-mal@37.157.216.181] has joined #bitcoin-core-dev     
03:42 -!- Alina-malina [~Alina-mal@37.157.216.181] has quit [Changing host]     
03:42 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
03:42 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
03:42 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
03:43 -!- Irssi: Join to #bitcoin-core-dev was synced in 866 secs
04:01 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev     
04:02 -!- Guest88054 [~luke-jr@adsl-98-70-231-167.gnv.bellsouth.net] has quit [Quit: ZNC - http://znc.sourceforge.net]     
04:03 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev     
04:06 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 260 seconds]     
04:19 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
04:29 -!- fengling [~fengling@43.255.176.13] has joined #bitcoin-core-dev     
04:41 -!- fengling [~fengling@43.255.176.13] has quit [Ping timeout: 268 seconds]     
04:55 -!- shaiguit1r [~rosenfs@shairosenfeld.com] has joined #bitcoin-core-dev     
04:55 -!- shaiguitar [~rosenfs@shairosenfeld.com] has quit [Read error: Connection reset by peer]     
05:02 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
05:02 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev     
05:05 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
05:07 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 260 seconds]     
05:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:13 -!- fengling [~fengling@43.255.176.13] has joined #bitcoin-core-dev     
05:32 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
05:35 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
05:48 -!- limpkin_ is now known as limpkin     
06:01 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 258 seconds]     
06:03 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev     
06:06 -!- cryptapus [~cryptapus@87.254.202.160] has joined #bitcoin-core-dev     
06:06 -!- cryptapus [~cryptapus@87.254.202.160] has quit [Changing host]     
06:06 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
06:08 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 260 seconds]     
06:18 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
06:20 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
06:24 -!- waxwing_ [~waxwing@62.205.214.125] has joined #bitcoin-core-dev     
06:24 -!- waxwing_ is now known as waxwing     
06:36 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
06:38 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:f937:6aa9:cf81:7247] has quit [Read error: Network is unreachable]     
06:40 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev     
06:56 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]     
06:59 -!- skyraider [uid41097@gateway/web/irccloud.com/x-mvyjuhwvcpmlnbao] has joined #bitcoin-core-dev     
07:04 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev     
07:28 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
07:28 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 260 seconds]     
07:29 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:29 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
07:39 < BlueMatt> #8904 doesnt need backporting - the test is overspecified but thats ok, just needs fixing on master
07:39 < BlueMatt> nvm, no one is here, I'll post on github
07:46 < sipa> if nobody is here, who are you?
07:47 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 248 seconds]     
07:48 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev     
07:48 < BlueMatt> I am your Conscience
07:49 < sipa> if nobody is here, who am i?
07:49 < BlueMatt> you are my Conscience
07:51 < bsm117532> RuntimeError: maximum recursion depth exceeded
07:51  * btcdrak segfaults
07:51 < sipa> so i'm my own conscience's conscience?
07:54 < kanzure> dmv5 says no
07:55 < bsm117532> I wouldn't rely on a DSM5 you got from the DMV :-P
07:57 < kanzure> oh oops.
08:04 -!- murch [~murch@p4FDB6B7F.dip0.t-ipconnect.de] has quit [Remote host closed the connection]     
08:04 -!- murch [~murch@p4FDB6B7F.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
08:06 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
08:09 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
08:15 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
08:16 < btcdrak> wumpus: is there a meeting today?
08:16 < BlueMatt> yes     
08:17 < btcdrak> wumpus: you've changed your hair colour?
08:17 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
08:24 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev     
08:29 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 260 seconds]     
08:48 < wumpus> btcdrak: yes re: meeting, no re: hair colour
08:51 < wumpus> thanks for reminding me it's thursday though, I'd probably have forgot the meeting otherwise :)
08:52 -!- adiabat [~adiabat@159.203.193.74] has quit [Remote host closed the connection]     
08:52 < sipa> i can confirm that at least until yesterday around noon, wumpus' hair color had not changed measurably
09:19 < jtimon> updated https://github.com/jtimon/consensus-doc/blob/generated/libconsensus.pdf with more images. any comments or suggestions welcomed
09:19 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 258 seconds]     
09:19 -!- harrymm [~wayne@104.222.140.105] has quit [Ping timeout: 252 seconds]     
09:19 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev     
09:21 -!- zooko [~user@2601:281:8080:b789:653a:a775:f86e:8e4b] has joined #bitcoin-core-dev     
09:22 < jtimon> or questions
09:25 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev     
09:30 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 252 seconds]     
09:36 < GitHub104> [bitcoin] laanwj opened pull request #8914: Kill insecure_random and associated global state (master...2016_10_kill_insecurerandom) https://github.com/bitcoin/bitcoin/pull/8914
09:38 -!- harrymm [~wayne@104.222.140.77] has joined #bitcoin-core-dev     
09:44 -!- warren [~warren@fedora/wombat/warren] has quit [Ping timeout: 248 seconds]     
09:45 -!- zooko [~user@2601:281:8080:b789:653a:a775:f86e:8e4b] has quit [Ping timeout: 258 seconds]     
09:46 -!- adam3us [~adam3us@unaffiliated/adam3us] has quit [Ping timeout: 248 seconds]     
09:47 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 268 seconds]     
09:48 < GitHub196> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8d46429c83ec...e2a17e43e36f
09:48 < GitHub196> bitcoin/master 4cdece4 Dagur Valberg Johannsson: [qa] Fix compact block shortids for a test case
09:48 < GitHub196> bitcoin/master e2a17e4 Wladimir J. van der Laan: Merge #8904: [qa] Fix compact block shortids for a test case...
09:49 < GitHub114> [bitcoin] laanwj closed pull request #8904: [qa] Fix compact block shortids for a test case (master...shortid-coinbase) https://github.com/bitcoin/bitcoin/pull/8904
09:52 -!- adam3us [~adam3us@unaffiliated/adam3us] has joined #bitcoin-core-dev     
09:54 -!- warren [~warren@fedora/wombat/warren] has joined #bitcoin-core-dev     
09:57 < GitHub192> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e2a17e43e36f...e2b8c394d61d
09:57 < GitHub192> bitcoin/master 4408558 jonnynewbs: Update bitcoin-tx to output witness data.
09:57 < GitHub192> bitcoin/master e2b8c39 Wladimir J. van der Laan: Merge #8817: update bitcoin-tx to output witness data...
09:57 < GitHub18> [bitcoin] laanwj closed pull request #8817: update bitcoin-tx to output witness data (master...bitcoin-tx-witness) https://github.com/bitcoin/bitcoin/pull/8817
10:00 -!- trippysa1mon [~trippy@cyberdynesys.org] has quit [Ping timeout: 248 seconds]     
10:01 -!- trippysalmon [~trippy@cyberdynesys.org] has joined #bitcoin-core-dev     
10:02 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
10:13 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
10:25 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev     
10:40 < GitHub60> [bitcoin] petertodd opened pull request #8915: Add copyright/patent issues to possible NACK reasons (master...2016-10-13-sound-legal-justification) https://github.com/bitcoin/bitcoin/pull/8915
10:47 -!- chauncie [~chauncie@95.215.44.99] has joined #bitcoin-core-dev     
11:06 -!- JackH [~laptop@79-73-185-184.dynamic.dsl.as9105.com] has quit [Remote host closed the connection]     
11:14 < MarcoFalke> wumpus: I think it is better to just cherry-pick https://github.com/bitcoin/bitcoin/pull/8643
11:22 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
11:22 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
11:22 < wumpus> yes, I'm working on backports now, will include that one
11:23 < wumpus> #8393 is turning out a bit tricky (due to CConnMan) the rest seems easy
11:24 < achow101> I think #8899 can be merged
11:25 < instagibbs> achow101, no it can not. There is an outstanding bug.
11:25 < instagibbs> https://github.com/bitcoin/bitcoin/pull/8499#issuecomment-253184633
11:26 < achow101> instagibbs: 8899, not 8499 (notice the 8)
11:26 -!- thomasthetank [448419a8@gateway/web/freenode/ip.68.132.25.168] has joined #bitcoin-core-dev     
11:26 < instagibbs> ah :)
11:28 < wumpus> yes, #8899 seems ready (not #8499)
11:30 < wumpus> I think sipa has a good point there, but I'm not sure of the matter, it's probably better to just take over boost's patch 
11:30 < wumpus> maybe the issue should be raised upstream though
11:31 < thomasthetank> hey, when i verify my txoutproof it returns incorrect txids
11:33 < thomasthetank> i noticed the txoutproof size goes from 248 to 235 bytes after being parsed 
11:33 < jl2012> i hope 8499 will be ready in a few days. I have a branch here but sipa is working on a different solution: https://github.com/jl2012/bitcoin/commits/badwitnesscheck-1012
11:33 < thomasthetank> is that standard 
11:34 < wumpus> thomasthetank: not sure, may be better to file an issue on github w/ exact input and output
11:39 -!- thomasthetank [448419a8@gateway/web/freenode/ip.68.132.25.168] has quit [Quit: Page closed]     
11:40 < GitHub164> [bitcoin] laanwj closed pull request #8643: [0.13 backport] Added feeler connections increasing good addrs in the tried table. (0.13...2016/08/feeler_013) https://github.com/bitcoin/bitcoin/pull/8643
11:44 < GitHub192> [bitcoin] laanwj opened pull request #8916: 0.13.1 backports (0.13...2016_10_backports) https://github.com/bitcoin/bitcoin/pull/8916
11:47 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev     
11:53 < wumpus> woohoo, just #8499 left https://github.com/bitcoin/bitcoin/pulls?utf8=%E2%9C%93&q=is%3Apr%20%20label%3A%22Needs%20backport%22%20milestone%3A0.13.1%20
11:55 < GitHub144> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/633c4a1f3690...4ed26277347c
11:55 < GitHub144> bitcoin/0.13 49be9f0 Michael Ford: Fix wake from sleep issue with Boost 1.59.0
11:55 < GitHub189> [bitcoin] laanwj closed pull request #8899: [0.13] Fix wake from sleep issue with Boost 1.59.0 (0.13...backport-boost-windows-patch) https://github.com/bitcoin/bitcoin/pull/8899
11:55 < GitHub144> bitcoin/0.13 4ed2627 Wladimir J. van der Laan: Merge #8899: [0.13] Fix wake from sleep issue with Boost 1.59.0...
11:57 < BlueMatt> woohoo
11:57 < BlueMatt> !     
12:00 < sipa> doing
12:00 < achow101> meeting?
12:00 < gmaxwell> #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
12:00 < kanzure> hi.     
12:00 < btcdrak> ping
12:00 < instagibbs> pre-sent
12:00 < sdaftuar> hi     
12:00 < jtimon> hi     
12:01 < BlueMatt> o where art though fearless leader wumpus 
12:01 < michagogo> hi     
12:01 < gmaxwell> Who called this meeting?
12:01 < BlueMatt> wumpus: said we were meeting earlier
12:01 < gmaxwell> Obviously a trap.
12:01 < BlueMatt> anyway, topic recommendations while we're waiting for a #?
12:01 < jtimon> I assume 0.13.1
12:01 < kanzure> 0.13.0 wallet bug about importaddress and scriptpubkeys
12:02 < kanzure> (and witnesses)
12:02 < gmaxwell> Backport statuses
12:02 < jtimon> libconsensus verifyBlock vs processBlock (ie the latter takes care of reorgs, updates the utxo, etc)
12:03 < kanzure> jtimon: thanks for https://github.com/jtimon/consensus-doc/blob/generated/libconsensus.pdf
12:03 < kanzure> jtimon: i suggest emailing that to mailing list at some point
12:03 < achow101> prefinal alert
12:03 < jtimon> kanzure: I already did
12:04 < wumpus> #startmeeting
12:04 < lightningbot> Meeting started Thu Oct 13 19:04:02 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:04 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:04 < BlueMatt> ok, start with 13.1 status update?
12:04 < wumpus> #topic 0.13.1
12:04 < jtimon> kanzure: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/013204.html
12:05 < wumpus> I've just done all the remaining backports in https://github.com/bitcoin/bitcoin/pull/8916
12:05 < BlueMatt> looks like we're one pr away from 13.1, sipa jl2012 or sdaftuar, where are we?
12:05 < sipa> close.
12:05 < BlueMatt> on 8916
12:05 < MarcoFalke> #link https://github.com/bitcoin/bitcoin/pull/8916
12:05 < wumpus> this leaves #8499
12:05 < BlueMatt> oh, sorry, 8916 is backports, meant 8499
12:05 < sipa> close.
12:05 < btcdrak> was 8393 backported yet?
12:06 < wumpus> 0.13.0 wallet bug about importaddress and scriptpubkeys <- issue id?
12:06 < wumpus> btcdrak: yes, that one is part of #8916
12:06 < sipa> jl2012 has been writing a lot of tests for 8499, as there are a lot of edge cases. i believe they're all identified and fixable noe
12:06 < BlueMatt> ok, so i guess hopefully by next meeting (or late this week) the final few commits on #8499 should be ready for review and we can finalize then?
12:06 < sipa> wumpus: will file one soon
12:07 < wumpus> so there's another blocker for 0.13.1? ok
12:07 < sipa> it's part of 8499
12:08 < sipa> will be fixed simulteneously
12:08 < jtimon> wumpus: bip9 parameters?
12:08 < gmaxwell> BIP9 recommends it be set roughly a month after software release. I don't currently see a reason to deviate from that.
12:09 < wumpus> jtimon: that's a topic suggestion I suppose?
12:09 < gmaxwell> There should be some list discussion. I have been one on oneing with large users of Bitcoin for the last couple weeks.
12:09 < jtimon> gmaxwell: ack
12:09 < instagibbs> So would the idea be to set it only at final release and not RC?
12:09 < gmaxwell> instagibbs: I think we would set it at RC and take a guess.
12:09 < sipa> it should be set for RC
12:10 < sipa> but if a new RC is needed, we can jncrement
12:10 < instagibbs> Ok. 
12:10 < gmaxwell> it doesn't have to be precise. The strong invariaent is that the start date should be _after_ the release. :)
12:10 < michagogo> Worst case, if there are a lot of RCs that can be adjusted before the last one
12:10 < wumpus> there can't be changes between the last RC and final
12:10 < MarcoFalke> Huh? If we just increment it may cause a consensus bug?
12:10 < wumpus> so it must be set for every RC too, I'm afraid
12:10 < gmaxwell> keeping in mind that it'll take minimum of 4 weeks to activate post start.
12:11 < MarcoFalke> I mean nodes don't agree
12:11 < sipa> MarcoFalke: assuming miners run RCs
12:11 < michagogo> But the last RC is generally within a week or so of final release
12:11 < jtimon> MarcoFalke: people should not use rc apart from testing
12:11 < michagogo> (Or, the other way around...)
12:11 < wumpus> michagogo: yes
12:11 < MarcoFalke> fine
12:11 < sipa> indeed
12:11 < sipa> when do we exoect 0.13.1rc1?
12:11 < gmaxwell> so I would recommend taking a best guess and changing it if release ends up past that date.
12:11 < wumpus> #topic BIP9 parameters
12:11 < cfields> whoops. Late, but made it.
12:11 < BlueMatt> lets avoid setting it differently in different rcs
12:11 < sdaftuar> i don't think we can just change bip9 params during the rc process
12:12 < sdaftuar> that's a consensus change
12:12 < sdaftuar> we almost screwed this up in 0.13.0 
12:12 < wumpus> sipa: all depends on #8499 + the bug fix for 0.13.1 
12:12 < wumpus> I'd do 0.13.1 today if it was not for those
12:12 < sipa> i'm sure we'll be ready next seek
12:12 < sipa> (i'd like to say tomorrow, but who knows)
12:12 < morcos> it seems not a bad idea to take a conservative estimate of the length of time the RC process will take, add a month to that and use the date.
12:13 < BlueMatt> proposal: do not set activation parameters in rc1, set them in an rc when we believe we are ready (ie last rc + 1 week or so) and then let that sit for a week before final tag
12:13 < morcos> so use 2 months after the time you issue the first RC for instance?
12:13 < jtimon> morcos: that makes sense to me
12:13 < wumpus> I usually estimate a month for the RC phase, for major releases
12:13 < btcdrak> BlueMatt: +1
12:13 < instagibbs> I think picking and staying with it is best. 
12:13 < morcos> or right, like matt said
12:13 < gmaxwell> BlueMatt: the RC's are supposted to be the same as the release.
12:13 < btcdrak> There is no way rc1 will pass anyway.
12:13 < sipa> btcdrak: unsure.
12:13 < BlueMatt> gmaxwell: then lets call the first rc beta :)
12:13 < morcos> btcdrak: ha ha
12:13 < gmaxwell> btcdrak: I think it's likely to do so, I've spent a lot more time on 0.13 branch than master lately. 
12:14 < jtimon> BlueMatt's solution is fine as well
12:14 < wumpus> the last RC is supposed to be the same as the release, you could do a RC that is not *really* a release candidate I guess ...
12:14 < BlueMatt> ok, so new proposal: lets do a "beta" phase first, and then graduate to rc?
12:14 < michagogo> Prerc1?
12:14 < michagogo> rc0?
12:14 < btcdrak> 0.13.1pre
12:14 < jtimon> btcdrak: if we know rc1 won't pass how come we make it an rc?
12:14 < gmaxwell> I think we're over thinking it. The purpose of the starting time was simply to avoid the case where there was a risk that a feature got activated before any released version of the implementation for it existed at all-- because we found that miners were running master/candidates.
12:14 < wumpus> I guess we can use beta now that bitcoin core itself is no longer beta
12:15 < michagogo> jtimon: its more like, if it passes, something's "wrong"
12:15 < jtimon> michagogo: not following
12:15 < wumpus> thoug hI"d prefer just calling it rc, all tooling is setup for that
12:15 < michagogo> Like when your code compiles without errors the first time
12:15 < sipa> i don't like this. just pick a date reasonably far in the future and do rc1
12:15 < BlueMatt> so set parameters to 1.5 months for rc1? or 2?
12:15 < gmaxwell> Considering that there is a _minimum_ 4032 block interval from startdate to activation, there is a LOT of safty margin here.
12:15 < wumpus> sipa: +1
12:15 < wumpus> just estimate 2 months for the RC process
12:15 < cfields> sipa: agreed. Otherwise there's no way we'll be able to explain the semantics.
12:15 < wumpus> that should be ample enough
12:15 < BlueMatt> ok, I'm ok with something like 2 months from rc1
12:15 < btcdrak> most releases take 3 or 4 rcs, so if we set the date for 5 weeks on rc1 that would cover it I am sure.
12:15 < morcos> or is wumpus saying 3 months
12:16 < jtimon> michagogo: you mean we expect to have more than one? sure, but we shouldn't make it rc if there's known bugs or required changes is my point
12:16 < BlueMatt> ehh, I'd rather be conservative btcdrak 
12:16 < wumpus> no, two months is fine
12:16 < morcos> 2 months for process, one for it to be released
12:16 < BlueMatt> i mean I'm ok with 1.5 months, too
12:16 < achow101> I think two months after rc1 is fine
12:16 < michagogo> jtimon: well, obviously the goal is for rc1 to = final
12:16 < morcos> ok, i'm fine with either, less than 2 is a bit rushing it
12:16 < btcdrak> this is like an auction.
12:16 < gmaxwell> There are many people who _urgently_ want segwit activated yesturday.
12:16 < jtimon> michagogo: undesrtood
12:16 < wumpus> usually I estimate 1 month for rc1->final, but this maybe be more involved than usual, dunno
12:16 < michagogo> Just like when you write code the goal is for it to compile perfectly the first time :P
12:16 < BlueMatt> wumpus: or less, hopefully
12:17 < BlueMatt> :p     
12:17 < sipa> i think this rc will be much shorter
12:17 < wumpus> BlueMatt: well this is a minor release, so it *should* be shorter
12:17 < gmaxwell> I think it would be fine to set start date 1 month after final. Even then if RCs take two months we still will not be at risk of activation before a software release.
12:17 < btcdrak> well we could just commit to sleepless nights to make release happen on time :-p
12:17 < sdaftuar> gmaxwell: the downside to rushing this out is that there's less time for everyone to test with the updated policy changes on testnet
12:17 < gmaxwell> er 1 month after RC1 not final.
12:17 < gmaxwell> sdaftuar: most of them are no-ops on testnet.
12:17 < sdaftuar> gmaxwell: how so? 
12:17 < gmaxwell> though I have been running with the patches applied and testnet set to enforce policy.
12:18 < gmaxwell> sdaftuar: testnet doesn't enforce standardness rules.
12:18 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
12:18 < BlueMatt> i mean can we get testnet miners to do compact-enforcement today?
12:18 < sdaftuar> yes it does, for the script checks
12:18 < BlueMatt> that should be most of it?
12:18 < BlueMatt> phantomcircuit: Lightsword please do that ^
12:18 < btcdrak> well remember there are non Core nodes mining on testnet
12:18 < sdaftuar> gmaxwell: am i missing something?
12:19 < btcdrak> I think lightsword's miner must be off, none of roasbeef's txs are getting mined.
12:19 < gmaxwell> sdaftuar: no, though not all the new policy is scriptchecks.
12:19 < gmaxwell> In any case, I don't think we should decide for sure here, we should make a list post.
12:19 < cfields> btcdrak: I'll be firing mine up in the next day or two
12:19 < sdaftuar> gmaxwell: sure not all, but the most significant ones IMO
12:19 < jtimon> prosed topic, maybe not for today: testnet4
12:19 < btcdrak> There are 4k unconfirmed "spam" txs https://testnet.smartbit.com.au/
12:20 < gmaxwell> But I think we should be suggesting 1month post rc1 as the starting time, when we do. Unless something specific comes up that suggests otherwise.
12:20 < BlueMatt> gmaxwell: agreed, for now lets recommend 1.25 months from rc1 release on the list, and get some testnet miners spun up mining #8499 today so that we're less worried about sdaftuar's objection?
12:20 < gmaxwell> Keep in mind, in prior softforks the starting time was infinitely far in the past. And BIP9 made its way through 95% of its development with no starting time.
12:20 < michagogo> BlueMatt: perhaps 50 days for roundness
12:20 < michagogo> Or 55
12:20 < sipa> nov 15.
12:21 < michagogo> That's good too
12:21 < btcdrak> great.
12:21 < michagogo> (A birthday gift for my brother, perhaps?)
12:21 < gmaxwell> it was added because for one prior sf we ended up with >30% hashpower weeks before release... and that was for a SF with no quieting period... so it had a real risk of activating basically before a release.
12:22 < wumpus> I doubt that's a risk for segwit
12:22 < gmaxwell> Agreed.
12:22 < jtimon> gmaxwell: I think it's useful beyond that
12:22 < btcdrak> yes, the fact BIP9 requires 4-6 weeks to kick in realistically, makes it less of an issue
12:23 < sipa> nov 15 is close to a retarget
12:23 < gmaxwell> 4-8 weeks with 6 weeks being the average if all miners immediately upgrade.
12:23 < btcdrak> ok so Nov 15th it is?
12:23 < sipa> maybe we want to pick a date just before a retarget
12:23 < achow101> nov 15th sounds good (at 00:00 AM?)
12:23 < btcdrak> sipa: yes and remember Bitfury are turning on a _lot_ of hash rate going forward
12:23 < gmaxwell> btcdrak: probably shouldn't be just setting it here, but just have a feel for what we think is reasonable.
12:23  * jtimon wishes we had chosen hieght instead of time not to wonder what will be close to retarget
12:24 < sipa> yes, let's propose on the ML
12:24 < BlueMatt> ok, seems like we have rough consensus on a month after rc1 is probably a reasonable recommendation, so lets propose to the ml
12:24 < instagibbs> Ack     
12:24 < wumpus> yes     
12:24 < gmaxwell> sipa: do you want to do the list thing, or should I or?
12:25 < sipa> i will
12:25 < jtimon> ack on following up on the mailing list, it seems nobody is unhappy about either rc1 + 1 month nor rc2 + 2 month
12:25 < wumpus> #action propose segwit activation parameters on the ML
12:25 < jtimon> nor 15 nov
12:25 < BlueMatt> ok, next topic?
12:25 < wumpus> #topic testnet4 (jtimon)
12:26 < BlueMatt> why?
12:26 < achow101> ^     
12:26 < wumpus> @jtimon
12:26 < jtimon> well, I would prefer to discuss verifyBlock vs processBlock actually
12:26 < wumpus> lol you proposed the topic
12:26 < jtimon> but some people complained about testnet being unreliable
12:27 < BlueMatt> isnt that a number of miners thing?
12:27 < wumpus> do you have a concrete proposal to fix that?
12:27 < gmaxwell> That has little to do with 'testnet4'  I think. It just is that testnet is not consistently mined.
12:27 < sipa> i don't know that resetting would help
12:27 < jtimon> my main interest would be to remove the special case for testnet on pow
12:27 < BlueMatt> that would make it more unreliable?
12:27 < jtimon> don't drop diff to 1, maybe just add a max difficulty or something simpler
12:27 < jtimon> BlueMatt: I doubts so
12:28 < BlueMatt> i mean we added that rule because testnet was unreliable
12:28 < jtimon> BlueMatt: and did it solved it?
12:28 < BlueMatt> though i have no intuition for properly setting a max testnet diff that is reasonable
12:28 < BlueMatt> jtimon: it made it an order of magnitude (or two) better
12:28 < wumpus> yes, without it it is even worse
12:28 < jtimon> BlueMatt: fair enough
12:28 < btcdrak> max diff would be a disaster
12:28 < jtimon> maybe next topic?
12:28 < sipa> we could live without the permanent reset bug, though
12:29 < wumpus> any other topics?
12:29 < wumpus> *crickets*
12:30 < achow101> the prefinal alert that was supposed to happen but didn't?
12:30 < wumpus> well, that concludes the meeting early I guess. Let's make sure we can have a 0.13.1rc1 by next week
12:30 < jtimon> libconsensus: verifyBlock vs processBlock (ie the latter takes care of reorgs, updates the utxo, etc)
12:30 < BlueMatt> achow101: suggested prefinal alert
12:31 < gmaxwell> jtimon: a lot of people would like us to have a signed testnet using the pluggable pow stuff that is in elements, so that it would have perfectly predictable blocks and perfectly predictable reorgs.
12:31 < gmaxwell> achow101: we need to write explination text for bitcoin.org and I haven't had time to do it and no one else has stepped up.
12:31 < gmaxwell> I have an alert ready to go.
12:31 < jtimon> gmaxwell: I would be more than happy to put that in core if it's desirable, thanks for letting me know
12:31 < wumpus> #topic prefinal alert
12:31 < achow101> copy-paste from email
12:32 < gmaxwell> Needs to have an explination of the alert system, why it's gone now. And a description of the future steps that we discussed here.
12:33 < gmaxwell> achow101: do you want to try drafting something? I would be happy to review/edit.
12:33 < achow101> sure, I can try writing it
12:33 < gmaxwell> sounds good.
12:34 < wumpus> #action achow101 post about alert system for bitcoin.org
12:34 < wumpus> thanks
12:34 < btcdrak> Just a random information topic, there is a segwit dev guide for downstream published here https://bitcoincore.org/en/segwit_wallet_dev/
12:34 < gmaxwell> jtimon: if we're going to do any 'new testnet thing' we should figure out how to extract the good test cases from the existing testnet. E.g. instrumenting for code coverage and syncing testnet while noting which transactions increased coverage.
12:35 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
12:35 < wumpus> btcdrak: awesome!
12:35 < wumpus> #link segwit dev guide for downstream https://bitcoincore.org/en/segwit_wallet_dev/
12:35 < gmaxwell> we have other upcoming doc works. We should have a segwit deployment guide-- covering things like explaining how to setup perimiter nodes to shield unupgraded custom stuff-- ready at the start of the segwit queting period. 
12:36 < achow101> apparently no one but me knew that dev guide even existed...
12:36 < gmaxwell> But we can get contributors outside of the regulars for this meeting, for the audience here advice on content would be good.
12:36 < morcos> it seems to me a better way to make testnet usable is to just pool some funding to have some small but non-trivial hashpower running it rather than implement more differences in behavior from mainnet
12:36 < wumpus> achow101: a lot of good information exists but the knowledge of that information is pretty sparse
12:36 < wumpus> achow101: has always been a problem in bitcoin :(
12:36 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 258 seconds]     
12:37 < gmaxwell> morcos: the problem is that some clown pool will occasionally drop a petahash onto it an drive the difficulty up.
12:37 < jtimon> gmaxwell: is there any recommended tool for coverage in bitcoin core?
12:37 < wumpus> jtimon: valgrind?
12:37 < jcorgan> gmaxwell: i could likely help with some of the documentation work, if there is someone on the team to work with
12:37 < gmaxwell> jtimon: lcov works. But to get data inline like that some stunts involving gprof can be done.
12:38 < gmaxwell> You can ask the gprof stuff to dump the current data with a function call, IIRC.. so presumably one could instrument doing that after processing each transaction.
12:38 < jtimon> oh, I just recently starting using lcov, nice
12:39 < gmaxwell> in any case, there are tests in testnet that do not exist in any unit test. It would be good to find most of them and be able to start out a new testnet where the first few hundred blocks excercise all of them.
12:39 < Chris_Stewart_5> gmaxwell: Content on what docs? Segwit docs? 
12:39 < wumpus> after each block may be enough granularity
12:40 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
12:40 < gmaxwell> Chris_Stewart_5: on what materials should be covered in a deployment guide. For non-miners the only really important thing that comes to mind to me is instructions on setting up peremiter nodes.
12:40 < Chris_Stewart_5> Gotcha. 
12:40 < gmaxwell> but no doubt there are other things.
12:40 < sdaftuar> all the policy changes!
12:41 < Chris_Stewart_5> jtimon: I think cfields has some sort of website that shows lcov coverage
12:41 < gmaxwell> sdaftuar: fair enough, though I expect those to be 99% invisible, but good to cover them more.
12:41 < cfields> Chris_Stewart_5: that was a one-time thing for segwit. Just need to fix up the makefile stuff so it can be auto-generated again
12:43 < wumpus> gah, looks like my backport of #8393 in #8916 is failing the RPC tests
12:43 < sdaftuar> wumpus: i'm running locally... compact blocks again
12:43 < sdaftuar> wumpus: i can reproduce at least
12:43 < wumpus> okay thanks!
12:43 < jtimon> Chris_Stewart_5: gmaxwell: awesome, maybe we should consider putting some lcov stuff as tooling? something like in https://github.com/jgriffiths/libwally-core#generating-a-coverage-report ? stupid people like me appreciate these things...
12:44 < jtimon> maybe I should start with that before a nexttestnet, anyway, I'll come back to you and cfields, we're mixing topics
12:44 < wumpus> jtimon: recently created a bitcoin-maintainer-tools repo https://github.com/laanwj/bitcoin-maintainer-tools, would make sense to add to that
12:45 < Chris_Stewart_5> jtimon: I think it is an easy way to direct new developers where it might be easiest to contribute to, as they can easily see where we are lacking tests 
12:45 < cfields> jtimon: we have an --enable-lcov (or something like that). But it's broken atm.
12:46 < jtimon> awesome, so there's work to be done here but there's a base, thank you guys
12:46 < cfields> just need to get it fixed up again, shouldn't be too tough.
12:46 < wumpus> we should probably create an issue for that
12:46 < jtimon> wumpus: will check that out, does it contain lcov too? maybe we should consid
12:46 < gmaxwell> I haven't been too generally impressed with the utility of lcov on the bitcoin core codebase-- better than nothing I guess, but the branch coverage is full of BS unreachable branches due allocations in templaized container objects.
12:47 < jtimon> s//wumpus: will check that out
12:47 < wumpus> jtimon: no, it currently contains only a tool for doing per-function binary comparison of builds
12:47 < wumpus> jtimon: but I'm generally for sharing our tools more
12:48 < jtimon> gmaxwell: yeah, for a new testchain, take into account that we're still using globals and some hardcoding
12:48 < wumpus> jtimon: I have a lot of other ones, but need to clean up and disentangle them from other local stuff first before I can publish them
12:49 < wumpus> (for example for creating release notes)
12:49 < jtimon> things like https://github.com/bitcoin/bitcoin/pull/8855 should help with new testchains
12:50 < gmaxwell> so... another topic, probably mostly for a future meeting.. sybil attacks.
12:50 < jtimon> wumpus: nice, we can incorporate those upstream little by little
12:50 < wumpus> anyhow let's end the meeting, seems we're not really on a topic anymore
12:50 < gmaxwell> I am now seeing 60+ connections within seconds of starting a node..
12:50 < wumpus> jtimon: I really prefer having meta-tools in a separate repo
12:51 < wumpus> jtimon: as they're not really on the same release cycle, and go through lots of changes that don't really need to go through the bitcoin core review process
12:51 < jtimon> wumpus: well I don't have a strong opinion, you can always document where those tools are somewhere
12:51 < wumpus> yes     
12:51 < wumpus> #topic sybil attacks
12:51 < gmaxwell> Does anyone here have any back channels into amazon operations? I'd like to know why they are unresponsive to abuse conmplaints regarding this user.
12:52 -!- sybil01 [~a@2a02:348:86:3011::1] has joined #bitcoin-core-dev     
12:52 < gmaxwell> So background: someone is mass connecting many times in parallel to all reachable ondes, pretending, poorly, to be a mix of different spv clients.
12:52 < wumpus> reminds me I should still file a complaint for that
12:53 < jtimon> suggested topic: libconsensus: verifyBlock vs processBlock (ie the latter takes care of reorgs, updates the utxo, etc)
12:53 < wumpus> sybil01: oh no :)
12:53 < gmaxwell> Because of the connection management stuff implemented a few versions ago, it doesn't disrupt the network much (these peers can get evicted). But I presume their motivation is to undermine user's privacy through observation.
12:54 < BlueMatt> gmaxwell: i mean if we fix the privacy leak that makes it useful to do this, maybe they'll go away :)
12:54 < CodeShark> hi guys...traveling and can't catch entire meeting but will read thr scrollback :)
12:54 < wumpus> that must be the reason to do this, it would be an extremely ineffective DoS
12:54 < gmaxwell> Right now, connecting more times in parallel will leak more information and we can reduce that leackage further with already planned future relay improvements. ... which I've only not finished due to focusing on testing segwit and whatnot.
12:54 < gmaxwell> wumpus: it would be a potent DOS prior to 0.12-ish. 
12:55 < gmaxwell> but yes, I presume they'll stop if we further reduce the privacy leaks. So thats the obvious thing to do.
12:55 < wumpus> gmaxwell: but it seems they open a fixed number of connections per node. A DoS would exhaust slots
12:55 < btcdrak> can we ban multiple connection from the same IP? that would be a start against this particular AWS spy.
12:55 < gmaxwell> presumably they were doing this before, and prior improvements killed the leaks unless they connected multiple times which made them visible.
12:55 < sipa> btcdrak: meh, they'll move to routing through different ips
12:56 < gmaxwell> btcdrak: it would be pretty harmful to do that network wide as there are many instutions and even a country where all connections come from one ip.
12:56 < wumpus> theyalready use multiple IPs, though they also do multiple connections per IP form some reason
12:56 < gmaxwell> and they do already use multiple IPs. and they changed them after people started circulating banlists.
12:56 -!- sybil01 [~a@2a02:348:86:3011::1] has quit [Ping timeout: 250 seconds]     
12:56 < BlueMatt> several folks now ban aws nodes wholesale, which sucks because aws nodes are useful due to DDoS protection built-in
12:56 < wumpus> but yes IPs are cheap anyway, as long as there's profit to be made from this they'll not go away. THough I personally ban multiple connects from a single IP on my nodes.
12:56 < BlueMatt> (including some of my nodes)
12:57 < gmaxwell> I'd like to avoid hardcoding netblock specific rules "one connection per IP from amazon IP space" and whatnot. :)
12:57 < gmaxwell> so in any case, reducing the leakage is always a good move and we should do that.
12:57 < BlueMatt> yup     
12:57 < sipa> i think we can make the relay delays use deterministic randomness based on netgroup, so nodes in the same range will see the same thing
12:57 < sipa> and many more ideas
12:58 < cfields> gmaxwell: for one in every X connections, we could proxy and route messages together for peer-pairs. Then they'd poison their own stats :p
12:58 < sipa> probably not for this meeting
12:58 < gmaxwell> cfields: That won't work for reasons I'd rather not say in public, unfortunately.
12:58 < btcdrak> 1 min 30 seconds to go
12:58 < wumpus> cfields: they don't actually ever send anything
12:58 < gmaxwell> well it would help. but not do quite what you think.. still could be useful.. many fun things to discuss.
12:59 < wumpus> cfields: they just negotiate the connection, answer pings, and listen. Though poisining the info sounds like fun.
13:00 < sipa> DANG
13:00 < instagibbs> ding ding
13:00 < btcdrak> dong
13:00 < wumpus> and yes, netblock specific rules are not an option, that'd be Hearnian
13:00 < wumpus> #endmeeting
13:00 < lightningbot> Meeting ended Thu Oct 13 20:00:10 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-13-19.04.html
13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-13-19.04.txt
13:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-13-19.04.log.html
13:00 < gmaxwell> wumpus: it would potentially make sense to ship with a IP -> ASN map to make the same-netgroup logic more intelligent... though it would be a couple megabytes of data to ship, unfortunately.
13:01  * midnightmagic would love to cooperate to poison network spy data.
13:01 < gmaxwell> but I don't know that doing anything that depends on IPs as a limit resource is worth any time.
13:01 < musalbas> blocking multiple connections per IP would also have the added benefit of helping to prevent Eclipse attacks (per http://eprint.iacr.org/2015/263.pdf)
13:01 < gmaxwell> musalbas: no, it wouldn't.
13:02 < wumpus> musalbas: IPv4's are cheap, any attack that runs profit of any kind can use tons of them
13:02 < musalbas> true
13:02 < wumpus> ... not to speak about IPv6's :)
13:02 < gmaxwell> musalbas: multiple inbound connections per IP cannot really be used to perform eclipse attacks in bitcoin due to how the connection management works.
13:02 < gmaxwell> musalbas: if we run out of connections, we will start kicking off peers, and those dupes are among the first to go.
13:02 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 260 seconds]     
13:04 < instagibbs> due to metrics in AttemptToEvictConnection?
13:04 < musalbas> yeah i recall some countermeasures being implemented
13:04 < gmaxwell> musalbas: the logic is that when we fill and a new one comes in, we make a decision to potentially evict a connection (including the new one). The decision first protects a subset of peers based on them being "good" according to varrious different criteria, then it kicks the shortest uptime peer from the netgroup with the most inbound connections. 
13:04 < instagibbs> if they're not serving data, and in same netgroup, only a small number may be protected from eviction
13:04 < musalbas> interesting
13:04 < wumpus> gmaxwell: yes IP to ASN map would be an idea
13:05 < instagibbs> musalbas, https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L873
13:06 < gmaxwell> the way this particular attacker works tends to exploit the longest uptime protection, unfortunately. Though we could easily strenghten that some.
13:07 < gmaxwell> I've hesitated adding narrow improvements that they could easily avoid, however.
13:07 < musalbas> out of curiosity are there any countermeasures to defend against the case where an attacker controls the user's network, forces them to only connect to their nodes and kills connections from the outside world, and starts giving them "secret" blocks?
13:07 < gmaxwell> musalbas: yes, proof of work.
13:08 < wumpus> gmaxwell: wonder if it woudl be possible to compress that map in a smart way, maybe approximate it, in a way that would be better than the current same-netgroup logic but fairly compact
13:08 < musalbas> gmaxwell, yes but assuming the adversary is well resourced but has less than 51% of hashing power they can still give a user secret blocks.
13:08 < gmaxwell> and the software knows about the identity of the 'real' chain, to enough extent that making a whole fake world is computationally hard, even if the node is interceptect from start.
13:09 < gmaxwell> musalbas: yup. There is no protection against that.  One of the motiviations behind the proposed authenticated transport is so that nodes could add authenticated peers.
13:09 < musalbas> gmaxwell, but the difference would be that the blocks would be a lot less frequence *unless they are pre-computed before the attack* - which could be a way to detect
13:09 < musalbas> frequent*
13:09 < musalbas> gmaxwell, i see
13:10 < BlueMatt> musalbas: even if the attacker has 50% of hashrate its gonna generate blocks slower than the "real" network
13:10 < BlueMatt> (though, at that point, the attacker potentially is the "real" network)
13:11 < musalbas> BlueMatt, unless the attacker knows the block height that the client is on before connecting to the network, and pre-computes a bunch of blocks with certain timestamps a long time before the attack occurs
13:11 < gmaxwell> musalbas: the slower criteria doesn't generally work that well, if you work out the math for an acceptably fp rate, the attacker has to be awfully slow for it to reliably trigger there.
13:11 < musalbas> i see
13:11 < BlueMatt> musalbas: i mean as long as the chain's hashpower isnt going up too fast, the client can tell that its last block was X days ago, and too few blocks were generated for that time
13:12 < BlueMatt> gmaxwell: luckily the math works out better over longer time horizons, like the attack musalbas is referencing :)
13:12 < musalbas> anyways, if the eclipse attack problem is solved for offline-networks, it could have some good applications for transparency overlays in threat models where the attacker owns the network
13:12 < BlueMatt> indeed, though you we also already have good tor support for this reason
13:13 < gmaxwell> musalbas: if it were actually solvable in a strong sense bitcoin wouldn't need mining.
13:14 < musalbas> gmaxwell, there are papers that suggest that bitcoin doesn't need mining if you collapse Bitcoin into Certificate Transparency-like system, but that assumes a level of trust in a set of distributed actors
13:15 < musalbas> however, if you can have trustless CT without blockchain then ... :)
13:15 < midnightmagic> -- then altcoin scams.
13:16 < musalbas> BlueMatt, yeah Tor could be good to prevent that, but it's not foolproof at you're transferring your trust to a set of distributed Tor directory authorities
13:16 < gmaxwell> musalbas: ultimately if you are not trusting a specified set, then what is to say that your isolating attacker _isn't_ the valid network.
13:17 < gmaxwell> So I think the problem you hope to solve is not well defined.
13:17 < gmaxwell> But having unforgable adjcencies with parties you know would protect from isolation attacks in practice, and requires no centeralized ttp. 
13:20 < musalbas> gmaxwell, I would be curious to hear your opinion in the creator of Certificate Transparency's criticisms of Bitcoin, who argues that Bitcoin is not decentralized unless 51% of the world's processing power is doing Bitcoin hashing, and therefore you have to trust the people who set the checkpoints in the Bitcoin source code otherwise you can just rewrite the chain.
13:20 < instagibbs> hmm, test before evict didn't go anywhere. Wonder if that can get worked on.
13:20 < instagibbs> now that feeler is in
13:20 < musalbas> (http://www.links.org/files/decentralised-currencies.pdf)
13:21 < gmaxwell> musalbas: he's full of shit.
13:21 < gmaxwell> :)     
13:21 < wumpus> the checkpoints are going to go
13:21 < gmaxwell> which I helpfully told him as soon as he wrote that, but alas, he didn't respond.
13:21 < gmaxwell> lemme give you my response.
13:22 < musalbas> yeah I agree - but I'm trying to making him come around by currently writing a paper for a way to make CT trustless but while keeping it scalable by enhancing it using the blockchain as a medium for partial transparency
13:23 < wumpus> only in the early blocks (when difficulty is very low) it'd be realistically possible to feed a client the wrong chain, and it may waste some time with that, and checkpoints are reasonably useful for avoiding that... but once it catches up it will notice anyhow that that's not the most-work chain
13:23 < gmaxwell> musalbas: http://0bin.net/paste/nyvikpO+-Q+R5ZsW#MmdECr9dkrXeLO0HKMp5LVvtgH377V-28cN9r1LSBGS  keep in mind, I wrote that in 2011... I would probably say some different things now.
13:24 < musalbas> i'll read
13:25 < musalbas> (but bbl for now as i have to travel home)
13:26 < gmaxwell> as wumpus mentions, we're now going to remove checkpoints soon, they don't do anything much anymore. There are a couple DOS attacks that they help with, getting rid of them is important to avoid misunderstandings like Ben's.
13:27 < gmaxwell> and FWIW, the last checkpoint was set at block 295000 ... over two years ago.
13:39 -!- whphhg [whphhg@gateway/vpn/mullvad/x-cjknjtqntqvqfzvo] has quit [Ping timeout: 260 seconds]     
13:43 -!- fengling [~fengling@43.255.176.13] has quit [Ping timeout: 268 seconds]     
13:58 -!- fengling [~fengling@43.255.176.13] has joined #bitcoin-core-dev     
14:05 -!- cryptapus_afk is now known as cryptapus     
--- Log closed Thu Oct 13 14:08:47 2016
--- Log opened Thu Oct 13 14:09:23 2016
14:09 -!- kanzure [~kanzure@bryan.fairlystable.org] has joined #bitcoin-core-dev     
14:09 -!- Irssi: #bitcoin-core-dev: Total of 157 nicks [0 ops, 0 halfops, 0 voices, 157 normal]     
14:09 -!- Guyver2__ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
14:12 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 252 seconds]     
14:12 -!- Guyver2__ is now known as Guyver2     
14:20 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []     
14:21 -!- Irssi: Join to #bitcoin-core-dev was synced in 778 secs
14:40 < achow101> gmaxwell: (and whoever can publish alerts, wumpus?) what do you think: https://github.com/achow101/bitcoin.org/blob/prefinal-alert/_alerts/2016-10-14-alert-retirement.md
14:46 -!- cryptapus is now known as cryptapus_afk     
14:52 < wumpus> looking :)
14:54 < btcdrak> achow101: also one key means we have no idea how many people the key was shared with and who is in possession of the key. 
14:54 -!- cdecker [~quassel@2a02:aa16:1105:4a80:fdf7:6cf4:b6b2:d619] has joined #bitcoin-core-dev     
14:55 < btcdrak> and it seems like magicaltux also has the key and he was detained by police it seems reasonable that the key might be in many many people's possession by now
14:59 < wumpus> yes, we don't know who has the key at this point. It's a typical issue with only having one, shared, key. You don't know who was it that sent an alert, and you can't revert one person's key
15:00 < wumpus> "No Bitcoins are at risk and this warning may be safely ignored" yes, indeed. It's a no-op for most.
15:00 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
15:01 < gmaxwell> I like the text overall!
15:02 < wumpus> in the case of bitcoin core we have the bitcoin core announcement list now: https://bitcoincore.org/en/list/announcements/join/
15:02 < wumpus> me too
15:03 < wumpus> seems good to me
15:03 < kanzure> achow101: i suggest linking to at least https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013104.html
15:03 < kanzure> and possibly earlier discussion too
15:04 < gmaxwell> I think the schedule should be: (1) that page goes up, (2) an email goes to varrious lists, warning about the prefinal alert. Then a day later, the prefinal alert goes out. (I don't see a reason to wait longer than a day, anyone who doesn't see it in a day won't see it anytime soon-- and the only reason to announce it in advance is just in case someone has automation that triggers a shutdown on 
15:04 < gmaxwell> any alert)
15:05 < kanzure> not sure about an earlier link, any hints anyone?
15:05 < kanzure> i suppose there was https://github.com/bitcoin/bitcoin/pull/6260 (remove alert system)
15:12 < achow101> kanzure: yeah, I'll link the email, the discussion here from a while back, and that pr
15:12 < gmaxwell> the announcement should point out what versions its deactivated in.
15:12 < achow101> ok     
15:13 < gmaxwell> because some people might want to update to a newer version but not all the way or something.
15:14 < gmaxwell> if we're close to a releaes it might make sense to delay sending the alert itself, as that might cause a few people to upgrade... would be kinda lame to have them upgrading to a version which is outdated a week later.
15:14 < wumpus> 0.10.3 added the option to disable alerts (-alerts=0)
15:15 < sipa> wow, so long already
15:15 < achow101> which releases should I mention?
15:17 -!- cdecker [~quassel@2a02:aa16:1105:4a80:fdf7:6cf4:b6b2:d619] has quit [Ping timeout: 260 seconds]     
15:17 < wumpus> alerts are disabled by default on the 0.11 branch, however, there has been no release after doing that
15:17 < wumpus> 0.12 removed alerts completely
15:18 < wumpus> (don't know which .x yet, looking)
15:18 < achow101> I thought only 0.13 had alerts actually removed
15:21 < gmaxwell> for the purpose of that message, disabled is probably the right milestone. Doesn't really matter to the user if the code is there but dead.
15:21 < wumpus> achow101: yes, you are right, had the 0.13 branch checkout out in my 0.12 repo for some reason, it is only disabled
15:22 < wumpus> but as gmaxwell says disabled is enough
15:22 < achow101> so 0.10.3, 0.11.x, and 0.12.x allows disabling with -alerts=0
15:22 < gmaxwell> question is where was it disabled by default first?
15:23 < wumpus> 0.10.3 and 0.11.* has it enabled by default but allows disabling
15:23 < wumpus> yes     
15:24 < wumpus> 0.12.1 has it disabled by default
15:24 < wumpus> 0.12.0 hasn't
15:24 < gmaxwell> seqeunce < spelling
15:24 < gmaxwell> As far as the final alert, I think we'd actually do it shortly prior to 0.14's RC phase?  so that we could hardcode it in to be given to older peers.
15:25 < achow101> Should I include other software that has removed alerts
15:26 < gmaxwell> What I would put is something stating that as far as we're aware all currently maintained implementations have removed alerts.
15:26 < wumpus> yes, 0.14.0 should hardcode the final alert
15:27  * luke-jr wonders if the final alert should mention the announce ML
15:27 < achow101> made changes, gtg
15:27 < wumpus> indeed - there may be some altcoins that have literally copied the alert key, but that's not releavant to this message
15:27 < achow101> i'll be back in ~1 hr
15:27 < wumpus> later achow101 
15:28 < gmaxwell> wumpus: there were a few but IIRC I didn't find any that were non-dead... and I attempted to contact all the ones I found.
15:28 < gmaxwell> there were a LOT more that copied litecoin's key.
15:29 < gmaxwell> like hundreds of them
15:29 < petertodd> achow101: ACK
15:29 < wumpus> yes the non-dead altcoins I've looked at also have a different key, didn't compare against the litecoin one :)
15:31 < wumpus> but it sounds sensible to me, most altcoins descent from litecoin, or the 'PoS' coins after that, not bitcoin directly
15:33 < sipa> anyone tried a gothib search for the alert key?
15:33 < sipa> eh, github
15:33 < gmaxwell> yes     
15:34 < sipa> how did i manage to get two typos in one word?
15:34 < wumpus> github search is pretty crappy, I'm amazed that worked :) I did  a google search though.
15:34 < gmaxwell> sipa: jsmf ,ods;ohm,rmt.
15:35 < gmaxwell> I didn't say it was useful, I said I tried it.
15:35 < gmaxwell> :)     
15:35 < gmaxwell> the openhub code search thing was more useful.
15:35 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
15:36 < wumpus> in any case they *too* are better off with the key being phased out,and the final alert being sent
15:37 < wumpus> it makes no sense for us to be able to send alerts on random altcoin networks
15:37 < gmaxwell> I think it makes lots of sense.
15:37 < gmaxwell> muhahah.
15:37 -!- whphhg [whphhg@gateway/vpn/mullvad/x-vgzjwmqechajrsry] has joined #bitcoin-core-dev     
15:38 < wumpus> yes :-)
15:38 < wumpus> <trollface>
15:40 -!- murch [~murch@p4FDB6B7F.dip0.t-ipconnect.de] has quit [Remote host closed the connection]     
15:46 < musalbas>  re: checkpointing - is there anything in Bitcoin consensus to prevent someone from going back 2048 blocks to a much lower difficulty, and then doing a 51% attack from there to get the longest chain? I think I must be missing a subtle consensus rule here
15:46 < gmaxwell> you are
15:46 < gmaxwell> Bitcoin's best chain selection is not 'most blocks', it's 'most work'.
15:47 < musalbas> ahh     
15:47 < gmaxwell> though this was originally wrong, and it's wrong in the whitepaper, and there is no real way to update it-- so a lot of people aren't aware.
15:47 < gmaxwell> but it's been 'most work' since some time in 2010.
15:47 < musalbas> well that clears up many shower thoughts of mine.
15:48 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]     
15:48 < gmaxwell> (it was fixed around the same time that bitcoin first moved off the minimum difficulty)
15:53 < wumpus> maybe it would make sense to publish an 'errata' to the whitepaper
15:53 < sipa> wumpus: you'll get lynched...
15:54 < gmaxwell> lol     
15:54 < musalbas> it will be like trying to modify the bible for many
15:54 < gmaxwell> so you might not be aware, but cobra proposed putting up an updated whitepaper on bitcoin.org with varrious errata and it started a week long lynchmob thing. OMG YOU CHALLENGED THE HOLY WORD.
15:55 < gmaxwell> nevermind that it's wrong in a few places, and we've learned _a lot_ about teaching people about Bitcoin since 2008.
15:56 < wumpus> oh I'd like to change the bible as well... </s>
15:57 < kanzure> all of them?
15:58 < wumpus> I think most oppositiion exists to changing the whitepaper, on the original URL, itself. Releaseing an updated version as long as it's clear that it's an updated version may run into less opposition. But I dunno, some people are pretty close to extremism
15:58 < musalbas> you can't update the bible. there are too many bible book nodes around the world, it's immutable 
15:59 < wumpus> never mess with the satoshi cults...
15:59 -!- davec_ [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]     
15:59 < kanzure> was there anyone offering to do the legwork on a bitcoin core whitepaper?
16:00 < sipa> i don't think it's a good topic for a whitepaper
16:00 < sipa> maybe some subsystems could use one
16:00 < kanzure> well maybe i have the color wrong
16:00 -!- davec_ [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev     
16:00 < sipa> how about a black paper?
16:01 < wumpus> yes! much better
16:01 < musalbas> a black paper would waste lots of ink; you don't want critics to accuse bitcoin of using lots of energy as well as ink now
16:01 < wumpus> or a purplepaper
16:01 < sipa> we should check with dark coin
16:01 < sipa> maybe they have prior art
16:02 < wumpus> Amir's revenge?
16:02 < wumpus> darker than dark wallet
16:04 < musalbas> scientists have developed a new colour darker than black called 'super black', so it' spossible: http://newatlas.com/vantablack-super-black-material/33011/
16:04 < wumpus> infrablack
16:04 < gmaxwell> I have access to a high power pulsed laser so we can make superblack.
16:05 < gmaxwell> black on black won't be readable, but no one was going to read it anyways.
16:05 < wumpus> a hyperblock
16:06 < wumpus> yes, no matter how much energy would go into creating it, one would read it anyway
16:08 < sipa> so we are no longer restricted to a blockchain, but could use a blackchain?
16:08 < sipa> we need to combine that with rainbow tables
16:09 < wumpus> if we're no longer restricted to whitelisting, I'd prefer rainbowlisting
16:10 < gmaxwell> thats good because rainbows don't include black.
16:11 < petertodd> gmaxwell: additive color rainbows do
16:11 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
16:12 < gmaxwell> sipa: back to work; is there any real reason that we couldn't just make all inbound connections one 'group' for the purpose of relay... it would slow relay down some, but really throughly kill that information leak.
16:14 < sipa> do you mean let all of them use the same timing for relay?
16:14 < gmaxwell> yes.
16:14 < gmaxwell> oh hmp. my own concern with that is it makes the traffic more bursty.
16:15 < sipa> it would worsen spikyness of relay memory
16:15 < sipa> right, and memory usage too
16:15 < gmaxwell> the memory usage should be trivial, the transactions are shared, so the usage is just pointers.
16:19 < sipa> it's a set of txids
16:19 < sipa> not shared_ptrs
16:20 < gmaxwell> pointer, txid, same difference. you're not on a 256 computer yet?
16:20 < gmaxwell> I suppose inbound could be assigned to 4 groups or 8 groups based on a hash of their netgroup. ... and that would give a lot of burst mitigation while bounding the attack upside.
16:21 < gmaxwell> (salted hash)
16:21 < sipa> i think we could turn them into weak_ptr's to CTransactions, thougg
16:22 < gmaxwell> well we could replace this datastructure per peer to a single queue, with a bitmap that has a bit per peer.
16:23 < gmaxwell> (or better, an efficiently encoded bitmap... I guess there is no STL container that works like a judy1.
16:23 < gmaxwell> )     
16:27 < achow101> i'm back
16:30 < achow101> should I submit a PR for the alert or will someone with commit access to bitcoin.org sign and push the commit?
16:30 < GitHub184> [bitcoin] luke-jr opened pull request #8918: Qt: Add "Copy URI" to payment request context menu (master...gui_req_copy_uri) https://github.com/bitcoin/bitcoin/pull/8918
16:32 < gmaxwell> PR. none of us have commit access in any case, AFAIK-- and we wouldn't skip review. :) 
16:32 < gmaxwell> a PR is fine.
16:32 < achow101> supposedly wumpus does: https://github.com/bitcoin-dot-org/bitcoin.org#who-to-contact
16:33 < achow101> and the readme says "Note: the commit must be signed by one of the people in the Who to Contact section for site auto-building to work." which is why I asked
16:35 < achow101> done: https://github.com/bitcoin-dot-org/bitcoin.org/pull/1392
16:39 < wumpus> a PR is good, I have commit access to be able to do emergency bitcoin core releases
16:59 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
17:03 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
17:04 -!- echonaut2 [~echonaut@46.101.192.134] has quit [Read error: Connection reset by peer]     
17:19 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Remote host closed the connection]     
17:33 -!- justanotheruser is now known as justan0theruser     
18:13 -!- fengling [~fengling@43.255.176.13] has quit [Ping timeout: 268 seconds]     
18:15 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 258 seconds]     
18:17 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-fzdpozinjdvdfltr] has quit [Quit: Connection closed for inactivity]     
18:35 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 258 seconds]     
18:44 -!- alpalp [~allen@2605:6000:f4d6:d600:275c:538f:fa83:370b] has joined #bitcoin-core-dev     
18:44 -!- alpalp [~allen@2605:6000:f4d6:d600:275c:538f:fa83:370b] has quit [Changing host]     
18:44 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
18:45 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
18:52 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Quit: Lost terminal]     
18:59 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 258 seconds]     
19:00 -!- DigiByteDev [~JT2@69.167.26.16] has joined #bitcoin-core-dev     
19:08 -!- alpalp [~allen@2605:6000:f4d6:d600:275c:538f:fa83:370b] has joined #bitcoin-core-dev     
19:08 -!- alpalp [~allen@2605:6000:f4d6:d600:275c:538f:fa83:370b] has quit [Changing host]     
19:08 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
19:18 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
19:19 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
19:52 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
19:53 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
19:58 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 258 seconds]     
20:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
20:17 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
20:20 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
20:21 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
20:36 -!- Guest20119 [~null@contents-vnder-pressvre.mit.edu] has quit [Quit: reconnecting]     
20:37 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev     
20:54 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
20:55 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:05 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:06 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:17 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:18 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:34 < GitHub157> [bitcoin] fanquake opened pull request #8920: Set minimum required Boost to 1.47.0 (master...set-minimum-boost) https://github.com/bitcoin/bitcoin/pull/8920
21:38 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has quit [Ping timeout: 260 seconds]     
21:39 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev     
21:48 -!- DigiByteDev [~JT2@69.167.26.16] has quit [Quit: DigiByteDev]     
21:50 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
21:56 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:57 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
22:00 -!- dermoth [~thomas@dsl-66-36-134-16.mtl.aei.ca] has quit [Read error: Connection reset by peer]     
22:00 -!- dermoth [~thomas@dsl-66-36-134-16.mtl.aei.ca] has joined #bitcoin-core-dev     
22:11 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
22:12 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
22:14 -!- DigiByteDev [~JT2@69.167.27.69] has joined #bitcoin-core-dev     
22:22 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]     
22:25 -!- mrkent [~textual@unaffiliated/mrkent] has quit []     
22:38 -!- pavel_ [~paveljani@79.98.72.176] has joined #bitcoin-core-dev     
22:39 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 250 seconds]     
22:41 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hxbkhohptxmhxjjc] has joined #bitcoin-core-dev     
22:44 -!- pavel__ [~paveljani@79.98.72.176] has joined #bitcoin-core-dev     
22:44 -!- pavel_ [~paveljani@79.98.72.176] has quit [Read error: Connection reset by peer]     
22:50 -!- skyraider [uid41097@gateway/web/irccloud.com/x-mvyjuhwvcpmlnbao] has quit [Quit: Connection closed for inactivity]     
23:13 -!- pavel__ [~paveljani@79.98.72.176] has quit [Quit: Leaving]     
23:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
23:26 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
23:37 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
23:57 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]