--- Day changed Thu Nov 12 2015
00:00 < wumpus> it may just have a hard time finding a working .onion peer here try this one: nns4r54x3lfbrkq5.onion
00:13 < MarcoFalke> It only connects to  nkf5e6b7pl4jfd4a.onion (TheBlueMatt)
00:14 < wumpus> ok, in that case it's at least not censorship, if it can connect to one onion it can in principle connect to all without your ISP knowing anything
00:18 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
00:26 -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Quit: Leaving]
00:26 < MarcoFalke> I don't have to set `-proxy=127...`?
00:26 < wumpus> you do have to set a proxy
00:26 < wumpus> otherwise it won't know how to connect to onions
00:26 < MarcoFalke> Right now I am doing `-onlynet=onion  -torpassword=`
00:26 < MarcoFalke> and I can `-connect=` to it
00:27 < MarcoFalke> but not sync
00:27 < wumpus> it isn't able to derive the Tor proxy from the control port. Maybe this is possible, but it is not implemented.
00:28 < MarcoFalke> I am doing `-connect=moheur3skn7jbca4.onion   -proxy=127.0.0.1:9050 -testnet` locally and get the connection
00:29 < MarcoFalke> But I need the proxy for outgoing connections, I see.
00:29 < wumpus> ohh testnet
00:30 < wumpus> probably very, very few onion testnet peers
00:30 < MarcoFalke> Still, why wouldn't they sync each others blocks if connected?
00:32 < MarcoFalke> Could you try  `-connect=moheur3skn7jbca4.onion -proxy=127.0.0.1:9050 -testnet` on your machine?
00:32 < wumpus> sure
00:32 < wumpus> with an empty datadir?
00:33 < MarcoFalke> yes, I have 2400 blocks
00:33 < MarcoFalke> *47762
00:34 < wumpus> 2015-11-12 08:34:02 SOCKS5 connecting moheur3skn7jbca4.onion / 2015-11-12 08:34:08 SOCKS5 connected moheur3skn7jbca4.onion/ 2015-11-12 08:34:08 receive version message: /Satoshi:0.11.99/: version 70011, blocks=47762, us=0.0.0.0:0, peer=1
00:34 < wumpus> and nothing after that
00:34 < wumpus> could mean two things a) I'm not sending getheaders b) peer is ignoring my getheaders
00:35 < wumpus> as for (b) I know this issue all too well: https://github.com/bitcoin/bitcoin/issues/6971
00:36 < wumpus> but this required P2P-level debugging, it's not tor's fault :)
00:36 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
00:37 < MarcoFalke> I don't run master. Still running `f1d548d squashme: mention torcontrol in doc/tor.md
00:37 < MarcoFalke> ` with no merge
00:37 < MarcoFalke> I guess thats an tested ACK on 6639, then?
00:37 < wumpus> that doesn't matter - if it's the *other* peer that's ignoring you, nothing you can do
00:38 < MarcoFalke> We are both in IBD?
00:39 < wumpus> using debug=net I can see that I'm sending getheaders, but he's not responding
00:39 < wumpus> or he's forked off the chain completely
00:39 < wumpus> anything that would make the tip older than 24 hours old will preent him from sending headers
00:40 < wumpus> I remember there were some issues on testnet
00:41 < MarcoFalke> block 47762 is Jan 2013
00:41 < wumpus> but he seems stuck there. blocks=... doesn't go up after reconnecting :)
00:42 < wumpus> so we'll have to find a good testnet onion peer to check this
00:42 < MarcoFalke> one sec...
00:42 < MarcoFalke> going to sync and then `-connect=` again
00:43 < wumpus> I can spin up one, after catching up (or I'll just comment out that check in #6971, so anyone-can-getheaders)
00:44 < wumpus> ok one min
00:45 -!- JackH [~Jack@host-80-43-141-3.as13285.net] has joined #bitcoin-core-dev
00:47 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
00:48 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
00:50 < wumpus> MarcoFalke:  tor: Got service ID vbzzvljohcyzlfzg, advertizing service vbzzvljohcyzlfzg.onion:8333   you should be able to sync from that
00:50 < wumpus> eh wait that's not testnet
00:51 < wumpus> it is: ytiwtue6no6c3cit.onion:18333
00:51 < wumpus> may take some seconds for the new service id to propagate over the tor network
00:53 < MarcoFalke> Could you make that `-connect=moheur3skn7jbca4.onion -proxy=127.0.0.1:9050 -testnet` and then sync me?
00:53 < MarcoFalke> because I am still running with no `-proxy` to prevent outgoing connections
00:55 < wumpus> ok
00:57 < wumpus> I can connect, but I cannot sync from you, because your node is in IBD
00:58 < wumpus> /Satoshi:0.11.99(hi_wumpus)/ hehe
01:00 < wumpus> anyhow yes that's a tested ACK on #6639 - it's clear that creating the hidden service and makng it connectible works
01:06 -!- molly [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
01:09 < MarcoFalke> Ok, then. Will do some more testing and comment on the pull. ;)
01:09 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
01:12 -!- MarcoFalke [50edea96@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.234.150] has left #bitcoin-core-dev []
02:22 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-core-dev
02:25 -!- zarathustra [zanoni@unaffiliated/tolstoi] has joined #bitcoin-core-dev
02:34 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
02:38 < phantomcircuit> gmaxwell, so im (soft) disabling walletbroadcast but what am i doing about whitelisted peers
02:38 < phantomcircuit> it seems that there's an argument to be made both ways
02:40 < gmaxwell> phantomcircuit: relay for them; and add an option to control their relay special casing (e.g. so you can turn off the behavior that irritates me too. :) ) and then you can soft set that off too when blocksonly is on.
02:41 < sipa> that seems neat
02:41 < phantomcircuit> -relaywhitelisted ?
02:43 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Quit: Leaving]
02:43 < gmaxwell> whitelistalwaysrelay  might be more descriptive.
02:44 < gmaxwell> since turning it off should turn off the current behavior where we will accept txn from a whitelisted peer that we wouldn't otherwise.
02:44 < sipa> right, normal relay for whitelisted peers would keep working even without the special case behaviour
02:45 < phantomcircuit> default to true or false?
02:45 < phantomcircuit> i guess default to true unless blocksonly=1
02:45 < gmaxwell> default to true (current behavior) and soft-off it in blocksonly mode.
02:46 < gmaxwell> then people who want to relay for nodes behind them while in blocksonly can turn it on.
02:46 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
02:56 < phantomcircuit> gmaxwell, bleh it's now a hideously huge 13 loc patch
02:56 < phantomcircuit> :P
02:57 < gmaxwell> obviously you have to find some unrelated code to remove at the same time... (heh no not really)
02:59 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
03:00 < wumpus> phantomcircuit: we don't make it easy to make a small patch, do we :)
03:01 < sipa> we need patches that are C++-neutral
03:02 < phantomcircuit> wumpus, lol @ constant
03:02 < phantomcircuit> BUT BUT
03:03 < phantomcircuit> wumpus, main.h or net.h?
03:03 < wumpus> phantomcircuit: depends on where it's used
03:03 < wumpus> I thought main.h
03:04 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
03:05 < sipa> phantomcircuit: your patch will go into history books as the one with the higher discussion per lines of code patch ever that got merged
03:06 < phantomcircuit> lol
03:07 < paveljanik> if it will be merged at all! :-)
03:26 < gmaxwell> sipa: pfft. 
03:27 < gmaxwell> https://github.com/bitcoin/bitcoin/commit/b196b685c9089b74fd4ff3d9a28ea847ab36179b
03:36 < phantomcircuit> oy the mix of logic between net.cpp and main.cpp is super annoying
03:36 < sipa> phantomcircuit: the certainties of life :)
03:37 < phantomcircuit> net.cpp:454:89: error: ‘DEFAULT_BLOCKSONLY’ was not declared in this scope
03:37 < phantomcircuit> well yes because it's defined in main.h
03:37 < phantomcircuit> >.>
03:37 < sipa> put it in the node state in main
03:38 < phantomcircuit> sipa, put it in CNode ?
03:38 < sipa> no
03:38 < sipa> in CNodeState
03:39 < sipa> CNode is the network layer's kitchen sink
03:39 < sipa> (with a ton of state from processing)
03:39 < sipa> CNodeState is just processing
03:40 < phantomcircuit> sipa, is that accessible from CNode::Cnode ?
03:40 < sipa> no
03:40 < sipa> that's the point
03:40 < sipa> none of this should be in net
03:45 < gmaxwell> http://blog.nordeus.com/dev-ops/power-failure-testing-with-ssds.htm
03:52 < wumpus> <phantomcircuit> oy the mix of logic between net.cpp and main.cpp is super annoying <- oh, you're only now discovering that? :-)
03:52 < phantomcircuit> sipa, ok then i have to move PushVerison out of Cnode::CNode :/
03:52 < phantomcircuit> (it actually shouldn't be there anyways so i guess net win... horray)
03:59 < wumpus> but yes, the split between net.cpp and main.cpp is not optimal, it left too many P2P related code in main
03:59 < GitHub139> [bitcoin] sipa opened pull request #6996: Add preciousblock RPC (master...preciousblock) https://github.com/bitcoin/bitcoin/pull/6996
04:00 < sipa> wumpus: and too much processing in net
04:00 < sipa> vRecvGetData has no business in CNode, for example
04:01 < wumpus> right
04:01 < sipa> how do i run the python tests from the command line?
04:01 < wumpus> cd qa/pulltester; ./rpc-tests.py
04:02 < sipa> ha, ok!
04:04 < wumpus> and if you want to run a seperate test you can execute it manually from qa/rpc-tests
04:05 < sipa> oh lol, i can't remember it being so easy
04:05 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
04:06 < wumpus> whoa does anyone ever read README.md? :-) it still mentions the pull-tester
04:06 < GitHub93> [bitcoin] sturles opened pull request #6997: Don't use hard-coded AllowFree, as this is usually far too low. (master...no-default-free-priority) https://github.com/bitcoin/bitcoin/pull/6997
04:09 < GitHub55> [bitcoin] laanwj opened pull request #6998: doc: Remove mention of pulltester from README.md (master...2015_11_readme_pull_pulltester) https://github.com/bitcoin/bitcoin/pull/6998
04:13 < wumpus> I also think the "Manual Quality Assurance (QA) Testing" is very much out of date
04:15 < GitHub86> [bitcoin] jonasschnelli opened pull request #6999: add (max)uploadtarget infos to getnetinfos RPC help (master...2015/11/maxuploadtarget_rpc_help) https://github.com/bitcoin/bitcoin/pull/6999
04:15 < GitHub29> [bitcoin] jonasschnelli opened pull request #7000: [Qt] add shortcurts for debug-/console-window (master...2015/11/qt_shortcuts) https://github.com/bitcoin/bitcoin/pull/7000
04:15 < jonasschnelli> Yeah. PR #7000!
04:16 < phantomcircuit> sipa, where else would vRecvGetData be?
04:16 < sipa> phantomcircuit: CNodeState
04:16 < phantomcircuit> ah
04:17 < phantomcircuit> sipa, is the distinction you're thinking between the socket and the protocol things?
04:17 < phantomcircuit> if so maybe CBitcoinNode : CNode
04:18 < sipa> phantomcircuit: the idea (well, my idea... i don't know how many people share it) is that CNode should hold pointers to various module-specific state objects
04:18 < sipa> phantomcircuit: and that when invoking code from one module, it just gets its own state objected handed to it
04:19 < sipa> so ping handling can be entirely separate from block synchronization for example, and use completely independent locks, and even be totally unaware of the other's existance
04:23 < wumpus> sounds like a sensible way to handle a protocol with different (mostly) independent concerns
04:28 < phantomcircuit> yes except for the part where we decided to maintain the order of responses
04:29 < wumpus> uhm, you mean that responses come in the same order as commands that trigger them?
04:30 < wumpus> that's a pretty sane assumption that holds for most network protocols AFAIK
04:30 < sipa> phantomcircuit: that's not incompatible
04:31 < sipa> phantomcircuit: the ping module could be processing a message from node A, while the block sync logic is processing a message from node B
04:32 < phantomcircuit> ah
04:33 < phantomcircuit> wumpus, there's afaict no really good reason to enforce ordering of the responses actually
04:33 < phantomcircuit> the only thing that relies on it in anyway is the initial block download thing
04:34 < phantomcircuit> and im not sure it really does anymore
04:34 < sipa> it does
04:34 < sipa> normal block sync does too
04:34 < sipa> bip37-based downloading does too
04:34 < wumpus> phantomcircuit: I don't see a reason to make it different though
04:34 < sipa> and a ton of test infrastructure relies on it
04:36 < wumpus> is there anything specific that could be done better if it was not the case?
04:59 -!- go1111111 [~go1111111@162.244.138.37] has quit [Ping timeout: 244 seconds]
05:02 -!- go1111111 [~go1111111@162.244.138.37] has joined #bitcoin-core-dev
05:09 -!- fkhan [weechat@gateway/vpn/mullvad/x-nvqlplnrfnptmhrh] has quit [Ping timeout: 255 seconds]
05:24 -!- fkhan [~weechat@unaffiliated/loteriety] has joined #bitcoin-core-dev
05:37 < GitHub129> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/5fcc14ee0562...54e8bfec8387
05:37 < GitHub129> bitcoin/master 06d81ad Alex Morcos: Skip BIP30 check after BIP34 activation
05:37 < GitHub129> bitcoin/master 33c90cf Alex Morcos: Make skipping BIP30 check chain agnostic
05:37 < GitHub129> bitcoin/master 54e8bfe Pieter Wuille: Merge pull request #6931...
05:37 < GitHub166> [bitcoin] sipa closed pull request #6931: Skip BIP 30 verification where not necessary (master...skipBIP30) https://github.com/bitcoin/bitcoin/pull/6931
05:45 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: This computer has gone to sleep]
05:49 -!- fkhan [~weechat@unaffiliated/loteriety] has quit [Ping timeout: 265 seconds]
05:51 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
06:01 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 255 seconds]
06:04 < phantomcircuit> wumpus, yes we could improve the throughput of getdata requests if they were out of order
06:05 < phantomcircuit> as it is there's a large latency hit if the block requested isn't in cache
06:05 < wumpus> how?
06:06 < phantomcircuit> wumpus, parallel fetch from disk
06:06 < wumpus> getdata is already enough of a i/o DoS attack as it is, thank you
06:06 < sipa> i don't think we should go write our own optimizer for disk fetches
06:06 < phantomcircuit> hell we could even rewrite the requests so that they hit disk sequentially
06:07 < sipa> phantomcircuit: you'd also need a reorganizer that rewrites the block files to be sequential
06:07 < sipa> please don't go there
06:07 < wumpus> TBH this doesn't sound very reasonable nor useful, please profile first before you think about optimizing anything
06:08 < phantomcircuit> sipa, parallel fetch isn't anywhere near as complex as writing our own optimizer.... but it might need one if it's not to completely break hdds
06:08 < wumpus> optimizing the disk component of getdata doesn't rank anywhere in the 'concerns that slow down bitcoin core in practice' I'm sure
06:08 -!- BashCo [~BashCo@unaffiliated/bashco] has quit []
06:10 < sipa> phantomcircuit: so if that's really a concern at a time when the protocol too strongly relies on the ordering to meaningfully change it, we can always add a pargetdata which allows answers in any order. fixed.
06:10 < wumpus> we already do parallel getdata on different nodes, that's even better paralleism thanks to sipa :)
06:13 < phantomcircuit> wumpus, it basically only effects people like me syncing over gigabit lans from systems with the entire thing in page cache
06:13 < wumpus> ... right
06:13 < phantomcircuit> increasing the fetch depth to 100 mostly fixes it
06:23 -!- jgarzik [~jgarzik@172.85.35.242] has joined #bitcoin-core-dev
06:23 -!- jgarzik [~jgarzik@172.85.35.242] has quit [Changing host]
06:23 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
06:24 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
06:28 < morcos> sipa: ha, i was chasing my own tail on that insecure_rand.  Ok so should I fix the extra 30 bits of randomness or take our chances on only 32.  I vote take our chances.
06:29 < sipa> morcos: will the test fail if it actually is identical?
06:30 < morcos> i was going to consider testing that.  i was thinking that it might allow you to spend a duplicate coinbase which has already been spent
06:30 -!- fkhan [weechat@gateway/vpn/mullvad/x-ukhjypffubvqyonq] has joined #bitcoin-core-dev
06:31 < morcos> but maybe even thats ok, unless you randomly spend the second copy in exactly the same way.  in which case it would break
06:31 < morcos> i think?
06:32 < sipa> morcos: hmm, your cache will be very slow
06:32 < sipa> eh, small
06:32 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
06:32 < morcos> it is slow, but what do you mean small?
06:33 < sipa> eh, for some reason i was assuming that normal transactions decreased the number of entries... but they create a new output too of course
06:33 < morcos> it about triples the time of that test from 300ms to 1sec
06:33 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
06:34 < sipa> i guess you grow to around 4000 entries
06:34 < morcos> yeah so on a typical test you generate around 4000 coinbases about 40 of which are duplicate and you end up towards the end of the test, failing on about 40 of them (if you have the broken fix)
06:34 < morcos> that should be right
06:35 < morcos> sorry around 400 of which are duplicate
06:37 < morcos> b/c you only fail on the duplicate if it happens to get spent before its flushed.   so i didn't check for coverage of that, since its a bit tricky, but that seemed a high enough failure rate that slight tweaks to the test shouldn't affect it.
06:38 < sipa> you have around 1.7% chance to hit a duplicate during a test run :)
06:38 < sipa> oh, wait, that's assuming there are only coinbases
06:41 < sipa> around 0.2% chance per run; i think you need 64-bit amounts :)
06:41 < morcos> how did you get 1.7%?  does that sound really high?  do you have to have the same random 32 bit number in 4000 tries (or 40k for the calculation you did)
06:42 < sipa> i calculated 1 - multiply(1 - x/2^32, x=1..4000)
06:42 < sipa> that's 0.2%
06:42 < morcos> oh silly me
06:43 < morcos> yes i calculated that wrong
06:44 < morcos> ok i'll make it a 64-bit number with the cast. 
06:44 < sipa> of course, you could just use the iteration counter instead :)
06:45 < morcos> good even easier
06:45 < morcos> in a car now..  i'll push it in a bit
06:58 < morcos> ok lots of traffic, squashed the fix in.
06:59 < instagibbs> Hopefully not while driving :)
06:59 < morcos> heh, no...
07:00 < jgarzik> heh
07:00 < sipa> Hopefully not while trafficking
07:03 < jgarzik> with Uber & self driving cars, non stop hacking is possible :)  Ah, the future.
07:03 < sipa> Where is my hoverboard?
07:23 -!- ParadoxSpiral [~ParadoxSp@p508B87F5.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
07:25 < jgarzik> sipa, http://hendohover.com
07:26 < sipa> jgarzik: ha, yes, i've heard about that
07:27 < wumpus> hah
07:28 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
07:29 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
07:48 -!- zooko [~user@2601:281:8001:26aa:8bb:2b7e:f24:e2fb] has joined #bitcoin-core-dev
07:49 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
08:06 -!- zooko [~user@2601:281:8001:26aa:8bb:2b7e:f24:e2fb] has quit [Ping timeout: 240 seconds]
08:32 -!- zooko [~user@2601:281:8001:26aa:8bb:2b7e:f24:e2fb] has joined #bitcoin-core-dev
08:38 < GitHub77> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/54e8bfec8387...eb6172a8ca7e
08:38 < GitHub77> bitcoin/master 830e3f3 Pieter Wuille: Make sigcache faster and more efficient
08:38 < GitHub77> bitcoin/master 0b9e9dc Pieter Wuille: Evict sigcache entries that are seen in a block
08:38 < GitHub77> bitcoin/master 69d373f Pieter Wuille: Don't wipe the sigcache in TestBlockValidity
08:38 < GitHub101> [bitcoin] laanwj closed pull request #6918: Make sigcache faster, more efficient, larger (master...smallsigcache) https://github.com/bitcoin/bitcoin/pull/6918
08:48 -!- rubensayshi [~ruben@91.206.81.13] has quit [Remote host closed the connection]
08:52 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
08:56 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
08:58 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Ping timeout: 276 seconds]
09:37 -!- MarcoFalke [8af6027f@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.127] has joined #bitcoin-core-dev
09:45 -!- skyraider [uid41097@gateway/web/irccloud.com/x-ovmlfilsoisnbdlp] has joined #bitcoin-core-dev
10:33 < GitHub51> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/eb6172a8ca7e...bd629d77edbe
10:33 < GitHub33> [bitcoin] laanwj closed pull request #6639: net: Automatically create hidden service, listen on Tor (master...2015_08_tor_hs_v2) https://github.com/bitcoin/bitcoin/pull/6639
10:33 < GitHub51> bitcoin/master 8f4e67f Wladimir J. van der Laan: net: Automatically create hidden service, listen on Tor...
10:33 < GitHub51> bitcoin/master 2f796e5 Peter Todd: Better error message if Tor version too old
10:33 < GitHub51> bitcoin/master 09c1ae1 Wladimir J. van der Laan: torcontrol improvements and fixes...
10:44 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds]
10:45 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
10:59 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
10:59 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Max SendQ exceeded]
10:59 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
10:59 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Max SendQ exceeded]
11:00 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
11:00 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Max SendQ exceeded]
11:00 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
11:02 < jcorgan> wow, i missed this PR entirely.  what a great idea, glad it is merged.
11:12 < MarcoFalke> yes, good to see this in 0.12!
11:35 < GitHub56> [bitcoin] sdaftuar closed pull request #6992: [WIP] [Mempool] Add space for priority transactions (master...add-priority-to-mempool) https://github.com/bitcoin/bitcoin/pull/6992
11:55 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
11:57 < Luke-Jr> morcos: ok, so back to your stuff? :P
11:58 < gmaxwell> Luke-Jr: on priority. the exact current behavior requires walking all inputs for all transactioin in the mempool on every CNB to update priorities. With large mempools this is an enormous amount of time, and we cannot continue doing this.
11:58 < Luke-Jr> morcos: can you make it so the accurate priority gets used with a policy option miners can enable? that makes current policy possible, right?
11:58 < gmaxwell> There are multiple alternatives but most result in lots of software complexity, which we also probably don't want.
11:58 < morcos> Hmm.. I think that would be possible
11:58 < Luke-Jr> gmaxwell: it can be disabled by default
11:58 < morcos> The original version of my pull did the expensive calculation
11:59 < morcos> it'll make the code slightly uglier casing that out
11:59 < gmaxwell> Luke-Jr: I think miners would be stupid to enable something that makes CNB 10x + slower, and we'd be stupid to offer it since slow CNB means more 'spv mining' and other bad effects.
11:59 < morcos> but yes, i agree with that concern
11:59 < sdaftuar> what's the motivation to keep the current version of priority rather than starting priority as the metric?
11:59 < Luke-Jr> gmaxwell: CNB is not time-critical with Eloipool, and doesn't imply SPV mining
11:59 < gmaxwell> I wouldn't _oppose_ an option, default off, except on the basis of carrying around code, and lack of testing (but I assume you'll test)
11:59 < morcos> Luke-Jr: it may be something you can just easily patch in yourself 
12:00 < petertodd> sdaftuar: I think for most uses of priority, updating every time shouldn't make much of a difference - we're talking about old inputs after all
12:00 < petertodd> sdaftuar: whats the difference betweek 1 month and 1 month + 1 hour?
12:00 < Luke-Jr> I suggest we have it in Core for 0.12, and try to optimise (or remove) by 0.13
12:00 < gmaxwell> sdaftuar: I think starting priority is a pretty poor approximation, though on the basis that I wouldn't be too opposed to ditching priority entirely, using a poor approximation isn't so bad. 
12:00 < sdaftuar> it just seems pretty arbitrary to me to decide to age inputs rather than use the age when relayed to you
12:01 < sdaftuar> so given two arbitrary calculations, might as well do the faster one
12:01 < gmaxwell> sdaftuar: age inputs has a property that the tx shouldn't hang around forever, but will actually bubble up and get mined at some point.
12:01 < Luke-Jr> sdaftuar: well, aging inputs properly may in some cases be necessary for txns to confirm ever
12:01 < sdaftuar> well we're about to deploy RBF and expiry
12:01 < petertodd> the only time this matters is very high value outputs which we're expecting to accumulate priority quickly, and why incentivise people to put everything in on etxout? can have bad privacy implications
12:02 < Luke-Jr> sdaftuar: as optional policies
12:02 -!- skyraider [uid41097@gateway/web/irccloud.com/x-ovmlfilsoisnbdlp] has quit [Quit: Connection closed for inactivity]
12:02 < phantomcircuit> Luke-Jr, then write a background thread to update priority
12:02 < petertodd> phantomcircuit: +1
12:02 < morcos> Luke-Jr: I'll see if I can whip up a dependent PR that adds back in the accurate calculation with an option, that could be included.  
12:02 < Luke-Jr> phantomcircuit: that would be one way to optimise it, but I hope to have something better for 0.13 anyway
12:03 < gmaxwell> I do agree if the functionality was retained update in the background would be prudent.
12:03 < Luke-Jr> morcos: well, I don't want to merge the existing PR without that included, so might as well put it in the same PR..
12:03 < morcos> If you want to properly calculate priority, you need to do it dynamicalyl as in 6357 otherwise you destroy your UTXO cache
12:03 < morcos> 6357 is strictly better than that
12:03 < morcos> Luke-Jr: yes but that may not be the prevailing view.
12:03 < morcos> Well lets argue about it when we see what it looks like anyway
12:04 < phantomcircuit> Luke-Jr, the priority calculation as it existed before mempool limiting cannot be reasonably calculated in realtime, the only way to do it is as a background thread
12:04 < wumpus>  * [new tag]         v0.11.2 -> v0.11.2
12:04 < petertodd> wumpus: +1
12:04 < morcos> First I have to fix the existing pull, it uses the wrong calculation now anyway
12:04 < petertodd> wumpus: or really, -rc
12:04 < Luke-Jr> petertodd: you missed the rc
12:04 < morcos> phantomcircuit: no, background thread is bad b/c of cache.  see 6357
12:04 < petertodd> Luke-Jr: lol, I mean, we're taking the rc off of v0.11.2rc1 :)
12:05 < Luke-Jr> o
12:05 < phantomcircuit> morcos, a background thread is equally as bad as any other way of doing it in that regard
12:06 < morcos> 6357 does not destroy your cache, and is way less computational complexity
12:06 < gmaxwell> as far as this priority discussion, I think people are being far too dismissive about priority. In particular, this idea of fee competition vs dos attacks is a situation where the defender has no advantage on an attacker at all... they spend the same. Having a tie breaker that rewards coins that haven't recently moved is, I think, an elegent way to create a gap so that attackers don't merely nee
12:06 < gmaxwell> d to pay market rate but slightly above.  And impact to miner income can be made negligible. 
12:07 < morcos> gmaxwell: that argument doesn't make sense to me
12:07 < morcos> i think the HOV/fast lane arguement makes sense
12:07 < morcos> but to have priority boost fee doesn't make sense
12:08 < petertodd> gmaxwell: why do we assume the defender always has more old coins than the attacker?
12:08 < morcos> so it boosts it by delta.  then attackers just have to pay market rate + delta, who cares, unless delta is large, in which case then you have prioirty txs crowding out fee paying txs and hurting miners profits
12:08 < gmaxwell> morcos: right now the attacker need only bid episilon more than market rate to replace the honest users at market rate in the mempool.
12:08 < gmaxwell> petertodd: it's a hurestic, and it maps to the actual attack pattern in that by their nature an attack requires making lots of transactions. Honest use may or may not have that property; but it remains a distinguisher, if not a super strong one.
12:08 < morcos> its impossible to pick the conversion so that it accomplishes exactly your goal.. unless you reserve only a certain amount of space for priority, which is what the existing code does
12:09 < petertodd> e.g. IIRC in lightning you can be in a situation where you need to get a recently mined tx spent, and the attacker may be trying to flood mempools to keep you from doing that
12:09 < morcos> the existing code makes sense for that purpose, i agree.  but combining to just one bucket filled on a combined metric does not
12:09 < Luke-Jr> petertodd: I'm sure there are lightning-optimised policies that are possible?
12:09 < petertodd> morcos: and *that* can be easily done with two separate mempools, each separately limited, which keeps the codebase simple
12:09 < petertodd> Luke-Jr: better for privacy if you can't distingish lightning txs from othre txs
12:10 < Luke-Jr> …
12:10 < gmaxwell> morcos: Okay, you're right there. I was thinking that even having the attacker have to pay the extra delta is a benefit, but you're right that its probably negligible.
12:10 < Luke-Jr> but you can
12:11 < phantomcircuit> morcos, 6357 is less computationally complex, but significantly more complex code
12:11 < wumpus> and another: * [new tag]         v0.10.4 -> v0.10.4
12:11 < morcos> phantomcircuit: ok that i will agree with!
12:11 < gmaxwell> The two pools approach can also resolve the repricing cost issue, I think, if transactions cannot move back from the feerate pool to the priority pool, and if the priority pool is small.
12:11 < morcos> sdaftuar's pull was 2 pools 
12:12 < morcos> maintained in the same structure
12:12 < phantomcircuit> morcos, and it's a bunch of caching of values which is genuinely hard to get right
12:12 < gmaxwell> (as you could limit repricing to the priority pool if the above assumptions are kept)
12:13 < gmaxwell> maybe I just need to come around to bluematt's thinking that priority is not worth maintaining...
12:13 < dgenr8> different-sized mempools mean that attacker doesn't have a perfectly defined function to erase a tx with a given fee
12:13 < morcos> gmaxwell: i mostly agree, i wanted to keep priority, but it is a lot of complication, and maybe its better to realize that if we can come up with some incentive compatible metric like priority
12:13 < morcos> then we can just add that back in in a clean way
12:13 < morcos> we dont' have to permanently shut the door on a metric like this
12:14 < dgenr8> also, attacker has to erase 299M of transactions to affect the lowest-feerate tx that's going into the next block
12:14 < dgenr8> at default mempool setting
12:14 < sipa> dgenr8: highest
12:15 < dgenr8> 300M to affect highest, no?
12:16 < gmaxwell> morcos: yes, if block costing is changed, then it becomes incentive compatible and works better; though I am really really not fond of multi-metric block costs.
12:16 < morcos> but block costs are inherently multi-metric with sig-op limit
12:16 < morcos> you could buy extra block size with older age coins even
12:17 < phantomcircuit> morcos, the sigop/byte limit is so high that no legitimate user is going to hit it
12:17 < Luke-Jr> removing policy actually increases maintenance costs
12:17 < sipa> dgenr8: oh, i see what you're saying; in theory, yes, but in practice chains of transactions are harder to kick out and tend to linger, making it more spread out
12:17 < gmaxwell> morcos: yes, and I want that to go away (it's busted anyways. :) )  fortunately the sigop limit is high enough that under ordinary use it's never hit.
12:17 < phantomcircuit> you basically need to have a transaction that consists of OP_DUP OP_DUP OP_CHECKSIG  repeated 100+ times to hit the limit
12:17 < morcos> gmaxwell: ha, but you're the one tryign to worry about hitting it now b/c of the flood
12:18 < morcos> if you dont' have multi metrics, then you have conversion factors between metrics which are hard to get right
12:18 < gmaxwell> yea I know, I know, short term effects because of people specifically trying to exploit it.
12:18 < gmaxwell> morcos: I don't know if for incentive reasons it matters if they're "right"
12:18 < gmaxwell> in that I think mostly the sign matters.  "oh I should prefer to make transactions that do X because it'll cost less"
12:18 < gmaxwell> or at least only matters to within an order of magnitude.
12:18 < morcos> gmaxwell: fair enough, but i'd say heuristics for optimizing multi metrics are also good enough for mining 
12:19 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
12:19 < gmaxwell> morcos: but will anyone ever implement them?  Multiple limits also complicate the implementation of fraud proofs, making it less likely that we'll ever have them.
12:20 < morcos> sure i will!  but fraud proofs, hmm...  because you ahve to be able to prove any one of those things?
12:20 < morcos> i don't understand enough about how fraud proofs work
12:21 < gmaxwell> yes, and efficiently proving a global limit requires commiting to a tree over its computation.  
12:22  * michagogo has his gitian-build script already running
12:23 < gmaxwell> E.g. you commit to the value of of each input and output, and hashtree it, and in the interior nodes include the sum fees of the children. Now you can make an efficient proof that a block creates inflation.   This can be done for any limit, e.g. sigops, whatever, but the interior nodes in the hashtree have to track each limit.
12:24 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
12:24 < gmaxwell> morcos: I worry less that you won't implement it, and more that miners won't bother running code that almost never fires. "Morcos solved it" is a stable solution only if we assume people are running your code, which they might not for smarter or dumber reasons.
12:26 -!- skyraider [uid41097@gateway/web/irccloud.com/x-vjghfzzgotugmjya] has joined #bitcoin-core-dev
12:26 < gmaxwell> morcos: also I think seperate limits are somewhat backwards in the sense that what we really seek to limit is "cost"; and turning cost into seperate limits is something we do because we don't know how to weigh for cost, but we do know what demand looks like, and demand uses a little of each dimension.
12:27 < gmaxwell> in any case the issue with fraud proofs is mostly just making things even more complex reduces the odds that they get correctly implemented.  Mempool hurestics are one thing-- they're not consensus critical, but limits are.
12:27 < wangchun> Luke-Jr: We have priority size set to 0 for maybe one year. But I have blockminsize set to 250 KB.
12:28 < sipa> wangchun: good to know!
12:28 < michagogo> Also, I found out I'm a bit of an idiot. The issue I was having where as soon as I upgraded the LXC base, I had to keep it updated or the build would fail?
12:28 -!- d4de [~d4de@41.234.188.168] has joined #bitcoin-core-dev
12:28 < Luke-Jr> wangchun: let's chat in #bitcoin since there is conversation here already
12:28 < michagogo> The fix is just to on-target -u root rm /var/cache/gitian/initial-upgrade
12:29 < michagogo> (on the target, before copying it back over the base)
12:29 < michagogo> (That's just a flag file that the upgrade script touches)
12:30 < kanzure> fraud proofs require each unique validation rule has separate fraud proof implementation to check https://bitcointalk.org/index.php?topic=1103281.msg11743498#msg11743498
12:31 < morcos> gmaxwell: ok, i'm not against weighted cost, i just worry about getting the weights right..  especially if those are consensus rules!
12:31 < jgarzik> giving #6771 (chain limits) one last test run
12:31 < gmaxwell> kanzure: that link is not correct in the details fwiw.
12:31 < michagogo> Hm, weird lines from configure:
12:31 < kanzure> quick overview of wrongness?
12:32 < gmaxwell> (like saying utxo commitments are required, they're not)
12:32 < michagogo> Checking for QT... no
12:32 < michagogo> Checking for QT... yes
12:32 < kanzure> okay, i'll keep that in mind.
12:32 < michagogo> One right after the other
12:32 < sipa> gmaxwell: until a few days ago i would have claimed that utxo commitments are required too :)
12:33 < gmaxwell> sipa: pshaw, I've known they were for like ... months now. You need to spend more time in my head. :)
12:33 < sipa> *walks back slowly*
12:33 < kanzure> why few days ago?
12:34 < sipa> kanzure: because that's when gmaxwell told me how to do it without commitments in a PM :)
12:34 < kanzure> PMs don't count
12:34 < kanzure> that's cheating
12:34 < gmaxwell> it's been discussed in #bitcoin-wizards.
12:34 < sipa> Oh.
12:34 < kanzure> ah okay
12:34 < kanzure> great
12:35 < gmaxwell> in any case, you do them without a utxo commitment by instead commiting to the input block and offset that the input came from.
12:35 < gmaxwell> then fraud can be proven by simply showing whatever is at that location, if its not the thing its supposted to be.
12:38 < gmaxwell> I mean, I'm probably at fault for making people think that its the only way to get a fraud proof for spending non-existing coins, since in the very first writeup I suggest that https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs
12:38 < gmaxwell> but always things like that should be considered necessary, back then I didn't give it more than a moment's thought.
12:38 < gmaxwell> er considered sufficient not necessary.
12:40 < kanzure> ok, just posted follow-up to that thread linking to this explanation.
12:42 < gmaxwell> (and obviously, spends of already spent coins proven by showing the other spend)
12:48 < phantomcircuit> morcos, i dont really see the point of using a complex cost metric today as the principle limiting factor is bandwidth (and presumably will remain that way for many years)
12:49 < phantomcircuit> if i was building a cost function is would be weighted to size so heavily as to be redundant
12:50 < jgarzik> morcos, currently waiting on travis for #6771, then go for launch
12:51 < gmaxwell> phantomcircuit: uh, even with libsecp256k1 dsa signature validation run at something like only 9mbit/sec/core (in terms of transaction size).
12:51 < morcos> phantomcircuit: i thought you were arguing otherwise?  but yes personally i think the biggest costs are bandwidth and utxo bloat.  my idea was the metric should be something simple like .5 * total_bytes + 1 * output_bytes, but then maybe discounting provably unspendable output bytes
12:52 < morcos> jgarzik: did it have a problem or you just rerun it for completeness
12:52 < jgarzik> morcos, the latter - I always travis in jgarzik/bitcoin on the merged tree before pushing
12:53 < jgarzik> travis results get stale rapidly
12:54 < gmaxwell> phantomcircuit: and those figures are without multisig, it's worse with multisig. (like 2 of 3 is like 6mb/s/core)
12:55 < morcos> gmaxwell: but you're saying that number is too low?  
12:56 < morcos> oh, i guess for a degenerate block that has all new sigs...   
12:56 < morcos> so maybe there is a standard cost metric, and then separate limits like sig op is now for the degenerate cases
12:59 -!- grieve [~gr1eve@50.248.81.66] has joined #bitcoin-core-dev
13:00 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
13:26 < phantomcircuit> gmaxwell, hmm that's slower than i was thinking
13:26 < phantomcircuit> why was i thinking it was faster?
13:26  * phantomcircuit doesn't know
13:28 < gmaxwell> phantomcircuit: thats the only reason I mentioned it.
13:28 < gmaxwell> Not that I thought it was super important here, but just because you were clearly thinking it was faster than that; you're probably thinking in terms of IBD with signature checking disabled.
13:33 < phantomcircuit> gmaxwell, hmm maybe
13:33 < phantomcircuit> gmaxwell, i know that we cant do >50mbps for that
13:33 < phantomcircuit> possibly with some of the recent performance improvements we can improve on that significantly though
13:39 < michagogo> CXX    test/test_test_bitcoin-Checkpoints_tests.o
13:39 < michagogo> That capital C seems out of place
13:40 < michagogo> So does _DoS just below
13:40 < michagogo> -DoS*
13:41 < michagogo> (Contrast to -pow which is kept lowercase)
13:41 < michagogo> Okay, 0.11.2 built, PR imminent
13:42  * michagogo starts the script to build 0.10.;
13:42 < michagogo> .4*
13:43 < GitHub107> [bitcoin] jgarzik pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bd629d77edbe...38ed190eefcc
13:43 < GitHub107> bitcoin/master 971a4e6 Alex Morcos: Lower default policy limits...
13:43 < GitHub107> bitcoin/master 38ed190 Jeff Garzik: Merge #6771 from branch 'lowerLimits' of git://github.com/morcos/bitcoin
13:43 < GitHub188> [bitcoin] jgarzik closed pull request #6771: Policy: Lower default limits for tx chains (master...lowerLimits) https://github.com/bitcoin/bitcoin/pull/6771
13:43 < jgarzik> morcos, email req :)
13:45 < morcos> jgarzik: sent
13:45 < morcos> I think I have 2 backed up in moderation queue now
13:46 < michagogo> Hm, I wonder if my script will break if there's an outstanding PR
13:47 < michagogo> Actually, probably not. The Ruby oneliner that makes the PR is the last line in the script, so even if it fails and exits non-zero, the script is over anyway and there's nothing to abort
13:48 < petertodd> gmaxwell: "utxo commitment by instead commiting to the input block and offset" <- that falls into the category of !@#$ why didn't I think of that :)
13:49 < michagogo> (set -ex)
13:54 -!- ParadoxSpiral [~ParadoxSp@p508B87F5.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
13:56 < CodeShark> petertodd: that was actually my stumbling block to not fully getting some of the potential advantages of MMR trees
13:57 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
13:57 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: leavin on a jet plane]
13:58 < CodeShark> in retrospect, it makes a lot more sense to index outputs that way
13:59 < CodeShark> at least for existence/nonexistence proofs - obviously for spending we need to reference the transaction in some way
14:20 -!- MarcoFalke [8af6027f@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.127] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
14:37 -!- aburan28 [~xypher@static-108-45-93-78.washdc.fios.verizon.net] has joined #bitcoin-core-dev
15:52 -!- murr4y [murray@kvikshaug.no] has quit [Ping timeout: 246 seconds]
15:59 -!- murr4y [murray@kvikshaug.no] has joined #bitcoin-core-dev
16:06 < gmaxwell> phantomcircuit: I hate to expand your patch, but in net.h there is a comment about fRelay which you should probably revise slightly to make it sound like until a filter load isn't the only use.
16:06 < phantomcircuit> gmaxwell, oh the humanity!
16:16 -!- PRab [~chatzilla@2601:40a:8000:8f9b:c49b:a2dc:3cab:6419] has quit [Quit: ChatZilla 0.9.92 [Firefox 42.0/20151029151421]]
16:16 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]
16:22 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
16:29 < phantomcircuit> gmaxwell, ok comment changed
16:52 < phantomcircuit> gmaxwell, i couldn't figure out a sane way to use the constant (which is defined in main.h) in net.cpp
17:00 < sipa> phantomcircuit: pass that true/false based on blocksonly as a parameter to PushVersion
17:01 < phantomcircuit> sipa, PushVersion is called from the constructor of CNode::CNode
17:01 < phantomcircuit> er from...
17:01 < phantomcircuit> words
17:01 < sipa> aaargh
17:02 < phantomcircuit> lol yeah that's why i just gave up and left it as a constant constant
17:02 < sipa> can you ehm... add an Start method to CNode or so?
17:02 < gmaxwell> it what?
17:04 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ghxpvhmldrcwsaxh] has quit [Quit: Connection closed for inactivity]
17:05 < phantomcircuit> sipa, the "clean" way is to add a fVersionSent flag and then check that in SendMessages
17:06 < phantomcircuit> you wont send anything until you get a verack anyways
17:08  * phantomcircuit lols at CNode flags
17:30 < dcousens> #d
17:30 < dcousens> nvm
18:01 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
18:11 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Ping timeout: 265 seconds]
18:15 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
18:26 -!- CodeShark [uid126576@gateway/web/irccloud.com/x-keiuhngghbfgyoci] has quit [Ping timeout: 264 seconds]
18:26 -!- CodeShark [uid126576@gateway/web/irccloud.com/x-gylzfgvtfqnzsvyc] has joined #bitcoin-core-dev
18:29 -!- skyraider [uid41097@gateway/web/irccloud.com/x-vjghfzzgotugmjya] has quit [Ping timeout: 264 seconds]
18:32 -!- sipa_ [~pw@2a02:348:86:3011::1] has joined #bitcoin-core-dev
18:32 -!- skyraider [uid41097@gateway/web/irccloud.com/x-aielshrpmdbpjdde] has joined #bitcoin-core-dev
18:32 -!- sipa [~pw@unaffiliated/sipa1024] has quit [Ping timeout: 264 seconds]
18:37 -!- Netsplit *.net <-> *.split quits: Apocalyptic, guruvan, gavinandresen, lecusemble
18:44 -!- Netsplit over, joins: guruvan, gavinandresen
18:44 -!- lecusemble [~lecusembl@104.233.76.133] has joined #bitcoin-core-dev
18:45 -!- Netsplit over, joins: Apocalyptic
19:01 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Quit: Lost terminal]
19:05 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
19:06 < dcousens> anyone here use any blockchain analyser tools?
19:06 < dcousens> sorry, will go to bitcoin-dev
19:42 -!- skyraider [uid41097@gateway/web/irccloud.com/x-aielshrpmdbpjdde] has quit [Quit: Connection closed for inactivity]
19:48 < petertodd> CodeShark: lol, and now you made me realise gmaxwell could equally be talking about my MMR ideas - the reinvention cycle just went meta full circle!
19:53 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection]
19:58 -!- PRab [~chatzilla@2601:40a:8000:8f9b:c49b:a2dc:3cab:6419] has joined #bitcoin-core-dev
20:00 < jcorgan>  /cl
20:01 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
20:14 -!- zooko [~user@2601:281:8001:26aa:8bb:2b7e:f24:e2fb] has quit [Ping timeout: 240 seconds]
20:25 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Quit: Leaving]
20:29 < gmaxwell> is someone going to update univalue in master?
20:29 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
20:46 -!- fanquake [~Adium@unaffiliated/fanquake] has joined #bitcoin-core-dev
20:57  * Luke-Jr wonders if we should increase the number of blocks for Core wallet to consider transactions confirmed.
20:57 < gmaxwell> oh wow, intel mpx when used changes the ABI and makes all pointers bounds checked.
20:58 < Luke-Jr> gmaxwell: 128-bit wide?
21:00 < gmaxwell> no, it's done in an odd way that makes mixed systems possible.
21:01 < gmaxwell> basically there is a seperate bounds table. though dealing with it is still part of the abi.
21:02 < gmaxwell> https://www.kernel.org/doc/Documentation/x86/intel_mpx.txt
21:03 < Luke-Jr> oh nice, compiling with MPX gracefully noops on old CPUs
21:59 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]
22:00 < CodeShark> if I whitelist a node, other than network/transport issues or misbehaving, is there ever any conceivable situation where the node could get disconnected by bitcoin core
22:02 < CodeShark> ?
22:03 < CodeShark> actually, even in the event of misbehaving
22:10 < cfields> gitian-builders: 0.11.2 detached sigs are pushed
22:11 < cfields> 0.10.4 is waiting on one more match
22:11 < fanquake> WIll push up shortly
22:11 < fanquake> mich is the only one so far?
22:13 < cfields> his and mine
22:13 < cfields> er.. i forgot to push
22:15 < cfields> ok, done
22:17 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
22:19 < fanquake> ok, signed sigs PR'd
22:19 < fanquake> will build 0.10.4
22:20 < fanquake> hopefully for the last time..
22:20 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
22:33 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds]
22:35 < Luke-Jr> I wish gitian had a way to pull the yml from the git repo directly, so I didn't need to close out my main git working dir just to build..
22:45 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
23:10 < fanquake> cfields pushed 0.10.4 sigs
23:14 < cfields> fanquake: great, thanks! all matches. Pushing up the 10.4 detached sig now
23:23 < cfields> gitian builders/fanquake: https://bitcoincore.org/cfields/bitcoin-0.10.4/signature.tar.gz
23:27 < fanquake> cfields great. Sigs PR'd
23:29 < cfields> fanquake: thanks a bunch. Off to bed now
23:43 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
23:49 < sipa_> Luke-Jr: you can, i forget how
23:49 < Luke-Jr> !
23:49 < sipa_> i wrote a patch for that years ago, which i kept using, but it isn't necessary anymore
23:54 < gmaxwell> So sipa updated this PR https://github.com/bitcoin/bitcoin/pull/6983  but I can't figure out what changed