1 2016-06-04 10:03:17	0|sipa|(where the merges have merge conflicts)
 2 2016-06-04 10:41:02	0|btcdrak|sipa: what dark magic is this?
 3 2016-06-04 10:42:02	0|sipa|first use git rebase -i -p <base commit>
 4 2016-06-04 10:43:09	0|btcdrak|TIL: -p
 5 2016-06-04 10:45:14	0|sipa|that will complain whenever the merge commit is to be merged, as it has merge conflicts
 6 2016-06-04 10:45:33	0|sipa|(and rebase -p can't deal with reapplying merge resolution)
 7 2016-06-04 10:45:48	0|sipa|then use git checkout -p <original merge commit id>
 8 2016-06-04 10:46:34	0|sipa|wait, first use git add -P, to mark all merge conflicts as resolved (you're lying, they aren't)
 9 2016-06-04 10:47:07	0|sipa|and then use git checkout -p <original merge commit id>, which applies all changes between the current tree and the tree after that commit
10 2016-06-04 10:47:15	0|sipa|sorry, git add -A
11 2016-06-04 10:47:16	0|sipa|grr
12 2016-06-04 10:49:15	0|sipa|that git checkout -p will show you all the differences between the current tree (which includes the <<< === >>> markers from conflicts you haven't actually resolved) and the result of the original merge commit
13 2016-06-04 10:50:13	0|sipa|which you all accept
14 2016-06-04 10:50:28	0|sipa|except the changes that are due to changes made earlier in history
15 2016-06-04 10:51:35	0|sipa|as you don't want those reset to the original
16 2016-06-04 13:26:33	0|NicolasDorier|sipa: are you here ? I noticed strange incoherence between the BIP and CMPTBLK implementation, I'm wondering if I've not missed something
17 2016-06-04 13:27:13	0|NicolasDorier|I've added some comment during my review, but either I'm completely misunderstanding something or the BIP and implementation is completely off
18 2016-06-04 13:27:51	0|phantomcircuit|NicolasDorier, something something dont ask to ask
19 2016-06-04 13:27:51	0|phantomcircuit|:P
20 2016-06-04 13:28:20	0|NicolasDorier|what does it mean ? :p
21 2016-06-04 13:29:12	0|NicolasDorier|so basically my problem is
22 2016-06-04 13:29:32	0|NicolasDorier|SENDCMPCT should have a boolean which indicate in which mode the peer want to receive new blocks
23 2016-06-04 13:29:55	0|NicolasDorier|either with INV or with CMPCT BLK
24 2016-06-04 13:30:08	0|sipa|indeed, and a version number
25 2016-06-04 13:30:33	0|NicolasDorier|problem is, in the PR, this boolean is used to indicate whether the sender provide or not CMPCTBLK
26 2016-06-04 13:30:45	0|NicolasDorier|https://github.com/bitcoin/bitcoin/pull/8068/files#diff-7ec3c68a81efff79b6ca22ac1f1eabbaR4915
27 2016-06-04 13:30:53	0|NicolasDorier|oups
28 2016-06-04 13:30:54	0|NicolasDorier|no
29 2016-06-04 13:31:01	0|NicolasDorier|this
30 2016-06-04 13:31:02	0|NicolasDorier|https://github.com/bitcoin/bitcoin/pull/8068/files#diff-7ec3c68a81efff79b6ca22ac1f1eabbaR4846
31 2016-06-04 13:33:16	0|sipa|NicolasDorier: i think you're right
32 2016-06-04 13:34:07	0|NicolasDorier|sipa: I guess the spec changed after the code was released for example: https://github.com/bitcoin/bitcoin/pull/8068/files#diff-7ec3c68a81efff79b6ca22ac1f1eabbaR4920
33 2016-06-04 13:34:26	0|NicolasDorier|the intention was to use the bool to activate or deactivate CMPCT
34 2016-06-04 13:34:39	0|NicolasDorier|as far as I understand
35 2016-06-04 13:35:26	0|NicolasDorier|I can work on fixing it, but I heard you are working on the PR right now sipa ?
36 2016-06-04 13:35:38	0|sipa|i think fProvidesHeaderAndIDs should just be set to true in response to SENDCMPCT
37 2016-06-04 13:35:58	0|NicolasDorier|mmh it is not the same semantic
38 2016-06-04 13:36:10	0|NicolasDorier|SENDCMPCT tell you about the want of the remote node
39 2016-06-04 13:36:14	0|NicolasDorier|not about his capabilities
40 2016-06-04 13:36:18	0|sipa|both
41 2016-06-04 13:36:33	0|NicolasDorier|well, you can already use the version in the handshake for it
42 2016-06-04 13:36:39	0|sipa|no, you can't
43 2016-06-04 13:36:57	0|sipa|nVersion >= 70014 does not imply you support compact blocks
44 2016-06-04 13:37:29	0|NicolasDorier|? why ? because of pruned nodes ?
45 2016-06-04 13:37:47	0|sipa|because we don't want everyone in the network to be forced to implement this
46 2016-06-04 13:38:04	0|sipa|maybe 70015 introduces another features that is easy to implement
47 2016-06-04 13:38:07	0|NicolasDorier|in such case maybe a service BIT can be useful
48 2016-06-04 13:38:16	0|sipa|service bits are expensive
49 2016-06-04 13:38:24	0|sipa|we only have 48
50 2016-06-04 13:38:28	0|sipa|sorry, 56
51 2016-06-04 13:39:10	0|sipa|BIP130 also does not use a service bit
52 2016-06-04 13:39:15	0|NicolasDorier|is it a problem ? if we run out of them we can release a new protocol version with more bits
53 2016-06-04 13:39:40	0|sipa|maybe :)
54 2016-06-04 13:39:46	0|sipa|but there is a lot of infrastructure
55 2016-06-04 13:40:06	0|sipa|that uses it
56 2016-06-04 13:40:26	0|NicolasDorier|understood, are you working on it ? I can refactor things a bit and fix the terminology to match the bip
57 2016-06-04 13:41:23	0|NicolasDorier|also https://github.com/bitcoin/bitcoin/pull/8068/files#diff-7ec3c68a81efff79b6ca22ac1f1eabbaR4920 is completely out of purpose
58 2016-06-04 13:41:39	0|NicolasDorier|and duplicated on https://github.com/bitcoin/bitcoin/pull/8068/files#diff-7ec3c68a81efff79b6ca22ac1f1eabbaR5504
59 2016-06-04 13:41:40	0|sipa|BlueMatt commented on the suggestion to use a service bit here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012630.html
60 2016-06-04 13:41:47	0|sipa|yes, i commented on the duplication
61 2016-06-04 13:42:57	0|sipa|you also commented on some of the refcounting... the refcounting is gone in my branch (https://github.com/sipa/bitcoin/commits/compactblocks)
62 2016-06-04 13:43:20	0|NicolasDorier|ok I'll continue my review on your branch instead
63 2016-06-04 13:44:44	0|sipa|i think the two assignments to preferheadersandids and providesheadersandids just need to be swapped
64 2016-06-04 13:46:34	0|NicolasDorier|it is also a bit confusing: I fail to understand if preferHeadersAndIds means that we use the "high bandwidth (without inv)" or the "low bandwidth" one
65 2016-06-04 13:46:56	0|sipa|that's exactly what it means
66 2016-06-04 13:47:12	0|NicolasDorier|it can also mean that it does not support CMPCTBLK at all
67 2016-06-04 13:47:20	0|sipa|no, that's providesheadersandids
68 2016-06-04 13:47:22	0|NicolasDorier|an enum with 3 values would be easier imhi
69 2016-06-04 13:47:38	0|sipa|providesheadersandids is something that affects our request logic
70 2016-06-04 13:47:48	0|sipa|preferheadersandids is something that affects our send logic
71 2016-06-04 13:49:51	0|NicolasDorier|sipa: on send logic we have 3 cases, legacy, high bandwidth and low bandwidth. PreferHeadersAndIds is a boolean
72 2016-06-04 13:50:30	0|NicolasDorier|oh
73 2016-06-04 13:50:36	0|NicolasDorier|oh no I get it
74 2016-06-04 13:50:52	0|NicolasDorier|because low bandwidth still use INV, it is not different from legacy
75 2016-06-04 13:51:30	0|NicolasDorier|ok, thanks... continuing my review I think it is clearer now
76 2016-06-04 13:51:52	0|sipa|indeed; the difference is that the peer will respond with a getdata MSG_COMPCT_BLOCK rather than MSG_COMPCT_BLOCK
77 2016-06-04 13:51:55	0|sipa|eh
78 2016-06-04 13:51:58	0|sipa|rather than MSG_BLOCK
79 2016-06-04 13:52:03	0|sipa|but that's not our worry
80 2016-06-04 13:52:20	0|NicolasDorier|yes make sense thanks!
81 2016-06-04 14:01:40	0|sipa|MarcoFalke: i have considered grinding commit hashes in segwit to be consecutive numbers :p
82 2016-06-04 14:01:52	0|GitHub189|13bitcoin/06master 14e39dc69 15instagibbs: comment nit: miners don't vote
83 2016-06-04 14:01:52	0|GitHub189|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8c1e49ba13a8...d46b8b50fc3e
84 2016-06-04 14:01:53	0|GitHub189|13bitcoin/06master 14d46b8b5 15Jonas Schnelli: Merge #8143: comment nit: miners don't vote...
85 2016-06-04 14:02:05	0|GitHub195|[13bitcoin] 15jonasschnelli closed pull request #8143: comment nit: miners don't vote (06master...06notavote) 02https://github.com/bitcoin/bitcoin/pull/8143
86 2016-06-04 14:02:05	0|MarcoFalke|You should do it after the rebase :P
87 2016-06-04 14:08:34	0|MarcoFalke|sipa: Could you push a `git commit --allow-empty` or something to have at least one travis result for https://github.com/bitcoin/bitcoin/pull/7749#issuecomment-223558640 ?
88 2016-06-04 14:33:20	0|sipa|MarcoFalke: dragons
89 2016-06-04 14:34:32	0|MarcoFalke|GitHub unicorn
90 2016-06-04 14:36:55	0|MarcoFalke|They have figured out AI that can solve conflicts for you
91 2016-06-04 14:39:56	0|sipa|we should invent a programming language in which every sequence of ascii characters is a valid program
92 2016-06-04 14:40:05	0|sipa|no more merge conflicts
93 2016-06-04 14:40:16	0|sipa|the result may however not be code you want to run
94 2016-06-04 14:40:29	0|sipa|<<< should mean "format disk"
95 2016-06-04 14:41:12	0|btcdrak|babies speak that but they forget it when they grow up so cant teach the adults