12016-08-10T00:01:35 *** d_t has quit IRC
22016-08-10T00:45:53 *** Chris_Stewart_5 has quit IRC
32016-08-10T00:49:05 *** Chris_Stewart_5 has joined #bitcoin-core-dev
42016-08-10T00:53:02 *** Alopex has quit IRC
52016-08-10T00:54:07 *** Alopex has joined #bitcoin-core-dev
62016-08-10T01:15:51 *** Ylbam has quit IRC
72016-08-10T01:23:27 *** Alopex has quit IRC
82016-08-10T01:24:32 *** Alopex has joined #bitcoin-core-dev
92016-08-10T01:28:37 *** FNinTak has quit IRC
102016-08-10T01:29:45 *** spudowiar has quit IRC
112016-08-10T01:34:12 *** Alopex has quit IRC
122016-08-10T01:35:17 *** Alopex has joined #bitcoin-core-dev
132016-08-10T01:35:36 *** spudowiar has joined #bitcoin-core-dev
142016-08-10T01:51:52 *** FNinTak has joined #bitcoin-core-dev
152016-08-10T01:59:49 <Chris_Stewart_5> How do you distinguish between a txid node and non txid node in a MerkleBlock message? Is it simply the fact that that we have hit the maximum height on the binary tree?
162016-08-10T01:59:51 <Chris_Stewart_5> https://bitcoin.org/en/developer-reference#parsing-a-merkleblock-message
172016-08-10T02:09:14 *** aalex has quit IRC
182016-08-10T02:10:28 <achow101> sipa: well clearly it doesn't work
192016-08-10T02:11:10 <sipa> achow101: sorry, can you give a link to your compile output again?
202016-08-10T02:11:14 <sipa> Chris_Stewart_5: eh...
212016-08-10T02:12:30 <sipa> Chris_Stewart_5: right, you do by knowing the transaction count
222016-08-10T02:13:38 *** aalex has joined #bitcoin-core-dev
232016-08-10T02:14:20 <Chris_Stewart_5> sipa: Is there any other way with just a merkle block message? The docs distinguish between txids nodes (leaves in the full merkle tree) and non txid nodes
242016-08-10T02:14:55 <Chris_Stewart_5> but, from what I can tell, you still need to compute the full tree with empty nodes to make that distinguishment? Am I missing something?
252016-08-10T02:17:07 *** dstadulis has joined #bitcoin-core-dev
262016-08-10T02:20:35 <achow101> sipa: https://gist.github.com/achow101/841c0c5bedaa3e0a6f641fa94b8e8c67
272016-08-10T02:26:21 <sipa> Chris_Stewart_5: no you don't
282016-08-10T02:28:24 <sipa> achow101: that really looks like you're compiling without c++11
292016-08-10T02:29:59 <achow101> any idea on how to fix it?I'm using the lates versions I caaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
302016-08-10T02:29:59 <achow101> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
312016-08-10T02:30:00 <achow101> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaan get
322016-08-10T02:30:22 *** Chris_Stewart_5 has quit IRC
332016-08-10T02:30:53 <sipa> achow101: what are you doing exactly?
342016-08-10T02:30:56 <sipa> achow101: is this gitian?
352016-08-10T02:31:22 *** achow101_ has joined #bitcoin-core-dev
362016-08-10T02:31:39 <achow101_> sorry the keyboard on my other computer spazzed out
372016-08-10T02:31:49 <achow101_> it isn't gitian
382016-08-10T02:32:05 <achow101_> gitian works fine
392016-08-10T02:32:11 <sipa> so what are you doing?
402016-08-10T02:32:44 <achow101_> cross compiling master for windows on Ubuntu 15.10
412016-08-10T02:35:39 <sipa> using depends?
422016-08-10T02:36:11 <achow101_> yes
432016-08-10T02:37:13 *** Chris_Stewart_5 has joined #bitcoin-core-dev
442016-08-10T02:37:29 <Chris_Stewart_5> sipa: What is the trick then to distinguish, the docs say:
452016-08-10T02:37:40 <sipa> you just walk the tree
462016-08-10T02:37:52 <sipa> you know the depth of each node you traverse
472016-08-10T02:38:03 <sipa> you know the total depth of the tree at every point
482016-08-10T02:38:18 <sipa> the rules tell you whether to descend or not
492016-08-10T02:38:48 <Chris_Stewart_5> ugh thank you for the help -- been talking (or thinking) myself in circles all day. That makes sense
502016-08-10T02:39:04 <Chris_Stewart_5> wait -- you derive the height from the tx count right?
512016-08-10T02:39:15 <Chris_Stewart_5> 2 ^ n?
522016-08-10T02:39:51 <sipa> yes
532016-08-10T02:40:53 <Chris_Stewart_5> much appreciated. Did you have a chance to look at my pull request for property based testing? Thoughts if so?
542016-08-10T02:43:12 *** achow101_ has quit IRC
552016-08-10T02:44:17 *** achow101_ has joined #bitcoin-core-dev
562016-08-10T02:44:44 <sipa> Chris_Stewart_5: i haven't looked at it, but no concerns about adding such a framework
572016-08-10T02:44:57 * sipa dinner
582016-08-10T02:57:32 *** dstadulis has quit IRC
592016-08-10T02:59:16 *** dstadulis has joined #bitcoin-core-dev
602016-08-10T03:03:32 *** achow101_ has quit IRC
612016-08-10T03:14:11 *** Alopex has quit IRC
622016-08-10T03:15:16 *** Alopex has joined #bitcoin-core-dev
632016-08-10T03:15:22 *** jtimon has quit IRC
642016-08-10T03:18:32 *** Chris_Stewart_5 has quit IRC
652016-08-10T03:22:35 *** sdfsdfsdfdsf has joined #bitcoin-core-dev
662016-08-10T03:24:00 *** sdfsdfsdfdsf has quit IRC
672016-08-10T03:24:55 *** nibor has quit IRC
682016-08-10T03:25:22 *** nibor has joined #bitcoin-core-dev
692016-08-10T03:27:21 *** Alopex has quit IRC
702016-08-10T03:28:26 *** Alopex has joined #bitcoin-core-dev
712016-08-10T03:32:50 *** afk11 has quit IRC
722016-08-10T03:40:07 *** mojan has joined #bitcoin-core-dev
732016-08-10T03:40:22 *** Alopex has quit IRC
742016-08-10T03:41:27 *** Alopex has joined #bitcoin-core-dev
752016-08-10T03:50:17 *** dstadulis has quit IRC
762016-08-10T03:51:09 *** mojan has quit IRC
772016-08-10T03:51:26 *** Alopex has quit IRC
782016-08-10T03:52:31 *** Alopex has joined #bitcoin-core-dev
792016-08-10T04:14:12 *** Alopex has quit IRC
802016-08-10T04:15:17 *** Alopex has joined #bitcoin-core-dev
812016-08-10T04:25:09 *** nibor has quit IRC
822016-08-10T04:25:33 *** nibor has joined #bitcoin-core-dev
832016-08-10T04:29:07 *** Alopex has quit IRC
842016-08-10T04:29:47 *** spudowiar has quit IRC
852016-08-10T04:30:12 *** Alopex has joined #bitcoin-core-dev
862016-08-10T04:40:06 *** fengling has quit IRC
872016-08-10T04:43:17 *** Alopex has quit IRC
882016-08-10T04:44:22 *** Alopex has joined #bitcoin-core-dev
892016-08-10T04:50:08 *** d_t has joined #bitcoin-core-dev
902016-08-10T04:54:21 *** Alopex has quit IRC
912016-08-10T04:54:33 *** d_t has quit IRC
922016-08-10T04:55:26 *** Alopex has joined #bitcoin-core-dev
932016-08-10T05:03:37 *** davec has quit IRC
942016-08-10T05:14:06 *** Alopex has quit IRC
952016-08-10T05:15:11 *** Alopex has joined #bitcoin-core-dev
962016-08-10T05:29:29 *** fengling has joined #bitcoin-core-dev
972016-08-10T05:32:11 *** Alopex has quit IRC
982016-08-10T05:33:16 *** Alopex has joined #bitcoin-core-dev
992016-08-10T05:43:16 *** Alopex has quit IRC
1002016-08-10T05:44:21 *** Alopex has joined #bitcoin-core-dev
1012016-08-10T05:48:21 *** execut3 has quit IRC
1022016-08-10T05:48:29 *** shesek has quit IRC
1032016-08-10T05:49:38 <GitHub128> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6e6ab2c32382...484312bda2d4
1042016-08-10T05:49:38 <GitHub128> bitcoin/master 4a35e0f Pavel JanÃk: Do not shadow members in dbwrapper
1052016-08-10T05:49:39 <GitHub128> bitcoin/master 484312b Pieter Wuille: Merge #8467: [Trivial] Do not shadow members in dbwrapper...
1062016-08-10T05:49:49 <GitHub86> [bitcoin] sipa closed pull request #8467: [Trivial] Do not shadow members in dbwrapper (master...20160805_Wshadow_dbwrapper) https://github.com/bitcoin/bitcoin/pull/8467
1072016-08-10T06:09:33 *** davec has joined #bitcoin-core-dev
1082016-08-10T06:10:36 *** jannes has quit IRC
1092016-08-10T06:13:01 *** MarcoFalke has joined #bitcoin-core-dev
1102016-08-10T06:39:16 *** davec has quit IRC
1112016-08-10T06:43:34 <GitHub189> [bitcoin] MarcoFalke opened pull request #8494: [init, wallet] ParameterInteraction() iff wallet enabled (master...Mf1608-initWalletParamInt) https://github.com/bitcoin/bitcoin/pull/8494
1122016-08-10T06:50:10 *** BashCo has quit IRC
1132016-08-10T06:50:49 *** jannes has joined #bitcoin-core-dev
1142016-08-10T06:55:11 *** Alopex has quit IRC
1152016-08-10T06:55:44 *** crudel has joined #bitcoin-core-dev
1162016-08-10T06:56:16 *** Alopex has joined #bitcoin-core-dev
1172016-08-10T06:59:16 *** tucenaber has quit IRC
1182016-08-10T07:03:02 <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?
1192016-08-10T07:07:45 *** davec has joined #bitcoin-core-dev
1202016-08-10T07:14:01 *** Alopex has quit IRC
1212016-08-10T07:15:06 *** Alopex has joined #bitcoin-core-dev
1222016-08-10T07:16:59 *** BashCo has joined #bitcoin-core-dev
1232016-08-10T07:18:48 *** BashCo_ has joined #bitcoin-core-dev
1242016-08-10T07:19:48 *** BashCo__ has joined #bitcoin-core-dev
1252016-08-10T07:19:50 *** BashCo_ has quit IRC
1262016-08-10T07:19:56 <gmaxwell> jonasschnelli: only opening the port.
1272016-08-10T07:20:08 <jonasschnelli> gmaxwell: Okay. Thanks.
1282016-08-10T07:20:24 <sipa> and for discovering external ip
1292016-08-10T07:20:50 <jonasschnelli> Would ICE works for Bitcoin? Or would that require UDP? (maybe off-topic here)
1302016-08-10T07:22:05 <GitHub4> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/484312bda2d4...edebf425a2df
1312016-08-10T07:22:06 <GitHub4> bitcoin/master 160f895 Luke Dashjr: Bugfix: Use pre-BIP141 sigops until segwit activates
1322016-08-10T07:22:06 <GitHub4> bitcoin/master 239cbd2 Luke Dashjr: qa/rpc-tests/segwit: Test GBT sigops before and after activation
1332016-08-10T07:22:07 <GitHub4> bitcoin/master edebf42 Wladimir J. van der Laan: Merge #8489: Bugfix: Use pre-BIP141 sigops until segwit activates (GBT)...
1342016-08-10T07:22:20 <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
1352016-08-10T07:22:23 *** BashCo has quit IRC
1362016-08-10T07:23:11 <GitHub28> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/114f7e944b1c...edc2c700a75c
1372016-08-10T07:23:11 <GitHub28> bitcoin/0.13 3f65ba2 Pieter Wuille: Treat high-sigop transactions as larger rather than rejecting them
1382016-08-10T07:23:11 <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
1392016-08-10T07:23:12 <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...
1402016-08-10T07:23:42 <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.
1412016-08-10T07:24:06 <jonasschnelli> heh.. okay. I see.
1422016-08-10T07:24:48 <gmaxwell> IMO, using tor hidden services is a /simpler/ way to bypass nat, as crazy as that sounds.
1432016-08-10T07:25:10 * jonasschnelli is thinking...
1442016-08-10T07:27:41 <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?
1452016-08-10T07:28:48 *** BashCo has joined #bitcoin-core-dev
1462016-08-10T07:30:21 <gmaxwell> jonasschnelli: normally tor connections are on 443 and look superficially like regular https connections.
1472016-08-10T07:30:38 <jonasschnelli> gmaxwell: thanks.
1482016-08-10T07:30:44 <gmaxwell> and as long as you can connect out to the tor network you can run a hidden service where people can connect in.
1492016-08-10T07:31:51 *** BashCo__ has quit IRC
1502016-08-10T07:32:42 <gmaxwell> sipa: we need to think about a replacement for addr messages at some point.
1512016-08-10T07:32:57 <gmaxwell> In particular, I2P and tor NG hidden services need more than 128 bits.
1522016-08-10T07:33:14 <gmaxwell> and it would be good to be able to carry a bit more metadata.
1532016-08-10T07:34:42 *** rubensayshi has joined #bitcoin-core-dev
1542016-08-10T07:35:35 *** laurentmt has joined #bitcoin-core-dev
1552016-08-10T07:35:50 <sipa> gmaxwell: well in light of bip151... should they also carry a host pubkey?
1562016-08-10T07:36:14 <jonasschnelli> sipa: that would open the trust network problem?
1572016-08-10T07:36:28 <jonasschnelli> I think only pre-sharing makes more sense?
1582016-08-10T07:37:35 <jonasschnelli> Or what if malicious peers change the host in the addr messages?
1592016-08-10T07:37:43 *** BashCo has quit IRC
1602016-08-10T07:38:02 *** BashCo has joined #bitcoin-core-dev
1612016-08-10T07:39:02 *** so_ is now known as so
1622016-08-10T07:39:20 <gmaxwell> sipa: I don't think thats very useful.
1632016-08-10T07:39:43 <GitHub30> [bitcoin] laanwj closed pull request #8465: [0.13] Document reindexing changes (0.13...docreindex) https://github.com/bitcoin/bitcoin/pull/8465
1642016-08-10T07:39:45 <GitHub185> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/edc2c700a75c...45c656b914f0
1652016-08-10T07:39:45 <GitHub185> bitcoin/0.13 b49d963 Pieter Wuille: Document reindexing changes
1662016-08-10T07:39:46 <GitHub185> bitcoin/0.13 45c656b Wladimir J. van der Laan: Merge #8465: [0.13] Document reindexing changes...
1672016-08-10T07:40:12 <gmaxwell> largely unrelated to BIP151 there is a question of it you'd like to have long lived node identities.
1682016-08-10T07:40:30 <gmaxwell> and then support a 'connect to identity'
1692016-08-10T07:40:52 <gmaxwell> allowing you to, e.g. maintain connections to known well performing peers.
1702016-08-10T07:41:16 <gmaxwell> But that is basically 180degrees off of all the fingerprinting resistance we've worked on in the past.
1712016-08-10T07:41:57 <jonasschnelli> gmaxwell: I guess theres nothing holding back power users of doing this with the current bip151 (+auth) specification..
1722016-08-10T07:42:05 <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.
1732016-08-10T07:42:20 <jonasschnelli> ah
1742016-08-10T07:42:57 <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).
1752016-08-10T07:43:37 <sipa> gmaxwell: hmm, that's not what i'm thinking of
1762016-08-10T07:43:49 * jonasschnelli hears Eric Voskuil grumbling...
1772016-08-10T07:43:51 <gmaxwell> I know, but what you were thinking of is not useful.
1782016-08-10T07:44:01 <sipa> gmaxwell: more: we currently treat IP addresses as identities
1792016-08-10T07:44:12 <sipa> when you connect to the same IP again, you expect it to be the same identity
1802016-08-10T07:44:35 <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'.
1812016-08-10T07:44:57 <gmaxwell> you might as well have just asked the host for a pubkey when you connected to it. :)
1822016-08-10T07:44:57 <jonasschnelli> Only if there would be a signature of the ip/port?
1832016-08-10T07:45:28 <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
1842016-08-10T07:46:10 <gmaxwell> but thats not really part of the addr message, its non-transitive.
1852016-08-10T07:46:37 <sipa> agree
1862016-08-10T07:46:46 <sipa> and i don't think we want a web-of-trust between nodes :)
1872016-08-10T07:47:25 <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.
1882016-08-10T07:47:36 <gmaxwell> But it's in conflict with avoiding fingerprinting.
1892016-08-10T07:49:50 <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
1902016-08-10T07:49:51 <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.
1912016-08-10T07:50:07 <gmaxwell> But to everyone else host with key P does not have a long lived identity.
1922016-08-10T08:28:57 *** Naphex has quit IRC
1932016-08-10T08:37:12 *** harrymm has quit IRC
1942016-08-10T09:17:40 <GitHub177> [bitcoin] MarcoFalke closed pull request #8477: [qa] Temporarily disable ipv6 in rpcbind test (master...Mf1608-qaIpv6) https://github.com/bitcoin/bitcoin/pull/8477
1952016-08-10T09:35:13 *** MarcoFalke has left #bitcoin-core-dev
1962016-08-10T09:43:32 *** Giszmo has joined #bitcoin-core-dev
1972016-08-10T09:45:27 *** Justinus has quit IRC
1982016-08-10T10:17:12 *** thesnark has quit IRC
1992016-08-10T10:18:41 *** Ginnarr has joined #bitcoin-core-dev
2002016-08-10T10:33:06 *** fengling has quit IRC
2012016-08-10T10:48:36 *** thesnark has joined #bitcoin-core-dev
2022016-08-10T11:17:53 *** cryptapus_ has joined #bitcoin-core-dev
2032016-08-10T11:17:53 *** cryptapus_ has joined #bitcoin-core-dev
2042016-08-10T11:18:04 *** cryptapus_ is now known as cryptapus
2052016-08-10T11:20:11 *** Alopex has quit IRC
2062016-08-10T11:21:17 *** Alopex has joined #bitcoin-core-dev
2072016-08-10T11:24:46 *** MarcoFalke has joined #bitcoin-core-dev
2082016-08-10T11:28:40 *** AaronvanW has quit IRC
2092016-08-10T11:28:59 *** BashCo_ has joined #bitcoin-core-dev
2102016-08-10T11:32:56 *** AaronvanW has joined #bitcoin-core-dev
2112016-08-10T11:32:57 *** AaronvanW has joined #bitcoin-core-dev
2122016-08-10T11:33:04 *** BashCo has quit IRC
2132016-08-10T11:39:14 *** Ginnarr has quit IRC
2142016-08-10T11:59:12 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2152016-08-10T12:56:03 *** MarcoFalke has quit IRC
2162016-08-10T12:56:27 *** MarcoFalke has joined #bitcoin-core-dev
2172016-08-10T13:04:52 <GitHub52> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/8b0eee66e9c9057b6e53bb1f4a0a3821083e5df0
2182016-08-10T13:04:52 <GitHub52> bitcoin/0.13 8b0eee6 Luke Dashjr: Bugfix: Use pre-BIP141 sigops until segwit activates...
2192016-08-10T13:05:22 <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
2202016-08-10T13:06:37 *** sgeisler has quit IRC
2212016-08-10T13:30:20 *** cryptapus_ has joined #bitcoin-core-dev
2222016-08-10T13:30:20 *** cryptapus_ has joined #bitcoin-core-dev
2232016-08-10T13:33:18 *** cryptapus has quit IRC
2242016-08-10T13:41:53 *** Chris_Stewart_5 has quit IRC
2252016-08-10T13:45:42 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2262016-08-10T13:57:28 *** BashCo_ has quit IRC
2272016-08-10T13:57:47 *** BashCo has joined #bitcoin-core-dev
2282016-08-10T14:05:53 *** davec has quit IRC
2292016-08-10T14:27:35 *** whphhg_ has joined #bitcoin-core-dev
2302016-08-10T14:30:20 *** whphhg has quit IRC
2312016-08-10T14:32:31 *** spudowiar has joined #bitcoin-core-dev
2322016-08-10T14:39:40 *** whphhg_ is now known as whphhg
2332016-08-10T14:40:21 *** Ylbam has joined #bitcoin-core-dev
2342016-08-10T14:40:58 *** cryptapus_ has quit IRC
2352016-08-10T14:41:11 *** cryptapus_ has joined #bitcoin-core-dev
2362016-08-10T14:59:05 *** cryptapus_ is now known as cryptapus
2372016-08-10T15:03:06 *** jtimon has joined #bitcoin-core-dev
2382016-08-10T15:08:38 *** Chris_Stewart_5 has quit IRC
2392016-08-10T15:23:58 *** MarcoFalke has left #bitcoin-core-dev
2402016-08-10T15:29:22 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2412016-08-10T15:32:03 *** davec has joined #bitcoin-core-dev
2422016-08-10T15:38:56 *** Guyver2 has joined #bitcoin-core-dev
2432016-08-10T15:44:58 *** rubensayshi has quit IRC
2442016-08-10T15:46:04 *** Chris_Stewart_5 has quit IRC
2452016-08-10T16:10:19 *** FNinTak has quit IRC
2462016-08-10T16:11:51 *** AtashiCon has quit IRC
2472016-08-10T16:11:51 *** Arnavion has quit IRC
2482016-08-10T16:17:17 *** Arnavion has joined #bitcoin-core-dev
2492016-08-10T16:19:56 *** AtashiCon has joined #bitcoin-core-dev
2502016-08-10T16:23:19 *** BashCo has quit IRC
2512016-08-10T16:49:40 *** afk11 has joined #bitcoin-core-dev
2522016-08-10T16:49:40 *** afk11 has quit IRC
2532016-08-10T16:49:40 *** afk11 has joined #bitcoin-core-dev
2542016-08-10T16:52:45 *** laurentmt has quit IRC
2552016-08-10T16:56:14 *** afk11 has quit IRC
2562016-08-10T17:00:11 *** btcdrak has quit IRC
2572016-08-10T17:05:51 *** Ylbam has quit IRC
2582016-08-10T17:10:31 *** afk11 has joined #bitcoin-core-dev
2592016-08-10T17:10:31 *** afk11 has quit IRC
2602016-08-10T17:10:31 *** afk11 has joined #bitcoin-core-dev
2612016-08-10T17:13:07 *** TomMc has joined #bitcoin-core-dev
2622016-08-10T17:27:11 *** Ylbam has joined #bitcoin-core-dev
2632016-08-10T17:46:34 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2642016-08-10T17:52:14 *** laurentmt has joined #bitcoin-core-dev
2652016-08-10T17:53:23 *** laurentmt has quit IRC
2662016-08-10T18:01:54 *** BashCo has joined #bitcoin-core-dev
2672016-08-10T18:19:59 *** laurentmt has joined #bitcoin-core-dev
2682016-08-10T18:35:36 <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.
2692016-08-10T18:35:52 <cfields> luke-jr: (i'm implementing the bip9 gbt changes in ckpool)
2702016-08-10T18:36:34 <luke-jr> MAY != MUST
2712016-08-10T18:36:58 <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.
2722016-08-10T18:37:40 <sipa> cfields: agree with luke-jr and gmaxwell here: you'd rather have mining infrastructure break at upgrade time than at segwit activation time
2732016-08-10T18:37:51 <sipa> where it potentially happen across all miners simultaneously
2742016-08-10T18:37:53 <luke-jr> '!' is required if there are such transactions, but optional (for non-segwit miners only) if there are not.
2752016-08-10T18:38:07 <gmaxwell> !segwit is super confusing. :(
2762016-08-10T18:38:08 <gribble> Error: "segwit" is not a valid command.
2772016-08-10T18:38:20 <gmaxwell> it even confuses gribble.
2782016-08-10T18:38:23 <luke-jr> lol
2792016-08-10T18:38:25 <cfields> heh, has not activated on gribble yet
2802016-08-10T18:38:28 <sipa> haha
2812016-08-10T18:38:57 <luke-jr> '*' would have probably made more sense, but I think it's too late to change it now?
2822016-08-10T18:39:23 <sipa> i never considered that '!' as part of a name would be interpreted as "not"
2832016-08-10T18:39:51 <sipa> and agree - i think it's not worth changing at this point
2842016-08-10T18:40:02 <cfields> heh. I read it as "segwit!" rather than "!segwit" and it's more clear :)
2852016-08-10T18:40:18 <sipa> yeah. it's "segwit! be aware!"
2862016-08-10T18:40:56 <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.
2872016-08-10T18:41:10 <sipa> cfields: that's fine
2882016-08-10T18:41:18 <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)..."
2892016-08-10T18:41:29 *** btcdrak has joined #bitcoin-core-dev
2902016-08-10T18:41:42 <sipa> cfields: ah, no
2912016-08-10T18:42:05 <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"
2922016-08-10T18:43:18 <cfields> got it. Ok, I'll PR a few clarifications there. Was trying to implement soley based on reading of bip9 changes.
2932016-08-10T18:43:19 <luke-jr> cfields: what's wrong with how you implemented it?
2942016-08-10T18:43:40 <sipa> but i don't see why "!segwit" -> "make coinbase commitment" would be a problem
2952016-08-10T18:43:48 <cfields> luke-jr: causes cb insertion even with no witness data
2962016-08-10T18:43:54 <sipa> cfields: which is fine
2972016-08-10T18:43:59 <sipa> just slightly wasteful
2982016-08-10T18:44:04 <gmaxwell> s/fine/desirable as far as I know.
2992016-08-10T18:44:36 <cfields> mm, i assumed the opposite. why desirable?
3002016-08-10T18:44:51 <sipa> because you'd test your infrastructures' compatibility ahead of time
3012016-08-10T18:45:01 <gmaxwell> Then the miner (and the network) can see their system correctly functioning.
3022016-08-10T18:45:12 <sipa> so things don't break all over the network when segwit activates
3032016-08-10T18:45:16 <gmaxwell> Otherwise you get the 'segwit tx shows up, now all the hashpower drops offline'
3042016-08-10T18:45:46 <cfields> ok, sure.
3052016-08-10T18:50:15 *** murch has joined #bitcoin-core-dev
3062016-08-10T18:50:31 *** spudowiar has quit IRC
3072016-08-10T18:57:35 *** shesek has joined #bitcoin-core-dev
3082016-08-10T18:57:38 *** execut3 has joined #bitcoin-core-dev
3092016-08-10T18:59:20 <cfields> sipa: in that case, can we append default_witness_commitment based on activation status rather than witness data presence?
3102016-08-10T19:00:05 <sipa> cfields: sure
3112016-08-10T19:00:18 <sipa> it's optional even when there are no witnesses in any transaction
3122016-08-10T19:00:53 <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
3132016-08-10T19:02:15 * luke-jr suspects nobody will care if it's present before activation either, but that's probably less of a good idea
3142016-08-10T19:02:47 <gmaxwell> I think it's a good idea to have it present as soon as software is updated.
3152016-08-10T19:02:59 <gmaxwell> otherwise there is a behavior change at activation that might go wrong.
3162016-08-10T19:03:45 <sipa> it even gives us a way to observe miner adoption before the start date
3172016-08-10T19:04:21 <luke-jr> hmm, that's a point
3182016-08-10T19:04:48 <cfields> sure, i can do it unconditionally if desired
3192016-08-10T19:06:01 <cfields> we could also have 13.0 warn on 1), though it's a bit late for that
3202016-08-10T19:06:03 *** achow101 has quit IRC
3212016-08-10T19:18:17 *** achow101 has joined #bitcoin-core-dev
3222016-08-10T19:21:03 *** jannes has quit IRC
3232016-08-10T19:23:58 *** laurentmt has quit IRC
3242016-08-10T19:40:23 *** d_t has joined #bitcoin-core-dev
3252016-08-10T19:58:52 *** Chris_Stewart_5 has quit IRC
3262016-08-10T20:00:46 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3272016-08-10T20:12:19 *** Chris_Stewart_5 has quit IRC
3282016-08-10T20:13:44 *** cryptapus has quit IRC
3292016-08-10T20:23:58 *** jtimon has quit IRC
3302016-08-10T20:28:34 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3312016-08-10T20:29:54 *** afk11 has quit IRC
3322016-08-10T20:35:58 *** afk11 has joined #bitcoin-core-dev
3332016-08-10T20:35:58 *** afk11 has quit IRC
3342016-08-10T20:35:58 *** afk11 has joined #bitcoin-core-dev
3352016-08-10T21:10:11 *** btcdrak has quit IRC
3362016-08-10T21:18:28 *** Yogh has quit IRC
3372016-08-10T21:19:13 *** alfas has joined #bitcoin-core-dev
3382016-08-10T21:19:33 <alfas> luke
3392016-08-10T21:20:01 *** Yogh has joined #bitcoin-core-dev
3402016-08-10T21:23:58 *** alfas has quit IRC
3412016-08-10T21:25:03 *** murch has quit IRC
3422016-08-10T21:25:27 *** alfas has joined #bitcoin-core-dev
3432016-08-10T21:30:18 *** afk11 has quit IRC
3442016-08-10T22:10:59 *** jtimon has joined #bitcoin-core-dev
3452016-08-10T22:14:35 *** zooko has joined #bitcoin-core-dev
3462016-08-10T22:20:28 *** jtimon has joined #bitcoin-core-dev
3472016-08-10T22:24:50 *** spudowiar has joined #bitcoin-core-dev
3482016-08-10T22:25:14 *** Guyver2_ has joined #bitcoin-core-dev
3492016-08-10T22:28:10 *** Guyver2 has quit IRC
3502016-08-10T22:28:17 *** Guyver2_ is now known as Guyver2
3512016-08-10T22:31:37 *** Guyver2 has quit IRC
3522016-08-10T22:44:57 <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
3532016-08-10T22:45:41 <kanzure> i have no bandwidth to physically test this
3542016-08-10T22:46:07 <kanzure> oh it looks like nothing added
3552016-08-10T22:46:23 <jtimon> BlueMatt: adviced to just move to the next simplest things to expose instead of trying to encapsulate verifyBlock without exposing anything new
3562016-08-10T22:46:26 <sipa> i now envision kanzure implementing this patch on a babbage machine, and then furiously turning the handles until it works
3572016-08-10T22:46:58 <kanzure> sipa: yeah i can be fairly serious about my esoteric architectures
3582016-08-10T22:47:34 <jtimon> kanzure: alternative APIs very welcomed
3592016-08-10T22:48:11 <kanzure> btw there is a typo in your pull request title
3602016-08-10T22:48:37 <jtimon> or alternative refactors, whatever, let's just try to force that PR to rebase and become smaller than +373 â94
3612016-08-10T22:49:49 <jtimon> kanzure: mhmm, it seems I wrote Expose correctly and I made up the other 3 words, can you be more specific?
3622016-08-10T22:50:03 <kanzure> 'libcosnensus'
3632016-08-10T22:50:10 <jtimon> oh, right
3642016-08-10T22:51:11 *** d_t has quit IRC
3652016-08-10T22:54:37 <kanzure> small concerns about name of 'ContextualCheckHeader' but this is only a nit
3662016-08-10T22:55:11 <kanzure> and i think this name is inherited from old code anyway, so it's a tough nit to do anything about
3672016-08-10T22:57:50 <jtimon> BlueMatt: also adviced not to be afraid of creating ugly wrappers or duplicating code if that was simpler to expose something
3682016-08-10T22:58: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
3692016-08-10T22:59:42 <jtimon> but yeah "Consensus::ContextualCheckHeader" it's a new name and it's open for bike-shedding, just like Consensus::VerifyHeader
3702016-08-10T23:01:10 <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)
3712016-08-10T23:03:11 <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
3722016-08-10T23:04:19 <jtimon> but yeah please give your opinion
3732016-08-10T23:05:58 <jtimon> I'm sure that some early nits can save me some work while turning jtimon/0.13-consensus-flags into another PR (WIP)
3742016-08-10T23:06:40 <jtimon> I want to expose get_flags too, but that sounds more crazy than verifyHeaders I think
3752016-08-10T23:09:36 <jtimon> where I would like more input is in https://github.com/bitcoin/bitcoin/pull/8493/files#diff-c2a099d775bac1dccc5f146a3cda81b8R11
3762016-08-10T23:10:28 <jtimon> or alternatives
3772016-08-10T23:13:09 <jtimon> and of course tests and testing
3782016-08-10T23:14:33 <jtimon> anyway, spammed the channel enough already...just please review
3792016-08-10T23:15:15 *** d_t has joined #bitcoin-core-dev
3802016-08-10T23:15:53 *** d_t has joined #bitcoin-core-dev