1 2016-04-23 16:56:10	0|Chris_Stewart_5|How is this a valid test case? Shouldn't the 0x00 be pushed onto the stack by just an OP_0?
  2 2016-04-23 16:56:13	0|Chris_Stewart_5|["0x01 0x00", "1", "MINIMALDATA"]
  3 2016-04-23 16:58:14	0|sipa|link?
  4 2016-04-23 16:58:30	0|sipa|ah, i get it
  5 2016-04-23 16:58:50	0|sipa|no, OP_0 pushes the empty vector onto the stack, not 0x00
  6 2016-04-23 16:59:24	0|Chris_Stewart_5|ooo.
  7 2016-04-23 16:59:45	0|Chris_Stewart_5|Tricky :-)
  8 2016-04-23 17:00:58	0|Chris_Stewart_5|Is that what this comment is saying? I didn't really understand the comment
  9 2016-04-23 17:01:01	0|Chris_Stewart_5|["Numeric minimaldata rules are only applied when a stack item is numerically evaluated; the push itself is allowed"]
 10 2016-04-23 17:01:32	0|Chris_Stewart_5|https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_tests.json#L598
 11 2016-04-23 17:03:15	0|sipa|yes, that's exactly what it's saying
 12 2016-04-23 17:04:09	0|sipa|MINIMALDATA includes 2 rules: for every push operation, the shortest possible form must be used 2) whenever a stack element is interpreter as a number, it must be in the shortest possible notation
 13 2016-04-23 17:04:28	0|sipa|here, 0x00 is pushed onto the stack with a push operation that satisfies 1)
 14 2016-04-23 17:04:45	0|sipa|2) is not applicable, because it is not being interpreted as a number
 15 2016-04-23 17:08:59	0|Chris_Stewart_5|Ok that makes sense. Thanks sipa.
 16 2016-04-23 19:25:44	0|luke-jr|oops, we released 0.12.1 with no practical way to mine (GBT hasn't been updated for BIP 9) :x
 17 2016-04-23 19:25:57	0|luke-jr|well, practical and correct I guess
 18 2016-04-23 19:26:29	0|luke-jr|should I de-bundle BIP 9 GBT stuff from segwit, or just figure wait for that?
 19 2016-04-23 19:32:03	0|luke-jr|not sure there's a way to support 0.12.1 properly, so basically means the softfork "needs" to be delayed?
 20 2016-04-23 19:32:34	0|sipa|how do you mean?
 21 2016-04-23 19:32:43	0|sipa|it's already being used by miners
 22 2016-04-23 19:32:57	0|luke-jr|sipa: there's no way for GBT clients to know what the rules are
 23 2016-04-23 19:33:22	0|sipa|there's no need for that if they're connecting to a trusted bitcoind
 24 2016-04-23 19:33:42	0|luke-jr|GBT requires it
 25 2016-04-23 19:34:04	0|luke-jr|since it could very well be needed
 26 2016-04-23 19:34:24	0|luke-jr|eg, with segwit the handling of txid/hash
 27 2016-04-23 19:34:51	0|sipa|so let's say there is a softfork that adds UTXO commitments
 28 2016-04-23 19:35:08	0|sipa|what you going to do? provide the entire utxo set in the GBT response?
 29 2016-04-23 19:35:09	0|luke-jr|I could hack libblkmaker to understand that the new "version" can be treated as the previous ones, but this will break as soon as that bit is reused
 30 2016-04-23 19:35:19	0|sipa|your view of reality is a dream
 31 2016-04-23 19:35:32	0|sipa|GBT is not being used the way you envision it
 32 2016-04-23 19:35:46	0|luke-jr|in such a case, the GBT client needs to be aware the commitment is required and where
 33 2016-04-23 19:36:01	0|luke-jr|so it can place the commitment from the local bitcoind in the right part of the block
 34 2016-04-23 19:36:32	0|sipa|or it could just not bother, and use a full node to construct the block proposals, which is in a much better position to do so, and already knows everything necessary (apart from coinbase outputs)
 35 2016-04-23 19:36:36	0|luke-jr|sipa: I wouldn't have even noticed this if it wasn't.
 36 2016-04-23 19:36:52	0|sipa|but no need to have thing discussion again
 37 2016-04-23 19:37:21	0|sipa|i'm fine with reporting what bip9 deployments are active and available in GBT
 38 2016-04-23 19:37:37	0|sipa|but please don't go claim that it's not possible to mine without
 39 2016-04-23 19:37:49	0|sipa|there is no real world mining now that needs such information
 40 2016-04-23 19:37:55	0|luke-jr|per spec, GBT clients cannot work with 0.12.1 as-is today.
 41 2016-04-23 19:38:06	0|luke-jr|and de facto miners implementing it do not work with it
 42 2016-04-23 19:39:04	0|sipa|why not? all deployed GBT clients in the world work fine with it
 43 2016-04-23 19:39:06	0|luke-jr|I'm just trying to find a clean way to fix this real-world problem miners are encountering
 44 2016-04-23 19:39:09	0|luke-jr|nope
 45 2016-04-23 19:39:14	0|sipa|how so?
 46 2016-04-23 19:39:31	0|luke-jr|the version field is unrecognised, so they throw an error
 47 2016-04-23 19:40:55	0|sipa|how do you mean?
 48 2016-04-23 19:41:38	0|luke-jr|https://github.com/bitcoin/libblkmaker/blob/master/blkmaker_jansson.c#L273
 49 2016-04-23 19:42:26	0|sipa|ok, so the software needs to be updated
 50 2016-04-23 19:43:09	0|sipa|i see what you're saying
 51 2016-04-23 19:43:48	0|sipa|though i think most gbt clients just pass through the version field, and they would be fine, because bitcoind's block template always corresponds to a valid block
 52 2016-04-23 19:44:17	0|luke-jr|those would be fine now (albeit not per spec), but they'll break worse with segwit
 53 2016-04-23 19:44:42	0|luke-jr|I suppose libblkmaker can treat the case of (currentsoftforkversion && !bip9)
 54 2016-04-23 19:44:59	0|luke-jr|as long as the next softfork uses BIP9 GBT changes, that would protect against bit reuse
 55 2016-04-23 19:45:17	0|sipa|i think it may be best to disentangle the segwit changes from bip9 changes to gbt
 56 2016-04-23 19:45:18	0|luke-jr|does that sound reasonable?
 57 2016-04-23 19:45:31	0|luke-jr|ok
 58 2016-04-23 19:46:11	0|luke-jr|so today I will focus/prioritise 1) finish revising GBT BIP changes, 2) split BIP9 GBT code from segwit, 3) update libblkmaker to detect 0.12.1 situation
 59 2016-04-23 19:47:50	0|sipa|so i think we at least agreed that gbt should report the list of currently active rules, probably by name
 60 2016-04-23 19:48:10	0|sipa|(trying to remember the discussion we had before)
 61 2016-04-23 19:49:26	0|luke-jr|version: bits the server likes you to set, vbavailable: {name:bit} mapping array the server allows you to set, vbrequired: bits the server demands you to set
 62 2016-04-23 19:49:47	0|sipa|apart from that there were two other functions: 1) policy about which bits the server allows you to set/not set, and a suggestion 3) providing information about linkage between available bits and the deployment they correspond to
 63 2016-04-23 19:50:25	0|sipa|i'm a bit unconfortable with the last thing, as it's only useful in the case the client trusts the server
 64 2016-04-23 19:51:13	0|luke-jr|so libblkmaker will have a special case for 0x20000000 && !vbavailable, to handle 0.12.1 correctly
 65 2016-04-23 19:51:33	0|sipa|how will you deal with 0x20000001?
 66 2016-04-23 19:52:35	0|luke-jr|hm, I'm confused
 67 2016-04-23 19:52:49	0|luke-jr|I pulled 0x20000000 out of a recent block to be lazy, but that indicates no softforks, doesn't it? :x
 68 2016-04-23 19:53:58	0|luke-jr|oh, the begin time..
 69 2016-04-23 19:54:22	0|sipa|yes, after may 1st it will set 0x20000001
 70 2016-04-23 19:54:49	0|luke-jr|so I need to check for & 0xFFFFFFFE == 0x20000000
 71 2016-04-23 19:55:21	0|sipa|cfields: ^ relevant discussion
 72 2016-04-23 19:56:31	0|luke-jr|sipa: re vbrequired: the server can always reject submissions that clear bits it insists on, so this merely informs clients in advance so they can choose not to use that server
 73 2016-04-23 20:02:34	0|sipa|luke-jr: right, no problem with saying "these bits you must set, and these you may set"
 74 2016-04-23 20:03:34	0|sipa|i'm unconvinced about providing information about what bits corresponds with whicj deployment, as that is ourely informational with nonrelevance to what answers are acceptable
 75 2016-04-23 20:03:53	0|sipa|*which *purely
 76 2016-04-23 20:04:01	0|sipa|*no relevance
 77 2016-04-23 20:04:52	0|luke-jr|in the sense that you wish to discuss it further before proceeding that direction, or just a comment?
 78 2016-04-23 20:05:06	0|sipa|like, we also don't provide information about what the coinbase maturity is, while it could just as easily change in a softfork
 79 2016-04-23 20:05:45	0|luke-jr|things like that are why GBT says clients shouldn't make assumptions about block versions they don't understand ;)
 80 2016-04-23 20:05:50	0|sipa|my point is that this mapping information is going beyond the scope of the GBT call, and if clients which tovparticipate in voting, well, then they are responsible for knowing what means what
 81 2016-04-23 20:06:03	0|sipa|*wish to participate
 82 2016-04-23 20:06:12	0|luke-jr|"what means what" depends on blockchain context they lack
 83 2016-04-23 20:06:30	0|sipa|nno, it does not
 84 2016-04-23 20:06:34	0|sipa|it's in the bips
 85 2016-04-23 20:06:54	0|sipa|ah, there is one piece of context information they lack
 86 2016-04-23 20:06:58	0|sipa|mediantimepast
 87 2016-04-23 20:08:08	0|luke-jr|also testnet vs mainnet, but that's admittedly less important
 88 2016-04-23 20:08:30	0|sipa|i see
 89 2016-04-23 20:08:41	0|luke-jr|possibly becomes important if we try to use GBT for sidechains (but I'm not convinced that makes sense)
 90 2016-04-23 20:23:22	0|luke-jr|ok, step 1 done I hope: https://github.com/bitcoin/bips/pull/365
 91 2016-04-23 20:27:24	0|btcdrak|luke-jr: your changes dont render properly https://i.imgur.com/Qmwqh0k.png
 92 2016-04-23 20:29:33	0|instagibbs|sipa, "Otherwise, going from WITNESS->P2SH+WITNESS would be possible, which is not a softfork." I don't grok this. Could you briefly explain it?
 93 2016-04-23 20:30:00	0|luke-jr|btcdrak: looks like none of the GBT stuff does, due to GitHub migration
 94 2016-04-23 20:31:22	0|luke-jr|https://help.github.com/articles/supported-mediawiki-formats/#unsupported-mediawiki-syntaxes :/
 95 2016-04-23 20:33:12	0|luke-jr|btcdrak: fixed by avoiding the templates
 96 2016-04-23 21:04:29	0|sipa|instagibbs: say you have a normal P2SH (not witness) output being spent
 97 2016-04-23 21:04:48	0|sipa|oh, no
 98 2016-04-23 21:05:52	0|sipa|instagibbs: say you have an invalid witness-in-p2sh spending
 99 2016-04-23 21:06:42	0|sipa|with just witness enabled, that's valid
100 2016-04-23 21:07:05	0|instagibbs|wait what, is it invalid or invalid?
101 2016-04-23 21:07:18	0|instagibbs|err valid
102 2016-04-23 21:08:42	0|sipa|say you have a p2sh output, and a corresponding input to spend it, which provides redeemscript which is a witness script, and then witness program that corresponds to it, but is invalid (say it's  wrong signature)
103 2016-04-23 21:09:31	0|kanzure|why would enabling witness make that valid?
104 2016-04-23 21:09:44	0|kanzure|wrong signatures should always be wrong
105 2016-04-23 21:10:06	0|sipa|if you evaluate that with WITNESS, it is valid, because it's a p2sh outout, which is an anyone can spend
106 2016-04-23 21:11:00	0|sipa|if you evaluate with WITNESS+P2SH, the P2SH evaluation happens, which triggers the witness logic, which is invalid
107 2016-04-23 21:11:03	0|sipa|eh
108 2016-04-23 21:11:14	0|sipa|that's all true, but not the reason why it's not a softfork
109 2016-04-23 21:11:54	0|kanzure|oops just checked context. didn't see the question re: the comment. nevermind.
110 2016-04-23 21:15:28	0|instagibbs|"say you have a p2sh output" are you saying this is a p2wsh or something similar
111 2016-04-23 21:15:56	0|instagibbs|or just a plain p2sh like today
112 2016-04-23 21:16:50	0|instagibbs|oh i see
113 2016-04-23 21:18:31	0|instagibbs|I'm not quite getting the comment then, although I agree with what you're saying here
114 2016-04-23 21:19:51	0|sipa|let me think again
115 2016-04-23 21:20:07	0|instagibbs|it sounds like you're saying SOFTFORK1 this is valid, then adding SOFTFORK2 it's now invalid
116 2016-04-23 21:20:13	0|instagibbs|which is def of softfork?
117 2016-04-23 21:20:47	0|sipa|there is a similar rule for cleanstack, and that one i can explain
118 2016-04-23 21:21:33	0|sipa|no, the problem is that when validation with  flags1 fails, but with flags1+flags2 succeeds, then it is not a aoftfork
119 2016-04-23 21:21:36	0|sipa|and all flags should be softforks
120 2016-04-23 21:22:40	0|sipa|mempool validations relies on that
121 2016-04-23 21:24:07	0|instagibbs|I'm clearly missing something important here.
122 2016-04-23 21:24:26	0|instagibbs|probably what the flag semantics are or something
123 2016-04-23 21:27:35	0|instagibbs|oh... it's just talking about the actual implementation and program flow...
124 2016-04-23 21:27:53	0|sipa|so, for ok, for WWITNESS and CLEANSTACK
125 2016-04-23 21:28:29	0|sipa|any witness spend would fail CLEANSTACK validation
126 2016-04-23 21:28:38	0|sipa|because it is just pushes
127 2016-04-23 21:28:52	0|sipa|so it clearly does not satisfy CLEANSTACK
128 2016-04-23 21:29:18	0|instagibbs|I misunderstood the comment, as I thought
129 2016-04-23 21:29:25	0|sipa|unless when WITNESS is enabled, then we ignore the CLEANSTACK rule
130 2016-04-23 21:29:45	0|sipa|thus, a change in flags from CLEANSTACK to CLEANSTACK+WITNESS is not a softfork
131 2016-04-23 21:29:49	0|instagibbs|I read it as "BIP141 by itself is somehow a hardfork"
132 2016-04-23 21:29:57	0|sipa|oh, no
133 2016-04-23 21:30:02	0|instagibbs|totally get it now
134 2016-04-23 21:30:27	0|sipa|we just make CLEANSTACK without WITNESS invalid, so such a change can never occur
135 2016-04-23 21:30:30	0|sipa|ok!
136 2016-04-23 21:30:47	0|luke-jr|sipa: does BIP68+112+113 have a VB name?
137 2016-04-23 21:30:57	0|sipa|luke-jr: csv
138 2016-04-23 21:31:00	0|luke-jr|k
139 2016-04-23 21:32:48	0|instagibbs|thanks for the explanation!
140 2016-04-23 21:33:35	0|luke-jr|sipa: am I correct in understanding that the block time itself is entirely unrelated to the meaning of bits?
141 2016-04-23 21:40:52	0|sipa|luke-jr: the rules that apply to a block are purely a function of its ancestor block header
142 2016-04-23 21:41:10	0|sipa|not of its own timestamp or version
143 2016-04-23 21:44:06	0|luke-jr|k
144 2016-04-23 21:51:32	0|luke-jr|wtf does this GCC thing mean: http://codepad.org/BfJgyPwQ :/
145 2016-04-23 21:53:47	0|gmaxwell|luke-jr: it's pointing out that you should use MAX_VERSION_BITS_DEPLOYMENTS instead of MAX_VERSION_BITS_DEPLOYMENTS.
146 2016-04-23 21:54:05	0|luke-jr|am I blind or something? those look the same to me :|
147 2016-04-23 21:54:49	0|sipa|different namespace?
148 2016-04-23 21:55:03	0|luke-jr|aha that could be it
149 2016-04-23 21:55:32	0|luke-jr|yup
150 2016-04-23 21:55:33	0|luke-jr|thanks
151 2016-04-23 22:09:39	0|Lightsword|luke-jr, why not version GBT separately from the block version?
152 2016-04-23 22:10:19	0|luke-jr|Lightsword: it doesn't make sense to do so
153 2016-04-23 22:11:39	0|Lightsword|most of the time soft forks don’t require mining software changes though, so it would be a good way to signal that mining software needs to be upgraded
154 2016-04-23 22:12:39	0|Lightsword|and in general mining software has no reason to care about the rules being enforced on the network since it assumes the template is valid anyways
155 2016-04-23 22:13:02	0|luke-jr|Lightsword: well, previously, GBT had the version/force mutation for that, but nobody ever considered it worth using
156 2016-04-23 22:13:49	0|Lightsword|luke-jr, so the mining software could actually enforce soft fork rules different from bitcoind?
157 2016-04-23 22:13:56	0|luke-jr|the new BIP 9 stuff doesn't really break that either
158 2016-04-23 22:14:01	0|luke-jr|Lightsword: ?
159 2016-04-23 22:14:15	0|Lightsword|what is the purpose of version/force mutation?
160 2016-04-23 22:14:40	0|luke-jr|Lightsword: tells clients to use the provided version despite their ignorance of its meaning
161 2016-04-23 22:15:10	0|luke-jr|so the server could look at what the client supports (in the GBT request), and decide it was close enough
162 2016-04-23 22:15:34	0|Lightsword|oh, is that for GBT pooled mining?
163 2016-04-23 22:17:23	0|luke-jr|mutations are defined in BIP 23, yes, but GBT itself has no distinction between pools and bitcoind
164 2016-04-23 22:23:17	0|Lightsword|luke-jr, so that would allow say embedded GBT clients to mine on a pool without support for segwit or only soft forks that have no GBT format changes like CSV?
165 2016-04-23 22:23:50	0|sipa|Lightsword: the choice that miner clients have is choosing to vote for a deployment or not
166 2016-04-23 22:24:01	0|sipa|not about rules that are actually enforced
167 2016-04-23 22:24:10	0|luke-jr|Lightsword: there is no way to support segwit in GBT clients unless the GBT client is aware of the segwit changes.
168 2016-04-23 22:24:15	0|sipa|those are set by the full node/server that has to accept them
169 2016-04-23 22:27:04	0|Lightsword|so the miners connecting to the pool would be able to modify their block version number to whatever they want?
170 2016-04-23 22:27:24	0|sipa|if the server supports it
171 2016-04-23 22:29:38	0|luke-jr|Lightsword: see https://github.com/bitcoin/bips/pull/365
172 2016-04-23 22:29:40	0|Lightsword|ok, well from a practical point of view why wouldn’t it make sense for GBT to be versioned separately from the block version so that mining clients can easially determine if they have to upgrade or if they can just use the provided block version as is?
173 2016-04-23 22:30:40	0|luke-jr|Lightsword: because that's not a simple boolean question, and provides no benefits over how GBT presently supports it
174 2016-04-23 22:31:18	0|luke-jr|the CSV deployment *could* have used version/force for old GBT clients, but it did not.
175 2016-04-23 22:32:57	0|Lightsword|I’m confused on what the purpose of the “name” field is, if miners have to be updated to recognize it why can’t they just decode the provided block version number and infer it themselves?
176 2016-04-23 22:34:11	0|luke-jr|the block version number indicates the pending proposals, not the ones in effect
177 2016-04-23 22:35:34	0|Lightsword|why would the mining software need to care about that specifically as opposed to just caring about whether it broke compatibility?
178 2016-04-23 22:37:47	0|luke-jr|Lightsword: compatibility is only guaranteed with the known rules
179 2016-04-23 22:38:46	0|Lightsword|luke-jr, but most soft fork rules are enforced by bitcoind by just not including transactions in the template, so in thsoe cases the GBT version would not need to be changed
180 2016-04-23 22:41:24	0|Lightsword|am I missing something here? I don’t see why the GBT client would need to care about those types of rule changes since they are enforced by bitcoind simply excluding invalid transactions
181 2016-04-23 22:43:11	0|luke-jr|Lightsword: eg, when the transactions and generation tx come from different servers
182 2016-04-23 22:48:17	0|Lightsword|luke-jr, wouldn’t both of those be versioned? are you talking about a GBT client mining off of two different GBT sources at once?
183 2016-04-23 22:48:26	0|luke-jr|yes
184 2016-04-23 22:49:13	0|Lightsword|so wouldn’t the client be able to recognize that the GBT version from the transactions server and generation tx server are different?
185 2016-04-23 22:50:20	0|luke-jr|…
186 2016-04-23 22:50:29	0|luke-jr|you're suggesting they be the same
187 2016-04-23 22:52:55	0|Lightsword|luke-jr, have previous soft forks restricted generation transaction validity?
188 2016-04-23 22:53:41	0|sipa|Lightsword: by definition, all of them
189 2016-04-23 22:53:50	0|sipa|ah, generation transaction, sorry
190 2016-04-23 22:54:09	0|sipa|bip30 and bip34
191 2016-04-23 22:54:38	0|luke-jr|^
192 2016-04-23 22:55:23	0|sipa|and bip141
193 2016-04-23 22:55:35	0|Lightsword|ok, but some don’t as well right?
194 2016-04-23 22:56:01	0|Lightsword|like CSV and BIP66?
195 2016-04-23 22:57:03	0|luke-jr|Lightsword: GBT code exists which will merge transaction sets from multiple servers as well, if we want to get pedantic
196 2016-04-23 22:58:40	0|Lightsword|basically what I’m thinking is that we should have a GBT version indicator that should change to signal to the miner that additional rules need to be enforced, but only for rules that aren’t simply enforced by the excluding the transaction from the template
197 2016-04-23 23:00:14	0|Lightsword|since the mining client doesn’t really need to care about a rule that is enforced simply by exclusion of a transaction
198 2016-04-23 23:00:35	0|luke-jr|it might
199 2016-04-23 23:01:48	0|Lightsword|in what sort of situation would that be?
200 2016-04-23 23:02:07	0|luke-jr|[22:57:03] <luke-jr> Lightsword: GBT code exists which will merge transaction sets from multiple servers as well, if we want to get pedantic
201 2016-04-23 23:03:04	0|Lightsword|does anybody actually do that?
202 2016-04-23 23:03:26	0|luke-jr|dunno, doubt it
203 2016-04-23 23:03:58	0|Lightsword|I mean, merging transactions means you have to support a lot of consensus logic within the mining software itself
204 2016-04-23 23:04:06	0|luke-jr|not much
205 2016-04-23 23:05:18	0|sipa|it also means you probably want a GBT that reports the entire mempool (or part of it), instead of something already tailored for a single block
206 2016-04-23 23:06:47	0|luke-jr|perhaps a "rules/force" mutation would make sense
207 2016-04-23 23:07:10	0|luke-jr|then the server can evaluate if the client's supported rules are sufficient and override that check
208 2016-04-23 23:07:17	0|Lightsword|since most mining software wouldn’t have the neccesary consensus logic to actually handle merging to begin with I would say it would be best to ignore that case for having a GBT version
209 2016-04-23 23:08:26	0|Lightsword|basically the issue right now is we don’t have a way to signal when mining software needs to upgrade or even likely needs to upgrade, at least for the most recent soft forks
210 2016-04-23 23:08:49	0|luke-jr|"version" did that pre-BIP9, and "rules" does it with BIP 9
211 2016-04-23 23:10:58	0|Lightsword|if the signaling method gets false positives on telling the mining software that it needs to upgrade then people will ignore those rules, the problem with using rules the way you have it right now is that fairly often the miner doesn’t actually care about the rules since it’s simply enforced by exclusion of transactions
212 2016-04-23 23:12:16	0|Lightsword|IMO we need a way to signal to the miner that they need to enforce a rule that is not simply enforced by transaction exclusion otherwise miners will outright ignore rules all together
213 2016-04-23 23:12:33	0|luke-jr|at their own risk
214 2016-04-23 23:13:57	0|Lightsword|well if we have a soft fork that we know is enforced by transaction exclusion we should have a way to tell the mining client that they are ok as long as they are only including the transaction provided in the template
215 2016-04-23 23:14:11	0|luke-jr|ok, that'd be a "rules/force" mutation..
216 2016-04-23 23:15:05	0|sipa|luke-jr: ext filesystems have an extension mechanism that lists the enabled extensions in an FS in 3 classes 1) if you don't know about this, you're fine 2) if you don't know about this, you can only mount ro 3) if you don't know this, you can't mount
217 2016-04-23 23:15:23	0|sipa|luke-jr: perhaps the active rules can use a similar classification
218 2016-04-23 23:16:15	0|Lightsword|I’m confused on how mutable actually works
219 2016-04-23 23:17:06	0|luke-jr|server-side, mutable is typically static in practice, but the server could evaluate the client's capabilities and set a rules/force to tell them they're okay
220 2016-04-23 23:17:43	0|sipa|i think you're overdesigning it, trying to cater to every possible use, without any real world demand
221 2016-04-23 23:17:44	0|luke-jr|client-side, it tells the client what they're allowed to do with the template
222 2016-04-23 23:18:00	0|luke-jr|sipa: yes, GBT is overdesigned and should be thrown out, but first we'd need a new protocol
223 2016-04-23 23:18:08	0|Lightsword|well in practical sense bitcoind is the server and the stratum server is the client
224 2016-04-23 23:18:22	0|luke-jr|Lightsword: you're only thinking about your one use case.
225 2016-04-23 23:18:34	0|Lightsword|the use case that basically the entire network runs on though :P
226 2016-04-23 23:18:36	0|sipa|the only one that matters
227 2016-04-23 23:18:39	0|luke-jr|…
228 2016-04-23 23:18:48	0|luke-jr|except the miners who don't.
229 2016-04-23 23:19:04	0|Lightsword|which is almost certainly well below 1% of the network
230 2016-04-23 23:19:45	0|Lightsword|hell, even eligius doesn’t allow GBT mining :P
231 2016-04-23 23:19:49	0|luke-jr|so let's favour the centralised miners abusing their position, at the expense of the 1% who actually care to solo mine?
232 2016-04-23 23:19:53	0|luke-jr|Lightsword: yes it does
233 2016-04-23 23:20:05	0|Lightsword|it just redirects to stratum last I checked
234 2016-04-23 23:20:11	0|luke-jr|you can disable the redirection
235 2016-04-23 23:20:33	0|Lightsword|does anybody actually do that?
236 2016-04-23 23:20:42	0|luke-jr|no idea, ask wizkid057
237 2016-04-23 23:21:36	0|Lightsword|ok, well IMO it’s better to design a signaling method that’s actually going to be useful in practice rather than just getting ignored like it is right now
238 2016-04-23 23:22:12	0|luke-jr|anyone know what testnet blocks made csv change states?
239 2016-04-23 23:22:35	0|Lightsword|huh? i didn’t know it changed status
240 2016-04-23 23:22:45	0|midnightmagic|Much of that ignored stance comes from the undeserved reputational damage that luke's suffered over the years, and the deliberate work that's gone *specifically* into being contrarian.
241 2016-04-23 23:23:36	0|midnightmagic|like, re-written and re-designed *as a specific and incompatible alternative* to things like GBT.
242 2016-04-23 23:23:49	0|luke-jr|Lightsword: splitting the rules list up like sipa suggested sounds like a possible approach, but would require approximately the same code to implement as rules/force would
243 2016-04-23 23:24:06	0|sipa|not sure what you mean by rules/force
244 2016-04-23 23:24:32	0|luke-jr|sipa: server evaluates the client's supported rules, and tells it that it can safely ignore the rules it doesn't know
245 2016-04-23 23:24:34	0|Lightsword|midnightmagic, to be fair GBT is pretty much impractical for pooled mining
246 2016-04-23 23:25:04	0|midnightmagic|And instead of making GBT better or including it in a superset, people did other things.
247 2016-04-23 23:25:45	0|phantomcircuit|luke-jr, i'm some large % of testnet and running 73fc922ed64333d45f18d8a448f30cfa2ae0281e
248 2016-04-23 23:25:47	0|luke-jr|midnightmagic: meh, GBT is fundamentally incompatible with sidechains, so it needs to be replaced anyway
249 2016-04-23 23:26:02	0|luke-jr|phantomcircuit: ?
250 2016-04-23 23:26:13	0|Lightsword|midnightmagic, well that’s what happens when something doesn’t fit people’s needs and redesigning it is easier than trying to fix it
251 2016-04-23 23:26:24	0|phantomcircuit|you asked about testnet and csv; i did not answer your question but did provide additional information
252 2016-04-23 23:26:41	0|luke-jr|phantomcircuit: I don't see an answer to my question >_
253 2016-04-23 23:26:43	0|luke-jr|>_<
254 2016-04-23 23:27:18	0|phantomcircuit|luke-jr, i'm so helpful right
255 2016-04-23 23:27:25	0|gmaxwell|Lightsword: consider what you're saying, that it's impratical to send the miner the block they're working on, once per block?  This should be setting off red alarm bells for you.
256 2016-04-23 23:27:51	0|phantomcircuit|gmaxwell, i think you need more specific nouns
257 2016-04-23 23:28:06	0|Lightsword|gmaxwell, when a “miner” is a server farm with 10k miners all directly connected to a pool…it’s going to be a problem in most cases
258 2016-04-23 23:28:10	0|phantomcircuit|(actually i think this entire conversation needs more specific nouns)
259 2016-04-23 23:28:28	0|Lightsword|even if the block size is 50k
260 2016-04-23 23:30:07	0|Lightsword|it’s really a matter of what can send out the block update faster, miners aren’t likely to give up profit margin unless they have a really good reason to
261 2016-04-23 23:30:09	0|gmaxwell|Lightsword: GBT isn't a protocol for dispatching to random hardware. But at the same time having 50k tcp connections from devices at one site to a pool makes no sense either.
262 2016-04-23 23:30:15	0|phantomcircuit|gmaxwell, (switching topics) i'm finding the afl hang detection to be pretty annoying, it refuses to start a new run if a test case is even 1ms above the hang threshold... which means moving tests between a server and my laptop results in having to purge a bunch of tests (the server being much faster than my laptop)
263 2016-04-23 23:30:18	0|phantomcircuit|any suggestion?
264 2016-04-23 23:30:41	0|gmaxwell|phantomcircuit: up your threshold on the laptop.
265 2016-04-23 23:30:56	0|Lightsword|gmaxwell, well that’s the reason stratum happened, because it was desgined for dispatching to random hardware more or less :P
266 2016-04-23 23:31:26	0|gmaxwell|No, it's a crappy protocol for that too.
267 2016-04-23 23:31:26	0|phantomcircuit|gmaxwell, it would be nice if it counted instructions instead but i assume that would be both harder and more expensive?
268 2016-04-23 23:31:39	0|phantomcircuit|i thought x86 systems had performance counters that could efficiently do that though
269 2016-04-23 23:31:52	0|sipa|phantomcircuit: rdtsc
270 2016-04-23 23:32:02	0|Lightsword|gmaxwell, sure but it was better than GBT for that and there wasn’t an alternative people could choose
271 2016-04-23 23:32:06	0|sipa|doesn't count instructions, just clock cycles
272 2016-04-23 23:32:15	0|bitcoinfr|.
273 2016-04-23 23:32:30	0|phantomcircuit|sipa, that seems better actually
274 2016-04-23 23:32:41	0|midnightmagic|Lightsword: they explicitly ignored most of the feedback about their new design, and in at least one case, it was done in a *trivially exploitable way.*
275 2016-04-23 23:33:03	0|luke-jr|and made no effort to collaborate with others already working on GBT
276 2016-04-23 23:33:11	0|luke-jr|but that's history, and irrelevant to what we do in BIP 9
277 2016-04-23 23:33:29	0|luke-jr|which is something that needs to get wrapped up sooner rather than later so solo mining is practical again
278 2016-04-23 23:33:34	0|gmaxwell|Lightsword: You're suffering history rewrite in terms of the current state of the world, back when these protocols were created the world was very different than now.
279 2016-04-23 23:35:41	0|Lightsword|was there much effort on either side to collaborate? at the time I thought luke was just arguing something along the lines of you shouldn’t use stratum you should use GBT instead
280 2016-04-23 23:38:57	0|luke-jr|Lightsword: GBT was developed and revised over the course of a year or two, before stratum was even mentioned publicly
281 2016-04-23 23:39:15	0|luke-jr|developed openly, with collaboration from multiple people
282 2016-04-23 23:53:38	0|midnightmagic|yes, lots of attempts at collaboration and unification.
283 2016-04-23 23:57:59	0|luke-jr|why does BOOST_FOREACH not work on UniValues? :<