--- Day changed Wed Jun 08 2016
00:17 -!- xiangfu [~xiangfu@58.135.95.136] has joined #bitcoin-core-dev
00:18 -!- ozanyurt [~ozanyurt@78.185.248.35] has joined #bitcoin-core-dev
00:19 -!- trippysa1mon [~trippy@cyberdynesys.org] has quit [Quit: leaving]
00:25 -!- adiabat [~adiabat@159.203.193.74] has joined #bitcoin-core-dev
00:46 -!- adiabat [~adiabat@159.203.193.74] has quit [Quit: Leaving.]
00:55 < jonasschnelli> wumpus: ParseInt does use int32_t and not uint32_t... isn't that a problem?
00:55 < wumpus> do you need the full range of uint32_t?
00:55 < jonasschnelli> nSequence is uint32_t i guess.
00:55 < wumpus> if so, we need a ParseUint32
00:56 < wumpus> I'll make one.
00:56 < jonasschnelli> Yes. I just saw that there are atoi in bitcoin-tx (before my change) and I just was "continue" that way. But I agree, re-using the ParseInt* stuff is better
00:56 < wumpus> do you need that atoi change in #8164 to 'unstuck' travis?
00:56 < jonasschnelli> yes.
00:57 < wumpus> ok
00:57 < wumpus> I'll just merge #8164 then
00:57 < jonasschnelli> yes.
00:57 < jonasschnelli> We can change it bitcoin-tx wide later
00:57 < wumpus> but we should move away from using low-level number parsing functions and use the ones in util where available
00:57 < wumpus> right
00:57 < jonasschnelli> There are servals atoi
00:57 < jonasschnelli> and even atoi64
00:58 < wumpus> the problem is that those functions don't have any error reporting, or range checking, etc
00:58 < wumpus> or if they do it's annoying to use
00:58 < wumpus> or even OS dependent
00:59 < GitHub30> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/79004d4ae671...0f24eaf253ab
00:59 < GitHub30> bitcoin/master 86efa30 Jonas Schnelli: [Bitcoin-Tx] fix missing test fixtures, fix 32bit atoi issue
00:59 < GitHub30> bitcoin/master 0f24eaf Wladimir J. van der Laan: Merge #8164: [Bitcoin-Tx] fix missing test fixtures, fix 32bit atoi issue...
00:59 < GitHub188> [bitcoin] laanwj closed pull request #8164: [Bitcoin-Tx] fix missing test fixtures, fix 32bit atoi issue (master...2016/04/rbf_base) https://github.com/bitcoin/bitcoin/pull/8164
01:01 < jonasschnelli> Yes. And sorry for the travis breaker...
01:01 < wumpus> I should have waited for travis before merging, I ran the test locally and assumed it'd be ok
01:03 < jonasschnelli> Yes. Did the same. Haven't though about 32bit issues. But great that we have Travis!
01:03 -!- blur3d [~blur3d@49.187.26.218] has joined #bitcoin-core-dev
01:03 < jonasschnelli> A failing travis is always a success. :)
01:03 < jonasschnelli> going to re-kick failed pulls
01:19 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 250 seconds]
01:27 < GitHub98> [bitcoin] laanwj opened pull request #8168: util: Add ParseUInt32 and ParseUInt64 (master...2016_06_parseuint) https://github.com/bitcoin/bitcoin/pull/8168
01:27 < wumpus> let's see if this one passes travis, what surprises windows has in store for us...
01:28 < gmaxwell> Great mysteries of the window--- who know what lies beyond it's curtain rimmed borders.
01:30 < sipa> the Window kingdom has been in decline for years
01:30 < wumpus> a perilous landscape full of traps and mines
01:33 < wumpus> "In locales other than the 'C' locale, other strings may be accepted.  (For example, the thousands separator of the current locale may be supported.)" ... oh crap, I thought strto* avoided the locale madness, I was wrong
01:34 < wumpus> why is it so difficult to have a number parsing function that does strict parsing and the set of inputs that it accepts is independent of geographical conditions
01:35 < wumpus> it's almost easier to just write one from scratch than use the C-provided functions
01:37 < wumpus> in any case using our own utility function makes it easier to swap it out later...
01:37 < gmaxwell> yea, there are actually a bunch of file formats that are befuxored by this... internationalization was bolted onto the standard library... so there aren't even normal locale independant functions, and you can't change the locale without potentially screwing up other threads.. (well there is the locale_t stuff, but not really portable yet AFAIK)
01:37 < wumpus> I can imagine - you need to be such a language lawyer to get these things rihgt
01:38 < wumpus> and yes it was bolted on in retrospect
01:39 < wumpus> I'm entirely for handling locales where it makes sense, but there's a place for simple deterministic parsing functions (network protocols, file formats) and a place for internationalized handling (such as GUIs), those don't really overlap
01:41 < gmaxwell> My general principle is to avoid strings in network protocols and file formats. :) but really, textual file formats are often fairly handy.
01:42 < wumpus> sure, but that's a completely orthogonal discussion, usually you don't get to choose
01:43 < wumpus> though passing binary numbers on the command line would be interesting :-)
01:45 < gmaxwell> just don't type anything with any zero bytes...
01:45 < wumpus> well wouldn't be the first time, passing addresses and code is very popular when trying to get setuid'ed executables to do eh non-standard things
01:46 < wumpus> yes, those are pesky
01:47 < gmaxwell> you mean, to do especially awesome things. :)
01:51 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev
01:52 < wumpus> exactly
01:52 < sipa> wumpus: binary numbers... as in head -n 10011101 file
01:56 -!- ozanyurt [~ozanyurt@78.185.248.35] has quit [Read error: Connection reset by peer]
01:56 < wumpus> binary, at the speed of one byte per bit!
01:56 -!- ozanyurt [~ozanyurt@78.185.248.35] has joined #bitcoin-core-dev
02:04 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
02:05 -!- ozanyurt [~ozanyurt@78.185.248.35] has quit [Read error: Connection reset by peer]
02:05 -!- ozanyurt [~ozanyurt@78.185.248.35] has joined #bitcoin-core-dev
02:19 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 240 seconds]
02:23 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev
02:29 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
02:45 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has joined #bitcoin-core-dev
02:47 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev
02:49 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Client Quit]
03:01 -!- xiangfu [~xiangfu@58.135.95.136] has quit [Ping timeout: 240 seconds]
03:09 -!- JackH [~Jack@79-73-185-113.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev
03:14 -!- xiangfu [~xiangfu@58.135.95.136] has joined #bitcoin-core-dev
03:25 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-hjwrojpksxoiknqt] has quit [Remote host closed the connection]
03:26 -!- xiangfu [~xiangfu@58.135.95.136] has quit [Ping timeout: 272 seconds]
03:40 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
03:45 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-ydfelyrcdvnymbvl] has joined #bitcoin-core-dev
03:57 < GitHub32> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/0f24eaf253ab...2156fa23b8ac
03:57 < GitHub32> bitcoin/master beceac9 Peter Todd: Disable the mempool P2P command when bloom filters disabled...
03:57 < GitHub32> bitcoin/master 3d3602f Jonas Schnelli: Add RPC test for the p2p mempool command in conjunction with disabled bloomfilters
03:57 < GitHub32> bitcoin/master 2156fa2 Wladimir J. van der Laan: Merge #8078: Disable the mempool P2P command when bloom filters disabled...
03:57 < GitHub78> [bitcoin] laanwj closed pull request #8078: Disable the mempool P2P command when bloom filters disabled (master...2016-05-mempool-p2p-and-bloom) https://github.com/bitcoin/bitcoin/pull/8078
04:02 < GitHub130> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/2156fa23b8ac...67c91f8c4cf7
04:02 < GitHub130> bitcoin/master c769c4a Gregory Maxwell: Avoid counting failed connect attempts when probably offline....
04:02 < GitHub130> bitcoin/master 6182d10 Gregory Maxwell: Do not increment nAttempts by more than one for every Good connection....
04:02 < GitHub130> bitcoin/master 67c91f8 Wladimir J. van der Laan: Merge #8065: Addrman offline attempts...
04:02 < GitHub45> [bitcoin] laanwj closed pull request #8065: Addrman offline attempts (master...addrman_offline_attempts) https://github.com/bitcoin/bitcoin/pull/8065
04:07 -!- edward [~edward@4angle.com] has joined #bitcoin-core-dev
04:08 -!- STAFFSCOINS_ [521b07f8@gateway/web/freenode/ip.82.27.7.248] has joined #bitcoin-core-dev
04:09 < GitHub196> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/67c91f8c4cf7...761cddb69029
04:09 < GitHub196> bitcoin/master 2e49448 Wladimir J. van der Laan: tor: Change auth order to only use HASHEDPASSWORD if -torpassword...
04:09 < GitHub196> bitcoin/master 761cddb Wladimir J. van der Laan: Merge #7703: tor: Change auth order to only use password auth if -torpassword...
04:10 < GitHub18> [bitcoin] laanwj closed pull request #7703: tor: Change auth order to only use password auth if -torpassword (master...2016_03_auth_order) https://github.com/bitcoin/bitcoin/pull/7703
04:13 -!- ozanyurt [~ozanyurt@78.185.248.35] has quit [Ping timeout: 264 seconds]
04:17 < MarcoFalke> wumpus: I have cherry picked the backports for .12 back in April: https://github.com/bitcoin/bitcoin/pull/7938 Hope this is helpful
04:17 < MarcoFalke> Also, I was wondering if we need any test framework backports
04:17 < sipa> i would say yes
04:17 < wumpus> MarcoFalke: thanks!
04:17 < MarcoFalke> i.e. segwit backport will be different due to missing py3 in .12
04:18 < sipa> i think 0
04:18 < sipa> i think 0.12 should be uograded to py3 as well
04:18 < wumpus> philosophy for the test framework should be: everything that can run against 0.12 should run against 0.12
04:18 < wumpus> agree with sipa
04:18 < sipa> of course, if a test requires an rpc that didn't exist in 0.12 yet
04:18 < wumpus> there is no reason to be exceedingly careful for regressions with backports of test changes
04:18 < sipa> then probably not
04:18 < MarcoFalke> Ok, will have a look tonight. Will be quite a huge diff.
04:19 < wumpus> yeah, no problem
04:19 < sipa> backporting tests never risks breakjng anything :)
04:19 < MarcoFalke> Will open a separate pull, just in case
04:19 < sipa> ... on the contrary, it may catch bugs in backports
04:20 < wumpus> agreed, better to do so in a separate PR, due to the difference in review density
04:21 < MarcoFalke> sipa: The python 3 switch for the segwit test was a single commit: https://github.com/sipa/bitcoin/commit/a7eeee1c07b5283c0984fcdaac04faac2d93b2e3. So in case I choke at backporting, you may as well not include those in the backport.
04:21 -!- ozanyurt [~ozanyurt@78.185.248.35] has joined #bitcoin-core-dev
04:28 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
04:30 < GitHub9> [bitcoin] jonasschnelli opened pull request #8169: OSX diskimages need 0775 folder permissions (master...2016/06/fix_gitian_osx) https://github.com/bitcoin/bitcoin/pull/8169
04:31 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds]
04:31 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
05:01 < GitHub172> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/761cddb69029...a7c41f2de03c
05:01 < GitHub172> bitcoin/master 1b9e6d3 Pieter Wuille: Add support for unique_ptr and shared_ptr to memusage
05:01 < GitHub172> bitcoin/master 8d39d7a Pieter Wuille: Switch CTransaction storage in mempool to std::shared_ptr
05:01 < GitHub172> bitcoin/master dbfb426 Pieter Wuille: Optimize the relay map to use shared_ptr's...
05:01 < GitHub0> [bitcoin] laanwj closed pull request #8126: std::shared_ptr based CTransaction storage in mempool (master...sharedmempool) https://github.com/bitcoin/bitcoin/pull/8126
05:02 < GitHub153> [bitcoin] laanwj closed pull request #7530: autogen.sh: check for libtool before automake fails to find it (master...libtool-check) https://github.com/bitcoin/bitcoin/pull/7530
05:14 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
05:15 < GitHub56> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/a7c41f2de03c...75ec320a0d53
05:15 < GitHub56> bitcoin/master faf82e8 MarcoFalke: [rpc] fundrawtransaction: Fix help text and interface
05:15 < GitHub56> bitcoin/master fa7f4f5 MarcoFalke: [rpc] fundrawtransaction feeRate: Use BTC/kB...
05:15 < GitHub56> bitcoin/master 75ec320 Wladimir J. van der Laan: Merge #8153: [rpc] fundrawtransaction feeRate: Use BTC/kB...
05:15 < GitHub172> [bitcoin] laanwj closed pull request #8144: [rpc] fundrawtransaction: Fix help text (master...Mf1606-rpcDoc) https://github.com/bitcoin/bitcoin/pull/8144
05:15 < GitHub0> [bitcoin] laanwj closed pull request #8153:  [rpc] fundrawtransaction feeRate: Use BTC/kB  (master...Mf1606-univalAny) https://github.com/bitcoin/bitcoin/pull/8153
05:21 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
05:24 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
05:25 < GitHub43> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/75ec320a0d53...6a034ed89891
05:26 < GitHub43> bitcoin/master 2b2d52e fanquake: [depends] Freetype 2.6.3...
05:26 < GitHub43> bitcoin/master 0385202 fanquake: [depends] ccache 3.2.5
05:26 < GitHub43> bitcoin/master bd3cbd5 fanquake: [depends] ZeroMQ 4.1.4
05:26 < GitHub64> [bitcoin] laanwj closed pull request #7993: [depends] Bump Freetype, ccache, ZeroMQ, miniupnpc, expat (master...depends-no-sourceforge) https://github.com/bitcoin/bitcoin/pull/7993
05:28 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:34 -!- murch [~murch@p4FE39057.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
05:38 -!- da2ce7_mobile [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 260 seconds]
05:40 -!- dermoth_ [~thomas@dsl-66-36-129-228.mtl.aei.ca] has joined #bitcoin-core-dev
05:40 -!- dermoth [~thomas@dial-216-221-43-121.mtl.aei.ca] has quit [Disconnected by services]
05:40 -!- dermoth_ is now known as dermoth
05:44 -!- da2ce7_mobile [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev
05:53 -!- fengling [~fengling@124.205.63.0] has joined #bitcoin-core-dev
05:55 < GitHub34> [bitcoin] sipa opened pull request #8170: Remove lookup-tx-by-utxo functionality (master...betternotxindex) https://github.com/bitcoin/bitcoin/pull/8170
06:13 -!- jarret [~jarret@162.216.46.142] has quit [Ping timeout: 260 seconds]
06:14 < jonasschnelli> Hmm....
06:15 < jonasschnelli> another cleanup required for one of my pulls..
06:15 < jonasschnelli> *sight*
06:16 < sipa> sight is good
06:16 < jonasschnelli> *sigh* :-)
06:17 < jonasschnelli> wumpus: can you extend your ParseUInt32 to univalue?
06:17 < wumpus> why would univalue need to parse unsigned 32 bit integers?
06:18 < jonasschnelli> createrawtransactions new sequence number input per vin does not support unsigned
06:18 < wumpus> we treat all integers as 64 bit signed
06:18 < jonasschnelli> So > 0x7FFFFFFF will be rejected.. :(
06:18 < wumpus> which should be enough to support the full 32 bit unsigned range
06:18 < jonasschnelli> It calls int UniValue::get_int() const
06:18 < jonasschnelli> which does a `if (!ParseInt32(getValStr(), &retval))`
06:18 < jonasschnelli> and throws > 0x7FFFFFFF
06:18 < wumpus> oh, just use the 64-bit one then
06:19 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]
06:19 < sipa> use get_int64(), and rangecheck the result
06:19 < wumpus> I don't think we should be adding more types of integers to JSON, that just complicates things
06:19 < jonasschnelli> Right... let me try
06:19 < wumpus> our previous JSON parsing library didn't even have a 32-bit signed integer get
06:25 -!- jtimon [~quassel@4.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
06:25 < jonasschnelli> should we allow -1 as sequence numbers? Pretty convenient.
06:28 < wumpus> wouldn't be very consistent if we do strict 32-bit unsigned int parsing for the -tx
06:29 < jonasschnelli> yes. Let me do a <0 check
06:30 < wumpus> I'd say sequence number is a positive value, and that should be enforced in the API; though -1 is convenient, negative numbers are slightly ambigious
06:31 < wumpus> we also print sequence numbers as unsigned int I hope?
06:32 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:37 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
06:38 < jonasschnelli> wumpus: at least decoderawtransaction does this correct.
06:39 < wumpus> good, thanks for checking
06:39 < jonasschnelli> heh: entry.push_back(Pair("sequence", (uint64_t)txin.nSequence));
06:39 < jonasschnelli> I guess UniValues has no uint32 pair?
06:40 < jonasschnelli> but (uint64_t)txin.nSequence is fine IMO
06:40 < wumpus> yea, please just use 64 bit signed integeres with JSON
06:41 < wumpus> there's no need to support other integer types - certainly not for output, for input a specific range checked get function could be mildly useful, but that probably belongs at the application (argument checking) side, not in univalue itself
06:44 < GitHub34> [bitcoin] jonasschnelli opened pull request #8171: [RPC] Fix createrawtx sequence number unsigned int parsing (master...2016/06/fix_crt) https://github.com/bitcoin/bitcoin/pull/8171
06:44 < GitHub123> [bitcoin] sipa pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/6a034ed89891...66ed450d771a
06:44 < GitHub123> bitcoin/master d3df40e Luke Dashjr: Implement BIP 9 GBT changes...
06:44 < GitHub123> bitcoin/master 72cd6b2 Luke Dashjr: qa/rpc-tests: bip9-softforks: Add tests for getblocktemplate versionbits updates
06:44 < GitHub123> bitcoin/master 9879060 Luke Dashjr: getblocktemplate: Explicitly handle the distinction between GBT-affecting softforks vs not
06:44 < GitHub100> [bitcoin] sipa closed pull request #7935: Versionbits: GBT support (master...gbt_bip9) https://github.com/bitcoin/bitcoin/pull/7935
06:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
06:45 < GitHub68> [bitcoin] sipa opened pull request #8172: Fix two warnings for comparison between signed and unsigned (master...fixunsigned) https://github.com/bitcoin/bitcoin/pull/8172
06:47 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
06:48 -!- jannes [~jannes@178.132.211.90] has quit [Remote host closed the connection]
06:52 < GitHub73> [bitcoin] laanwj opened pull request #8173: test: Add more test vectors for siphash (master...2016_06_siphash_testing) https://github.com/bitcoin/bitcoin/pull/8173
06:54 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
06:55 < GitHub7> [bitcoin] sipa closed pull request #8086: Use SipHash for node eviction (master...moresiphash) https://github.com/bitcoin/bitcoin/pull/8086
07:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:04 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
07:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
07:25 -!- _anthony_ [~anthony@ec2-54-164-183-56.compute-1.amazonaws.com] has joined #bitcoin-core-dev
07:26 < _anthony_> woohoo it's like I've built a time machine
07:26 < _anthony_> hello all
07:28 < _anthony_> BtcDrak said that I can be a core dev
07:28 < sipa> hello
07:28 < _anthony_> hi sipa
07:33 < achow101> _anthony_: anyone can be a "core dev". You just need to submit PRs to Bitcoin Core
07:34 < instagibbs> please don't forget review of PRs
07:34 < _anthony_> OK. What PRs do you want me to work on?
07:34 < _anthony_> Is there any internals documentation that needs to be worked on?
07:36 < wumpus> generally all PRs and issues that are open are fair game, of course reviewing segwit or compact blocks etc may be the most urgent
07:37 < instagibbs> when is freeze for 0.13
07:37 < wumpus> segwit: https://github.com/bitcoin/bitcoin/pull/8149  compact blocks: https://github.com/bitcoin/bitcoin/pull/8068
07:38 < wumpus> instagibbs: feature freeze is june 16
07:38 < wumpus> release schedule for 0.13.0: https://github.com/bitcoin/bitcoin/issues/7679
07:38 < instagibbs> I'll try and make time to review CB soon
07:39 -!- fengling [~fengling@124.205.63.0] has quit [Quit: WeeChat 1.4]
07:39 < _anthony_> hmm I definitely need to get more familiar with the way the code is layed out...maybe while reviewing segwit I can do that
07:39 < btcdrak> welcome  _anthony_
07:40 < instagibbs> _anthony_, that's a bear of a first PR to review :) 
07:40 < _anthony_> thanks btcdrak
07:40 < sipa> _anthony_: usually the best way to learn a codebase is by contributing yourself... find relatively simple improvements, and try to fix them
07:40 < sipa> _anthony_: reviewing changes to a codebase that you're not familiar with is not so effective i think
07:40 < _anthony_> I went through some of the open issues yesterday...it looks like some of them should be closed
07:41 < instagibbs> Writing tests can be good practice too.
07:41 < wumpus> _anthony_: that can certainly happen, feel free to let us know if that is the case
07:41 < _anthony_> k I'll keep a list next time I come across one
07:41 < wumpus> sometimes an issue is fixed but forgotten about, I tend to go over the full list at least monthly but some things slip through
07:54 -!- ozanyurt_ [~ozanyurt@178.162.216.49] has joined #bitcoin-core-dev
07:57 -!- ozanyurt [~ozanyurt@78.185.248.35] has quit [Ping timeout: 276 seconds]
08:02 -!- blur3d [~blur3d@49.187.26.218] has quit [Quit: blur3d]
08:39 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev
08:40 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Client Quit]
08:42 < GitHub12> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/66ed450d771a...cd0c5135ab22
08:42 < GitHub12> bitcoin/master 2d83013 Jonas Schnelli: Add support for dnsseeds with option to filter by servicebits
08:42 < GitHub12> bitcoin/master cd0c513 Pieter Wuille: Merge #8083: Add support for dnsseeds with option to filter by servicebits...
08:42 < GitHub53> [bitcoin] sipa closed pull request #8083: Add support for dnsseeds with option to filter by servicebits (master...2016/05/dnsfilter) https://github.com/bitcoin/bitcoin/pull/8083
08:44 < cfields_> jonasschnelli: great work on ^^
08:44 < sipa> petertodd, luke-jr: subtle ping to update your dns seeds to support service bits filtering
08:46 < jonasschnelli> cfields_: the bitcoin part was easy, the part on the bitcoin-seeder was more complex. :)
08:46 < jonasschnelli> Also code i'm not use to play around with.
08:47 < jonasschnelli> But as always, sipa made the important last changes/fixes. :)
08:47 < cfields_> jonasschnelli: yea, i took a quick look. steep learning curve there
08:50 < sipa> i wrote it in a week while i was ill
08:50 < sipa> certainly not the best code i've written :)
08:53 < cfields_> heh, well it's apparently pretty bullet-proof. can't argue with that :)
09:08 < cfields_> ok, I was trying to avoid this because i know everyone's busy with a dozen other things, but I'll be away for a while after Friday, and I'm hoping to get as much net refactor stuff as possible knocked out first...
09:08 < cfields_> so... review begs for #8128 and #8085
09:09 -!- aj [~aj@cerulean.erisian.com.au] has quit [Ping timeout: 244 seconds]
09:09 < cfields_> (and taking requests for anything I should prioritize before leaving)
09:10 -!- aj [aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev
09:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
09:33 < GitHub88> [bitcoin] sipa pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/cd0c5135ab22...4286f4302514
09:33 < GitHub88> bitcoin/master 053930f Patrick Strateman: Avoid recalculating vchKeyedNetGroup in eviction logic....
09:33 < GitHub88> bitcoin/master 9bf156b Pieter Wuille: Support SipHash with arbitrary byte writes
09:33 < GitHub88> bitcoin/master c31b24f Pieter Wuille: Use 64-bit SipHash of netgroups in eviction
09:33 < GitHub140> [bitcoin] sipa closed pull request #8173: Use SipHash for node eviction (cont'd) (master...2016_06_siphash_testing) https://github.com/bitcoin/bitcoin/pull/8173
09:54 < jonasschnelli> Is there a way within CWallet / CWalletTx to detect which of the tx.vout's is the change output if the wtx is a spend-to-myself?
09:55 < jonasschnelli> AddressBook lookup?
09:55 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
09:57 < luke-jr> yes
09:57 < jonasschnelli> So I need to solve the pubkey and check if its P2PKH (or different), get the CKeyID and do an addressbook lookup...
09:57 < jonasschnelli> hmm... not good. :)
09:58 < jonasschnelli> s/solve the pubkey/use the solver on the scriptPubKey to retrieve the address
09:58 < sipa> jonasschnelli: no, you convert to a CTxDestination and then check whether that's in the address book
09:59 < jonasschnelli> sipa: with ExtractDestination()?
09:59 < sipa> yes
09:59 < jonasschnelli> Okay.. that sounds feasible. 
10:02 < cfields_> sipa: wrt #7749, do we want to maybe filter the addresses we send in response to getaddr based on the current connection's common services? or maybe prioritize those somehow?
10:07 -!- jarret [~jarret@162.216.46.142] has joined #bitcoin-core-dev
10:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:10 -!- ozanyurt_ [~ozanyurt@178.162.216.49] has quit [Ping timeout: 264 seconds]
10:13 < jl2012> is it possible to use signrawtransaction to sign a multisig tx with flags other than SIGHASH_ALL?
10:15 < gmaxwell> Yes.
10:15 < gmaxwell> it takes an argument to set the flags it will sign with.
10:20 -!- Squidicuz [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
10:22 < NicolasDorier> sipa: long story short bytespersigop enforced in AcceptToMempool broke some use case on upper layer (https://github.com/bitcoin/bitcoin/issues/8079) we have a simple way to fix it, but it would require to count signatures for a transaction a second time accuratly.  Do you think it would be a problem performance wise ? I don't think so but maybe I am missing
10:22 < NicolasDorier> something.
10:24 < jl2012> gmaxwell: the sighash flag is the 4th argument. 1st argument is the unsigned tx. However, when I use [] [] as the 2nd and 3rd arguments, it fails to sign
10:25 < jl2012> without any optional arguments, it signs normally
10:25 < jl2012> btw i'm signing a P2SH-P2WSH
10:45 < NicolasDorier> oh whatever, I'm pretty sure it can't be a perf problem, as the second count is done only on a very specific case. nevermind
10:46 < sipa> NicolasDorier: i don't understand the solution you suggest
10:47 < NicolasDorier> sipa: Well basically bytespersig use GetLegacySigCount which overshoot multisig real signature count. Because of that, it broke an upper layer protocol (counteryparty)
10:47 < NicolasDorier> the solution
10:48 < NicolasDorier> would be "if(nSigOps > MAX_STANDARD_TX_SIGOPS)", then you count signature again accurately, and use such count for calculating if bytespersigop is reached or not
10:48 < sipa> heh, does counterparty still e ist
10:48 < sipa> i see
10:48 < sipa> that would work
10:49 < NicolasDorier> well, I'm not using it, but yeah it seems very much alive
10:49 < sipa> :(
10:49 < sipa> anyway, sounds like a good solution
10:49 < NicolasDorier> ok cool
10:53 < rubensayshi> counterparty uses it as fallback when > 80 bytes, which is 0.0x% or something
10:56 < gmaxwell> People involved with counterparty have told me they intend for counterparty to replace the bitcoin currency because the distribution of bitcoins is "unfair" and counterparty is "more equitable"-- I don't think it's accurate to describe it as an "upper layer" system, it's a system that explicitly is in competition with the bitcoin currency.
11:02 < sipa> NicolasDorier: your solution does not work, because it reintroduces the problem that the original PR was intended to fix
11:02 < sipa> NicolasDorier: the consensus rules count those as 20 sigops; if for mining purposes do not count it as 20, the attack reappears
11:04 < sdaftuar> sipa: doesn't the code as merged still allow for an attack, as you could fill up 400kb of block space with 20k sigops?
11:04 < sipa> sdaftuar: hmm?
11:05 < sipa> 20k sigops should be counted as 1 MB, no?
11:05 < sdaftuar> sorry i think i phrased poorly.  at 20bytes/sigop, you could hit the 20k sigops limit with only 400kb of transactions
11:05 < sipa> it should be 50 bytes/sigop
11:05 < sdaftuar> yes
11:06 < sdaftuar> unless there are valid use cases which we'd preclude, that is?
11:06 < sdaftuar> but regardless we should have had this discussion when that PR was merged.  i have no idea where 20 comes from
11:06 < sdaftuar> or what the valid use cases are...
11:06 < sipa> i think i assumed that number was the correct translation factor when it was merged
11:07 < sipa> but dropping transactions that go over the limit is wrong, i think
11:07 -!- Squidicuz [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has quit [Quit: Oh no, not again]
11:07 -!- Squidicuz [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
11:07 < sipa> we should just count them as if they were the correspondig size
11:07 -!- Squidicc [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
11:08 < sdaftuar> you mean for feerate purposes?
11:10 < gmaxwell> thats what I argued for forever but there was some reason people didn't like it... convert each limit to a feerate, and take the worst... under the approximation that whatever is worst will be the limiting factor.
11:10 < sdaftuar> that approximation doesn't hold in CreateNewBlock, most of the time, i'd think
11:11 < sdaftuar> most of the time you're nowhere near the sigops limit
11:11 < gmaxwell> it doesn't, but the size is the worst most of the time, so it doesn't matter except for excpetional transactions.
11:11 < sipa> yes, this is the nonlinear optimization problem again
11:11 < paveljanik> sipa, thanks for fixing the warnings!
11:11 < sipa> but if you use the same count for mining and for relay/priority, there is no problem i think
11:12 < sipa> at least you wouldn't lose money over it as a miner
11:12 < sdaftuar> well miners woulnd't be doing the optimal thing?
11:13 < helo> they'll intend to do the optimal thing, at least
11:13 -!- bsm1175321 [~mcelrath@38.121.165.30] has quit [Ping timeout: 246 seconds]
11:15 < sipa> sdaftuar: right, suboptimal, but not susceptible to losing a majority of yiur available block space
11:16 < gmaxwell> Suboptimal though only in the presence of transactions whos sigops cost would dominate their size cost.
11:16 < sdaftuar> yeah maybe that's good enough, and better than the status quo
11:19 < gmaxwell> It's my belief (and hope) that the other limits are set so high that they should never come into effect in practice.
11:19 < gmaxwell> (though this isn't true if people use bare multisig, but they mostly don't)
11:20 < sipa> the fact that this problem only got detected so many months after 0.12 shows that probably not many people use bare multisig...
11:23 < GitHub47> [bitcoin] laanwj opened pull request #8175: gitian: Add --disable-bench to config flags for windows (master...2016_06_disable_bench_windows) https://github.com/bitcoin/bitcoin/pull/8175
11:31 < rubensayshi> offtopic; gmaxwell, I've never heard any1 say counterparty competes with bitcoin, it's focus is tokens (and soon EVM), it would be insane to think it could compete with bitcoin (considering the reduced efficiency) 
11:32 < rubensayshi> sipa, I wouldn't find it odd if you guys would decide to block bare multisig from isstandard, but this check wasn't intended that way and the result did 
11:32 < rubensayshi> though there might be people still  using it, and I don't see it being isstandard as such a big problem
11:33 < sipa> rubensayshi: agree, i think there are good reasons to make it nonstandard, but it should happen intentionally and after communication, not as an unintended side effect
11:34 < rubensayshi> the consensus rules count bare multisig as 20 sigops, and considering it's part of consensus should continue to do so
11:34 < rubensayshi> I guess the reason why we don't properly count the sigops to begin with is because it's been part of consensus since day 1
11:35 < gmaxwell> it wasn't a part of consensus since day 1, </pedantic>
11:35 < rubensayshi> oh?
11:36 < sipa> i assume it was introeuced somewhere in 2010
11:37 < sipa> whether they were part of the consensus rules on day 1 is also irrelevant; what matters if they are part of consensus now :)
11:39 < rubensayshi> ok, but changing the `bytespersigop` check in AcceptToMempool to use `fAccurate=True` shouldn't be a problem right? 
11:40 < gmaxwell> that would defeat the fix against the bloat attack.
11:40 < gmaxwell> The counting has to work exactly as the consensus rule does.
11:42 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []
11:45 < rubensayshi> hmm, the consensus prevents a block being larger than 1mb or 20k sigops, so you don't want to accept any txs that would tip over the balance to reaching the 20k sigops before you'd reach 1mb?
11:46 < rubensayshi> as in; to optimize fees?
11:46 < gmaxwell> rubensayshi: thats right.. there was some attacker a while back flooding the network with transactions that used huge amounts of sigops, which would cause miners to needlessly produce small blocks.
11:47 < gmaxwell> there are multiple ways to address that.
11:47 < rubensayshi> ok so I guess I get sipa's point, because we rely on fee/size and not on sigops/size when that's higher 
11:48 -!- adiabat [~adiabat@159.203.193.74] has joined #bitcoin-core-dev
11:57 < rubensayshi> so there's no way to bring back bare multisig other than miners choosing to run with a lower `bytespersigop` (but you just said the default should be 50, not the current 20 to begin with) or changing the consensus rule where bare multisig is counted as 20 sigops?
11:57 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
11:58 < gmaxwell> the broken counting was a softfork added in sept 2010, in ~0.3.12. 
11:59 < rubensayshi> so the only valid option would be to improve selecting TXs for blocks in a way that it won't use TXs with high sigops/bytes if it would result in not having a full block so that the check doesn't have to be in the mempool policy
12:00 < rubensayshi> which is ... 
12:00 < rubensayshi> way to much complexity and too big of a task
12:02 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:04 < gmaxwell> 20 is more permissive than 50, fwiw.
12:04 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
12:04 < gmaxwell> there was a discussion on IRC about setting it, and 20 seemsed to be the lowest that it could be set without outright enabling that attack.
12:05 < sdaftuar> gmaxwell: pointer to the IRC conversation?  i looked and never found any discussion
12:05 < gmaxwell> rubensayshi: right, and generally we consider bare multisig undesirable for unrelated reasons too, and there is longstanding discussion toward moving to make it non-standard... so doesn't really justify a bunch of complexity to try to work around it.
12:06 < rubensayshi> I guess it should just be made non standard then
12:06 < rubensayshi> which it essentially is now
12:07 < rubensayshi> how about some extra bytes for opreturn then :P ?
12:09 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:10 < gmaxwell> sdaftuar: turns out searching for the number 20 is really hard.
12:10 < btcdrak> maybe sigop?
12:11 < btcdrak> gmaxwell: how about this? https://botbot.me/freenode/bitcoin-core-dev/2015-10-22/?msg=52464204&page=1
12:12 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
12:12 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
12:13 < btcdrak> another conversation starts here https://botbot.me/freenode/bitcoin-core-dev/2015-11-04/?msg=53446658&page=2 
12:13 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
12:14 < luke-jr> regardless of what we do to fix bytespersigop, I think we should disable bare multisig by default; with that in mind, *which* solution we go with seems less important
12:15 < luke-jr> (but IMO the better fix is to simply count CHECKMULTISIG correctly for this purpose, since the goal is spam prevention, and higher fees don't matter in that case)
12:15 < GitHub83> [bitcoin] luke-jr opened pull request #8176: [0.12.x]: Versionbits: GBT support (0.12...gbt_bip9-0.12.x) https://github.com/bitcoin/bitcoin/pull/8176
12:17 < luke-jr> rubensayshi: what happened to OP_RETURN counterparty?
12:17 < gmaxwell> it isn't about charging more fees, the whole attack was causing miners to produce needlessly small blocks because they thought sigopbloat txn were more attractive to produce than they were.
12:17 < gmaxwell> if an attacker had to pay as much to 'fill' a block that way as they would with ordinary transactions, then it's no longer an interesting attack vector.
12:17 < rubensayshi> luke-jr, literally 99.988% of CP txs are opreturn
12:18 < btcdrak> luke-jr: they use OP_RETURN for messages < 80 bytes which is most of them.
12:18 < luke-jr> rubensayshi: why not 100%?
12:18 < luke-jr> rubensayshi: is there a good way we could teach Core to identify CP OP_RETURN separate from spam OP_RETURN, so we can allow longer lengths for CP only?
12:19 < rubensayshi> is there a reason not to change isstandard to allow opreturn with more data?
12:19 -!- ozanyurt [~ozanyurt@78.185.248.35] has joined #bitcoin-core-dev
12:19 < rubensayshi> they dont polute utxo set and are prunable
12:19 < rubensayshi> and fee is paid for them
12:19 < gmaxwell> rubensayshi: Bitcoin is a currency not a public shared database.
12:19 < sipa> you're storing data on my disk, without benefitting me or the bitcoin ecosystem
12:20 -!- grubles_ [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev
12:20 < btcdrak> gmaxwell: what concerns me is if systems resort to bloating the UTXO with unspendable transactions as a way to encode >80 bytes.
12:20 < gmaxwell> btcdrak: they're not unspendable AFAIK.
12:20 < luke-jr> btcdrak: it seems they currently use spendable CHECKMULTISIGs
12:20 -!- ozanyurt_ [~ozanyurt@178.162.216.49] has joined #bitcoin-core-dev
12:20 < rubensayshi> the bare multisig are spendable btw
12:20 < luke-jr> 1-of-2 with the 2nd key up to 500 or so bytes
12:21 < gmaxwell> though if they were we should simply filter them out generally. 
12:21 < rubensayshi> that's the reason to use bare multisig, they're 1-of-3 and the 3rd key is a real key
12:21 < rubensayshi> the last resort is pubkeyhash encoding ...
12:21 < luke-jr> we could probably enforce a pubkey format for bare multisig even when they're enabled, but nobody afaik is legitimately using it, so might as well just disable it by default
12:22 < btcdrak> gmaxwell: pubkeyhash encoding is unspendable afaik
12:22 < luke-jr> pubkeyhash encoding can't do >80 bytes anyway?
12:22 < rubensayshi> yea
12:22 < rubensayshi> 100s of outputs ...
12:22 < luke-jr> -.-
12:22 < rubensayshi> all unspendable
12:22 < luke-jr> sigh, maybe we really do need p2sh^2 sooner rather than later
12:23 < rubensayshi> the bare multisig was perfect tbh, because we could clean the outputs
12:23 < btcdrak> it really is about the lesser of the evils. I would say a slightly larger OP_RETURN is preferable than unspendable junk
12:23 < rubensayshi> as a fallback to opreturn that is 
12:23 < luke-jr> [19:18:46] <luke-jr> rubensayshi: is there a good way we could teach Core to identify CP OP_RETURN separate from spam OP_RETURN, so we can allow longer lengths for CP only?
12:23 < gmaxwell> rubensayshi: you should have your own network, and stop storing data unrelated to bitcoin in the bitcoin network.
12:23 -!- ozanyurt [~ozanyurt@78.185.248.35] has quit [Ping timeout: 260 seconds]
12:23 < gmaxwell> The OP_RETURN as standard facility was intended to store _commitments_ not data.
12:23 < rubensayshi> luke-jr, is there a way you won't change that to drop all of them the next release xD?
12:24 < rubensayshi> gmaxwell, I'm just a script kiddie who dropped by a project that needed some work and sounded fun to do
12:24 < rubensayshi> I didn't come up with this stuff xD
12:24 < gmaxwell> rubensayshi: :)
12:24 < btcdrak> :D
12:24 < rubensayshi> I just get the bug reports
12:24 < gmaxwell> rubensayshi: but you could help rescue it. :)
12:24 < gmaxwell> Dare to dream.
12:25 < btcdrak> sidechains...
12:25 < rubensayshi> hehe
12:25 < gmaxwell> it's not even a 'sidechain'-- it's a seperate currency/asset tracking network. :)
12:25 -!- mkarrer [~mkarrer@3.red-83-55-151.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
12:25 < luke-jr> rubensayshi: believe it or not, the 0.12 thing was an accident in affecting CP
12:26 < gmaxwell> indeed, that wasn't intended. if we had intended to block CP then it would be blocked completely.
12:26 < rubensayshi> I gave you the benefit of doubt luke-jr, but not having any tests for it makes it look funky (I'll write some tests 2morrow for it!)
12:26 < adiabat> is there a recommended / reliable way to put this data in the witness stack?
12:26 < adiabat> it'd be nicer to have it there instead of in an OP_RETURN
12:26 < rubensayshi> would that be better?
12:27 < luke-jr> adiabat: it's probably better in OP_RETURN tbh
12:27 < gmaxwell> adiabat: it's not under a signature there, so it can be stripped in relay, unfortunately. 
12:27 < adiabat> yeah... 
12:27 < gmaxwell> There is no good place to store arbritary data, unfortunately.
12:27 < adiabat> you'd have to put like a hash of it in the output script, then put your 520 byte preimage in the witness
12:27 < rubensayshi> op_drop?
12:27 < luke-jr> gmaxwell: Factom! :P
12:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
12:27 < adiabat> heh
12:28 < gmaxwell> except via a _commitment_ in op_return and the data elsewhere, which was already whas op_return as standard was supposted to be.
12:28 < adiabat> op_2drop is even more efficient :)
12:28 < rubensayshi> if all my addresses would be P2SH I could put it in the scriptSig with an op_drop no? 
12:28 -!- grubles_ is now known as grubles
12:28 < gmaxwell> The problem with op_return is that the data still ends up in prued-nowit-sync and in SPV scans.  The problem with putting it in the witness is that it's not signed.
12:29 < gmaxwell> rubensayshi: sure you can, but any joker can strip it out of the transactions as they go past.
12:29 < adiabat> at some point someone should make like a p2pool backed merkle-branch-service
12:29 < rubensayshi> ah right
12:30 < adiabat> ~most of the data on the segnet4 blockchain is op_2drop witness items
12:30 < adiabat> nobody modified any of them :)
12:30 < gmaxwell> I think we should add some 'notes' facility, where people can publish data into a DHT(spit) with access rate limited by ownership of stationary txouts.  Then if they want commitments in op-returns great. We'd hoped people would build this for themselves, but building complex infrastructure isn't something many people do when there is a speculative asset they could be pumping instead.
12:31 < gmaxwell> adiabat: thats been done, it was called chronobit.
12:31 < gmaxwell> adiabat: yea, sure lots of things work for a while. :)
12:31 < adiabat> huh!  look at that.  and people use op_return instead...
12:31 < luke-jr> gmaxwell: the hard part there is proving ownership
12:32 < gmaxwell> luke-jr: you just write a non-minable transaction to perform your insert.
12:32 < luke-jr> gmaxwell: that involves key reuse :<
12:32 < gmaxwell> adiabat: utter refusal to use anything except the simplest possible thing. "This is why we can't have nice things".
12:32 < gmaxwell> luke-jr: so? not in a way that matters.
12:33 < gmaxwell> Key reuse isn't inherently bad. Reusing in dumb ways is.
12:33 < gmaxwell> If your alternative was to transact; then signmessaging is stricly superior.
12:33 -!- ozanyurt_ [~ozanyurt@178.162.216.49] has quit [Ping timeout: 260 seconds]
12:33 < adiabat> oh, semi-unrelated but, gmaxwell: remember the "bloom filter digest" post about a month ago on the mailing list
12:33 < luke-jr> there is zero risk of QC ever?
12:33 < adiabat> and you said, since you're not updating, there's better structures than bloom filters
12:34 < gmaxwell> luke-jr: it doesn't change anything wrt QC when your alternative was just transacting!
12:34 < luke-jr> transacting doesn't leave coins on the key ;)
12:34 < gmaxwell> adiabat: yes. 
12:34 < adiabat> gmaxwell: Do you know if anyone's working on that, or a BIP or anything?  It looked like it was from a troll account...
12:35 < gmaxwell> I don't think anyone is working on it right now.
12:35 < adiabat> I don't really want to commit to like "I'll work on that" because I might not have time but...
12:35 < adiabat> it seems so much nicer than the current merkle block stuff
12:35 < gmaxwell> adiabat: well would be good for you to, and if other people show up I can point them at you.
12:35 -!- ozanyurt [~ozanyurt@178.162.216.49] has joined #bitcoin-core-dev
12:35 < luke-jr> a better way IMO would be to use sign-to-contract to commit to another key, and use that key to sign the DHT publication
12:35 < gmaxwell> TBH, I'm a bit afraid to work on technology that I really like right now, because it'll just get attacked because I like it. :( 
12:36 < AaronvanW> "Do you guys know what the the latest up to date spec for stealth addresses is?" (asking for someone... who is asking for me.)
12:36 < gmaxwell> luke-jr: but then access to publish is people who don't have bitcoins anymore which would be kinda odd. :)
12:36 < adiabat> gmaxwell: heh yeah... do you have any links to the more efficient filters, like the binomial codec you linked to?
12:37 < luke-jr> gmaxwell: contracthash then? :P
12:37 -!- grubles is now known as dingus
12:38 < gmaxwell> adiabat: well the more efficient filter is just like a bloom but with a single hash function and large number of candidate positions, and then you compress the result, using your choice of optimal compressor for cases where the probablity of a 1 is very low
12:38 < gmaxwell> luke-jr: doesn't achieve your goal.
12:38 < luke-jr> hm
12:39 < gmaxwell> I wish I never pointed out that the use of hashed keys might harden a little against QC, it's vastly overestimated in performance. If we think that is at all a threat we need to be urgently migrating to secure schemes.
12:39 < luke-jr> MAST with a branch for payment vs message vs DHT-message :P
12:40 < gmaxwell> adiabat: So, for example, a simple range coder would work. rice coding might be reasonably efficient, or things like the binomial codec I linked to.
12:40 < gmaxwell> luke-jr: cute.
12:40 < adiabat> gmaxwell: so maybe start with the current murmur hash, and look at different compression encodings?
12:40 < luke-jr> gmaxwell: I consider it a useful property in that it doesn't cause QCs to take all old coins not being spent immediately. It does that, at least, no?
12:40 < gmaxwell> adiabat: or siphash 1-3.     Yes, thats possible.
12:41 < gmaxwell> adiabat: another newly trendy kind of data structure for this is a cuckoo filter, though for ideal use here you'd also need to compress it, though the compression could be simpler.
12:42 < gmaxwell> it might work better simply because it will be smaller in memory when matching.
12:42 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
12:42 < adiabat> gmaxwell: OK thanks, will look into it.  Probably can't work on it much, but it doesn't *feel* that hard... in fact feels simpler than the current merkle-blocks and then send txs stuff
12:42 < gmaxwell> Yes, it's simpler. I think fully elaborated out you could go very deep down a rabbit hole, but the basic idea is simple.
12:43 < adiabat> gmaxwell: the main design tradeoff seems to be the size of the block digest.  Too small and lots of false positives and people have to download lots of blocks.  Too big and you're spending a lot of space on the digest.
12:43 < gmaxwell> A cool thing about it is that it could be used before being commited, so people could try many different designs and explore the solution space pretty far.
12:44 < adiabat> yeah, could implement it on the p2p layer without any consensus changes
12:44 < gmaxwell> well you can also do things like multiple tiers, like a digest covering groups of 8 blocks, and a digest covering single blocks.. even digests covering parts of blocks. 
12:44 < adiabat> and the node could lie to you, but they can do that right now with bloom filters anyway
12:45 < adiabat> also feels like maybe a perverse incentive would be that you'd not want to make as many new addresses, as your false positive rate would go up and you'd have to download more...
12:45 < gmaxwell> the current system has that issue, these commited schemes have less of it.
12:46 < adiabat> yeah, basically nothing about it seems any *worse* than the current filter system
12:47 < gmaxwell> There are other totally different alternatives though, like PIR scan services, which I think we almost have enough in bitcoin core to support as a purely external add on.
12:48 < adiabat> PIR scans would be better but also seems more complex...
12:48 < gmaxwell> much more complex, though a lot of the heavy lifting has been done by other people (percy++)
12:48 < adiabat> not that people shouldn't do it, but I feel like I could reasonably get a block digest to work, but getting a PIR system seems more .. innovative :)
12:49 < gmaxwell> hah
12:49 < gmaxwell> I only bring it up in the hope that someone will be foolish enough to think it easy.
12:49 < gmaxwell> Though actually I think they're more similar in difficulty than you think... in both cases the details are what get you.
12:50 < adiabat> yeah, I guess with the digest, you can get something working even if the details are wrong and it works sub-optimally
12:50 < adiabat> with PIR, well... I guess you wouldn't really know if it was horribly broken and revealed everything that you were requesting
12:51 < gmaxwell> PIR is straight forward: there is existing software that lets you have a {key, value} database and query it privately.  Take the existing utxo set, order by address, for every txout for each address, generate a txout proof (gettxoutproof rpc), for it. ... now thats your database.  People query it with each of there addresses, and import the results into the wallet after verifying the proofs. Tad
12:51 < gmaxwell> a.
12:52 < gmaxwell> The reality is less simple, because different addresses have (vastly) different numbers of txouts connected with them.. so you have to have some way of handling it.
12:53 < gmaxwell> Probably the thing to do is take all the txouts for each address and make the keys  key, key_2, key_3, key_4... for each of them.  and have the first key tell you how many txouts there are in total.
12:53 < gmaxwell> Though that still will have some inefficiency since the txoutproof has the whole transaction paying you in it, so they'd all need to be padded up to a constant (large size).
12:54 < gmaxwell> and maybe the inefficiency of all that makes it unreasonable to use.
12:55 < adiabat> yeah... also percy++ looks a little scary to work with in that I don't think there's a lot of real world implementations using it right now
12:56 < adiabat> wheras the block digest idea just jumps out as like "Oh yeah that'll work!"
12:56 < gmaxwell> Right.  Well most people have no desire,  "keep user data private? but then how will we sell it?" :)  a positive point is that the academics working on it are actually competent programmers too (not always the case)... so I think it's likely to not be a software engineering disaster (and it's always worked right when I've messed around with it)
12:56 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 250 seconds]
12:57 < adiabat> yeah I looked at percy++ a year or two ago and it does seem to be well made
12:57 < gmaxwell> adiabat: indeed, it will, though less private!  it's also not exclusive with using PIR.. a simpler way to use PIR would be to use it to fetch the whole blocks you're going to fetch.
12:58 < adiabat> I guess I'm also not just looking at it from a privacy perspective, though that's a big part of it
12:58 < gmaxwell> ::nods::
12:58 < adiabat> with LN channels, a false negative can be a big problem
12:58 < gmaxwell> the existing bloom stuff is just broken on a bunch of levels.
12:59 < adiabat> yeah, if the node you're asking to filter for you omits the tx where someone closes a channel incorrectly, you might not know and lose coins
12:59 < gmaxwell> it's vulnerable to attack both from data hiding and from denial of service, its resource intensive, .. strongly discourages  single use addresses.. quite non-private... 
12:59 < adiabat> oh and the merkle-block data structure is... weird...
13:00 < adiabat> and then it sends the txs, unrequested
13:00 < _anthony_> bitcoin satellites are definitely the way to go
13:01 < gmaxwell> yea, a side effect of the bitcoin protocol having no mechensim to just fetch txn already in blocks, which has a good reason for it (among other things, it helps keep the network from being abused as a file trading DHT)
13:01 < gmaxwell> BIP152 actually adds a sutiable mechenism-- getblocktxn that fetches txn in a block by index, that only works for recent blocks.
13:05 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
13:07 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
13:08 -!- Squidicc [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has quit [Quit: Oh no, not again]
13:11 < sipa> my train internet connection is too weak to actually visit github.com, but can someone see if https://github.com/sipa/bitcoin/commits/dogcgit renerders nicely?
13:15 < gmaxwell> sipa: 404.
13:15 < paveljanik> sipa, yes, looks nice - https://github.com/bitcoin/bitcoin/compare/master...sipa:docgit
13:15 < gmaxwell> https://github.com/sipa/bitcoin/commits/docgit maybe
13:20 < sipa> yes indeed; thanks!
13:21 < GitHub146> [bitcoin] kazcw opened pull request #8177: developer notes: deprecate C-style casts (master...no-c-casts) https://github.com/bitcoin/bitcoin/pull/8177
13:35 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
13:38 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
14:02 -!- adiabat [~adiabat@159.203.193.74] has quit [Quit: Leaving.]
14:16 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
14:23 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 260 seconds]
14:26 -!- JackH [~Jack@79-73-185-113.dynamic.dsl.as9105.com] has quit [Ping timeout: 258 seconds]
14:40 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
14:42 < luke-jr> can someone reopen https://github.com/bitcoin/bitcoin/pull/5872 so I can push to it (addressing unreviewability concerns)?
15:31 -!- xiangfu [~xiangfu@124.207.50.216] has joined #bitcoin-core-dev
15:32 < frankenmint> heh, rusty russel also invented modprobe
15:32 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:32 < gmaxwell> Someday we'll forgive him.
15:41 < luke-jr> XD
15:41 < sipa> and if not, we'll xkcd538 him with a 5 AUD rusty wrench
15:41 < luke-jr> sipa: ^ 1 hr ago
15:42 < GitHub126> [bitcoin] sipa reopened pull request #5872: configure: BITCOIN_SUBDIR_TO_INCLUDE: Improve compatibility with paths including space and multiline cpp output (master...subdir_incl_compat) https://github.com/bitcoin/bitcoin/pull/5872
15:42 < luke-jr> thx
15:44 < luke-jr> hopefully that's finally reviewable
15:48 -!- mkarrer [~mkarrer@3.red-83-55-151.dynamicip.rima-tde.net] has quit []
15:50 -!- mkarrer [~mkarrer@3.red-83-55-151.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
15:51 < sipa> luke-jr: i'm not sure i understand the problem it os trying to address
15:51 < sipa> you say it is biggy
15:52 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 264 seconds]
15:52 < sipa> how does that manifest?
15:53 < luke-jr> sipa: I think mostly paths with spaces failing
15:54 < sipa> ah
16:06 < GitHub106> [bitcoin] sipa opened pull request #8178: Add git and github tips and tricks to developer notes (master...docgit) https://github.com/bitcoin/bitcoin/pull/8178
16:09 -!- xiangfu [~xiangfu@124.207.50.216] has quit [Ping timeout: 240 seconds]
16:16 < btcdrak> sipa: more gitfu please
16:17 -!- xiangfu [~xiangfu@124.207.50.216] has joined #bitcoin-core-dev
17:09 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 252 seconds]
17:13 < dgenr8> adiabat: bloom filter digests would be great, but won't kill off connection bloom filters. people want to see unconfirmed activity
17:16 < gmaxwell> dgenr8: the addition of filtering the current transactions was a 12th hour addition to BIP37, and for many users saving an average of 13kbit/sec for a total loss of privacy is not all that interesting just to see unconfirmed transactions that their wallets can't even tell are at all remotely possily correct.
17:23 < dgenr8> gmaxwell: so you think wallet should be watching all live tx, or none, or "either of those, just not filtered"?
17:24 < gmaxwell> Or filtered, it's the wallets call. The exact behavior depends on the specific use case, and I think the specific use case for filtered is fairly narrow.
17:25 < gmaxwell> If the digests idea had come up at the time of BIP37, I think it would have been implemented and filtering of relayed transactions wouldn't have been.
17:28 -!- blur3d [~blur3d@49.187.26.218] has joined #bitcoin-core-dev
17:31 -!- xiangfu [~xiangfu@124.207.50.216] has quit [Remote host closed the connection]
17:32 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Ping timeout: 244 seconds]
17:32 < dgenr8> one use case is "i'm told a tx was broadcast that pays me. i wonder if that's true"
17:33 -!- murch [~murch@p4FE39057.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
17:37 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev
17:49 -!- raedah [~x@172.58.41.91] has joined #bitcoin-core-dev
18:01 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hgnnnqixfhtduefi] has quit [Quit: Connection closed for inactivity]
18:05 -!- dermoth [~thomas@dsl-66-36-129-228.mtl.aei.ca] has quit [Read error: Connection reset by peer]
18:05 -!- dermoth [~thomas@dsl-66-36-129-228.mtl.aei.ca] has joined #bitcoin-core-dev
18:25 < gmaxwell> P2Pool is updated for CSV.
18:35 -!- dermoth [~thomas@dsl-66-36-129-228.mtl.aei.ca] has quit [Read error: Connection reset by peer]
18:35 < luke-jr> it needed updating?
18:35 < luke-jr> oh, because peers need to police each other
18:36 -!- dermoth [~thomas@dsl-66-36-129-228.mtl.aei.ca] has joined #bitcoin-core-dev
18:45 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds]
18:48 < gmaxwell> also because it compensates for lack of softfork flags on gbt by not signaling higher versions than p2p knows about.
18:50 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev
18:52 < GitHub140> [bitcoin] gmaxwell opened pull request #8179: Evict orphans which are included or precluded by accepted blocks. (master...reap_orphans) https://github.com/bitcoin/bitcoin/pull/8179
19:02 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Read error: Connection reset by peer]
19:02 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
19:14 -!- JackH [~Jack@79-73-185-113.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev
19:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
19:21 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer]
19:22 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
19:24 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
19:56 < luke-jr> gmaxwell: ah, right
20:04 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 252 seconds]
20:04 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
20:09 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Quit: Leaving]
20:40 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
20:43 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
21:02 -!- adiabat [~adiabat@159.203.193.74] has joined #bitcoin-core-dev
21:20 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
21:23 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
21:27 -!- jtimon [~quassel@4.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]
21:28 -!- _anthony_ [~anthony@ec2-54-164-183-56.compute-1.amazonaws.com] has quit [Quit: WeeChat 1.3]
21:47 < iniana> Will miners who don't upgrade get their blocks orphaned immediately once the grace period is over (by not signalling the activated bit) or only when they mine an invalid block?
22:04 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
22:08 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 250 seconds]
22:13 < GitHub77> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/4286f4302514...19ea17302e8f
22:13 < GitHub77> bitcoin/master b676f38 Cory Fields: depends: allow for CONFIG_SITE to be used rather than stealing prefix...
22:13 < GitHub77> bitcoin/master ad38204 Cory Fields: gitian: use CONFIG_SITE rather than hijacking the prefix
22:13 < GitHub77> bitcoin/master 7e7eb27 Cory Fields: gitian: create debug packages for linux/windows...
22:13 < GitHub1> [bitcoin] laanwj closed pull request #8167: gitian: Ship debug tarballs/zips with debug symbols (master...split-debug) https://github.com/bitcoin/bitcoin/pull/8167
22:21 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
22:22 -!- xiangfu [~xiangfu@124.207.50.216] has joined #bitcoin-core-dev
22:23 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-easiufkhpvlcwnew] has quit [Ping timeout: 250 seconds]
22:23 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-bklkwwnwdzpcxxrm] has quit [Ping timeout: 250 seconds]
22:23 < GitHub156> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/19ea17302e8f...f0299d80fd42
22:23 < GitHub156> bitcoin/master 74c1347 Wladimir J. van der Laan: gitian: Add --disable-bench to config flags for windows...
22:23 < GitHub156> bitcoin/master f0299d8 Wladimir J. van der Laan: Merge #8175: gitian: Add --disable-bench to config flags for windows...
22:23 < GitHub5> [bitcoin] laanwj closed pull request #8175: gitian: Add --disable-bench to config flags for windows (master...2016_06_disable_bench_windows) https://github.com/bitcoin/bitcoin/pull/8175
22:23 -!- limpkin [sid20909@gateway/web/irccloud.com/x-xjelfruunysnfquh] has quit [Ping timeout: 250 seconds]
22:24 -!- mturquette [sid66043@gateway/web/irccloud.com/x-tonmxfrnhdbtsvee] has quit [Ping timeout: 250 seconds]
22:24 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-wquwuvlsxmjoyfwg] has joined #bitcoin-core-dev
22:24 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-smnnxrrffnwagcuu] has quit [Ping timeout: 272 seconds]
22:24 -!- eragmus [sid136308@gateway/web/irccloud.com/x-uoanbfeasmaacjrb] has quit [Ping timeout: 272 seconds]
22:25 -!- zmanian__ [sid113594@gateway/web/irccloud.com/x-jwjzkiwinnrrktcn] has quit [Ping timeout: 272 seconds]
22:25 -!- binns [sid105317@21/bitcoin/binns] has quit [Ping timeout: 272 seconds]
22:25 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-ccvntfpdqxcuyisf] has quit [Ping timeout: 260 seconds]
22:26 < gmaxwell> iniana: the latter
22:27 < GitHub35> [bitcoin] luke-jr opened pull request #8180: Update luke-jr's PGP key (master...2016_pgp_update) https://github.com/bitcoin/bitcoin/pull/8180
22:28 -!- eragmus [sid136308@gateway/web/irccloud.com/x-mychxenjvjpxdhtq] has joined #bitcoin-core-dev
22:28 < gmaxwell> or even "if" not when, these txn are non-standard, so they won't likely mine them
22:28 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-evanvuyqmmatdbiw] has joined #bitcoin-core-dev
22:28 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-awexuyjvnxxyzgta] has joined #bitcoin-core-dev
22:29 < GitHub0> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f0299d80fd42...7e6dd7bee479
22:29 < GitHub0> bitcoin/master 77f63a4 Pieter Wuille: Fix two warnings for comparison between signed and unsigned
22:29 < GitHub0> bitcoin/master 7e6dd7b Wladimir J. van der Laan: Merge #8172: Fix two warnings for comparison between signed and unsigned...
22:29 < GitHub101> [bitcoin] laanwj closed pull request #8172: Fix two warnings for comparison between signed and unsigned (master...fixunsigned) https://github.com/bitcoin/bitcoin/pull/8172
22:30 -!- binns [sid105317@21/bitcoin/binns] has joined #bitcoin-core-dev
22:31 -!- mturquette [sid66043@gateway/web/irccloud.com/x-fvivsmhlblfvefbw] has joined #bitcoin-core-dev
22:32 < gmaxwell> Thanks. those have been bothering me.
22:32 -!- limpkin [sid20909@gateway/web/irccloud.com/x-gvcngrgcudbwdmty] has joined #bitcoin-core-dev
22:33 < luke-jr> ☺
22:33 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-awexuyjvnxxyzgta] has quit [Ping timeout: 272 seconds]
22:33 -!- zmanian__ [sid113594@gateway/web/irccloud.com/x-btoxsexdzqtodijk] has joined #bitcoin-core-dev
22:35 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-oqxparktabjyaloh] has joined #bitcoin-core-dev
22:36 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-rrhdatankybciwnl] has joined #bitcoin-core-dev
22:37 < GitHub102> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7e6dd7bee479...d36618585de6
22:37 < GitHub102> bitcoin/master e012f3c Wladimir J. van der Laan: util: Add ParseUInt32 and ParseUInt64...
22:37 < GitHub102> bitcoin/master d366185 Wladimir J. van der Laan: Merge #8168: util: Add ParseUInt32 and ParseUInt64...
22:37 < GitHub92> [bitcoin] laanwj closed pull request #8168: util: Add ParseUInt32 and ParseUInt64 (master...2016_06_parseuint) https://github.com/bitcoin/bitcoin/pull/8168
22:40 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has quit [Remote host closed the connection]
22:40 -!- xiangfu [~xiangfu@124.207.50.216] has quit [Remote host closed the connection]
22:49 -!- frankenmint [~frankenmi@67-5-211-132.ptld.qwest.net] has joined #bitcoin-core-dev
23:07 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-rrhdatankybciwnl] has quit [Ping timeout: 250 seconds]
23:08 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-oqxparktabjyaloh] has quit [Ping timeout: 250 seconds]
23:10 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-dsayumsjmsgievvv] has joined #bitcoin-core-dev
23:13 < GitHub168> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d36618585de6...1445835bd3c4
23:13 < GitHub168> bitcoin/master d3d02d5 Kaz Wesley: drop vAddrToSend after sending big addr message...
23:13 < GitHub168> bitcoin/master 1445835 Wladimir J. van der Laan: Merge #8154: drop vAddrToSend after sending big addr message...
23:13 < GitHub102> [bitcoin] laanwj closed pull request #8154: drop vAddrToSend after sending big addr message (master...drop-vAddrToSend) https://github.com/bitcoin/bitcoin/pull/8154
23:20 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-hedqbgygvgdalojh] has joined #bitcoin-core-dev
23:25 < GitHub197> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1445835bd3c4...0b5279f89c9a
23:25 < GitHub197> bitcoin/master c2715d3 Pavel Janík: Do not shadow local variables
23:25 < GitHub197> bitcoin/master 0b5279f Wladimir J. van der Laan: Merge #8166: src/test: Do not shadow local variables...
23:25 < GitHub194> [bitcoin] laanwj closed pull request #8166: src/test: Do not shadow local variables (master...20160607_shadowing_tests) https://github.com/bitcoin/bitcoin/pull/8166
23:28 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
23:36 < GitHub92> [bitcoin] laanwj closed pull request #7398: Improve seed generation script for clarity (master...contrib-seeds) https://github.com/bitcoin/bitcoin/pull/7398