1 2015-12-28T00:02:33  *** xiangfu has quit IRC
  2 2015-12-28T00:13:56  <Luke-Jr> sipa: indeed, I think the decision whether to translate or not really lies with the target languag
  3 2015-12-28T00:14:11  <Luke-Jr> when it is inappropriate, the translators can just leave it as-is
  4 2015-12-28T01:04:07  *** brg444 has quit IRC
  5 2015-12-28T01:08:44  *** ghtdak has quit IRC
  6 2015-12-28T01:19:10  *** Thireus has quit IRC
  7 2015-12-28T01:23:18  *** ghtdak has joined #bitcoin-core-dev
  8 2015-12-28T01:44:33  *** Ylbam has quit IRC
  9 2015-12-28T01:49:44  *** Thireus has joined #bitcoin-core-dev
 10 2015-12-28T02:03:58  *** Tera2342 has joined #bitcoin-core-dev
 11 2015-12-28T02:04:45  *** xiangfu has joined #bitcoin-core-dev
 12 2015-12-28T03:46:13  *** zookolap` has quit IRC
 13 2015-12-28T03:46:22  *** zookolaptop has quit IRC
 14 2015-12-28T04:03:22  *** belcher has quit IRC
 15 2015-12-28T04:16:25  *** Tera2342 has quit IRC
 16 2015-12-28T04:17:42  *** Tera2342 has joined #bitcoin-core-dev
 17 2015-12-28T04:46:50  *** xiangfu has quit IRC
 18 2015-12-28T04:52:37  *** xiangfu has joined #bitcoin-core-dev
 19 2015-12-28T05:36:50  *** Guest90279 is now known as amiller
 20 2015-12-28T05:37:20  *** amiller is now known as Guest1038
 21 2015-12-28T05:49:23  *** tripleslash_w is now known as [\\\]
 22 2015-12-28T06:03:18  *** xiangfu has quit IRC
 23 2015-12-28T06:03:50  *** xiangfu has joined #bitcoin-core-dev
 24 2015-12-28T06:35:16  *** p15 has joined #bitcoin-core-dev
 25 2015-12-28T06:54:12  *** Thireus has quit IRC
 26 2015-12-28T07:14:17  *** Thireus has joined #bitcoin-core-dev
 27 2015-12-28T07:14:20  *** xiangfu has quit IRC
 28 2015-12-28T07:14:40  *** xiangfu has joined #bitcoin-core-dev
 29 2015-12-28T07:23:30  *** cryptopeddler has quit IRC
 30 2015-12-28T07:25:22  *** cryptopeddler has joined #bitcoin-core-dev
 31 2015-12-28T07:27:34  *** Thireus has quit IRC
 32 2015-12-28T07:32:15  *** Tera2342 has quit IRC
 33 2015-12-28T07:33:10  *** cryptopeddler has quit IRC
 34 2015-12-28T07:34:35  *** cryptopeddler has joined #bitcoin-core-dev
 35 2015-12-28T08:10:35  *** Amnez777 has quit IRC
 36 2015-12-28T08:44:19  *** Amnez777 has joined #bitcoin-core-dev
 37 2015-12-28T08:46:56  *** Amnez777 has quit IRC
 38 2015-12-28T08:46:56  *** Amnez777 has joined #bitcoin-core-dev
 39 2015-12-28T08:58:03  *** MarcoFalke has joined #bitcoin-core-dev
 40 2015-12-28T09:29:52  *** Tera2342 has joined #bitcoin-core-dev
 41 2015-12-28T09:30:38  *** Thireus has joined #bitcoin-core-dev
 42 2015-12-28T09:31:12  *** Ylbam has joined #bitcoin-core-dev
 43 2015-12-28T09:34:06  *** BashCo has joined #bitcoin-core-dev
 44 2015-12-28T09:55:20  *** JackH has joined #bitcoin-core-dev
 45 2015-12-28T10:21:12  *** raedah has quit IRC
 46 2015-12-28T10:38:07  *** wangchun has quit IRC
 47 2015-12-28T10:39:46  *** wangchun has joined #bitcoin-core-dev
 48 2015-12-28T10:40:50  *** JackH has quit IRC
 49 2015-12-28T10:49:50  *** laurentmt has joined #bitcoin-core-dev
 50 2015-12-28T10:50:42  *** laurentmt has quit IRC
 51 2015-12-28T10:51:26  *** JackH has joined #bitcoin-core-dev
 52 2015-12-28T11:00:09  *** JackH has quit IRC
 53 2015-12-28T11:19:19  *** Guyver2 has joined #bitcoin-core-dev
 54 2015-12-28T11:30:02  *** Thireus has quit IRC
 55 2015-12-28T11:34:15  *** JackH has joined #bitcoin-core-dev
 56 2015-12-28T12:13:12  *** afk11 has joined #bitcoin-core-dev
 57 2015-12-28T12:38:55  *** afk11 has quit IRC
 58 2015-12-28T12:39:31  *** afk11 has joined #bitcoin-core-dev
 59 2015-12-28T13:20:01  <Luke-Jr> anyone happen to remember what the whitelist-peer hack is needed to get RPC tests to pass on 0.10/0.11? :/
 60 2015-12-28T13:42:38  *** p15 has quit IRC
 61 2015-12-28T14:16:20  *** Tera2342 has quit IRC
 62 2015-12-28T14:17:20  *** brg444 has joined #bitcoin-core-dev
 63 2015-12-28T14:17:36  *** cryptopeddler has quit IRC
 64 2015-12-28T14:19:14  *** cryptopeddler has joined #bitcoin-core-dev
 65 2015-12-28T14:46:43  *** belcher has joined #bitcoin-core-dev
 66 2015-12-28T14:54:05  *** civos has quit IRC
 67 2015-12-28T15:14:26  *** cryptopeddler has quit IRC
 68 2015-12-28T15:16:14  *** cryptopeddler has joined #bitcoin-core-dev
 69 2015-12-28T16:09:02  *** tripleslash_t has joined #bitcoin-core-dev
 70 2015-12-28T16:11:00  *** [\\\] has quit IRC
 71 2015-12-28T16:23:01  *** BashCo has quit IRC
 72 2015-12-28T16:24:45  *** JackH has quit IRC
 73 2015-12-28T16:35:42  *** zookolaptop has joined #bitcoin-core-dev
 74 2015-12-28T16:44:17  *** afk11 has quit IRC
 75 2015-12-28T16:56:13  *** laurentmt has joined #bitcoin-core-dev
 76 2015-12-28T16:56:26  *** laurentmt has quit IRC
 77 2015-12-28T17:17:03  *** BashCo has joined #bitcoin-core-dev
 78 2015-12-28T17:22:00  *** MarcoFalke has left #bitcoin-core-dev
 79 2015-12-28T17:47:02  *** JackH has joined #bitcoin-core-dev
 80 2015-12-28T17:49:28  *** jayd3e has joined #bitcoin-core-dev
 81 2015-12-28T18:02:48  *** Luke-Jr has quit IRC
 82 2015-12-28T18:03:54  *** Luke-Jr has joined #bitcoin-core-dev
 83 2015-12-28T18:44:34  *** jcorgan is now known as jcorgan|away
 84 2015-12-28T18:49:22  *** belcher has quit IRC
 85 2015-12-28T18:59:59  <jayd3e> I'm receiving this error "scheduler.h:14:35: fatal error: boost/chrono/chrono.hpp: No such file or directory", even though I have installed libboost-dev-all
 86 2015-12-28T19:00:37  <jayd3e> followed the directions for 12.04 exactly
 87 2015-12-28T19:00:46  <phantomcircuit> jayd3e, iirc chrono is missing in older versions of ubuntu
 88 2015-12-28T19:01:12  <jayd3e> so use 14.04?
 89 2015-12-28T19:02:15  <jayd3e> phantomcircuit:
 90 2015-12-28T19:02:42  <phantomcircuit> jayd3e, sorry i dont know which ubuntu versions will work
 91 2015-12-28T19:02:47  <phantomcircuit> i dont think 12.04 will though
 92 2015-12-28T19:02:51  <jayd3e> kk
 93 2015-12-28T19:34:06  *** JackH has quit IRC
 94 2015-12-28T19:42:42  *** gijensen has quit IRC
 95 2015-12-28T19:47:04  *** raedah has joined #bitcoin-core-dev
 96 2015-12-28T19:49:03  *** gijensen has joined #bitcoin-core-dev
 97 2015-12-28T19:50:07  *** JackH has joined #bitcoin-core-dev
 98 2015-12-28T20:07:01  *** jcorgan|away is now known as jcorgan
 99 2015-12-28T20:20:37  *** c-cex-finch has joined #bitcoin-core-dev
100 2015-12-28T20:59:39  *** neilf has joined #bitcoin-core-dev
101 2015-12-28T21:00:59  *** zookolaptop has quit IRC
102 2015-12-28T21:37:11  *** laurentmt has joined #bitcoin-core-dev
103 2015-12-28T21:37:46  *** laurentmt has quit IRC
104 2015-12-28T21:38:35  *** zookolaptop has joined #bitcoin-core-dev
105 2015-12-28T21:52:53  *** Guest1038 has quit IRC
106 2015-12-28T21:52:54  *** Guest1038 has joined #bitcoin-core-dev
107 2015-12-28T21:52:54  *** Guest1038 is now known as amiller
108 2015-12-28T21:59:16  *** raedah has quit IRC
109 2015-12-28T21:59:47  <morcos> CodeShark: sorry, dirty way of getting your attention
110 2015-12-28T22:00:05  <CodeShark> No worries :)
111 2015-12-28T22:00:07  <morcos> Are we still trying to get this rolled out as the next soft fork
112 2015-12-28T22:00:51  <morcos> if so we should be concentrating core development effort on all of these things so we can show progress.  versionbits, BIP68/CSV, segwit
113 2015-12-28T22:01:25  <morcos> but there doesn't seem to have been any movement on the versionbits PR for quite some time
114 2015-12-28T22:01:26  <btcdrak> who is doing the final implementation now, CodeShark or rusty?
115 2015-12-28T22:01:31  <morcos> oh
116 2015-12-28T22:01:35  <morcos> see i didn't know about that
117 2015-12-28T22:01:37  <CodeShark> I think the segwit testnet has taken priority right now
118 2015-12-28T22:01:41  <morcos> is there a different implementation?
119 2015-12-28T22:01:52  <morcos> is that something that is being worked on?
120 2015-12-28T22:02:01  <morcos> i asked sipa about that earlier and he didn't reply
121 2015-12-28T22:02:09  <morcos> where is that happening?
122 2015-12-28T22:02:13  <btcdrak> morcos: even if versionbits was not ready we can still deploy using ISM though...
123 2015-12-28T22:02:23  *** Thireus1 has joined #bitcoin-core-dev
124 2015-12-28T22:03:11  <petertodd> morcos: and there's still my pseudo-versionbits proposal that we can use too
125 2015-12-28T22:03:34  <morcos> sure i agree we don't have to have versionbits before segwit
126 2015-12-28T22:03:47  <morcos> i just thought that was what wumpus laid out in his plan
127 2015-12-28T22:04:09  <petertodd> also, for the record, I would NACK segwit myself without a validationless mining fix
128 2015-12-28T22:04:20  *** zookolaptop has quit IRC
129 2015-12-28T22:05:18  *** Thireus1 has quit IRC
130 2015-12-28T22:05:27  *** Thireus has joined #bitcoin-core-dev
131 2015-12-28T22:05:43  <CodeShark> wanna help implement that, petertodd?
132 2015-12-28T22:06:38  <petertodd> CodeShark: yes, but note that I have no funding right now for core dev work, so I can't promise anything
133 2015-12-28T22:07:23  <petertodd> CodeShark: that said, I'm fairly certainly I'll be able to get some soon
134 2015-12-28T22:07:31  *** Thireus1 has joined #bitcoin-core-dev
135 2015-12-28T22:07:50  <CodeShark> the short-term objective is to deploy a functional testnet without all the intended features and to set up a framework for adding more features
136 2015-12-28T22:08:58  <petertodd> CodeShark: makes sense to me
137 2015-12-28T22:09:00  *** Thireus1 has quit IRC
138 2015-12-28T22:09:57  *** Thireus1 has joined #bitcoin-core-dev
139 2015-12-28T22:10:21  *** Thireus has quit IRC
140 2015-12-28T22:11:03  <CodeShark> deployment to mainnet is still at least another couple months away, I'd say...once we near that we can figure out which activation mechanism we'll use
141 2015-12-28T22:11:41  <CodeShark> So versionbits is now on the backburner
142 2015-12-28T22:12:55  *** raedah has joined #bitcoin-core-dev
143 2015-12-28T22:13:16  *** brg444 has quit IRC
144 2015-12-28T22:14:06  <CodeShark> If you have some extra time and want to dig in, petertodd, I'd love to hear your suggestions
145 2015-12-28T22:15:31  <petertodd> CodeShark: well, I'll see that I can do
146 2015-12-28T22:16:40  *** zookolaptop has joined #bitcoin-core-dev
147 2015-12-28T22:18:14  <morcos>  /window 24
148 2015-12-28T22:18:17  <morcos> oops
149 2015-12-28T22:20:52  *** JackH has quit IRC
150 2015-12-28T22:27:06  <sipa> petertodd: your suggestion is easy to implement for consensus rules; i just worry about the logic needed to get mining software to support it
151 2015-12-28T22:27:27  <sipa> anything that changes the coinbase outputs needs extra logic
152 2015-12-28T22:28:26  <btcdrak> CodeShark: what about rusty, he has code done also.
153 2015-12-28T22:28:39  <btcdrak> oh wait, wrong conversion :)
154 2015-12-28T22:28:46  *** Tera2342 has joined #bitcoin-core-dev
155 2015-12-28T22:30:52  <petertodd> sipa: I'm not suggesting changing the coinbase outputs, just committing to something calculated form them
156 2015-12-28T22:31:09  <petertodd> sipa: equaly, the idea probably would work even without the coinbase output commitment
157 2015-12-28T22:31:44  <petertodd> sipa: important thing is that miners never soft-fork in a commitment to the prior-block possession proof in the prior block
158 2015-12-28T22:33:00  <sipa> petertodd: you're suggesting making block X commit to for example H(full block X-1 incl witness, X's coinbase outouts) ?
159 2015-12-28T22:33:21  <sipa> s/,/||/
160 2015-12-28T22:33:23  <sipa> right?
161 2015-12-28T22:36:03  <petertodd> sipa: yes
162 2015-12-28T22:36:57  <sipa> which means that any software which computes the coinbase outouts will need updated code to compute the commitment
163 2015-12-28T22:37:21  <petertodd> sipa: right, that's fair
164 2015-12-28T22:37:37  <sipa> which for example makes the 21 computer incompatible with it
165 2015-12-28T22:37:38  <petertodd> sipa: so maybe make it commit to H(full block X-1 + nonce)
166 2015-12-28T22:37:45  <sipa> ah!
167 2015-12-28T22:37:54  <sipa> what is nonce?
168 2015-12-28T22:37:56  <petertodd> sipa: then soft-forking in a later committment to the coinbase outputs is possible, as is anything else
169 2015-12-28T22:38:25  <petertodd> sipa: it's probably ok if the nonce can be picked arbitrarily - so long as miners don't actually soft-fork in a commitment to that commitment in the previous block, we're ok
170 2015-12-28T22:38:35  <petertodd> sipa: and in fact, if it's the *full* block that's impossible :)
171 2015-12-28T22:39:34  <sipa> i'm very interested in including solutions for this, but i think it will need input from people with more experience with mining software/hardware
172 2015-12-28T22:39:49  <petertodd> sipa: agreed
173 2015-12-28T22:39:51  *** Tera2342 has quit IRC
174 2015-12-28T22:40:08  <petertodd> sipa: part of why I want to do this now, is because I think if we *don't* fix this, we will have significant pushback on fixing it later
175 2015-12-28T22:40:12  <sipa> petertodd: also, i think you want the full block data at the end of the hash, so you can't compute a midstate for it
176 2015-12-28T22:40:30  <petertodd> sipa: IE, we probably will have to allow a validationless mining alternative where you leave off the commitment, in exchange for an empty block
177 2015-12-28T22:41:11  <petertodd> sipa: well, if the nonce is picked arbitrarily, that's technically not an issue, but yeah, best to do H(nonce + <data>)
178 2015-12-28T22:44:22  <sipa> petertodd: i mean, you probably want to prevent a setup where someone can send a midstate of the full prevblock
179 2015-12-28T22:45:34  <sipa> petertodd: i think there may be significant pushback against this already; any device that decides the coinbase but leaves tx selection up to something else will now need to be burdened with full blocks, where it only needed very low bandwidth beforehand
180 2015-12-28T22:47:01  <petertodd> sipa: well, the fact that you can do that is probably a flaw in the bitcoin protocol
181 2015-12-28T22:47:51  <morcos> sipa: "pushback against this" you mean segwit itself?
182 2015-12-28T22:47:54  <petertodd> sipa: I'm just trying to at least get us back to thecurrent situation, where if you do validationless mining you're trusting others
183 2015-12-28T22:48:03  <petertodd> sipa: IE, don't make the situation worse
184 2015-12-28T22:48:20  <btcdrak> morcos: against validationless mining fix
185 2015-12-28T22:48:43  <morcos> but the issue with the coinbase needing more data exists with just segwit
186 2015-12-28T22:49:22  <petertodd> morcos: not quite - with just segwit the rest of the coinbase outputs can be picked freely
187 2015-12-28T22:50:19  <sipa> morcos: segwit makes the coinbase input depend on tx selection
188 2015-12-28T22:50:21  <morcos> petertodd: so what was the reasoning of having it commit to block X's coinbase outputs
189 2015-12-28T22:50:51  <sipa> morcos: the fact that segwit allows easy mining without validating signatures
190 2015-12-28T22:51:45  <petertodd> morcos: so, the reasoning of committing to H(nonce + prev-block-data) is to force you to have that data to be able to mine; making it H(coinbase-outputs + prev-block-data) would additionally constrain that calculation to be miner-specific
191 2015-12-28T22:51:46  <morcos> yes i understand why to commit to previous blocks witness, but the point of it being your coinbase in there is just to prove that the computation had to be done individually for each miner
192 2015-12-28T22:52:01  <morcos> right, ok
193 2015-12-28T22:52:51  <petertodd> morcos: like I saidabove, it's probably sufficient to just make it H(nonce+prevblockdata), and if coinbase is worth committing too we can do that later with a H(H(nonce+coinbase)+prevblockdata) softfork
194 2015-12-28T22:53:08  <morcos> so personally i'm not convinced of why this is so critically important, i think if you don't have enough full nodes validating everything to keep the network honest then we've failed anyway.
195 2015-12-28T22:54:01  <morcos> the only thing from your email that i found particularly compelling though was maybe there is some gaming behind witholding your witness data
196 2015-12-28T22:54:17  *** c-cex-finch has quit IRC
197 2015-12-28T22:54:20  <petertodd> morcos: sure, but this makes it much easier for miners to skip validating - in practice that'll be a major engineering risk at the very least
198 2015-12-28T22:54:41  <petertodd> morcos: minres don't like to do anything they don't have too- the existing validationless mining code they run is scary enough
199 2015-12-28T22:54:42  <morcos> so anyway, to sipas point about pushback..  there would no additional pushback to the H(nonce + prevblockdata) approach then
200 2015-12-28T22:55:01  <petertodd> morcos: I don't think there would be, same kind of data needed to calculate segwit
201 2015-12-28T22:55:13  <petertodd> (calcualte it honestly anyway)
202 2015-12-28T22:56:01  <sipa> petertodd: not true
203 2015-12-28T22:56:01  <morcos> ok, that was my original confusion
204 2015-12-28T22:56:10  <petertodd> sipa: why not?
205 2015-12-28T22:56:40  <sipa> petertodd: with segwit, the code doing the tx selection needs to be able to make coinbase commitments
206 2015-12-28T22:57:09  <sipa> petertodd: with your proposal (the eventual one), the code doing coinbase output selection needs to be able to make coinbase commitments
207 2015-12-28T22:57:23  <sipa> this is already not the same hardware in some cases now
208 2015-12-28T22:57:40  <petertodd> sipa: sure, but I mean the arbitrary nonce version - committing to the coinbae output is *think* optional
209 2015-12-28T22:57:41  <morcos> sipa: yes but we're talking about just the H(nonce + prev) version
210 2015-12-28T22:57:56  <sipa> who chooses the nonce?
211 2015-12-28T22:58:03  <petertodd> sipa: minerdoes
212 2015-12-28T22:58:11  <petertodd> sipa: they'll probably all choose 0x00 :)
213 2015-12-28T22:58:27  <sipa> you can construct a validationless mining scheme where everyone just agrees on a constant noncr
214 2015-12-28T22:58:32  <morcos> there are other ways you could make it unique'ish to the miner if that was important, that doesn't depend on coinbase outputs anyway
215 2015-12-28T22:58:32  <sipa> *nonce
216 2015-12-28T22:58:52  *** Thireus1 has quit IRC
217 2015-12-28T22:58:59  <petertodd> sipa: no! because you don't know for sure if the nonce the previous miner gave you with their block is actually correct, and they can't commit to it in the block itself
218 2015-12-28T22:59:26  <sipa> petertodd: so?
219 2015-12-28T22:59:35  <sipa> they can make a deal that they have to
220 2015-12-28T22:59:45  <petertodd> sipa: like I say, that gets us back to the status quo, where such arrangements involve trust
221 2015-12-28T23:00:13  <petertodd> sipa: I'm certainly not claiming this isa perfect solution, but keeping at least the status quo is important
222 2015-12-28T23:00:17  <sipa> does segwit-without-witness-validation not give you just a weaker version of that?
223 2015-12-28T23:00:37  <sipa> that also requires trust, but only trust in valid signatures
224 2015-12-28T23:00:49  <sipa> rather than trust in fully valid block
225 2015-12-28T23:00:59  <petertodd> sipa: which is bloody dangerous given how many SPV nodes there are
226 2015-12-28T23:01:39  <petertodd> sipa: note that my *other* proposed solution was that we allow invalid txs to be committed to in blocks, and have miners commit to the subset that were valid n-1 blocks ago, but I figured that was too far out to get any acceptance
227 2015-12-28T23:01:46  <sipa> my point is: if they're going to bother not doing full validation, why wouldn't they go all the way
228 2015-12-28T23:02:26  <sipa> nowitvalidation gives you a small constant factor bandwidth improvememt
229 2015-12-28T23:02:38  <petertodd> sipa: whatdo you mean by "all the way", empty blocks?
230 2015-12-28T23:02:46  <sipa> Ah.
231 2015-12-28T23:03:02  <sipa> now i see the distinction: it requires giving up fees
232 2015-12-28T23:03:06  <petertodd> indeed
233 2015-12-28T23:03:47  <petertodd> equally, giving an option to leave out the prev-block posession proof,in exchange for an empty block, is a nice way to make gmaxwell's validationless mining flag actually have some consensus enforced teeth
234 2015-12-28T23:04:56  <morcos> yeah i guess i agree it could be a step backwards that if you withold your witness data without one of these fixes, other miners won't have the fee incentive to ignore you, and will be more likely to build on top
235 2015-12-28T23:05:13  <petertodd> yup
236 2015-12-28T23:05:36  <morcos> thats more compelling to me than the miners won't bother with the witness data
237 2015-12-28T23:06:12  <petertodd> well, I'm sure some won't bother... it's a lot of engineering work to do it right
238 2015-12-28T23:06:57  <morcos> so couldn't we just do H(cur block wit data + prev block data) or something to make it unique to miner
239 2015-12-28T23:07:17  <petertodd> morcos: hmm, actually I think that works
240 2015-12-28T23:07:33  <morcos> if someone doesn't give you the witness data, you aren't free to pick your own txs to include in the block
241 2015-12-28T23:07:53  <petertodd> morcos: though you'd have to recalculate the commitment every time you change the tx contents of the block, but that's not too expensive - just hashing a few MB of data
242 2015-12-28T23:08:07  <petertodd> morcos: makes sense
243 2015-12-28T23:08:08  <morcos> you have to do that anyway for your own witness commitment
244 2015-12-28T23:08:15  <petertodd> morcos: yup
245 2015-12-28T23:09:22  *** tripleslash_a has joined #bitcoin-core-dev
246 2015-12-28T23:09:52  <sipa> ... of course, a fraud proof for that requires access to the whole block
247 2015-12-28T23:10:13  <petertodd> sipa: that's kinda the point :)
248 2015-12-28T23:10:32  <petertodd> sipa: fraud proofs are themselves a dangerous double-edged sword...
249 2015-12-28T23:11:15  *** tripleslash_t has quit IRC
250 2015-12-28T23:12:30  *** raedah has quit IRC
251 2015-12-28T23:14:30  *** Thireus has joined #bitcoin-core-dev
252 2015-12-28T23:25:48  <sipa> petertodd: i'm aware that you feel that way
253 2015-12-28T23:27:27  <sipa> i'd prefer a mechanism that didn't preclude compact fraud proofs though
254 2015-12-28T23:28:15  <petertodd> to use the terminology of banking/fintech, fraud proofs lull you into an ecosystem without strong transaction finality: you never know if there's a fraud proof out there that you're being prevented from learning about via a sybil
255 2015-12-28T23:28:57  <petertodd> sipa: note how, if you make the prev-block-data commitment into a tree, allowing for a compact fraud proof, you'd simultaneously make it easy and compact to prove that it was correct!
256 2015-12-28T23:30:15  <sipa> petertodd: but what if the alternative to those who would run partial validation node is not more full node, but more centralized api providers?
257 2015-12-28T23:30:38  <petertodd> sipa: that said, in that type of scheme, it may be sufficient that the sender of that "proof" can lie about a subset of the tree and get away with it
258 2015-12-28T23:31:04  <petertodd> sipa: the alternative isn't that, it's that we scale up bitcoin differently
259 2015-12-28T23:31:23  <sipa> petertodd: i think that question may be independent of scale :)
260 2015-12-28T23:31:31  *** brg444 has joined #bitcoin-core-dev
261 2015-12-28T23:31:51  <sipa> but i understand your concern, and i'm certainly not pushing to get the ecosystem into a fraud proof model now
262 2015-12-28T23:31:52  <petertodd> sipa: a 4MB fraud proof isn't all that bad
263 2015-12-28T23:32:40  <petertodd> sipa: remember, right now we have ~50GB fraud proofs :)
264 2015-12-28T23:32:45  <sipa> aware!
265 2015-12-28T23:34:15  <sipa> petertodd: "lull you into an ecosystem without strong transaction finality"... isn't that already the case for bitcoin? you never know that the block you saw may be reorganized away
266 2015-12-28T23:34:56  <sipa> the difference is of course that PoW, under certain assumptions about mining strategies and distribution, allows you to compute an upper bound on the chance for that
267 2015-12-28T23:35:07  <sipa> and that you can observe long term sybils
268 2015-12-28T23:35:22  *** Thireus has quit IRC
269 2015-12-28T23:35:32  <sipa> but bitcoin doesn't have the strong transaction finality either as such
270 2015-12-28T23:36:09  <petertodd> sipa: bitcoin has very strongly *defined* transaction finality: at a given # of confirmations from a point after which you're sure is in the longest chain, you know exactly what it'dcost to reorganize
271 2015-12-28T23:36:19  *** raedah has joined #bitcoin-core-dev
272 2015-12-28T23:36:23  <sipa> fair enoigh
273 2015-12-28T23:36:24  <petertodd> sipa: fraud proofs aren't like that at all
274 2015-12-28T23:36:42  <sipa> nope, for fraud proofs it is just assuming no censorship
275 2015-12-28T23:36:43  <petertodd> sipa: especially in an envifronment where we're relying heavily on them
276 2015-12-28T23:37:23  <petertodd> not quite, remember a fraud proof can't be made from data that you don't have access too, so the actual mechanism of a fraud proof will always be challenge->response - it's not fraud proofs that matter, but rather *non-fraud* proofs
277 2015-12-28T23:37:52  <sipa> ?
278 2015-12-28T23:38:40  <sipa> well SNARKs that can encompass the entirety of a block validation would of course solve many things :)
279 2015-12-28T23:39:20  <kanzure> once the SNARK scheme is figured out, you can often figure out a way to do the same thing without SNARKs
280 2015-12-28T23:42:21  <petertodd> sipa: with SNARKs even treechains is trivial, so... :)
281 2015-12-28T23:43:07  <petertodd> sipa: consider the case of a prev-block-possession commitment, proved via merkle tree of H(nonce + <part of prev-block>)
282 2015-12-28T23:43:38  <sipa> well, if computing the proof takes a google-size datacenter to produce within 10 minutes, we get a different type of centralization concern
283 2015-12-28T23:43:44  <petertodd> sipa: now, if I commit fraud in that tree, meaning one of the leaves isn't valid, I'm obviously not going to give you that leaf - you'd have a handy fraud proof! instead, I'll distribute all but the data required to prove that fraud
284 2015-12-28T23:44:17  <petertodd> sipa: now, what'll happen is nodes will notice "hey, how do I know leaf #123 is valid?", and they'll ask they're peers to prove it to them - that's a challenge
285 2015-12-28T23:44:34  <sipa> petertodd: a partial node wouldn't accept a block that lacks revealing all its commitments
286 2015-12-28T23:44:56  <petertodd> sipa: the peers will response with a *non-fraud/validity proof*, showing that that part of the block is correct
287 2015-12-28T23:45:01  <kanzure> wasn't there a proposal about making an explicit commitment(?) to the sum of the values of the outputs
288 2015-12-28T23:45:04  <petertodd> sipa: however, at no point is a fraud proof ever going to be generated
289 2015-12-28T23:45:23  <petertodd> sipa: right, but in that case, the partial node doesn't even need fraud proofs
290 2015-12-28T23:45:28  <sipa> how so?
291 2015-12-28T23:46:06  <petertodd> sipa:you just said thhe partial node is validating everything relevant...
292 2015-12-28T23:46:14  <sipa> no
293 2015-12-28T23:46:17  <petertodd> sipa: IOW, you just said 'full node' and made a typo :)
294 2015-12-28T23:46:20  <sipa> i said it is receiving everything relevant
295 2015-12-28T23:46:24  <sipa> not validating it
296 2015-12-28T23:46:42  <petertodd> sipa: right, in which case it's just a dumb transmitter of information - fraud proofs don't come into it
297 2015-12-28T23:47:04  <petertodd> sipa: again, in what scenario would the fraudster ever reveal the data required to prove fraud? I'd argue never
298 2015-12-28T23:47:26  <sipa> petertodd: in that scenario, no node will accept its block
299 2015-12-28T23:48:06  <petertodd> sipa: ok, but this goes back transitively - a block may be in itself 100% locally valid, but it's invalid because it depends on an invalid block - why would the partial node eversee thatblock?
300 2015-12-28T23:48:06  <sipa> because it is failing to reveal commitments
301 2015-12-28T23:48:29  <petertodd> but who forces it to revealthe commitments? fraud challenges!
302 2015-12-28T23:48:31  <sipa> petertodd: a partial node sees everything; it just doesn't verify everything
303 2015-12-28T23:48:43  <petertodd> sipa: that's a contradiction...
304 2015-12-28T23:48:52  <petertodd> sipa: what do you think a partial node sees exactly?
305 2015-12-28T23:48:59  <sipa> petertodd: all blocks and witnesses
306 2015-12-28T23:49:11  <sipa> (in the current model, more things can be added of course)
307 2015-12-28T23:49:21  <petertodd> sipa: all blocks from the genesis block?
308 2015-12-28T23:49:38  <sipa> down to a block it trusts; that may be the genesis block or not
309 2015-12-28T23:49:57  <sipa> same as a full node now verifies down to genesis, or gets a utxo set copied from a trusted place
310 2015-12-28T23:50:06  <petertodd> sipa: right, so again, the only time fraud ever comes into it is fraud in a block prior to the one it trusts
311 2015-12-28T23:50:24  <sipa> that makes no sense
312 2015-12-28T23:50:25  <petertodd> sipa: and again, under what circumstance would the fraudster ever give that partial node the data necessary to prove fraud?
313 2015-12-28T23:50:37  <petertodd> sipa: like, come up with a concrete example!
314 2015-12-28T23:50:52  <sipa> i said no node accepts without seeing the commitment
315 2015-12-28T23:51:03  <sipa> there is no need to prove fraud
316 2015-12-28T23:51:07  <sipa> nobody accepts it
317 2015-12-28T23:51:53  <petertodd> sipa: ok, so... I think we're in violent agreement :) I'm just saying, there's actually no scenario where fraud proofs themselves make sense - what's actually important is fraud challenges, responded to via local validity proofs
318 2015-12-28T23:52:08  <sipa> i disagree
319 2015-12-28T23:52:20  <petertodd> ok, so where's the concrete example of a fraud proof?
320 2015-12-28T23:52:42  <sipa> for example, you could build a node that maintains only a utxo set for txids whose hash starts with a 0
321 2015-12-28T23:52:55  <petertodd> right
322 2015-12-28T23:53:14  <sipa> the assumption is that other nodes are either full, or do together validation for all txids whose hash starts with (not 0)
323 2015-12-28T23:53:21  <petertodd> right
324 2015-12-28T23:53:25  <sipa> and that you're not censored from them
325 2015-12-28T23:53:42  <sipa> this partial node would still download full blocks and witnesses
326 2015-12-28T23:53:43  <petertodd> sure, so when exactly does the fraud proof get generated?
327 2015-12-28T23:54:20  <sipa> and will not accept a block that hash merkle malleability, pow failure, mismatching txids, mismatching witness hashes, ...
328 2015-12-28T23:54:41  <petertodd> ok, so lets come up with a concrete example: tx in block n spends an output that doesn't exist
329 2015-12-28T23:55:40  <sipa> the witness will be required to contain a reference (for example, height) to the block that created the output, and an index into it the block (transaction number 5 in that block)
330 2015-12-28T23:56:06  <petertodd> now, as a miner, why would I give a partial node that data? instead, knowing that'll instantly get turned into a fraud proof, I just don't distribute that part of the block, and instead create block n+1 that spends output in block n from tx A, where tx A simply isn't valid
331 2015-12-28T23:56:34  <sipa> nobody will accept n+1 without seeing n
332 2015-12-28T23:57:01  <petertodd> ah! but then, why do we need a fraud proof system? you just said no-one will accept n+1 without n, so fraud doesn't come into it
333 2015-12-28T23:57:23  <petertodd> again, I'm just not seeing a concrete example where a fraud proof would ever be generated
334 2015-12-28T23:57:40  <petertodd> ccccccducvnvnecvrblijvucvhtrgnudfblcnfukdkjt
335 2015-12-28T23:57:42  <sipa> the fraud is needed so the partial node can be told its block n spends from an invalid output
336 2015-12-28T23:57:45  <petertodd> lol, yubikey
337 2015-12-28T23:57:47  <sipa> yeah, i agree with that
338 2015-12-28T23:57:51  <petertodd> good thing that's one-time :)
339 2015-12-28T23:58:00  <sipa> *fraud proof
340 2015-12-28T23:58:04  *** raedah has quit IRC
341 2015-12-28T23:58:34  <petertodd> right, and like I say, in an ecosystem with partial nodes, no miner making an invalid block would ever publish the parts of theirblocks that allow fraud to be proven, so the fraud proof itself is irrelevant
342 2015-12-28T23:59:03  <sipa> that's like saying full nodes are irrelevant because no miner will produce a block that is invalid
343 2015-12-28T23:59:07  <petertodd> it's pointless to do that - better to just setup a bunch of sybil's that prevent to SPV clients that everything is ok
344 2015-12-28T23:59:12  <sipa> that's the point obviously
345 2015-12-28T23:59:48  <petertodd> if everyone ran full nodes, then yes, that'd be irrelevant, but only on a tautological level :)
346 2015-12-28T23:59:58  <sipa> it's the same thing