--- Day changed Sun Oct 30 2016
01:30 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-fcwhdwhohlufbmvs] has joined #bitcoin-core-dev     
01:36 -!- rebroad [~rebroad@1.46.236.157] has quit [Ping timeout: 250 seconds]     
01:57 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev     
01:58 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host]     
01:58 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:07 -!- cdecker [~quassel@2a02:aa16:1105:4a80:4970:e3e6:793:b05f] has joined #bitcoin-core-dev     
02:32 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev     
02:36 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
03:24 < wasi> great job on v0.13.1 guys. thanks to all the contributors for making this version a reality. looking forward to see the segwit sf happening.
04:14 -!- JackH [~laptop@79-73-190-13.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
04:41 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
05:20 -!- Guyver2__ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
05:20 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds]     
05:20 -!- Guyver2__ is now known as Guyver2     
05:27 < btcdrak> sipa: luke-jr: jonasschnelli: each of you dns seeds appear to be down.
05:29 -!- goatpig [5a5c653a@gateway/web/freenode/ip.90.92.101.58] has joined #bitcoin-core-dev     
05:30 < goatpig> Are there specific rules to create SW outputs from legacy outputs? Can I just create a SW tx with empty witness programs, redeeming only legacy outputs? Do I have to use nested outputs in a legacy tx?
05:41 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Ping timeout: 265 seconds]     
05:49 < phantomcircuit> goatpig: "from legacy outputs" huh?
05:52 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
05:56 < goatpig> phantomcircuit: current P2PKH and P2SH outputs
05:59 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]     
06:00 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev     
06:03 < jl2012> goatpig, current P2PKH and P2SH outputs will be spent in the old way
06:03 < jl2012> you may send to your own segwit-compliant address, of course
06:05 < goatpig> my concern is what is the preferred/legal path to convert a legacy output to a sw one
06:10 < Victorsueca> goatpig: I'd just make a standard transaction to send them to the segwit address
06:10 < aj> goatpig: same way you would upgrade from a legacy single-pubkey address to a 2-of-3 multisig address, you just spend the coin to your new address
06:13 < goatpig> ok so i dont have to force my users to spend to a nested sw first?
06:13 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 245 seconds]     
06:17 < aj> goatpig: no, you don't have to. you'd save a step if you did though (which would be more efficient usage of the blockchain, and help free up tx space for other people to use)
06:18 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
06:21 < goatpig> aj: you mean in their ability to provide non SW wallets with a way to pay into a SW output? 
06:22 < goatpig> my plan was to ease my users into SW by defaulting change to SW outputs in the long run
06:23 < goatpig> im more concerned about migrating my users funds to SW than interfacing with non upgraded services
06:28 < GitHub39> [bitcoin] s-matthew-english opened pull request #9041: keypoololdest denote Unix epoch, not GMT (master...patch-8) https://github.com/bitcoin/bitcoin/pull/9041
06:28 < jl2012> goatpig, maybe using segwit output as change, but that hurts privacy
06:33 < goatpig> jl2012: how?
06:33 < goatpig> by revealing the change output?
06:33 < jl2012> it indicates which output is the change
06:34 < jl2012> but that's a chicken and egg problem
06:34 < goatpig> but that's basically the case as long as you have a mixed set of outputs
06:35 < goatpig> if you have only SW outputs and you are paying to a legacy output, the same privacy leak takes place
06:35 < aj> goatpig: you can give out an address for people to send money to you that looks like (is) a legacy P2SH address, but that you spend via segwit (ie saving tx fees when you spend it)
06:35 < aj> goatpig: if you have only SW outputs, you're not paying to a legacy output by definition?
06:36 < goatpig> aj: sure but it is less efficient that SW in that you still have to fulfill the p2sh script in the input before interpreting it as SW
06:36 < jl2012> goatpig: you could use native SW as change
06:36 < goatpig> aj: if someone requests a payment to a plain P2PKJ
06:36 < goatpig> P2PKH*
06:36 < goatpig> and i only have SW outputs
06:36 < goatpig> jl2012: that's what i want to run with so far
06:37 < goatpig> if the user wants "soft" SW conversion, send change to native P2WPKH
06:37 < aj> goatpig: then you're *inputs* (or prevouts) are SW, and one of your outputs is the P2PKH
06:37 < jl2012> SW outputs could be sent to anything, P2PKH or segwit
06:37 < goatpig> aj: yes, which is a privacy leak, in the light of jl2012 remarks
06:37 < aj> oops, "your"
06:38 < goatpig> jl2012: sure you can, but if your payee requests a legacy P2PKH payment, chances are his wallet isn't SW compliant
06:38 < jl2012> native SW is a even bigger privacy leak, because there is no address for that
06:38 < goatpig> and he won't see that payment if you force it to SW on your own
06:38 < aj> goatpig: there was a suggestion to have your change address be in the same form as one of the real outputs, so if you're spending to P2PKH, make your change address P2PKH...
06:38 < jl2012> goatpig: wallet doesn't verify txs, anyway
06:39 < jl2012> it's a softfork
06:39 < goatpig> jl2012: no but you are at best stuck with an output you can't spent, at worst you have a weird miscommunication where one end paid and the other lacks the software to aknowledge the payment
06:39 < jl2012> of course they will see it. That's the point of a softfork
06:40 < jl2012> the wallet should not care what the input is
06:40 < jl2012> they just care  what the output is
06:41 < jl2012> the input, for an unupgraded wallet, is anyone-can-spend
06:42 < goatpig> there's an argument to be made for non upgrade wallets, that they simply won't consider the output as theirs
06:42 < goatpig> even P2WPKH
06:42 < goatpig> as for native SW, i thought there was a spec for creating addresses out of those?
06:43 < jl2012> if the payee gives you a P2PKH address, you must send to P2PKH, not P2WPKH
06:43 < goatpig> of course
06:43 < goatpig> if all my outputs however are P2WPKH
06:43 < jl2012> so what's the problem?
06:43 < goatpig> that's a privacy leak anyways
06:44 < jl2012> P2WPKH could pay to P2PKH
06:44 < goatpig> so taht goes back to using P2WPKH output change as default and the privacy leak
06:44 < goatpig> wait
06:44 < goatpig> im confusing a couple things here
06:44 < goatpig> nvm     
06:44 < goatpig> although that's a bit annoying
06:45 < goatpig> you'd be downgrading a SW output to a P2PKH change in that scenario
06:45 < jl2012> that's by design
06:45 < goatpig> ok     
06:45 < goatpig> what's the status on BIP142?
06:46 < jl2012> i mean, it's up to your design. Or just let the user chooses
06:46 < goatpig> more GUI complexity, sweet!
06:46 < jl2012> expert mode
06:46 < goatpig> i just hate working pyqt4
06:48 < goatpig> anyways
06:48 < jl2012> we have some discussion about the address design, like using BASE32
06:48 < goatpig> wait so BIP142 isn't approved?
06:48 < goatpig> and why the sudden change?
07:03 < jl2012> many people hate BASE58
07:04 < Victorsueca> is base32 like base58 but without caps?
07:04 < jl2012> case-insensitive
07:05 < Victorsueca> but addresses would be longer with base32 rigth?
07:05 < Victorsueca> rigth*
07:05 < jl2012> sure
07:06 < jl2012> should be 17% longer with same amount of data
07:06 < goatpig> is it gonna be a little flavored to avoid 0 and o? or i guess the case agnostic aspect covers that?
07:06 < Victorsueca> goatpig: I think base 58 already avoids 0 and O
07:07 < jl2012> there is some discussion to avoid bad word
07:07 < goatpig> Victorsueca: it does, im wondering if the base 32 proposal is gonna
07:07 < jl2012> but anyway, we could only take 4 characters away
07:08 < Victorsueca> it would be base28 then
07:08 < jl2012> no, 26 + 10 - 4 = 32
07:08 < luke-jr> btcdrak: nothing wrong with my DNS seed, so must be on your end?
07:08 < Victorsueca> ahh it's already counted
07:09 < jl2012> so the question is which 4
07:09 < Victorsueca> I would remove 0, O, I and i
07:09 < jl2012> 1-L-I ; 0-O
07:09 < jl2012> if you remove O, you may keep 0
07:11 < goatpig> quick question about SW, can i create a SW tx but have all emtpy witness programs?
07:12 < Victorsueca> goatpig: wouldn't e a segwit transaction at all
07:12 < Victorsueca> be*     
07:12 < jl2012> you mean something like all inputs are P2PKH?
07:12 < goatpig> jl2012: yup
07:12 < goatpig> with with the marker and flag
07:12 < jl2012> you must serialize it in the old way
07:13 < goatpig> ok     
07:14 < jl2012> goatpig: this is a checklist for everything you need to do as wallet dev https://bitcoincore.org/en/segwit_wallet_dev/
07:15 < btcdrak> luke-jr: is is not accessible from 3 geolocations I tried.
07:16 < goatpig> jl2012: ive seen that but didnt go over it. thanks
07:17 < jl2012> feel free to ask for clarification
07:20 < goatpig> once i get the signer out of the way ill be back with more i expect
07:20 < goatpig> thanks for the help =)
07:33 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev     
07:33 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host]     
07:33 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
07:58 < Victorsueca> does bitcoin core support 64-bit POSIX time?
08:11 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev     
08:15 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving]     
08:22 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]     
08:40 -!- rebroad [~rebroad@175.145.183.31] has joined #bitcoin-core-dev     
08:49 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
09:06 -!- tonikt [~tonikt@unaffiliated/tonikt] has joined #bitcoin-core-dev     
09:08 < tonikt> Hi. Is there a way to find out whether "cmpctblock" message is version 1 or 2, just by looking into the content of the message?
09:10 < GitHub141> [bitcoin] MarcoFalke opened pull request #9042: [rpc] ParseHash: Fail when length is not 64 (master...Mf1611-rpcParseHash64) https://github.com/bitcoin/bitcoin/pull/9042
09:11 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
09:21 -!- rebroad [~rebroad@175.145.183.31] has quit [Ping timeout: 244 seconds]     
09:56 -!- alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 256 seconds]     
10:03 -!- Alina-malina [~Alina-mal@37.157.216.159] has joined #bitcoin-core-dev     
10:05 -!- Alina-malina [~Alina-mal@37.157.216.159] has quit [Changing host]     
10:05 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
10:27 < GitHub107> [bitcoin] MarcoFalke opened pull request #9043: [qt] Return useful error message on ATMP failure (master...Mf1611-qtATMPerror) https://github.com/bitcoin/bitcoin/pull/9043
10:32 < luke-jr> btcdrak: well, others seem to hit it fine
10:32 < sipa> tonikt: no
10:32 < luke-jr> Victorsueca: kinda has to, to work on x86_64 Linux
10:33 < luke-jr> sipa: hmm, I understand why that is, but maybe it's going to make life hard for Wireshark >_<
10:34 < sipa> luke-jr: well thankfully the data inside is very similar
10:34 < sipa> 2 uses wtxid and can contains witnesses in transactions
10:34 < sipa> 1 uses txid and can't
10:35 < luke-jr> yes, but maybe something to keep in mind for future versions
10:36 < sipa> agree
10:47 -!- LeMiner [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Read error: Connection reset by peer]     
10:57 -!- wasi [~wasi@183.12.202.62.static.wline.lns.sme.cust.swisscom.ch] has quit [Read error: Connection reset by peer]     
10:57 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []     
11:06 -!- whphhg [whphhg@gateway/vpn/mullvad/x-jobdkmhspvpetgpo] has quit [Ping timeout: 245 seconds]     
11:25 < GitHub139> [bitcoin] paveljanik closed pull request #8468: Do not shadow member variables in serialization (master...20160805_Wshadow_serialization) https://github.com/bitcoin/bitcoin/pull/8468
11:31 -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev     
11:52 < petertodd> sipa: ah cool, I was having problems with 100% cpu usage; my vps provider kept turning the seed node off
11:52 -!- wasi [~wasi@183.12.202.62.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-core-dev     
12:42 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
13:39 -!- CubicEarth [~cubiceart@2601:648:8301:6650:2d71:edf9:82cc:9e5f] has joined #bitcoin-core-dev     
13:40 -!- CubicEarth [~cubiceart@2601:648:8301:6650:2d71:edf9:82cc:9e5f] has quit [Remote host closed the connection]     
14:24 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 268 seconds]     
14:28 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
14:41 -!- CubicEarth [~cubiceart@c-73-15-209-20.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
14:46 -!- CubicEarth [~cubiceart@c-73-15-209-20.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds]     
14:49 < midnightmagic> hah, hilarious: <sipa>    wow, mtgox almost reached $0.5
14:49 < midnightmagic> oldschool
14:50 < sipa> date?
15:05 < Lightsword> hmm, anyone seeing a bunch of spy nodes from AWS? I’m seeing a pattern of 3 connections per IP to my node
15:05 < BlueMatt> thoughts on https://github.com/TheBlueMatt/bitcoin/commit/fe1dc62cef88280d2490a619beded052f313c6fc ?
15:05 < BlueMatt> lightningbot: 3 connections seems low...theres been a bunch of deanonymisation services doing like 10/30 per IP from aws
15:05 < lightningbot> BlueMatt: Error: "3" is not a valid command.
15:05 < BlueMatt> ehh, Lightsword 
15:06 < Lightsword> BlueMatt, 3 connections per IP, but many sets of 3
15:06 < BlueMatt> yea, thats some deanonmization attack services
15:06 < Lightsword> BlueMatt, yeah and it’s bitcoinj which normally gets kicked since I block bloom filters
15:07 < BlueMatt> its obviously bullshit bitcoinj, because they claim to be actual wallets (multibit, etc) but dont send bloom filters :p
15:07 < BlueMatt> i mean, yes, probably based on bitcoinj, but obviously not real wallets
15:07 < sipa> BlueMatt: looks good. no need to do hashing in the message processing thread
15:07 < Lightsword> BlueMatt, yep, there a good way to filter those out?
15:08 < BlueMatt> Lightsword: ban them? run a script to ban anything that looks like /bitcoinj :p
15:09 < BlueMatt> sipa: ok, pr'd
15:09 < GitHub178> [bitcoin] TheBlueMatt opened pull request #9045: Hash P2P messages as they are received instead of at process-time (master...2016-10-p2p-hash) https://github.com/bitcoin/bitcoin/pull/9045
15:12 < Lightsword> BlueMatt, won’t they just fake useragent if I do that? is there an easy way to ban all clients that aren’t full nodes or is that hard to determine?
15:12 < sipa> BlueMatt: i'm a bit surprised we weren't doing that already, actually :)
15:12 < BlueMatt> sipa: i was as well
15:12 < BlueMatt> Lightsword: well at least it'll fix it temporarily :p
15:13 < BlueMatt> Lightsword: you could hack your shit up to request a recent block on connection and ban if they dont respond?
15:19 < gmaxwell> Lightsword: I put up a ban list previously.
15:20 < gmaxwell> http://0bin.net/paste/V0GAccklhV+huNVC#8uKrkZB0NYEHakf+GEf6Bz7995wvwjpYiYddPzAU71e
15:22 < Lightsword> gmaxwell, thanks, think that got most of them
15:23 -!- CubicEarth [~cubiceart@2601:648:8301:6650:9c14:8e41:9ac2:99c3] has joined #bitcoin-core-dev     
15:23 < gmaxwell> 128.101.34.77 is another I've seen more recently.
15:24 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-fcwhdwhohlufbmvs] has quit [Ping timeout: 245 seconds]     
15:24 < sipa> gmaxwell: university of minnesota?
15:24 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-titrtvnojexxwgaq] has joined #bitcoin-core-dev     
15:25 < Lightsword> any idea why they open 3 connections per IP?
15:26 < gmaxwell> they're trying to bypass the relay privacy protections.
15:26 < gmaxwell> right now we leak somewhat more information if you make more connections.
15:27 < gmaxwell> We should fix that.  (I knew that when I put in the currency scheme, but it was better than what we had)
15:34 < CubicEarth> Good day! Does anyone know of a protocol / standard so that wallets from different developers can work together in the creation of a multi-sig address?
15:39 -!- cdecker [~quassel@2a02:aa16:1105:4a80:4970:e3e6:793:b05f] has quit [Ping timeout: 250 seconds]     
15:51 < Victorsueca> Lightsword: I just banned the whole 52.0.0.0/8 space
15:51 < Victorsueca> that will get you rid of most of them
15:59 < TD-Linux> that's effectively all of aws, clearly not a very sustainable solution
16:04 -!- tulip [uid192128@gateway/web/irccloud.com/x-khqrzyulimkczlao] has joined #bitcoin-core-dev     
16:05 < sipa> only 45% of AWE
16:05 < tulip> none of this is sustainable really. rightward suggested an aliveness test by asking for a block from them, but there's already software which transparently proxies these requests to other peers on the network. it's not feasible to IP ban (because they will evade it with more distributed IPs), if we ban on services on subversions they will just change them. 
16:05 < sipa> only 45% of AWS's IPv4 space is under 54/*
16:05 < tulip> s/rightward/lightsword
16:05 < sipa> oh, 52
16:06 < sipa> 36% is under 52/*
16:07 < BlueMatt> argh, whens the next block :(
16:08 < tulip> BlueMatt: 10 minutes time. 
16:11 < tulip> there's no clear solution to these sybil nodes, regardless. the core problem is they obviously have a huge amount of money to spend attacking the network, and consequently you could assume they're getting results if they're continuing to spend money on this regardless. 
16:12 < BlueMatt> well the obvious solution is to fix the bug they're exploiting
16:12 < BlueMatt> if there is no gain from them connecting 10x to each node then hopefully they will go away
16:13 < sipa> is there a reason to assume that hosts in multiple netgroups are harder to obtain than individual ips?
16:14 < BlueMatt> not harder, just more effort and maybe 1.5x cost
16:14 < BlueMatt> well, not hard
16:14 < BlueMatt> tiny bit more effort, not a ton, though
16:14 < sipa> s/harder/costlier/
16:15 < BlueMatt> usually a host will sell you extra ips for reasonably cheap compared to another host somewhere else
16:15 < BlueMatt> but a host that is just proxying traffic is also dirt cheap
16:16 < sipa> otherwise an easy solution would be to use deterministic randomness for the inv push events based on netgroup
16:16 < sipa> so nodes within the same netgroup will see correlated sends
16:17 < BlueMatt> bucketed-announces to most peers is probably the way to go?
16:17 < BlueMatt> it has plenty of issues itself, but at least it solves this specific problem
16:18 < sipa> what do you mean?
16:20 < BlueMatt> gmaxwell's original suggestion of announce live only to eg two statically-selected peers and to the rest, batch inv announcements eg announce every 30 seconds the previous 30 seconds worth of txn you saw
16:22 < BlueMatt> still has correlation issues since prop. is relatively deterministic, but it solves the issue we have now, and you could randomly delay the ~3 peers to which you announce live, as we do now
16:23 < gmaxwell> there are providers that will give you IPs in diverse /8s (even better than /16s) basically for the purpose of tracing users in varrious DHT schemes.
16:24 < BlueMatt> heh, cool
16:27 < gmaxwell> I've never priced it out but I assume it's not horiffically expensive compared to what that one attacker is spending on ec2 costs already.
16:28 < BlueMatt> I'm sure it cant be too much more expensive
16:28 < BlueMatt> aws is stupid expensive
16:39 -!- CubicEarth [~cubiceart@2601:648:8301:6650:9c14:8e41:9ac2:99c3] has quit [Remote host closed the connection]     
16:44 -!- CyrusV [~cyrus@unaffiliated/cyrusv] has left #bitcoin-core-dev []     
17:21 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Quit: Leaving]     
17:34 < BlueMatt> does anyone care about a 0.5ms speedup to CheckBlock?
17:35 < gmaxwell> is it a simple clean change?
17:35 < gmaxwell> I had speedups at that levle (somewhat faster) by merging loops over all the txn.
17:36  * gmaxwell goes looking for those patches that were held off waiting for segwit.
17:36 < BlueMatt> well half of it is (https://github.com/bitcoinfibre/bitcoinfibre/commit/e4884c9f706881fb33ed49f7098e1cea58807e87) the other half is only bareless less so (https://github.com/bitcoinfibre/bitcoinfibre/commit/8bd42b8f763fb736bfde4fba7390d49b9f3cccc6) though i havent benchmarked individually so not sure which is helping
17:36 < BlueMatt> i think it might actually be the first one, which is 2 line diff
17:37 -!- goatpig [5a5c653a@gateway/web/freenode/ip.90.92.101.58] has quit [Quit: Page closed]     
17:37 < sipa> do we even need that check?
17:37 < BlueMatt> which? the transaction-length one? no, it is 100% redundant
17:38 < BlueMatt> the duplicate-inputs one? unclear, probably not but we added it for a reason
17:38 < BlueMatt> dont recall what it was
17:38 < BlueMatt> i do remember that we had a reason, however
17:38 < gmaxwell> was it related to bip30?
17:39 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer]     
17:40 < BlueMatt> hum...i dont see why? :/
17:40 < BlueMatt> lol, all these half-empty blocks are fucking with my benchmarking :/
17:42 < sipa> https://github.com/bitcoin/bitcoin/pull/443
17:42 < sipa> you added this.
17:42 < BlueMatt> yes, and i recall having a reason :(
17:43 < gmaxwell> the pr explains, they were getting relayed.
17:43 < gmaxwell> (or so says the pr)
17:43 < BlueMatt> hum, that seems strange to me?
17:44 < BlueMatt> i mean that was a long time ago, though, i guess before CCoins
17:44 < BlueMatt> CCoinsViewCache stuff should have fixed this?
17:44 < sipa> yes     
17:45 < sipa> i believe the ConnectInputs code at the time may not have been able to catch this
17:45 < BlueMatt> yes, this sounds correct to me
17:46 < sipa> it had an fBlock which was false for mempool txn, and it disabled part of the checks
17:49 < gmaxwell> removal trumps optimizing, though if you want to optimize there, I think I found a 1ms-scale speedup by fusing varrious loops over every transaction in the block into a single loop.
17:52 < BlueMatt> you mean in CheckBlock?
17:52 < BlueMatt> theres only two over-tx loops
17:52 < BlueMatt> no, 3
17:53 < gmaxwell> there are three, coinbase check, checktransaction and sigops check.
17:53 < BlueMatt> yea, should merge that, though the sigops loop is ~free
17:54 < BlueMatt> well, its well under 1ms
17:54 < BlueMatt> well, well under
17:54 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
17:54 < gmaxwell> IIRC I benchmarked it an it was about a 1ms change. 
17:55  * BlueMatt -> dinner
17:55 < BlueMatt> hum, that would surprise me (or your system was slower than mine :p)
17:55 < gmaxwell> well slower probably, -- probably benchmarked it on my laptop.
17:58 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
17:58 < gmaxwell> BlueMatt: or I flubbed the meaurement. 
17:59 < gmaxwell> But I think the opterations can basically be fused into CheckTransaction... e.g. takes a flag that indicates if its allowed to be a coinbase, and returns the sigops count.
18:06 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 250 seconds]     
18:15 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 265 seconds]     
18:18 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
18:19 -!- CubicEarth [~cubiceart@c-73-15-209-20.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
18:20 -!- tulip [uid192128@gateway/web/irccloud.com/x-khqrzyulimkczlao] has quit [Quit: Connection closed for inactivity]     
18:27 -!- CubicEarth [~cubiceart@c-73-15-209-20.hsd1.ca.comcast.net] has quit []     
18:40 -!- rebroad [~rebroad@124.13.30.26] has joined #bitcoin-core-dev     
19:07 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-ykxndtzmafgwcdny] has quit [Quit: Connection closed for inactivity]     
19:20 -!- rebroad [~rebroad@124.13.30.26] has quit [Ping timeout: 265 seconds]     
19:50 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-titrtvnojexxwgaq] has quit [Quit: Connection closed for inactivity]     
19:56 -!- rebroad [~rebroad@175.142.3.133] has joined #bitcoin-core-dev     
20:04 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 245 seconds]     
20:08 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
20:15 < gmaxwell> BlueMatt: in 9045 what initilizes data_hash?
20:16 < BlueMatt> gmaxwell: default-initialized to null
20:16 < BlueMatt> its a class
20:26 < BlueMatt> gmaxwell: anyway, i'll look at optimizing it a bit tomorrow...see if i can write a bench_bitcoin thinggy for it
20:27 < BlueMatt> CheckBlock is not-insignificant in terms of time from wire to udp broadcast (which is right before disk write in AcceptBlock - same place compact block announcement will end up)
20:27 < BlueMatt> ofc actual block deserialization is really the largest time sink
20:29 < gmaxwell> I don't believe you. http://0bin.net/paste/KLQCR8JpdMu5i-x2#VitVZ6nLLdJSu+EnHlCy70e95NLkWxxGgoeNtjY7JmZ
20:36 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
20:36 < gmaxwell> BlueMatt: ^
20:37 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev     
20:37 < sipa> gmaxwell: ints are default not initialized
20:40 < gmaxwell> oh, matt was saying the uint256 constructor is initing it. I thought he was saying because CNetMessage is a class all its members are initilized.
20:40 < sipa> yes, it is
20:40 < sipa> CNetMessage is a class, so all its members have their default constructor called
20:41 < gmaxwell> Yes, I'd just missed that the hash was a uint256. (or rather that a uint256 behaves differently from a primitive type. :) )
20:41 < sipa> we could in theory not initialize the member chars in a uint5
20:41 < sipa> *uintw56
20:42 < sipa> **uint256
20:42 < sipa> but i think that would surprise people
20:59 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 268 seconds]     
20:59 -!- rebroad [~rebroad@175.142.3.133] has quit [Ping timeout: 244 seconds]     
21:01 -!- rebroad [~rebroad@175.145.183.215] has joined #bitcoin-core-dev     
21:03 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
21:23 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:24 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:48 -!- rebroad [~rebroad@175.145.183.215] has quit [Ping timeout: 265 seconds]     
21:51 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
21:52 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
21:53 -!- rebroad [~rebroad@175.145.183.215] has joined #bitcoin-core-dev     
22:04 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
22:05 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
23:23 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-kpwuapjdhnhmauub] has joined #bitcoin-core-dev     
23:43 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
23:44 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
23:58 -!- rebroad [~rebroad@175.145.183.215] has quit [Ping timeout: 250 seconds]     
23:58 -!- wasi [~wasi@183.12.202.62.static.wline.lns.sme.cust.swisscom.ch] has quit [Ping timeout: 260 seconds]