--- Day changed Wed Aug 10 2016
00:03 < jonasschnelli> Does bitcoin-cores UPNP (or UPNP in general) uses nat traversal or ICE? Or is the only way to get connection from the outside if your router supports uPNP and opens the port?
00:07 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
00:14 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
00:15 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
00:16 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:18 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:19 -!- BashCo__ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:19 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
00:19 < gmaxwell> jonasschnelli: only opening the port.
00:20 < jonasschnelli> gmaxwell: Okay. Thanks.
00:20 < sipa> and for discovering external ip
00:20 < jonasschnelli> Would ICE works for Bitcoin? Or would that require UDP? (maybe off-topic here)
00:22 < GitHub4> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/484312bda2d4...edebf425a2df
00:22 < GitHub4> bitcoin/master 160f895 Luke Dashjr: Bugfix: Use pre-BIP141 sigops until segwit activates
00:22 < GitHub4> bitcoin/master 239cbd2 Luke Dashjr: qa/rpc-tests/segwit: Test GBT sigops before and after activation
00:22 < GitHub4> bitcoin/master edebf42 Wladimir J. van der Laan: Merge #8489: Bugfix: Use pre-BIP141 sigops until segwit activates (GBT)...
00:22 < GitHub114> [bitcoin] laanwj closed pull request #8489: Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (master...bugfix_gbt_sigops_presegwit) https://github.com/bitcoin/bitcoin/pull/8489
00:22 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 258 seconds]
00:23 < GitHub28> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/114f7e944b1c...edc2c700a75c
00:23 < GitHub28> bitcoin/0.13 3f65ba2 Pieter Wuille: Treat high-sigop transactions as larger rather than rejecting them
00:23 < GitHub79> [bitcoin] laanwj closed pull request #8438: [0.13] backport: Treat high-sigop transactions as larger rather than rejecting them (0.13...btc-13-sigops) https://github.com/bitcoin/bitcoin/pull/8438
00:23 < GitHub28> bitcoin/0.13 edc2c70 Wladimir J. van der Laan: Merge #8438: [0.13] backport: Treat high-sigop transactions as larger rather than rejecting them...
00:23 < gmaxwell> jonasschnelli: general traversal requires third party introduction, and no one technique generally works (and traversal for TCP almost never works)... I think firefox has a significant fraction of a million lines of code for nat traversal w/ rtcweb.
00:24 < jonasschnelli> heh.. okay. I see.
00:24 < gmaxwell> IMO, using tor hidden services is a /simpler/ way to bypass nat, as crazy as that sounds.
00:25  * jonasschnelli is thinking...
00:27 < jonasschnelli> gmaxwell: So using tor hidden service over 443 would probably allow bypassing firewalls (assume some large company firewalls where only 80,443 is open) to connect to the bitcoin network?
00:28 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:30 < gmaxwell> jonasschnelli: normally tor connections are on 443 and look superficially like regular https connections.
00:30 < jonasschnelli> gmaxwell: thanks.
00:30 < gmaxwell> and as long as you can connect out to the tor network you can run a hidden service where people can connect in.
00:31 -!- BashCo__ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 276 seconds]
00:32 < gmaxwell> sipa: we need to think about a replacement for addr messages at some point.
00:32 < gmaxwell> In particular, I2P and tor NG hidden services need more than 128 bits.
00:33 < gmaxwell> and it would be good to be able to carry a bit more metadata.
00:34 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-core-dev
00:35 -!- laurentmt [~Thunderbi@80.215.178.84] has joined #bitcoin-core-dev
00:35 < sipa> gmaxwell: well in light of bip151... should they also carry a host pubkey?
00:36 < jonasschnelli> sipa: that would open the trust network problem?
00:36 < jonasschnelli> I think only pre-sharing makes more sense?
00:37 < jonasschnelli> Or what if malicious peers change the host in the addr messages?
00:37 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
00:38 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:39 -!- so_ is now known as so
00:39 < gmaxwell> sipa: I don't think thats very useful.
00:39 < GitHub30> [bitcoin] laanwj closed pull request #8465: [0.13] Document reindexing changes (0.13...docreindex) https://github.com/bitcoin/bitcoin/pull/8465
00:39 < GitHub185> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/edc2c700a75c...45c656b914f0
00:39 < GitHub185> bitcoin/0.13 b49d963 Pieter Wuille: Document reindexing changes
00:39 < GitHub185> bitcoin/0.13 45c656b Wladimir J. van der Laan: Merge #8465: [0.13] Document reindexing changes...
00:40 < gmaxwell> largely unrelated to BIP151 there is a question of it you'd like to have long lived node identities.
00:40 < gmaxwell> and then support a 'connect to identity'
00:40 < gmaxwell> allowing you to, e.g. maintain connections to known well performing peers.
00:41 < gmaxwell> But that is basically 180degrees off of all the fingerprinting resistance we've worked on in the past.
00:41 < jonasschnelli> gmaxwell: I guess theres nothing holding back power users of doing this with the current bip151 (+auth) specification..
00:42 < gmaxwell> in that model you wouldn't have a 'addr' message, you'd have a 'nodeid' message, which is announcing a pubkey and one or more addresses it can be reached on, signed by that key.
00:42 < jonasschnelli> ah
00:42 < gmaxwell> so then there is a 'what if peers change the host' -- nothing can be changed because it's signed. And thing addrman would track is not addresses but IDs.. (and then when it wants to connect to an ID it would take that ID's latest addr announcement).
00:43 < sipa> gmaxwell: hmm, that's not what i'm thinking of
00:43  * jonasschnelli hears Eric Voskuil grumbling... 
00:43 < gmaxwell> I know, but what you were thinking of is not useful.
00:44 < sipa> gmaxwell: more: we currently treat IP addresses as identities
00:44 < sipa> when you connect to the same IP again, you expect it to be the same identity
00:44 < gmaxwell> just stapling a pubkey to an addr message accomplishes nothing useful, anyone can and would change it in flight. If it doesn't match 'oh well, someone changed it in flight or the host changed'.
00:44 < gmaxwell> you might as well have just asked the host for a pubkey when you connected to it. :)
00:44 < jonasschnelli> Only if there would be a signature of the ip/port?
00:45 < sipa> when a peer tells you about a particular IP, you want to make sure that what you're connecting to is actually who they meant
00:46 < gmaxwell> but thats not really part of the addr message, its non-transitive.
00:46 < sipa> agree
00:46 < sipa> and i don't think we want a web-of-trust between nodes :)
00:47 < gmaxwell> I don't think thats very useful. If nodes really did have a persistant tracable identity, "this node was good in the past, I want to find it again" would be a useful service.
00:47 < gmaxwell> But it's in conflict with avoiding fingerprinting.
00:49 < GitHub120> [bitcoin] luke-jr opened pull request #8495: [0.13] Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (0.13...bugfix_gbt_sigops_presegwit-0.13.x) https://github.com/bitcoin/bitcoin/pull/8495
00:49 < gmaxwell> I suppose there is a middle ground where you can relay messages signed by P + H(P||blockhash[height//144*144]) or the like, and so if you know P (e.g. having previously been configured to authenticate towards that node), you can locate its updated addr messages.
00:50 < gmaxwell> But to everyone else host with key P does not have a long lived identity.
01:28 -!- Naphex [~naphex@unaffiliated/naphex] has quit [Quit: leaving]
01:37 -!- harrymm [~wayne@178.162.211.236] has quit [Ping timeout: 240 seconds]
02:17 < GitHub177> [bitcoin] MarcoFalke closed pull request #8477: [qa] Temporarily disable ipv6 in rpcbind test (master...Mf1608-qaIpv6) https://github.com/bitcoin/bitcoin/pull/8477
02:35 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has left #bitcoin-core-dev []
02:43 -!- Giszmo [~leo@ip5f5ac08d.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev
02:45 -!- Justinus [~Justinus@192.122.131.41] has quit [Remote host closed the connection]
03:17 -!- thesnark [~mike@unaffiliated/thesnark] has quit [Remote host closed the connection]
03:18 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has joined #bitcoin-core-dev
03:33 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
03:48 -!- thesnark [~mike@unaffiliated/thesnark] has joined #bitcoin-core-dev
04:17 -!- cryptapus_ [~cryptapus@87.254.202.132] has joined #bitcoin-core-dev
04:17 -!- cryptapus_ [~cryptapus@87.254.202.132] has quit [Changing host]
04:17 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
04:18 -!- cryptapus_ is now known as cryptapus
04:20 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
04:21 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
04:24 -!- MarcoFalke [~marco@5.199.182.203] has joined #bitcoin-core-dev
04:28 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
04:28 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
04:32 -!- AaronvanW [~ewout@145.97.231.198] has joined #bitcoin-core-dev
04:32 -!- AaronvanW [~ewout@145.97.231.198] has quit [Changing host]
04:32 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:33 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 265 seconds]
04:39 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has quit [Quit: Textual IRC Client: www.textualapp.com]
04:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:56 -!- MarcoFalke [~marco@5.199.182.203] has quit [Quit: MarcoFalke]
05:56 -!- MarcoFalke [~marco@5.199.182.203] has joined #bitcoin-core-dev
06:04 < GitHub52> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/8b0eee66e9c9057b6e53bb1f4a0a3821083e5df0
06:04 < GitHub52> bitcoin/0.13 8b0eee6 Luke Dashjr: Bugfix: Use pre-BIP141 sigops until segwit activates...
06:05 < GitHub7> [bitcoin] laanwj closed pull request #8495: [0.13] Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (0.13...bugfix_gbt_sigops_presegwit-0.13.x) https://github.com/bitcoin/bitcoin/pull/8495
06:06 -!- sgeisler [~sebastian@x04c11a.wh7.tu-dresden.de] has quit [Ping timeout: 244 seconds]
06:30 -!- cryptapus_ [~cryptapus@66.119.84.15] has joined #bitcoin-core-dev
06:30 -!- cryptapus_ [~cryptapus@66.119.84.15] has quit [Changing host]
06:30 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
06:33 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
06:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]
06:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:57 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
06:57 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
07:05 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Quit: leaving]
07:27 -!- whphhg_ [whphhg@gateway/vpn/mullvad/x-yaaybitwseqyowua] has joined #bitcoin-core-dev
07:30 -!- whphhg [~whphhg@unaffiliated/whphhg] has quit [Read error: Connection reset by peer]
07:32 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
07:39 -!- whphhg_ is now known as whphhg
07:40 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jnehgdrhqmizioit] has joined #bitcoin-core-dev
07:40 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!]
07:41 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
07:59 -!- cryptapus_ is now known as cryptapus
08:03 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
08:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]
08:23 -!- MarcoFalke [~marco@5.199.182.203] has left #bitcoin-core-dev []
08:29 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
08:32 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
08:38 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
08:44 -!- rubensayshi [~ruben@82.201.93.169] has quit [Ping timeout: 265 seconds]
08:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
09:10 -!- FNinTak [~jonhbit@tsarviajado.media.mit.edu] has quit [Quit: Leaving]
09:11 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection]
09:11 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection]
09:17 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
09:19 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
09:23 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
09:49 -!- afk11 [~afk11@109.255.154.81] has joined #bitcoin-core-dev
09:49 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host]
09:49 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
09:52 -!- laurentmt [~Thunderbi@80.215.178.84] has quit [Quit: laurentmt]
09:56 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 258 seconds]
10:00 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-cncxmjzysqxjdjqs] has quit [Quit: Connection closed for inactivity]
10:05 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jnehgdrhqmizioit] has quit [Quit: Connection closed for inactivity]
10:10 -!- afk11 [~afk11@109.255.154.81] has joined #bitcoin-core-dev
10:10 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host]
10:10 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
10:13 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
10:27 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nlyizpyiccujtsau] has joined #bitcoin-core-dev
10:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:52 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
10:53 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
11:01 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
11:19 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
11:35 < cfields> luke-jr: ping. gbt sends out the !segwit rule even if there are no segwit transactions included. that goes against my reading of the spec.
11:35 < cfields> luke-jr: (i'm implementing the bip9 gbt changes in ckpool)
11:36 < luke-jr> MAY != MUST
11:36 < gmaxwell> cfields: hm. It would be pretty surprising if the behavior modulates based on tx in mempool. I.e. your stuff catches fire when you're not looking.
11:37 < sipa> cfields: agree with luke-jr and gmaxwell here: you'd rather have mining infrastructure break at upgrade time than at segwit activation time
11:37 < sipa> where it potentially happen across all miners simultaneously
11:37 < luke-jr> '!' is required if there are such transactions, but optional (for non-segwit miners only) if there are not.
11:38 < gmaxwell> !segwit is super confusing. :(
11:38 < gribble> Error: "segwit" is not a valid command.
11:38 < gmaxwell> it even confuses gribble.
11:38 < luke-jr> lol
11:38 < cfields> heh, has not activated on gribble yet
11:38 < sipa> haha
11:38 < luke-jr> '*' would have probably made more sense, but I think it's too late to change it now?
11:39 < sipa> i never considered that '!' as part of a name would be interpreted as "not"
11:39 < sipa> and agree - i think it's not worth changing at this point
11:40 < cfields> heh. I read it as "segwit!" rather than "!segwit" and it's more clear :)
11:40 < sipa> yeah. it's "segwit! be aware!"
11:40 < cfields> either way, i'd say it's not entirely clear in the spec. I (wrongly) first implemented coinbase insertion based on the "!segwit" flag's presence.
11:41 < sipa> cfields: that's fine
11:41 < cfields> "On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction)..."
11:41 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-eginzemsmlwnjfer] has joined #bitcoin-core-dev
11:41 < sipa> cfields: ah, no
11:42 < sipa> it means "you must understand why segwit means before you can mine on top of this, because things may have changed beyond normal transaction inclusion selection"
11:43 < cfields> got it. Ok, I'll PR a few clarifications there. Was trying to implement soley based on reading of bip9 changes.
11:43 < luke-jr> cfields: what's wrong with how you implemented it?
11:43 < sipa> but i don't see why "!segwit" -> "make coinbase commitment" would be a problem
11:43 < cfields> luke-jr: causes cb insertion even with no witness data
11:43 < sipa> cfields: which is fine
11:43 < sipa> just slightly wasteful
11:44 < gmaxwell> s/fine/desirable as far as I know.
11:44 < cfields> mm, i assumed the opposite. why desirable?
11:44 < sipa> because you'd test your infrastructures' compatibility ahead of time
11:45 < gmaxwell> Then the miner (and the network) can see their system correctly functioning.
11:45 < sipa> so things don't break all over the network when segwit activates
11:45 < gmaxwell> Otherwise you get the 'segwit tx shows up, now all the hashpower drops offline'
11:45 < cfields> ok, sure.
11:50 -!- murch [~murch@p4FE3832A.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
11:50 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: I tried to dereference a null pointer... and I succeeded!]
11:57 -!- shesek [~shesek@bzq-84-110-209-223.red.bezeqint.net] has joined #bitcoin-core-dev
11:57 -!- execut3 [~shesek@bzq-84-110-209-223.red.bezeqint.net] has joined #bitcoin-core-dev
11:59 < cfields> sipa: in that case, can we append default_witness_commitment based on activation status rather than witness data presence? 
12:00 < sipa> cfields: sure
12:00 < sipa> it's optional even when there are no witnesses in any transaction
12:00 < sipa> the rule is (after activation): 1) if the witness commitment is present, it must be correct 2) if there are any witnesses in any transaction, the witness commitment must be present
12:02  * luke-jr suspects nobody will care if it's present before activation either, but that's probably less of a good idea
12:02 < gmaxwell> I think it's a good idea to have it present as soon as software is updated.
12:02 < gmaxwell> otherwise there is a behavior change at activation that might go wrong.
12:03 < sipa> it even gives us a way to observe miner adoption before the start date
12:04 < luke-jr> hmm, that's a point
12:04 < cfields> sure, i can do it unconditionally if desired
12:06 < cfields> we could also have 13.0 warn on 1), though it's a bit late for that
12:06 -!- achow101 [~achow101@pool-108-2-70-199.phlapa.fios.verizon.net] has quit [Ping timeout: 240 seconds]
12:18 -!- achow101 [~achow101@pool-108-2-70-199.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
12:21 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
12:23 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
12:40 -!- d_t [~textual@83-244-233-136.cust-83.exponential-e.net] has joined #bitcoin-core-dev
12:58 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
13:00 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
13:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
13:13 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 260 seconds]
13:23 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]
13:28 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
13:29 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 276 seconds]
13:35 -!- afk11 [~afk11@109.255.154.81] has joined #bitcoin-core-dev
13:35 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host]
13:35 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
14:10 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-eginzemsmlwnjfer] has quit [Quit: Connection closed for inactivity]
14:18 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has quit [Ping timeout: 264 seconds]
14:19 -!- alfas [256118e2@gateway/web/freenode/ip.37.97.24.226] has joined #bitcoin-core-dev
14:19 < alfas> luke
14:20 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has joined #bitcoin-core-dev
14:23 -!- alfas [256118e2@gateway/web/freenode/ip.37.97.24.226] has quit [Ping timeout: 250 seconds]
14:25 -!- murch [~murch@p4FE3832A.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
14:25 -!- alfas [~asl@37.97.24.226] has joined #bitcoin-core-dev
14:25 -!- alfas [~asl@37.97.24.226] has quit [Client Quit]
14:30 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Quit: ZNC 1.6.3 - http://znc.in]
15:10 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
15:11 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection]
15:14 -!- zooko [~user@2601:281:8080:7af5:e0fa:fc99:73c4:fc79] has joined #bitcoin-core-dev
15:20 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
15:24 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
15:25 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
15:28 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 252 seconds]
15:28 -!- Guyver2_ is now known as Guyver2
15:31 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:44 < jtimon> kanzure: https://github.com/bitcoin/bitcoin/pull/8493 looks like a long branch (because it has many tiny steps commits that could be squashed) but it's only  +373 −94 , please check it out
15:45 < kanzure> i have no bandwidth to physically test this
15:46 < kanzure> oh it looks like nothing added
15:46 < jtimon> BlueMatt: adviced to just move to the next simplest things to expose instead of trying to encapsulate verifyBlock without exposing anything new
15:46 < sipa> i now envision kanzure implementing this patch on a babbage machine, and then furiously turning the handles until it works
15:46 < kanzure> sipa: yeah i can be fairly serious about my esoteric architectures
15:47 < jtimon> kanzure: alternative APIs very welcomed
15:48 < kanzure> btw there is a typo in your pull request title
15:48 < jtimon> or alternative refactors, whatever, let's just try to force that PR to rebase and become smaller than +373 −94
15:49 < jtimon> kanzure: mhmm, it seems I wrote Expose correctly and I made up the other 3 words, can you be more specific?
15:50 < kanzure> 'libcosnensus'
15:50 < jtimon> oh, right
15:51 -!- d_t [~textual@83-244-233-136.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
15:54 < kanzure> small concerns about name of 'ContextualCheckHeader' but this is only a nit
15:55 < kanzure> and i think this name is inherited from old code anyway, so it's a tough nit to do anything about
15:57 < jtimon> BlueMatt:  also adviced not to be afraid of creating ugly wrappers or duplicating code if that was simpler to expose something
15:58 < jtimon> in this case I'm renaming main::ContextualCheckBlockHeader to Consensus::ContextualCheckHeader, but I'm keeping one with the original name in cppwrappers.o to avoid disruption in main
15:59 < jtimon> but yeah "Consensus::ContextualCheckHeader" it's a new name and it's open for bike-shedding, just like Consensus::VerifyHeader
16:01 < jtimon> I added Pow as a prefix for the 2 pow.o functions that needed a wrapper, also open for bikeshedding (but ideally the necessary preparations for not needing the wrappers should be done beforehand IMO)
16:03 < jtimon> if we do that, we don't even need to rename ContextualCheckBlockHeader,I don't care either way, for me it's just two paths to the same place
16:04 < jtimon> but yeah please give your opinion
16:05 < jtimon> I'm sure that some early nits can save me some work while turning jtimon/0.13-consensus-flags into another PR (WIP)
16:06 < jtimon> I want to expose get_flags too, but that sounds more crazy than verifyHeaders I think
16:09 < jtimon> where I would like more input is in https://github.com/bitcoin/bitcoin/pull/8493/files#diff-c2a099d775bac1dccc5f146a3cda81b8R11
16:10 < jtimon> or alternatives
16:13 < jtimon> and of course tests and testing
16:14 < jtimon> anyway, spammed the channel enough already...just please review
16:15 -!- d_t [~textual@83-244-233-136.cust-83.exponential-e.net] has joined #bitcoin-core-dev
16:15 -!- d_t [~textual@83-244-233-136.cust-83.exponential-e.net] has quit [Max SendQ exceeded]
16:15 -!- d_t [~textual@83-244-233-136.cust-83.exponential-e.net] has joined #bitcoin-core-dev
16:16 -!- d_t [~textual@83-244-233-136.cust-83.exponential-e.net] has quit [Client Quit]
17:16 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.]
17:31 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
18:05 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nlyizpyiccujtsau] has quit [Quit: Connection closed for inactivity]
18:08 -!- Giszmo [~leo@ip5f5ac08d.dynamic.kabel-deutschland.de] has quit [Quit: Leaving.]
18:15 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
18:16 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
19:05 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-ltfywrbjgfjxzvoq] has joined #bitcoin-core-dev
19:18 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 244 seconds]
19:28 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
19:30 -!- nibor [~nibor@185.9.34.66] has quit [Read error: Connection reset by peer]
19:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
20:44 < GitHub104> [bitcoin] jtimon opened pull request #8498: Optimization: Minimize the number of times it is checked that no money... (master...0.13-consensus-inputs) https://github.com/bitcoin/bitcoin/pull/8498
20:44 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 250 seconds]
20:45 -!- eenoch [~eenoch@unaffiliated/eenoch] has quit [Ping timeout: 250 seconds]
20:46 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 258 seconds]
20:47 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
20:47 -!- ryan-c [~ryan@znc.rya.nc] has quit [Ping timeout: 250 seconds]
20:47 -!- eenoch [~eenoch@unaffiliated/eenoch] has joined #bitcoin-core-dev
20:48 -!- achow101 [~achow101@pool-108-2-70-199.phlapa.fios.verizon.net] has quit [Ping timeout: 250 seconds]
20:48 -!- go1111111 [~go1111111@104.200.154.22] has quit [Ping timeout: 250 seconds]
20:49 -!- Silence_ [jb@ip.fi] has quit [Ping timeout: 258 seconds]
20:49 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]
20:49 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
20:49 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Client Quit]
20:50 -!- Silence_ [jb@ip.fi] has joined #bitcoin-core-dev
20:53 -!- ryan-c [~ryan@znc.rya.nc] has joined #bitcoin-core-dev
20:53 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev
20:53 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
20:55 -!- go1111111 [~go1111111@104.200.154.22] has joined #bitcoin-core-dev
20:55 -!- achow101 [~achow101@pool-108-2-70-199.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
21:39 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
21:51 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]
21:56 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 244 seconds]
22:31 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
22:35 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]
22:39 -!- murch [~murch@p4FE38C50.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
22:40 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-ltfywrbjgfjxzvoq] has quit [Quit: Connection closed for inactivity]
22:41 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev
22:42 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
22:48 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 250 seconds]
22:48 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds]
23:20 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:21 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:42 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:43 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:47 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
23:56 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
23:58 < dcousens> If I submit an incorrectly formed CLTV transaction,  I get a Error 64: non-mandatory-script-flags error... is that odd considering CLTV is active?
23:58 < dcousens> I know it comes down to  Mandatory script verification flags that all new blocks must comply with for
23:58 < dcousens> I know it comes down MANDATORY_SCRIPT_VERIFY_FLAGS* being const and only has P2SH
23:59 < dcousens> Sorry, mis-type