1 2015-12-29T00:00:11  <petertodd> anyway, I'm arguing that what's important isn't the fraud proof, but rather the proof of correctness - take the fraud thing to it's logal conclusion
  2 2015-12-29T00:00:43  <petertodd> given that the existance of fraud proofs can be countered by making them impossible to generate, we need *another* level of protection, and that level of protection makes fraud proofs irrelevant
  3 2015-12-29T00:00:55  <sipa> *sigh*
  4 2015-12-29T00:01:11  <petertodd> note how in my scheme, a fraud proof is actually the *challenge*, which unless met with valid data is proof of fraud
  5 2015-12-29T00:01:17  <sipa> it's trivial to bypass that weakness by requiring all data committed to is revealed
  6 2015-12-29T00:01:32  <sipa> which means that partial nodes don't get a bandwidth reduction
  7 2015-12-29T00:01:41  <petertodd> I get that...
  8 2015-12-29T00:01:51  <petertodd> you're missing my point: whose using partial nodes?
  9 2015-12-29T00:02:23  <sipa> does that matter?
 10 2015-12-29T00:02:30  <petertodd> yes!
 11 2015-12-29T00:02:34  <sipa> anyone who likes to
 12 2015-12-29T00:02:54  <petertodd> if I'm a fraudulent miner, I'll sybil the network with a bunch of partial nodes that never give up fraud anyway
 13 2015-12-29T00:03:15  <petertodd> now, if my sybil isn't100% succesful, fraud proofs don't help, but validity challenges do
 14 2015-12-29T00:03:46  <sipa> if someone is able to sybil you, then yes, fraud proofs fail
 15 2015-12-29T00:04:12  <sipa> 00: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)
 16 2015-12-29T00:04:15  <sipa> 00:53:21 < petertodd> right
 17 2015-12-29T00:04:17  <sipa> 00:53:25 < sipa> and that you're not censored from them
 18 2015-12-29T00:04:18  <kanzure> i am not sure that "reveal all the committed data" is the only way to solve this
 19 2015-12-29T00:04:26  <sipa> oh, snarks can do it too :p
 20 2015-12-29T00:04:27  <petertodd> right, but in the non-100% succesful sysbil example, the best defence is the validity challenges, not pure fraud proofs, because the former is what lets me find out which nodes are lying to me
 21 2015-12-29T00:04:42  <petertodd> SNARKs can do anything; not interesting :)
 22 2015-12-29T00:05:00  <sipa> give me an example of a validity challenge?
 23 2015-12-29T00:05:48  <petertodd> so, in my simple merkletree example above, a validity challenge would be "I think leaf X in merkle tree Y is invalid, prove that it (locally) isn't"
 24 2015-12-29T00:06:23  <petertodd> if that validity challenge is unmet, it's a strong suggestion that there is fraud - if you have at least one peer that validated that part of the blockchain, when the challenge will be responded too with valid data
 25 2015-12-29T00:06:27  <kanzure> traditional fraud proof example is "here's two transactions that were committed to, and they are both spending the same inputs". the non-fraud proof version would be "show that this input is only used once" i guess?
 26 2015-12-29T00:07:02  <petertodd> kanzure: sure, but like I argued above, no-one would actually make a series of blocks where that can be proven and publish it, there's no point, resulting in the need for fraud challenges
 27 2015-12-29T00:07:39  <kanzure> well my message was an attempt to show a non-fraud proof variant of the same, but i think i failed :)
 28 2015-12-29T00:08:35  <petertodd> kanzure: yeah, the non-fraud proof would actually be to for a variety of nodes to challenge + respond to parts of the block(s) involved in that potential fraud, until there's a challenge that isn't extingished by valid data
 29 2015-12-29T00:08:45  <kanzure> "prove that there are no other inputs used" would require, as far as i can tell, something on the order of "send me all of your data"
 30 2015-12-29T00:09:18  <petertodd> kanzure: in that specific example, it'd be the part of the merkle tree leading to where the second spend of that output would be that'd fail to be met with valid data
 31 2015-12-29T00:09:45  <kanzure> why would you know where the second spend would be?
 32 2015-12-29T00:09:52  <petertodd> kanzure: only in a badly designed protocol :) a good protocol will have TXO commitments that let you prove validity of spending locally
 33 2015-12-29T00:10:00  <petertodd> kanzure: process of elimination
 34 2015-12-29T00:10:24  <kanzure> elimination sounds a lot like "send me all your data" except you might get lucky and bail early
 35 2015-12-29T00:10:36  <petertodd> kanzure: that should be telling... :)
 36 2015-12-29T00:10:57  <petertodd> kanzure: if you have a fraudulent peer, they're never going to send you a fraud proof, or the data that lets you generate one
 37 2015-12-29T00:11:09  <petertodd> kanzure: (which is why the whole idea is suspect anyway)
 38 2015-12-29T00:11:45  <kanzure> transaction commitments offer a proof of spending only once?
 39 2015-12-29T00:11:56  <petertodd> kanzure: note how my linearized tx history scheme redefines what fraud is to make double-spend fraud compactly provable (for a kinda terrible definition of 'compact')
 40 2015-12-29T00:11:57  <kanzure> oh, transaction output commitments..
 41 2015-12-29T00:12:02  <petertodd> kanzure: yeah
 42 2015-12-29T00:14:26  <kanzure> yes so i think that we can avoid the total bandwidth reduction that sipa was worried aobut above
 43 2015-12-29T00:15:08  <petertodd> what do you mean by "total bandwidth reduction"?
 44 2015-12-29T00:15:30  <sipa> anyway, i'm not planning on adding fraud proof support in the first version anyway; perhaps more discussion is needed - i'm just wary of changes that make compact fraud proofs less viable overall
 45 2015-12-29T00:16:15  <petertodd> sipa: sure, and the entire fraud proof vs. fraud challenge debate is orthogonal - an expensive fraud proof is an expensive validity proof
 46 2015-12-29T00:16:16  *** Guyver2 has quit IRC
 47 2015-12-29T00:16:54  <petertodd> sipa: so convince me that a merkle tree of prev-block-contents is acceptable :)
 48 2015-12-29T00:24:12  *** d_t has quit IRC
 49 2015-12-29T00:26:28  *** d_t has joined #bitcoin-core-dev
 50 2015-12-29T00:27:10  *** d_t has joined #bitcoin-core-dev
 51 2015-12-29T00:27:53  *** d_t has joined #bitcoin-core-dev
 52 2015-12-29T00:32:25  <kanzure> petertodd: by "total bandwidth reduction" i meant "total bandwidth increase" heh. sipa was concerned about losing out on the bandwidth reduction benefits.
 53 2015-12-29T00:32:50  <sipa> kanzure: no
 54 2015-12-29T00:33:07  <sipa> kanzure: oh, you mean by committing to the prev block + witness?
 55 2015-12-29T00:33:20  <sipa> i will think more about that
 56 2015-12-29T00:34:51  *** belcher has joined #bitcoin-core-dev
 57 2015-12-29T00:37:56  *** ghtdak has quit IRC
 58 2015-12-29T00:38:14  *** ghtdak has joined #bitcoin-core-dev
 59 2015-12-29T00:58:52  <GitHub179> [bitcoin] dooglus opened pull request #7262: Reduce inefficiency of GetAccountAddress() (master...faster-getaccountaddress) https://github.com/bitcoin/bitcoin/pull/7262
 60 2015-12-29T01:02:24  *** raedah has joined #bitcoin-core-dev
 61 2015-12-29T01:11:25  *** Tera2342 has joined #bitcoin-core-dev
 62 2015-12-29T01:18:26  *** JackH has joined #bitcoin-core-dev
 63 2015-12-29T01:44:34  *** Ylbam has quit IRC
 64 2015-12-29T01:58:38  *** zookolaptop has quit IRC
 65 2015-12-29T01:59:16  *** zookolaptop has joined #bitcoin-core-dev
 66 2015-12-29T02:03:39  <morcos> sipa: petertodd: sometimes i find following these conversations over IRC very difficult.  But I have to say I mostly have many of the same thoughts as petertodd.  It's not really clear to me what situations we envision fraud proofs being actually used in.
 67 2015-12-29T02:04:18  <morcos> I wouldn't go as far as he has.  But I think its worth really carefully writing up the scenarios where we think they might be useful, so we know whats worth worrying about making compact and what isn't.
 68 2015-12-29T02:04:52  <morcos> Also whether 4MB is compact or not is relevant to the situation in which these things might be used
 69 2015-12-29T02:05:20  <sipa> i gave one... whether you consider the additional assumptions (censorship resistance from other nodes that do validation of the parts you don't) to be a worthwhile outcome is something else :)
 70 2015-12-29T02:07:25  <morcos> sipa: so if you don't get the bandwidth reduction, then what exactly is a partial node saving?
 71 2015-12-29T02:08:01  <sipa> UTXO set maintenance, signature validation, ...
 72 2015-12-29T02:09:38  <morcos> so perhaps thats valuable during the bootstrapping phase?
 73 2015-12-29T02:10:17  <morcos> don't get me wrong, its not that i dont think these tools are of value, but trying to sketch out how we envision them actually being used is important
 74 2015-12-29T02:10:41  <sipa> fair enough, there is a lot of work left there
 75 2015-12-29T02:19:15  <phantomcircuit> morcos, signature validation from tip down, which is expensive to do without the fraud proofs
 76 2015-12-29T02:19:33  <phantomcircuit> (but which is largely incompatible with pruning)
 77 2015-12-29T02:21:50  *** jayd3e has quit IRC
 78 2015-12-29T02:22:07  *** brg444 has quit IRC
 79 2015-12-29T02:41:24  *** brg444 has joined #bitcoin-core-dev
 80 2015-12-29T02:56:16  *** jayd3e has joined #bitcoin-core-dev
 81 2015-12-29T02:56:46  <jayd3e> so, I'm finding the bitcoin-core code pretty dense, it does a lot of things and is configured for a number of different platforms
 82 2015-12-29T02:58:12  <jayd3e> are all of the open threads for sending/receiving messages from other peers located in StartNode?
 83 2015-12-29T02:58:17  <jayd3e> in net.cpp
 84 2015-12-29T03:00:27  <sipa> there is 1 network thread (which sends/received between the network and CNode buffers) and one message habdling thread (which runs ProcessMessages and SendMessages in main.cpp)
 85 2015-12-29T03:00:52  <sipa> cfields is working on replacing a significant part of the network code with libevent
 86 2015-12-29T03:08:13  *** Tera2342 has quit IRC
 87 2015-12-29T03:08:18  <jayd3e> sipa: gotcha thanks
 88 2015-12-29T03:17:01  *** Alopex has joined #bitcoin-core-dev
 89 2015-12-29T03:18:08  *** Alopex has quit IRC
 90 2015-12-29T03:21:39  <maaku> petertodd: I find any proposal that requires miners or worse hashing hardware to have full block data to be a dangerous regression over the segwit proposal
 91 2015-12-29T03:22:05  <petertodd> maaku: dangerous? I consider that to be a good thing
 92 2015-12-29T03:22:18  <maaku> right now transaction selection can be delegated to a third party, not so under your proposal I believe
 93 2015-12-29T03:22:47  <petertodd> maaku: yeah, you don'twant tx selection to be delegatable
 94 2015-12-29T03:23:01  <brg444> maaku is transaction selection delegation desirable?
 95 2015-12-29T03:23:33  *** Alopex has joined #bitcoin-core-dev
 96 2015-12-29T03:24:24  <maaku> petertodd: I strongly disagree. We don't live in an ideal world where every hashing hardware is running a full node.
 97 2015-12-29T03:24:46  <petertodd> maaku: I know, that's why I'm not proposing that yet
 98 2015-12-29T03:24:54  <maaku> having the hardware poll one source for coinbase rewards, and another for transaction selection would be an important incremental improvement over the current situation
 99 2015-12-29T03:25:10  <petertodd> maaku: I'm just proposing we ensure that mining pools have the data sufficient to validate
100 2015-12-29T03:25:13  <maaku> something which is very much possible today but no one is doing
101 2015-12-29T03:25:22  *** JackH has quit IRC
102 2015-12-29T03:25:26  *** Alopex has joined #bitcoin-core-dev
103 2015-12-29T03:25:33  <petertodd> maaku: why would that be an improvement?
104 2015-12-29T03:26:30  <maaku> petertodd: transaction selection would no longer be confined to the same centralization pressures as mining hardware (power availability, distance from manufacturing, etc.)
105 2015-12-29T03:26:57  *** Alopex has quit IRC
106 2015-12-29T03:27:28  <petertodd> maaku: are you assuming DRM tech?
107 2015-12-29T03:27:51  <maaku> petertodd: ideally, yes, but it is still an improvement without
108 2015-12-29T03:28:06  <maaku> we could have 100% hashpower in Shenzhen, but if it is smart property miners tied to transaction sources all over the world, with hundreds of orgs providing that data
109 2015-12-29T03:28:28  *** jayd3e has quit IRC
110 2015-12-29T03:28:55  <petertodd> maaku: I think that's incredibly unrealistic - the guy with the power switch isn't going to delegate control like that
111 2015-12-29T03:29:32  <petertodd> maaku: at best, the hashing power can be turned off by force
112 2015-12-29T03:29:47  <petertodd> maaku: equally, I'm not very worried about that kind of centralization, as cheap power has diseconomies of scale
113 2015-12-29T03:30:08  <maaku> petertodd: turning off the hashers is a risk under any scenario
114 2015-12-29T03:30:18  <maaku> DRM just makes it the only thing he can do
115 2015-12-29T03:30:52  <petertodd> maaku: DRM puts you in possitions where mfg's are encouraged to produce back doorable hardware
116 2015-12-29T03:31:17  <maaku> petertodd: eh, cheapest power has diseconomies, but it's not like the whole globe evens out when your power usage goes up
117 2015-12-29T03:31:36  <alpalp> .
118 2015-12-29T03:31:40  <petertodd> "whole globe evens out"<- what do you mean by that?
119 2015-12-29T03:32:21  *** Alopex has joined #bitcoin-core-dev
120 2015-12-29T03:32:22  <sipa> i would also be opposed to a system that requires full block access to anything that does not do the transaction selection
121 2015-12-29T03:32:45  <petertodd> again, I think you're crazy and optimising for the wrong things
122 2015-12-29T03:32:46  <sipa> but it seems like that may not be needed to combat the validationless mining degradation
123 2015-12-29T03:32:58  <petertodd> maaku: ^^^
124 2015-12-29T03:33:02  *** Alopex has quit IRC
125 2015-12-29T03:33:09  <sipa> so stop arguing
126 2015-12-29T03:33:14  <petertodd> heh
127 2015-12-29T03:33:24  <sipa> whether you agree or not is not relevant
128 2015-12-29T03:34:41  *** Alopex has joined #bitcoin-core-dev
129 2015-12-29T03:35:38  <maaku> i'm not convinced we need to combat validationless mining, that's the issue :\
130 2015-12-29T03:35:52  *** Alopex has quit IRC
131 2015-12-29T03:36:21  <petertodd> maaku: with segwit validationless mining is a significantly worse problem, as non-validating miners both have an advantage, yet can still collect tx fees
132 2015-12-29T03:36:35  <sipa> maaku: or validationless transaction selection, if you will
133 2015-12-29T03:37:58  <sipa> petertodd: of course, if there is trust, mining can always get pooling advantages by doing block construction in one central place for multiple pools
134 2015-12-29T03:38:38  <petertodd> sipa: which we don't want
135 2015-12-29T03:38:43  <sipa> agree
136 2015-12-29T03:38:57  <sipa> but it may be inevitable...
137 2015-12-29T03:39:08  *** Alopex has joined #bitcoin-core-dev
138 2015-12-29T03:39:09  <petertodd> sipa: so? why hasten it?
139 2015-12-29T03:39:19  <sipa> i'm not arguing either way
140 2015-12-29T03:39:27  <sipa> just observing
141 2015-12-29T03:39:45  <petertodd> sipa: the blocksize limit needs to be kept low enough to keep that from being a major problem; if the ecosystem wants to go elsewhere, I'm leaving bitcoin development, and so should the rest of you
142 2015-12-29T03:40:30  <petertodd> keep in mind I'm designing for a system that's worth designing - other designs are possible, but solve "problems" that I'm not interested in solving (and frequently are simply bone headed stupid)
143 2015-12-29T03:40:46  <sipa> no disagreement :)
144 2015-12-29T03:41:34  <petertodd> if startinga new pool is ever difficult (assuming enough hashing power joins to keep variance reasonable) then we've failed and the system we have isn't bitcoin as we know it
145 2015-12-29T03:41:36  <maaku> petertodd sipa: I'm aware that segwit makes non-validating mining easier to do. I'm not convinced that this is a problem, at least so much of a problem that we take actions which constrain the mining space
146 2015-12-29T03:41:53  *** Alopex has quit IRC
147 2015-12-29T03:42:18  <petertodd> maaku: I'd judge my "nightmare scenario" in my dev list post to have >50% probability of happening - miners are pretty lazy in what they implement
148 2015-12-29T03:42:27  <maaku> so far you guys are not arguing from first prinicples. rather i'm hearing a cached 'miners must have the data they need to validate!' without explaining why the cost is necessary
149 2015-12-29T03:42:33  <petertodd> maaku: equally, I'd judge the probability of DRM hardware getting developed in the way you imagine as being <5%
150 2015-12-29T03:43:04  <petertodd> maaku: currently the system assumes miners validate; if they stop validating we risk massive reorgs at best
151 2015-12-29T03:43:49  <sipa> maaku: not just easier; it makes it more profitable and less observable too (by no longer being restricte to minkng empty blocks without validation)
152 2015-12-29T03:43:53  <petertodd> maaku: heck, even in treechains you still need to force miners to actually have blockchain data for the system to work - bitcoin is at its core a proof-of-publication system, and the only thing forcing miners to publish right now is validation
153 2015-12-29T03:44:14  *** Alopex has joined #bitcoin-core-dev
154 2015-12-29T03:44:30  <petertodd> sipa: and validationless blocks with txs in them are much more dangerous
155 2015-12-29T03:44:41  <sipa> petertodd: though, compared to downloading the full block right now and disabling script verification, there is not much difference
156 2015-12-29T03:45:04  <sipa> petertodd: segwit just makes that use a constant factor less bandwidth
157 2015-12-29T03:45:14  <petertodd> sipa: downloading the block is a huge bottleneck, and equally, the fact that everyone has to download it discourages the development of infrastructure where that isn't possible
158 2015-12-29T03:45:15  <sipa> which may be an issue still
159 2015-12-29T03:45:36  *** dcousens has joined #bitcoin-core-dev
160 2015-12-29T03:45:46  <petertodd> sipa: e.g. w/ segwit as described, we're guaranteed to get specialized relay networks that don't even propagate witness data at all
161 2015-12-29T03:45:49  <dcousens> why does OP_CLTV care about the transactions lock time?
162 2015-12-29T03:46:09  <dcousens> (when it just checks the stack item pushed just prior?)
163 2015-12-29T03:46:23  <sipa> dcousens: ?
164 2015-12-29T03:46:36  <petertodd> dcousens: CLTV checks the stack item against nLockTime
165 2015-12-29T03:46:40  <sipa> dcousens: it compares that stack item with tx.nLocktime
166 2015-12-29T03:47:16  <dcousens> Need to re-read that BIP then
167 2015-12-29T03:47:27  <petertodd> dcousens: read the source
168 2015-12-29T03:48:17  <sipa> petertodd: that is risky though... a miner could create a block with invalid witness data but not reveal that witness data, and not build on top himself, while his buddies all waste time on it
169 2015-12-29T03:48:37  <petertodd> sipa: creating such a block costs 25BTC - it's a good bet that they won't
170 2015-12-29T03:48:44  <petertodd> sipa: exactly like today...
171 2015-12-29T03:48:46  <sipa> yup
172 2015-12-29T03:48:49  <sipa> yup
173 2015-12-29T03:51:05  <sipa> but that means that relying on such a relay network means you are trusting your buddies to a pretty significant degree
174 2015-12-29T03:51:15  <sipa> same as with a relay network today
175 2015-12-29T03:51:24  <sipa> if you don't fully validate
176 2015-12-29T03:51:41  <petertodd> sipa: why? there's PoW proof that they're risking 25BTC, so the block is very probably valid
177 2015-12-29T03:52:01  <petertodd> sipa: how many delibrately invalid blocks have *ever* been created? I'm guessing zero in recent history
178 2015-12-29T03:53:09  <dgenr8> petertodd: how low is "low enough"?
179 2015-12-29T03:53:14  <petertodd> and remember, if we don't constrain that form of mining now, it'll be much more difficult politically to constrain it in the future
180 2015-12-29T03:53:21  <petertodd> dgenr8: huh?
181 2015-12-29T03:53:51  <dgenr8> [15-12-28 19:39:52] <petertodd> sipa: the blocksize limit needs to be kept low enough to keep that from being a major problem; if the ecosystem wants to go elsewhere, I'm leaving bitcoin development, and so should the rest of you
182 2015-12-29T03:54:51  <petertodd> dgenr8: I'm working on a document actually to set design criteria - a major one is the hashing power in adttendance at scaling bitcoin came to consensus that under attack conditions the orphan rates of largest and smallest pools should vary no more than +- 0.5%
183 2015-12-29T03:55:10  <petertodd> dgenr8: that's a business requirement for there to be a level playing field
184 2015-12-29T03:55:40  <dgenr8> do you know what that measurement is today?
185 2015-12-29T03:56:19  <petertodd> dgenr8: no I don't, because we're not under attack conditions
186 2015-12-29T03:56:45  <dgenr8> what are those? not just full blocks / spam?
187 2015-12-29T03:57:03  <petertodd> dgenr8: miners who aren't cooperating with other miners is the big one
188 2015-12-29T03:57:19  <dgenr8> not relaying others' blocks?
189 2015-12-29T03:57:23  <petertodd> dgenr8: in fact, we're going to have to fix some exploits to be able to even meet that criteria with 1MB blocks, although at least fixing those exploits is easy
190 2015-12-29T03:57:45  <petertodd> dgenr8: making blocks that contain not-previously-relayed (or recently relayed) transactions
191 2015-12-29T03:58:05  <dgenr8> ah
192 2015-12-29T03:58:16  <petertodd> dgenr8: basically, all the relay optimizations that work in the averge case can't be taken into account for that +-0.5% figure
193 2015-12-29T03:59:19  <dgenr8> maybe the relay network should be turned off
194 2015-12-29T03:59:36  <petertodd> dgenr8: there's no way to force people to do that
195 2015-12-29T04:01:51  <phantomcircuit> <petertodd> sipa: how many delibrately invalid blocks have *ever* been created? I'm guessing zero in recent history
196 2015-12-29T04:02:01  <phantomcircuit> petertodd, that's only true when mining is largely centralized
197 2015-12-29T04:02:09  <petertodd> phantomcircuit: huh?
198 2015-12-29T04:02:50  <phantomcircuit> petertodd, there's effectively a reputation system at work with mining today
199 2015-12-29T04:03:02  <phantomcircuit> the stratum mining stuff is whitelist based
200 2015-12-29T04:03:03  <petertodd> phantomcircuit: huh?
201 2015-12-29T04:03:34  <petertodd> phantomcircuit: well yeah, I want to stay *at* the status quo, and not make things *worse*
202 2015-12-29T04:03:35  <maaku> sipa: (re: pm) My point is that this is a spectrum not a binary choice. Things we'd close off is a hasher using an external transaction validation source but injecting its own transactions from a white list
203 2015-12-29T04:03:42  <phantomcircuit> im saying that comparing mining off blocks w/o witness data validated isn't exactly comparable to the stratum mining that's happening today
204 2015-12-29T04:03:50  <petertodd> phantomcircuit: I'd rather make things better, but that's probably politically/technically impooossible right now
205 2015-12-29T04:04:32  <petertodd> phantomcircuit: the stratum stuff  has a strong disincentive to lying: if the other pools connect to you anonymously, you can't feed them bad data without hurting your own hashers
206 2015-12-29T04:04:58  <phantomcircuit> petertodd, the problem is self correcting if mining becomes less centralized
207 2015-12-29T04:05:24  <petertodd> phantomcircuit: why?
208 2015-12-29T04:06:02  <phantomcircuit> petertodd, at least the stratum one does
209 2015-12-29T04:06:14  <petertodd> phantomcircuit: I'm still not seeing your point
210 2015-12-29T04:06:22  <phantomcircuit> reputation management is much more difficult with lots of players
211 2015-12-29T04:06:34  <petertodd> phantomcircuit: this has nothing to do with reputation
212 2015-12-29T04:07:32  <petertodd> phantomcircuit: (I mean, obviously it can, but stratum-using validationless mining works even if you don't trust the other guy, so long as you can connect to their pool anonymously)
213 2015-12-29T04:09:14  <phantomcircuit> petertodd, there's an asynmetry between smaller and larger pools though
214 2015-12-29T04:09:22  <petertodd> phantomcircuit: how so?
215 2015-12-29T04:09:58  <phantomcircuit> a smaller miner can signal a nonsensical block with cost x * 25 while the larger miners cost is (x*2) * 25
216 2015-12-29T04:10:13  <petertodd> phantomcircuit: sure, but you can weight that if you want, and it's still expensive
217 2015-12-29T04:10:22  <petertodd> phantomcircuit: that also doesn't negate my segwit objections
218 2015-12-29T04:11:05  <phantomcircuit> petertodd, maybe but the reasoning here isn't so simple
219 2015-12-29T04:11:39  <petertodd> phantomcircuit: again, I'm simply preventing an ecosystem from developing where people regularly create blocks with txs in them w/o validating
220 2015-12-29T04:14:06  *** belcher has quit IRC
221 2015-12-29T04:21:53  <aj> phantomcircuit: hmm, back-of-the-envelope calculations seem to indicate it's never profitable for a miner to create fake blocks to trick SPV-miners to work on a bad chain (and it's only break-even if everyone else is SPV mining)
222 2015-12-29T04:22:51  *** brg444 has quit IRC
223 2015-12-29T04:23:13  <aj> phantomcircuit: (assuming: no external profits, eg shorting bitcoin on a different exchange; and the cost of creating a hash of an invalid block is the same as for a valid block -- if PoW was changed so you could produce a hash that simultaneously attested to a good and a bad block, that'd change)
224 2015-12-29T04:36:39  *** arowser has quit IRC
225 2015-12-29T04:37:12  *** arowser has joined #bitcoin-core-dev
226 2015-12-29T04:38:07  *** Tera2342 has joined #bitcoin-core-dev
227 2015-12-29T04:38:57  *** Tera2342 has quit IRC
228 2015-12-29T04:40:42  *** alpalp has quit IRC
229 2015-12-29T04:42:28  *** alpalp has joined #bitcoin-core-dev
230 2015-12-29T05:03:57  *** p15 has joined #bitcoin-core-dev
231 2015-12-29T05:08:30  *** Quent has quit IRC
232 2015-12-29T05:08:56  *** Quent has joined #bitcoin-core-dev
233 2015-12-29T05:24:52  *** PRab has quit IRC
234 2015-12-29T05:25:44  *** PRab has joined #bitcoin-core-dev
235 2015-12-29T06:01:18  *** Yoghur114 has quit IRC
236 2015-12-29T06:01:43  *** Yoghur114 has joined #bitcoin-core-dev
237 2015-12-29T06:35:43  *** frankenmint has joined #bitcoin-core-dev
238 2015-12-29T06:44:30  *** Yoghur114 has quit IRC
239 2015-12-29T06:44:49  *** smooth has joined #bitcoin-core-dev
240 2015-12-29T06:44:50  *** Yoghur114 has joined #bitcoin-core-dev
241 2015-12-29T06:48:42  <dcousens> anyone know of an up to date reference for coinswap?
242 2015-12-29T06:49:13  <dcousens> (or is https://bitcointalk.org/index.php?topic=321228.0 still considered the latest?)
243 2015-12-29T06:52:46  <jcorgan> i don't think it ever made it to an implementation, and malleability would have broken it anyway.  of course, now, all these things deserve a second look.
244 2015-12-29T06:53:34  <dcousens> I didn't necessarily mean impl, but, just in terms of an algorithm
245 2015-12-29T06:54:02  <dcousens> Only curious because I'm currently playing with an algo. that might be more optimal, and just wondering if I could get some review over it
246 2015-12-29T06:55:04  <jcorgan> probably a good -wizards discussion
247 2015-12-29T06:55:08  <dcousens> ok
248 2015-12-29T07:09:50  *** zookolaptop has quit IRC
249 2015-12-29T07:09:51  *** tripleslash_b has joined #bitcoin-core-dev
250 2015-12-29T07:09:55  *** tripleslash_a has quit IRC
251 2015-12-29T07:34:36  *** Alopex has quit IRC
252 2015-12-29T07:43:22  *** mturquette has joined #bitcoin-core-dev
253 2015-12-29T09:04:44  *** Ylbam has joined #bitcoin-core-dev
254 2015-12-29T09:08:40  *** BashCo has quit IRC
255 2015-12-29T09:15:16  *** Guyver2 has joined #bitcoin-core-dev
256 2015-12-29T09:27:54  *** BashCo has joined #bitcoin-core-dev
257 2015-12-29T09:47:23  *** JackH has joined #bitcoin-core-dev
258 2015-12-29T10:05:00  *** teward has quit IRC
259 2015-12-29T10:12:05  *** teward has joined #bitcoin-core-dev
260 2015-12-29T10:19:50  *** frankenmint has quit IRC
261 2015-12-29T10:23:24  *** Prattler has quit IRC
262 2015-12-29T10:24:03  *** JackH has quit IRC
263 2015-12-29T10:28:35  *** Yoghur114 has quit IRC
264 2015-12-29T10:29:18  *** Yoghur114 has joined #bitcoin-core-dev
265 2015-12-29T10:45:15  *** tripleslash_k has joined #bitcoin-core-dev
266 2015-12-29T10:46:35  *** tripleslash_b has quit IRC
267 2015-12-29T10:47:30  *** d_t has quit IRC
268 2015-12-29T10:49:33  *** p15 has quit IRC
269 2015-12-29T10:53:48  *** JackH has joined #bitcoin-core-dev
270 2015-12-29T10:53:53  *** JackH has quit IRC
271 2015-12-29T11:01:00  *** arowser has quit IRC
272 2015-12-29T11:01:20  *** arowser has joined #bitcoin-core-dev
273 2015-12-29T12:04:46  *** mturquette has quit IRC
274 2015-12-29T12:05:06  *** mturquette has joined #bitcoin-core-dev
275 2015-12-29T12:17:01  *** Prattler has joined #bitcoin-core-dev
276 2015-12-29T12:19:28  *** maaku has quit IRC
277 2015-12-29T12:36:35  *** xiangfu has quit IRC
278 2015-12-29T13:32:23  *** maaku has joined #bitcoin-core-dev
279 2015-12-29T13:32:47  *** maaku is now known as Guest87480
280 2015-12-29T13:33:29  *** Guest87480 is now known as maaku
281 2015-12-29T13:46:05  *** tripleslash_i has joined #bitcoin-core-dev
282 2015-12-29T13:47:36  *** tripleslash_k has quit IRC
283 2015-12-29T13:54:29  *** treehug88 has joined #bitcoin-core-dev
284 2015-12-29T14:55:40  *** wangchun has quit IRC
285 2015-12-29T14:57:41  *** wangchun has joined #bitcoin-core-dev
286 2015-12-29T14:59:46  *** alpalp has quit IRC
287 2015-12-29T15:07:39  *** davec has quit IRC
288 2015-12-29T15:13:39  *** davec has joined #bitcoin-core-dev
289 2015-12-29T15:24:39  *** zookolaptop has joined #bitcoin-core-dev
290 2015-12-29T15:29:47  *** molz has joined #bitcoin-core-dev
291 2015-12-29T15:34:23  *** moli has quit IRC
292 2015-12-29T16:02:06  *** bsm117532 has joined #bitcoin-core-dev
293 2015-12-29T16:09:21  *** tripleslash_q has joined #bitcoin-core-dev
294 2015-12-29T16:10:58  *** tripleslash_i has quit IRC
295 2015-12-29T16:15:47  *** d_t has joined #bitcoin-core-dev
296 2015-12-29T17:28:14  *** brg444 has joined #bitcoin-core-dev
297 2015-12-29T17:34:34  *** BashCo has quit IRC
298 2015-12-29T17:50:18  *** BashCo has joined #bitcoin-core-dev
299 2015-12-29T17:59:48  *** BashCo_ has joined #bitcoin-core-dev
300 2015-12-29T18:02:44  *** BashCo has quit IRC
301 2015-12-29T18:51:17  *** desantis has joined #bitcoin-core-dev
302 2015-12-29T18:52:30  *** desantis has left #bitcoin-core-dev
303 2015-12-29T19:09:31  *** JackH has joined #bitcoin-core-dev
304 2015-12-29T19:27:35  *** Thireus has joined #bitcoin-core-dev
305 2015-12-29T19:30:15  *** bsm117532 has quit IRC
306 2015-12-29T19:42:22  *** Thireus has quit IRC
307 2015-12-29T19:44:55  *** treehug88 has quit IRC
308 2015-12-29T19:47:05  *** bsm117532 has joined #bitcoin-core-dev
309 2015-12-29T19:49:09  *** Thireus has joined #bitcoin-core-dev
310 2015-12-29T20:07:20  *** jayd3e has joined #bitcoin-core-dev
311 2015-12-29T20:07:34  <jayd3e> how can nThreadsServicingQueue be called as a function in scheduler.cpp
312 2015-12-29T20:07:42  <jayd3e> on line 13
313 2015-12-29T20:08:00  <jayd3e> it's defined as an int in scheduler.h
314 2015-12-29T20:10:39  <jayd3e> nvm figured it out
315 2015-12-29T20:14:26  *** bsm117532 has quit IRC
316 2015-12-29T20:18:57  *** bsm117532 has joined #bitcoin-core-dev
317 2015-12-29T20:28:59  <jayd3e> what does the "<>" indicate in this line: newTaskScheduled.wait_until<>(lock, taskQueue.begin()->first)
318 2015-12-29T20:29:17  <jayd3e> from line 58 of scheduler.cpp
319 2015-12-29T20:34:50  <instagibbs> Not a c++ guy myself, but http://stackoverflow.com/questions/20398587/template-function-call-with-empty-angle-brackets
320 2015-12-29T20:36:14  <jayd3e> instagibbs: nice, thanks.  That makes sense
321 2015-12-29T20:46:33  *** d_t has quit IRC
322 2015-12-29T20:47:14  *** d_t has joined #bitcoin-core-dev
323 2015-12-29T21:12:02  *** fkhan_ has quit IRC
324 2015-12-29T21:12:22  *** brg444 has quit IRC
325 2015-12-29T21:17:12  *** jayd3e has quit IRC
326 2015-12-29T21:23:13  *** fkhan_ has joined #bitcoin-core-dev
327 2015-12-29T21:48:20  *** brg444 has joined #bitcoin-core-dev
328 2015-12-29T21:53:39  *** Thireus has quit IRC
329 2015-12-29T21:56:35  *** Thireus has joined #bitcoin-core-dev
330 2015-12-29T21:59:51  *** Thireus1 has joined #bitcoin-core-dev
331 2015-12-29T22:01:47  *** Thireus has quit IRC
332 2015-12-29T22:07:26  *** Thireus has joined #bitcoin-core-dev
333 2015-12-29T22:07:26  *** Thireus1 has quit IRC
334 2015-12-29T22:09:29  *** Thireus1 has joined #bitcoin-core-dev
335 2015-12-29T22:09:29  *** Thireus has quit IRC
336 2015-12-29T22:09:49  *** Thireus has joined #bitcoin-core-dev
337 2015-12-29T22:13:55  *** Thireus1 has quit IRC
338 2015-12-29T22:40:30  *** go1111111 has quit IRC
339 2015-12-29T22:40:49  *** Alopex has joined #bitcoin-core-dev
340 2015-12-29T22:57:35  *** go1111111 has joined #bitcoin-core-dev
341 2015-12-29T23:07:00  *** neha_ has quit IRC
342 2015-12-29T23:09:00  *** go1111111 has quit IRC
343 2015-12-29T23:09:58  *** tripleslash has joined #bitcoin-core-dev
344 2015-12-29T23:11:30  *** tripleslash_q has quit IRC
345 2015-12-29T23:18:44  *** jcorgan is now known as jcorgan|away
346 2015-12-29T23:22:15  *** go1111111 has joined #bitcoin-core-dev