--- Day changed Wed Oct 05 2016 00:01 < wumpus> luke-jr: I suspect it's a very young person and someone that doesn't know English very well, and he's just trying to be helpful. But indeed, wtf 00:09 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:09 -!- rubensayshi [~ruben@82.201.92.138] has joined #bitcoin-core-dev 00:11 < wumpus> and indeed, in fact most of build-unix.md is about linux distros, and the only UNIX that gets mentioned separately has its own document (openbsd), but no, adding kernel versions will not clarify that in any way :) 00:13 * wumpus goes to add a section about FreeBSD to balance it out 00:17 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev 00:18 -!- shesek [~shesek@bzq-84-110-179-95.red.bezeqint.net] has quit [Ping timeout: 248 seconds] 00:19 -!- harrymm [~wayne@104.222.140.84] has quit [Ping timeout: 276 seconds] 00:19 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 00:19 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-buzlefooaisrebhm] has joined #bitcoin-core-dev 00:45 -!- laurentmt [~Thunderbi@80.215.234.85] has joined #bitcoin-core-dev 00:47 -!- laurentmt [~Thunderbi@80.215.234.85] has quit [Client Quit] 00:54 -!- laurentmt [~Thunderbi@80.215.234.85] has joined #bitcoin-core-dev 01:13 -!- laurentmt [~Thunderbi@80.215.234.85] has quit [Ping timeout: 265 seconds] 01:14 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 01:14 < dcousens> btcdrak: "uncompressed keys which are disallowed under segwit.", interesting, no issue but can't find that in the BIP? 01:16 < btcdrak> dcousens: because it is too late to change the consensus layer without causing delays, so it is implemented as policy for now and consider for future sf. 01:16 < btcdrak> see last meetung notes 01:17 < dcousens> btcdrak: ok, sweet, will do 01:18 < dcousens> btcdrak: seen in notes, cheers ;) 01:22 < btcdrak> I think we will make a note in the BIP bow, thanks. 01:23 < wumpus> maybe, though it should be very clear that it is policy and not consensus then 01:24 < gmaxwell> My suggestion is that it should state that it's policy created with the intent of making it consensus in a future softfork. 01:30 < wumpus> or already create a BIP for such a future softfork, although that may be premature if it's to be combined with other things that may still come to light using this in the wild 01:31 < gmaxwell> Well we can do like we did with CSV, we had three BIPs triggered on one bit. 01:31 < wumpus> indeed. true. 01:31 < gmaxwell> The thing I'd combine it with would be low-S enforcement. 01:32 < dcousens> gmaxwell: agreed 01:32 < wumpus> yes that would make sense, it's a comparable thing 01:33 < gmaxwell> (low-S doesn't have the blowing up anyone's pubkey risk, though, and already IsStandard for non-segwit, so no need to warn about it.) 01:34 < dcousens> btcdrak: that was uncompressed rejection only in witnesses, or even in regular scriptSigs? 01:35 < luke-jr> indeed, node policy isn't something BIPs should cover, except in the case of it being preparation for a softfork 01:36 < btcdrak> dcousens: only for segwit 01:36 < dcousens> or I suppose the question is targeted at the idea in general, would it be a soft-fork to reject all uncompressed keys? Or only uncompressed keys in witness scripts 01:36 < luke-jr> dcousens: only in witnesses; it'd break compatibility otherwise 01:37 < dcousens> ok 01:52 < gmaxwell> dcousens: I would be reasonable for a library to strongly discourage uncompressed keys in whatever ways it can do so without breaking things. 01:53 < dcousens> gmaxwell: indeed, defaults are almost all against it now anyway... but I think by the time that soft-fork came around, it'd be something I'd probably move into the "hard enough to do you have to do it manually" camp 01:53 < dcousens> rather than just flick a switch 01:55 < gmaxwell> we can't, unfortunately, get rid of uncompressed keys for non-segwit, as that would confiscate coins. But for segwit we can so long as it's clearly non-kosher from the start. 01:56 < dcousens> gmaxwell: hmmm, I suppose that is risky, but I can see some actors aggrevating the issue for agendas 01:58 < GitHub50> [bitcoin] fanquake opened pull request #8891: [Doc] Update bips.md for Segregated Witness (master...segwit-bips-md) https://github.com/bitcoin/bitcoin/pull/8891 01:58 < gmaxwell> dcousens: changing things for existing keys is just completely impratical ... people with random uncompressed keys printed out... coins paid to them.. no idea that the keys are uncompressed. 01:59 < dcousens> gmaxwell: I 100% agree its a good move, I just wonder if its worth delaying instead of policy for a short time... probably already discussed in the meeting, I'll look up the logs more in depth 02:00 < dcousens> delaying segwit* (and then putting it in that SF) 02:00 < gmaxwell> policy makes it safer. 02:00 < GitHub135> [bitcoin] laanwj opened pull request #8892: doc: Add build instructions for FreeBSD (master...2016_10_freebsd_build) https://github.com/bitcoin/bitcoin/pull/8892 02:00 < gmaxwell> even if its outright bard in SW some genius might still manage to send infinity coins to an invalid script 02:01 < gmaxwell> with it non-standard, they could coordinate with miners to rescue them. 02:01 -!- harrymm [~wayne@104.222.140.71] has joined #bitcoin-core-dev 02:02 < dcousens> gmaxwell: true, problematic from the start. I suppose it's just one of things that might need some big bold writing and dates 02:07 -!- harrymm [~wayne@104.222.140.71] has quit [Ping timeout: 252 seconds] 02:18 < wumpus> no, it's not worth delaying segwit 02:19 < wumpus> there will always be some last-minutes things that could have been slightly better, don't let them delay what is a great improvement 02:22 -!- harrymm [~wayne@104.222.140.125] has joined #bitcoin-core-dev 02:49 -!- cdecker [~quassel@2a02:aa16:1105:4a80:b16e:e2a4:ecd2:4483] has joined #bitcoin-core-dev 02:52 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection timed out] 02:53 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 03:05 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev] 03:36 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 03:36 < GitHub188> [bitcoin] laanwj closed pull request #8886: Add Arch Linux instructions to build-unix.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8886 03:37 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev 03:40 -!- JackH_ [~laptop@79-73-184-168.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 03:42 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Ping timeout: 265 seconds] 03:43 -!- JackH [~laptop@79-73-187-144.dynamic.dsl.as9105.com] has quit [Ping timeout: 244 seconds] 03:46 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev 03:47 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Client Quit] 04:07 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-buzlefooaisrebhm] has quit [Quit: Connection closed for inactivity] 04:17 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev 04:25 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 04:46 < wumpus> achow101: https://github.com/bitcoin/bips/pull/457 04:58 -!- cryptapus [~cryptapus@87.254.202.228] has joined #bitcoin-core-dev 04:58 -!- cryptapus [~cryptapus@87.254.202.228] has quit [Changing host] 04:58 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 04:58 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Client Quit] 04:58 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 05:00 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Client Quit] 05:00 -!- jtimon [~quassel@150.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 05:01 -!- cryptapus [~cryptapus@87.254.202.228] has joined #bitcoin-core-dev 05:01 -!- cryptapus [~cryptapus@87.254.202.228] has quit [Changing host] 05:01 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 05:12 -!- laurentmt [~Thunderbi@80.215.234.242] has joined #bitcoin-core-dev 05:19 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 05:32 -!- laurentmt [~Thunderbi@80.215.234.242] has quit [Quit: laurentmt] 05:44 < GitHub79> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f92805025d5b...223f4c2dd5fa 05:44 < GitHub79> bitcoin/master a78e542 Luke Dashjr: Bugfix: Trivial: RPC: getblockchaininfo help: pruneheight is the lowest, not highest, block 05:44 < GitHub79> bitcoin/master 223f4c2 Wladimir J. van der Laan: Merge #8884: Bugfix: Trivial: RPC: getblockchaininfo help: pruneheight is the lowest, not highest, block... 05:44 < GitHub78> [bitcoin] laanwj closed pull request #8884: Bugfix: Trivial: RPC: getblockchaininfo help: pruneheight is the lowest, not highest, block (master...trivial_pruneheight_help) https://github.com/bitcoin/bitcoin/pull/8884 05:48 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Quit: ZZZzzz…] 05:57 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 05:57 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 248 seconds] 05:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:04 -!- JackH_ [~laptop@79-73-184-168.dynamic.dsl.as9105.com] has quit [Quit: Leaving] 06:05 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 06:09 -!- laurentmt [~Thunderbi@80.215.234.242] has joined #bitcoin-core-dev 06:12 -!- cryptapus_ is now known as cryptapus 06:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 06:13 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:39 -!- waxwing [~waxwing@84.237.213.217] has joined #bitcoin-core-dev 06:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 06:47 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 06:54 -!- laurentmt [~Thunderbi@80.215.234.242] has quit [Quit: laurentmt] 06:55 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 248 seconds] 06:55 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:56 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 07:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds] 07:16 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Quit: Lost terminal] 07:28 -!- 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:37 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 07:38 -!- Netsplit *.net <-> *.split quits: achow101, Expanse, aalex, davec, sdaftuar, jl2012, Anduck, musalbas, Evel-Knievel, wasi, (+5 more, use /NETSPLIT to show all of them) 07:39 -!- Netsplit over, joins: Evel-Knievel 07:39 -!- Netsplit over, joins: arowser 07:39 -!- Netsplit over, joins: sdaftuar 07:39 -!- Netsplit over, joins: achow101 07:39 -!- Netsplit over, joins: wasi 07:39 -!- Netsplit over, joins: BashCo 07:39 -!- Netsplit over, joins: Anduck 07:39 -!- stan_ [~stan@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 07:39 -!- Netsplit over, joins: moli 07:40 -!- Netsplit over, joins: musalbas 07:41 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-dcfuldtvbzvidzxk] has joined #bitcoin-core-dev 07:41 -!- aalex [uid189135@gateway/web/irccloud.com/x-dnqefolnfficvtgp] has joined #bitcoin-core-dev 07:45 -!- ensign [~ensign@2001:41d0:8:d711::1] has joined #bitcoin-core-dev 07:48 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 07:53 -!- Expanse [sid146237@gateway/web/irccloud.com/x-jvzylqzqhogcfrbi] has joined #bitcoin-core-dev 08:07 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer] 08:07 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 08:25 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 08:26 -!- droark [~droark@199.167.24.131] has joined #bitcoin-core-dev 08:27 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection timed out] 08:32 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 08:35 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-core-dev 08:37 -!- laurentmt [~Thunderbi@80.215.234.242] has joined #bitcoin-core-dev 08:48 -!- laurentmt [~Thunderbi@80.215.234.242] has quit [Quit: laurentmt] 08:50 -!- Guest26311 is now known as bsm117532 08:53 -!- rubensayshi [~ruben@82.201.92.138] has quit [Remote host closed the connection] 08:53 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has left #bitcoin-core-dev [] 08:54 < Lauda> Any estimate for 0.13.1 yet? 08:56 < sipa> soon. 08:56 < instagibbs> Two Weeks(TM) 08:57 < sipa> TW 08:57 < sipa> not TM, i hope 08:57 < Lauda> I dislike the word soon as it can mean anywhere between now and sometime in the distant future. :P 08:57 < sipa> Lauda: that is exactly what it meams 08:57 < sipa> there are very few remaining issues 08:58 < achow101> Lauda: as soon as everything in the milestone is taken care of 08:58 < Lauda> tl;dr: Soon. 08:59 < Lauda> I've checked the milestone not long ago. 08:59 < achow101> they keep adding new stuff 09:00 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection timed out] 09:04 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection] 09:06 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 09:16 < cdecker> Soon is still better than 'eventually' :-) 09:32 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 09:34 < instagibbs> achow101, people can ask for milestone tags, may not happen tho 09:34 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 09:34 < instagibbs> a number have been pruned off already 09:39 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds] 09:44 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev 09:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 09:49 -!- xiangfu [~xiangfu@58.135.95.141] has quit [Ping timeout: 276 seconds] 09:49 -!- xiangfu [~xiangfu@58.135.95.141] has joined #bitcoin-core-dev 10:06 -!- laurentmt [~Thunderbi@80.215.234.242] has joined #bitcoin-core-dev 10:09 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] 10:10 -!- laurentmt [~Thunderbi@80.215.234.242] has quit [Client Quit] 10:12 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 10:16 -!- jtimon [~quassel@150.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds] 10:19 -!- droark [~droark@199.167.24.131] has quit [Quit: ZZZzzz…] 10:28 -!- droark [~droark@199.167.24.131] has joined #bitcoin-core-dev 10:31 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-eezigjlaavtmpnmx] has joined #bitcoin-core-dev 10:35 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 10:44 -!- droark [~droark@199.167.24.131] has quit [Quit: ZZZzzz…] 10:46 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has quit [Read error: Connection reset by peer] 10:46 -!- cryptapus_ [~cryptapus@66.119.84.15] has joined #bitcoin-core-dev 10:46 -!- cryptapus_ [~cryptapus@66.119.84.15] has quit [Changing host] 10:46 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 10:47 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-core-dev 10:50 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 252 seconds] 10:50 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 10:51 -!- shesek [~shesek@bzq-84-110-179-194.red.bezeqint.net] has joined #bitcoin-core-dev 10:52 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has joined #bitcoin-core-dev 10:53 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 272 seconds] 10:54 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev 10:55 -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Ping timeout: 272 seconds] 10:56 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Client Quit] 10:58 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 11:01 < cfields_> jonasschnelli: ping 11:02 -!- jouke [~jouke@unaffiliated/komkommer] has joined #bitcoin-core-dev 11:14 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 252 seconds] 11:15 -!- jtimon [~quassel@150.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 11:21 -!- ensign is now known as rexnsh 11:26 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 265 seconds] 11:31 < GitHub16> [bitcoin] jnewbery opened pull request #8894: [Testing] Include fRelay in mininode version messages (master...mininode-relay-field) https://github.com/bitcoin/bitcoin/pull/8894 11:35 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Ping timeout: 272 seconds] 11:40 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has quit [Ping timeout: 265 seconds] 11:47 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-core-dev 11:54 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 12:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 12:17 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 12:42 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] 12:52 -!- h1d [~h1d@unaffiliated/h1d] has joined #bitcoin-core-dev 12:54 -!- h1d [~h1d@unaffiliated/h1d] has quit [Client Quit] 12:59 -!- stan_ [~stan@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [] 12:59 -!- stan_ [~stan@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 13:04 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 265 seconds] 13:35 -!- alpalp [d86e4bba@gateway/web/cgi-irc/kiwiirc.com/ip.216.110.75.186] has joined #bitcoin-core-dev 13:44 -!- alpalp [d86e4bba@gateway/web/cgi-irc/kiwiirc.com/ip.216.110.75.186] has quit [Excess Flood] 13:44 -!- alpalp [d86e4bba@gateway/web/cgi-irc/kiwiirc.com/ip.216.110.75.186] has joined #bitcoin-core-dev 13:53 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev 13:54 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 13:58 -!- alpalp [d86e4bba@gateway/web/cgi-irc/kiwiirc.com/ip.216.110.75.186] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 14:10 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 14:19 -!- meowzus [~meowzus@bas8-hamilton14-2925006729.dsl.bell.ca] has joined #bitcoin-core-dev 14:26 -!- randy-waterhouse [~kiwigb@107.150.94.6] has joined #bitcoin-core-dev 14:26 -!- randy-waterhouse [~kiwigb@107.150.94.6] has quit [Changing host] 14:26 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 14:28 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 14:31 -!- shesek [~shesek@bzq-84-110-179-194.red.bezeqint.net] has quit [Ping timeout: 264 seconds] 14:32 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Read error: No route to host] 14:34 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 14:35 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection] 14:35 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 14:35 -!- shesek [~shesek@bzq-84-110-179-194.red.bezeqint.net] has joined #bitcoin-core-dev 14:38 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 14:51 < GitHub134> [bitcoin] JeremyRubin opened pull request #8895: Better SigCache Implementation (master...cuckoocache-pull-request) https://github.com/bitcoin/bitcoin/pull/8895 14:52 < jeremyrubin> \me \o/ 14:52 * jeremyrubin \o/ 14:53 < sipa> this is not \LaTeX 14:54 < gmaxwell> oh good. someone implement a Cuckoo Hash Table... now we need a lossy version and can get rid of those cahe destroying huge bloom filters we're using all over the place. 14:55 < jeremyrubin> sipa: latex irc plugin would be dope 14:56 < sipa> jeremyrubin: 14:56 < jeremyrubin> $\mu$'s eveywhere 14:56 < sipa> ỉţ ẅờữľđ çëřŧẩîńļŷ șïḿpľìƒỹ ẁřîŧīňğ ťẽxŧ ŵíţĥ ĺốţš ôƒ ďīäćŗìťĩčș 14:56 < jeremyrubin> gmaxwell: this is a lossy version 14:58 < gmaxwell> whats lossy about it? looks like if there is a collision you ripple, like an ordinary cuckoo hash. 14:58 < jeremyrubin> gmaxwell: once depth is reached, last thing touched goes bye-bye 14:58 < jeremyrubin> gmaxwell: no rehashing 14:59 < gmaxwell> Did you test if that optimization mattered? I think if makes a difference at all, your table is over populated and the performance will be poor. 14:59 < bsm117532> https://sourceforge.net/projects/pidgin-latex/ 15:00 < gmaxwell> (because if it makes a difference it means you are hitting the limit often, and if you're doing that you're probably doing it for almost every insert.) 15:00 -!- gmaxwell is now known as gmaxwell_ 15:01 -!- stan_ [~stan@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection] 15:01 -!- gmaxwell_ is now known as gmaxwell 15:01 < jeremyrubin> gmaxwell_: I tested many many optimizations... not that one because I have a fixed size table so rehashing can't help 15:02 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services] 15:02 -!- stan_ [~stan@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 15:02 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev 15:02 < jeremyrubin> gmaxwell: ^^^ 15:02 < gmaxwell> jeremyrubin: what you need to do if you hit the maximum then is go delete entries at random. 15:02 -!- drizztbsd is now known as timothy 15:02 < jeremyrubin> gmaxwell: I did however test with more hashes per entry (10) 15:03 < kanzure> is it correct that 8393 should be marked "needs backport" ? https://github.com/bitcoin/bitcoin/pull/8393#issuecomment-238783829 15:03 < gmaxwell> If you look at a cuckoo hash number of expected accesses as a function of table fullness, you get this behavior where it's basically 2 until the table is half full and then it shoots up like a rocket. 15:03 < jeremyrubin> Yeah 15:03 < jeremyrubin> so fortunately insert performance isn't a large priority 15:03 < sipa> with 3 hashes you can get to 90% full :) 15:03 < gmaxwell> So your depth limit means that you'll never hit it until you're too full, then you'll often hit it. 15:04 < jeremyrubin> and we'd rather spend the compute poking around the table looking for things that have been deleted than clear something that hasn't been deleted 15:04 < jeremyrubin> So the "eager-delete" strategy is a loser 15:04 < jeremyrubin> sipa: yes, but on a non-fixed memory system 15:04 < sipa> ? 15:05 < jeremyrubin> *non-fixed 15:05 < jeremyrubin> eg, you can get to 90% before needing a re-hash 15:05 < jeremyrubin> but we never increase memory size 15:05 < jeremyrubin> so we always get to 100% full 15:05 < jeremyrubin> it's just a matter of how fast 15:06 < jeremyrubin> There are gains to be made with more hashes/other things I agree. I'm pretty excited about some of them, but this is minimal & those all add some uneeded complexity 15:06 -!- stan_ [~stan@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Ping timeout: 252 seconds] 15:06 < gmaxwell> jeremyrubin: what is the depth limit you're using? 15:06 < jeremyrubin> log(size) 15:07 < gmaxwell> yea, so you're going to end up doing log() accesses on insert basically every time once its run long enough. 15:07 < jeremyrubin> Yeah that's fine 15:08 < jeremyrubin> We don't really care about insert performance (non-hot path) 15:08 < jeremyrubin> And we also do care about deleting things that have been erased preferentially (rather than randomly) 15:08 < jeremyrubin> so it's worth it. 15:10 < sipa> jeremyrubin: i see 15:11 -!- droark [~droark@209.226.201.248] has joined #bitcoin-core-dev 15:14 < jeremyrubin> besides, log2(40mb/32bytes per entry) ~~ 21 which is not trivial, but not huge by any means 15:15 < gmaxwell> it's a lot of random memory accesses. 15:16 < jeremyrubin> gmaxwell: I tested designs that did less random mem accesses and it wasn't terribly better for much added complexity 15:16 < jeremyrubin> gmaxwell: I'll float those later if this gets through review 15:17 < jeremyrubin> gmaxwell: for instance, one can split keys to an 8-bit tag and 258-bit main value, and do initial lookups on the tags. 15:18 < gmaxwell> what matters is the access, 1-64 bytes (and likely 1-128 bytes) will all end up being basically the same speed. 15:18 < jeremyrubin> gmaxwell: you can also do buckets of two hashes so that k can be stored at h0(k) & ~1 and h0(k) | 1. 15:18 < jeremyrubin> gmaxwell: wrong. l1/l2 matters at that size 15:19 < jeremyrubin> gmaxwell: you can also do linear probing style stuff with 64 entries per bucket (and say, 2 buckets per entry allowed) and 1 byte tags 15:19 < jeremyrubin> (I implemented and tested all of the above, none are a clear winner over the K.I.S.S. solution PR'd) 15:21 < sipa> (h0(k) & 1, h0(k) | 1) won't result in a cuckoo style behaviour, i think 15:22 < sipa> as the collisions are perfectly correlated 15:22 < gmaxwell> no, it won't. 15:22 < jeremyrubin> sipa: that's why you have two hashes still 15:22 < jeremyrubin> sorry if that was unclear 15:22 < sipa> ah, you mean in addition 15:22 < sipa> right 15:22 < jeremyrubin> yes 15:23 < gmaxwell> but this table doesn't really make use of cuckoo style behavior once it fills. 15:23 < sipa> you're turning each entry into a 2-way associativr cache 15:23 < gmaxwell> it just becomes a 2-way set assc cache. 15:23 < jeremyrubin> sure 15:24 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Read error: Connection reset by peer] 15:24 < jeremyrubin> gmaxwell: more or less the same thing 15:24 < sipa> what would be the effect if you greatly reduced the max iterations? 15:24 < jeremyrubin> less likely to find garbage on insert 15:24 < sipa> (in the otherwise kiss design) 15:25 < sipa> so why bother doing 21 iterations? 15:25 < gmaxwell> Well I'm saying this cuckoo table is a not one, at least once filled it's a two way set assc cache. I think you can probably make your insert behavior stop at the first collision once you're over some fullness threshold (like 90%) and you'll see performance improve. 15:26 < BlueMatt> remember: we really give 0 shits about insert performance....ATMP isnt our hot-path, and it just did sigchecks, so a bunch of lookups (even hitting memory) isnt all that bad 15:26 < gmaxwell> sorry if I didn't state it clearly above: this data structure is a cucokoo hash table that turns into a 2way set assc cache once it becomes overfull 15:26 < gmaxwell> BlueMatt: I'm also thinking about other places where we should use this. 15:26 < BlueMatt> ahh, ok, fair enough 15:26 < gmaxwell> And I care about the overall cpu usage of bitcoin, not just the block race. :) 15:27 < gmaxwell> it looks like great work too, I'm not being negative, just thinking it through. 15:27 < BlueMatt> ehh, doing a few more memory hits after doing ATMP checksigs isnt all that much too notice :p 15:27 < jeremyrubin> sipa: Finding garbage means finding a signature you don't need again (unless reorg) 15:27 < sipa> yes, in case it isn't clear, i'm just playing devil's advocate to understand 15:28 < jeremyrubin> sipa: finding !garbage means you delete something maybe valuable 15:28 < jeremyrubin> sipa: (yes :) ) 15:28 -!- shesek [~shesek@bzq-84-110-179-194.red.bezeqint.net] has quit [Ping timeout: 256 seconds] 15:28 < jeremyrubin> If i math'd right: (1-((5000/((float(40<<20)/(32.0+1.0/8))))))**21 15:28 < gmaxwell> though I wonder if its code complexity wouldn't be reduced by dropping the cuckoo behavior entirely... thats a question that depends on how full the cache is typically. 15:28 < jeremyrubin> == ~92% 15:28 < jeremyrubin> should be chance of deleting with this design 15:29 < jeremyrubin> gmaxwell: what is the cuckoo behavior? Eg, one hash location? 15:29 < gmaxwell> jeremyrubin: no, cuckoo behavior is the rippling insertion. 15:29 < jeremyrubin> gmaxwell: so not iterating at all? 15:29 < gmaxwell> In a plain 2way set assc cache, you'll probe both locations on insert and if both are full you'll evict one (at random or whatever). 15:29 < BlueMatt> gmaxwell: i think, here, thats motly there so that you can find entries marked deleted while rippling 15:30 < BlueMatt> if you didnt have the delete flags, probably 15:30 < gmaxwell> okay, I wasn't thinking about the delete flags, hows that work? 15:30 < BlueMatt> its the sigcache - we used to delete things while checking sigs in blocks 15:30 < BlueMatt> now they're marked for deletion in an atomic 15:30 < BlueMatt> so jeremyrubin's thing goes through and treats slots as empty if they have a delete flag on insert 15:30 < gmaxwell> I don't think that matters actually. 15:31 < BlueMatt> this has an interesting benifit of making it so that reorgs at the tip might use sigcache 15:31 < gmaxwell> When you go to insert, if either are free or marked delete, overwrite. 15:31 < gmaxwell> otherwise pick one and overwrite. 15:31 < gmaxwell> rippling at that point doesn't do you any good. 15:31 < gmaxwell> the other entries you would delete will get deleted when something tries to insert in them. 15:31 < jeremyrubin> yes it does? the next one might find a trash 15:32 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [] 15:32 < sipa> jeremyrubin: i see! 15:32 < gmaxwell> I don't. 15:32 < jeremyrubin> k1 and k2 sharing location X are highly unlikely to have another in common 15:32 < gmaxwell> If I insert k1 and one of its locations contains trash, I'll use that location. 15:33 < sipa> gmaxwell: if you iterate 21 times, you've had 21 independent chances of finding an empty/deleted position, so you don't need to evict anything potentially valua le 15:33 < gmaxwell> I don't need someone to have come in front of me and taken out the trash for me, I can do it then. 15:33 < jeremyrubin> eg, h1(k1) == h1(k2), unlikely h2(k1) != h2(k2) 15:33 < gmaxwell> sipa: yes; thats equal to saying that cuckoo is helpful if the table is not overfull. 15:34 < sipa> well, yes, but it won't be if many entries are marked deleted 15:34 < gmaxwell> which it is, but if the table is normally more than 50% full, it doesn't help. 15:34 < sipa> i think it can be way more than 50% full 15:34 < jeremyrubin> will always go to 100% full 15:35 < jeremyrubin> except after a block 15:35 < gmaxwell> which is what I said above... depending on how full the table is (and by full I am counting trash as deleted), this could just be a set assc cache with no loss in performance. 15:35 < sipa> if there are no deleted positions (or very few), agree 15:35 < jeremyrubin> there are n_sigops(last_block) empty slots 15:35 < BlueMatt> gmaxwell: by recursing you're less likely to throw out non-trash if there are delete positions available, this is esp true if you eg have blocks come in quickly in succession 15:35 < gmaxwell> sipa: not just 'very few'. The benefit of cuckoo drops of exponentially after 50%. 15:36 < gmaxwell> BlueMatt: not if the table is well over 50% full (deleted entries are not full in this measure). 15:36 < sipa> gmaxwell: i believe that if you're 90% full, you have a very high chance that a new insert will end up with you consuming an empty position 15:36 < jeremyrubin> This can be addressed by increasing hashes to 3 or 4 (or 10!) 15:36 < jeremyrubin> not fact 10 just 10 excitement 15:37 < BlueMatt> gmaxwell: indeed, though if you have quick blocks it means you're less full... 15:37 < gmaxwell> yes, the table can run fuller if there are more probes, but with a linear slowdown for your lookup. 15:37 < BlueMatt> as an aside: we could also add a few bits to indicate feerate for each entry, which would make the probing actually really matter 15:37 < sipa> BlueMatt: or age 15:37 < BlueMatt> or age 15:38 < jeremyrubin> Yep 15:38 < sipa> add generation numbers like the bloom filter cache 15:38 < jeremyrubin> Yep 15:38 < gmaxwell> sipa: I think you're overestimating it, when you're 90% full most entries end up in the posistion they're in because their sibling was alreaady full. 15:38 < jeremyrubin> Or like.. clear them on eviction 15:38 < sipa> gmaxwell: 0.9^21, no? 15:39 < gmaxwell> sipa: no, because the when you consider entry X the current member is more likely to be in X because its alternate Y is full. The sequence of tests are no longer independant. 15:39 < jeremyrubin> Wait what? 15:40 < gmaxwell> this is why the performance falls off so dramatically at over 50% full. 15:40 < jeremyrubin> That's only true if we prefer h0 over h1? 15:40 < BlueMatt> this is only true if your table is small compared to your iteration count? 15:41 < jeremyrubin> Also... so what! If it's really such a big deal we can just clear 50% of things out from this one 15:41 < jeremyrubin> and still be on par with existing :P 15:41 < gmaxwell> BlueMatt: I'm responding to sipa saying that the odds you fail to find a free entry in 21 hops is 0.9^21 15:41 < BlueMatt> gmaxwell: i mean it should be close 15:41 < sipa> gmaxwell: i don't understand 15:41 < sipa> gmaxwell: maybe we have different assumptions 15:42 < jeremyrubin> I agree with sipa 15:42 < jeremyrubin> my math was: ((1-((5000/((float(40<<20)/(32.0+1.0/8))))))**1) 15:42 < jeremyrubin> oops last one should be a 21 15:42 < BlueMatt> anyway, headed out, y'all figure it out and report back :P 15:42 < jeremyrubin> for a block clearing 5k things 15:43 < jeremyrubin> Gonna head out for some dinner; looking forward to hearing more of your thoughts. 15:43 -!- shesek [~shesek@bzq-84-110-55-54.red.bezeqint.net] has joined #bitcoin-core-dev 15:44 -!- cdecker [~quassel@2a02:aa16:1105:4a80:b16e:e2a4:ecd2:4483] has quit [Ping timeout: 252 seconds] 15:45 < jeremyrubin> gmaxwell: if you want I have a super templated version where you can enable/disable a ton of things... but it's quite unsightly and needs some bugfixes. 15:45 < gmaxwell> sipa: as a cuckoo hashtable fills, everythign initially starts out in it's h0 position. then you start getting collisions, when the table is way overfull, and you hit a collision (p=.9) then you look at that entry and go to put it in its alternate... but the reason it was in the entry you looked at was often because the alternate was already full. So the comparison you now make on the alternate 15:45 < gmaxwell> if >p=.9 even though the table is only 90% full overall. 15:48 < sipa> if evictions are independent from insertions (and evictions are responsible for all of the 10% empties), then i think any chain of entries up to 21 deep will have 0.9^21 chance to not have any evicted entries 15:48 < sipa> you're talking about a model where there are only insertions 15:49 < gmaxwell> okay, if we assume that the table is completely full, then evictions happen, then on your next insert I agree with you. 15:50 < gmaxwell> but on the insert after that the performance will be worse than 0.899^21 15:50 < sipa> right. 15:51 < sipa> the iterations are at fullness just a search for entries that were deleted after the chain being traversed was created 15:51 < sipa> and increasing the iteration count means you're willing to spend more time looking for those 15:52 < sipa> i'm not convinced that making this choice depend on the table size is the best choice 15:52 < sipa> but it looks simple and it works better than what we have 15:53 < gmaxwell> But a 2-way set assc cache would be even simpler. 15:54 < jeremyrubin> sipa: you could make the choice based on the number of sigops in the last block 15:54 < jeremyrubin> eg, st (1-empty%)^iter > .50 15:54 < gmaxwell> and at very full levels it will perform no worse, you give an argument which I can can buy that the complexity does improve performance, e.g. at the 90% full level. I dunno what level of fullness would be typical. 15:56 < gmaxwell> if the cache has 40MB of 32 byte entries. and a single block empties 4000 and before a new block arrives 4000 are added, then the low watermark would be 99.6% 15:56 < sipa> yeah, i think in optimal cases you want to artificially keep the fullness low 15:56 < gmaxwell> and 21 probes would be pretty unlikely to find a deleted entry. 15:57 < gmaxwell> meaning a plain 2way set assc would have performed just as well but with simpler code and 40x faster insertion. 15:57 < sipa> find some function of the fullness for the maximum number of iterations 15:57 < sipa> which is 1 when completely 15:57 < sipa> full 15:58 < sipa> jeremyrubin: can you efficiently keep track of fullness? 15:58 < gmaxwell> well what you want is something that is an insertion time tolerance, and when that tolerance would not be likely to yield an improvement, you just go 1 deep. 15:59 < sipa> it's a balance between chance of evicting a live entry and increasing fullness 15:59 < sipa> perhaps the max iterations should be 1 already at 90% 16:00 < sipa> and $TOLERANCE at 0% 16:00 < sipa> and some nifty fitted function in between 16:00 < gmaxwell> well the question you have is the marginal rate of return for each probe. 16:01 < gmaxwell> for low full levels the tolerance exists to prevent cycles. 16:02 < gmaxwell> the probably of going more than N times when you are M full, is negligible unless there is a cycle. 16:02 < gmaxwell> so thats normally where the max probe count (which then triggers a resize and/or rehashing of the whole time) in an ordinary cuckoo hash. 16:03 < gmaxwell> I'm sure tromp could tell us all about those probablities. :P 16:05 < sipa> there is an annoyong collision in my brain's cuckoo table between john trump and donald tromp. 16:06 < gmaxwell> ... just move one to its alternative location? 16:07 < gmaxwell> s/whole time/whole table/ 16:08 < gmaxwell> In any case, unless there is something surprising about fullness going on, with our current tables, I believe that setting the max depth to 1 (turning this into a 2way set assc cache) would not hurt block validation performance. 16:14 < gmaxwell> but a generation count could make it be effectively 50% free at all time, and then that argument goes out the window. 16:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 16:15 < jeremyrubin> you can cheaply do generations for cost of one bit 16:16 < gmaxwell> it would be fine to reduce the key size by a couple bits. 16:16 < jeremyrubin> hell, you can even replace marking garbage at all and just do generations 16:16 < jeremyrubin> gmaxwell: yeah I built a version like that 16:16 < jeremyrubin> you use the last bit/byte for flags 16:17 < gmaxwell> to be honest the keys could be 16 bytes, since the hash is privately salted... but at least with the old datastructure there wouldn't have been a huge performance improvement from that. 16:17 < jeremyrubin> If memory overhead is really a must 16:17 < jeremyrubin> gmaxwell: agree 100%, but I thought that wasn't reviewable 16:18 < gmaxwell> If we wanted the same code to work as a replacement for the bloom filter elsewhere we'd want to use the location xor trick, where other_index = this_index^H(key) ... this lets you use very small keys.. the original insert tries to go into index = H(bigger_key). 16:18 < gmaxwell> jeremyrubin: yea, I wouldn't bother but it would be good to know what performance we were leaving on the floor, if any. If it's a lot it would be worth considering. 16:20 < jeremyrubin> yeah; the nice thing is I think this patch is a nesc first step to trying out those designs; so my feeling is we should try to review this then such improvements can be measured 16:23 < jeremyrubin> I didn't try a version with half sized keys FYI.. figured proposing that would be DOA 16:23 < gmaxwell> it would only be an interesting proposal if it showed a big speedup, otherwise it's not worth trying to reason about the security. 16:24 < jeremyrubin> Also if we're going to 128 bit may as well do md5 or something if you really want things to go faster 16:24 < jeremyrubin> md5+salt should be just as secure 16:24 < jeremyrubin> (iirc) 16:25 < sipa> SipHash128. 16:25 < sipa> me ducks 16:26 < jeremyrubin> haha isn't that experimental tho 16:27 < jeremyrubin> but yeah computing the hashes is a hot path thing, so if one really wants to rice this sucker would make things faster 16:27 < jeremyrubin> (ComputeEntry called once per lookup) 16:31 < GitHub138> [bitcoin] randy-waterhouse opened pull request #8896: Update INSTALL landing redirection notice for build instructions. (master...master) https://github.com/bitcoin/bitcoin/pull/8896 16:31 < tunafizz> needs moar power al *grunt*grunt*grunt* 16:31 < gmaxwell> well if you want faster, using blake2b would be the same speed as md5, and keeping the ~32 byte output I wouldn't really have much to fuss about the security. 16:35 < tunafizz> needs the binford2000 hash al *grunt*grunt*grunt* 16:35 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev 16:38 < sipa> gmaxwell: 3 cycles per byte, damn... 16:48 -!- juscamarena [~jus@47.148.186.144] has joined #bitcoin-core-dev 17:19 -!- droark [~droark@209.226.201.248] has quit [Quit: ZZZzzz…] 17:23 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 17:24 -!- juscamarena [~jus@47.148.186.144] has quit [Ping timeout: 272 seconds] 17:24 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 17:28 -!- juscamarena [~jus@47.148.186.144] has joined #bitcoin-core-dev 17:28 -!- juscamarena [~jus@47.148.186.144] has quit [Read error: Connection reset by peer] 17:29 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 276 seconds] 17:37 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-eezigjlaavtmpnmx] has quit [Quit: Connection closed for inactivity] 18:02 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 18:04 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 252 seconds] 18:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 18:50 -!- baldur [~baldur@pool-72-69-25-42.nycmny.fios.verizon.net] has quit [Ping timeout: 272 seconds] 18:55 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 18:56 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 19:03 -!- baldur [~baldur@209.95.50.163] has joined #bitcoin-core-dev 19:06 < Dabs> uh. md5? isn't that "broken" ? 19:20 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 265 seconds] 19:24 -!- harrymm [~wayne@104.222.140.125] has quit [Ping timeout: 264 seconds] 19:26 < luke-jr> Dabs: not because of its speed 19:41 -!- randy-waterhouse [~kiwigb@150.242.131.38] has joined #bitcoin-core-dev 19:44 -!- harrymm [~wayne@104.222.140.117] has joined #bitcoin-core-dev 19:51 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 19:52 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 19:58 < jeremyrubin> Dabs: probably not if you use a unique secret salt 20:04 -!- randy-waterhouse [~kiwigb@150.242.131.38] has quit [Quit: Leaving.] 20:09 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 20:10 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 20:12 < Dabs> yeah, but ... you'll have to always justify using a "broken" primitive. ... anyway. I guess it depends on the purpose.. hmac md5 or something. 20:12 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 252 seconds] 20:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 20:18 < jeremyrubin> Dabs: I'm not seriously advocating using it... but it's really not broken in this use case. 20:18 < jeremyrubin> Dabs: For the same reason RIPEMD-160 is OK 20:19 < jeremyrubin> oops RIPEMD != RIPEMD-160 20:20 < jeremyrubin> Anyways, most of those collisions require the attacker to fully control both documents being hashed 20:20 < jeremyrubin> to collide their hashes 20:31 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 20:32 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 20:42 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 20:43 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 20:46 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev 20:48 < luke-jr> Dabs: MD5 is not a primitive of BLAKE2b, they just have similar speeds 20:55 -!- waxwing [~waxwing@84.237.213.217] has quit [Quit: Leaving] 21:03 -!- harrymm [~wayne@104.222.140.117] has left #bitcoin-core-dev [] 21:12 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 21:13 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 21:24 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 21:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 21:29 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 21:39 -!- jtimon [~quassel@150.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 265 seconds] 22:00 -!- dermoth [~thomas@dsl-66-36-135-108.mtl.aei.ca] has quit [Read error: Connection reset by peer] 22:01 -!- dermoth [~thomas@dsl-66-36-135-108.mtl.aei.ca] has joined #bitcoin-core-dev 22:14 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 22:26 -!- meowzus [~meowzus@bas8-hamilton14-2925006729.dsl.bell.ca] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 22:46 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 22:52 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 22:53 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 23:07 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 23:08 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 23:19 < wumpus> please don't use md5 in new code 23:19 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-dcfuldtvbzvidzxk] has quit [Ping timeout: 265 seconds] 23:19 < wumpus> it's, at its current level of brokenness still fine for some continuing legacy usages, but for new designs it should be avoided 23:22 < wumpus> there are modern fast and secure hash functions (indeed as BLAKE), and if speed trumps cryptographic security there are tons of other options 23:23 < wumpus> 23:23 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-khrlfyqrkwehnmwr] has joined #bitcoin-core-dev 23:45 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-khrlfyqrkwehnmwr] has quit [Ping timeout: 252 seconds] 23:50 -!- jeremias [~jeremias@kangasbros.fi] has joined #bitcoin-core-dev 23:52 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 23:52 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-ygpcmldnlitucofw] has joined #bitcoin-core-dev