12015-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
  22015-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
  32015-12-29T00:00:55  <sipa> *sigh*
  42015-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
  52015-12-29T00:01:17  <sipa> it's trivial to bypass that weakness by requiring all data committed to is revealed
  62015-12-29T00:01:32  <sipa> which means that partial nodes don't get a bandwidth reduction
  72015-12-29T00:01:41  <petertodd> I get that...
  82015-12-29T00:01:51  <petertodd> you're missing my point: whose using partial nodes?
  92015-12-29T00:02:23  <sipa> does that matter?
 102015-12-29T00:02:30  <petertodd> yes!
 112015-12-29T00:02:34  <sipa> anyone who likes to
 122015-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
 132015-12-29T00:03:15  <petertodd> now, if my sybil isn't100% succesful, fraud proofs don't help, but validity challenges do
 142015-12-29T00:03:46  <sipa> if someone is able to sybil you, then yes, fraud proofs fail
 152015-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)
 162015-12-29T00:04:15  <sipa> 00:53:21 < petertodd> right
 172015-12-29T00:04:17  <sipa> 00:53:25 < sipa> and that you're not censored from them
 182015-12-29T00:04:18  <kanzure> i am not sure that "reveal all the committed data" is the only way to solve this
 192015-12-29T00:04:26  <sipa> oh, snarks can do it too :p
 202015-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
 212015-12-29T00:04:42  <petertodd> SNARKs can do anything; not interesting :)
 222015-12-29T00:05:00  <sipa> give me an example of a validity challenge?
 232015-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"
 242015-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
 252015-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?
 262015-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
 272015-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 :)
 282015-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
 292015-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"
 302015-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
 312015-12-29T00:09:45  <kanzure> why would you know where the second spend would be?
 322015-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
 332015-12-29T00:10:00  <petertodd> kanzure: process of elimination
 342015-12-29T00:10:24  <kanzure> elimination sounds a lot like "send me all your data" except you might get lucky and bail early
 352015-12-29T00:10:36  <petertodd> kanzure: that should be telling... :)
 362015-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
 372015-12-29T00:11:09  <petertodd> kanzure: (which is why the whole idea is suspect anyway)
 382015-12-29T00:11:45  <kanzure> transaction commitments offer a proof of spending only once?
 392015-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')
 402015-12-29T00:11:57  <kanzure> oh, transaction output commitments..
 412015-12-29T00:12:02  <petertodd> kanzure: yeah
 422015-12-29T00:14:26  <kanzure> yes so i think that we can avoid the total bandwidth reduction that sipa was worried aobut above
 432015-12-29T00:15:08  <petertodd> what do you mean by "total bandwidth reduction"?
 442015-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
 452015-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
 462015-12-29T00:16:16  *** Guyver2 has quit IRC
 472015-12-29T00:16:54  <petertodd> sipa: so convince me that a merkle tree of prev-block-contents is acceptable :)
 482015-12-29T00:24:12  *** d_t has quit IRC
 492015-12-29T00:26:28  *** d_t has joined #bitcoin-core-dev
 502015-12-29T00:27:10  *** d_t has joined #bitcoin-core-dev
 512015-12-29T00:27:53  *** d_t has joined #bitcoin-core-dev
 522015-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.
 532015-12-29T00:32:50  <sipa> kanzure: no
 542015-12-29T00:33:07  <sipa> kanzure: oh, you mean by committing to the prev block + witness?
 552015-12-29T00:33:20  <sipa> i will think more about that
 562015-12-29T00:34:51  *** belcher has joined #bitcoin-core-dev
 572015-12-29T00:37:56  *** ghtdak has quit IRC
 582015-12-29T00:38:14  *** ghtdak has joined #bitcoin-core-dev
 592015-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
 602015-12-29T01:02:24  *** raedah has joined #bitcoin-core-dev
 612015-12-29T01:11:25  *** Tera2342 has joined #bitcoin-core-dev
 622015-12-29T01:18:26  *** JackH has joined #bitcoin-core-dev
 632015-12-29T01:44:34  *** Ylbam has quit IRC
 642015-12-29T01:58:38  *** zookolaptop has quit IRC
 652015-12-29T01:59:16  *** zookolaptop has joined #bitcoin-core-dev
 662015-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.
 672015-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.
 682015-12-29T02:04:52  <morcos> Also whether 4MB is compact or not is relevant to the situation in which these things might be used
 692015-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 :)
 702015-12-29T02:07:25  <morcos> sipa: so if you don't get the bandwidth reduction, then what exactly is a partial node saving?
 712015-12-29T02:08:01  <sipa> UTXO set maintenance, signature validation, ...
 722015-12-29T02:09:38  <morcos> so perhaps thats valuable during the bootstrapping phase?
 732015-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
 742015-12-29T02:10:41  <sipa> fair enough, there is a lot of work left there
 752015-12-29T02:19:15  <phantomcircuit> morcos, signature validation from tip down, which is expensive to do without the fraud proofs
 762015-12-29T02:19:33  <phantomcircuit> (but which is largely incompatible with pruning)
 772015-12-29T02:21:50  *** jayd3e has quit IRC
 782015-12-29T02:22:07  *** brg444 has quit IRC
 792015-12-29T02:41:24  *** brg444 has joined #bitcoin-core-dev
 802015-12-29T02:56:16  *** jayd3e has joined #bitcoin-core-dev
 812015-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
 822015-12-29T02:58:12  <jayd3e> are all of the open threads for sending/receiving messages from other peers located in StartNode?
 832015-12-29T02:58:17  <jayd3e> in net.cpp
 842015-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)
 852015-12-29T03:00:52  <sipa> cfields is working on replacing a significant part of the network code with libevent
 862015-12-29T03:08:13  *** Tera2342 has quit IRC
 872015-12-29T03:08:18  <jayd3e> sipa: gotcha thanks
 882015-12-29T03:17:01  *** Alopex has joined #bitcoin-core-dev
 892015-12-29T03:18:08  *** Alopex has quit IRC
 902015-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
 912015-12-29T03:22:05  <petertodd> maaku: dangerous? I consider that to be a good thing
 922015-12-29T03:22:18  <maaku> right now transaction selection can be delegated to a third party, not so under your proposal I believe
 932015-12-29T03:22:47  <petertodd> maaku: yeah, you don'twant tx selection to be delegatable
 942015-12-29T03:23:01  <brg444> maaku is transaction selection delegation desirable?
 952015-12-29T03:23:33  *** Alopex has joined #bitcoin-core-dev
 962015-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.
 972015-12-29T03:24:46  <petertodd> maaku: I know, that's why I'm not proposing that yet
 982015-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
 992015-12-29T03:25:10  <petertodd> maaku: I'm just proposing we ensure that mining pools have the data sufficient to validate
1002015-12-29T03:25:13  <maaku> something which is very much possible today but no one is doing
1012015-12-29T03:25:22  *** JackH has quit IRC
1022015-12-29T03:25:26  *** Alopex has joined #bitcoin-core-dev
1032015-12-29T03:25:33  <petertodd> maaku: why would that be an improvement?
1042015-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.)
1052015-12-29T03:26:57  *** Alopex has quit IRC
1062015-12-29T03:27:28  <petertodd> maaku: are you assuming DRM tech?
1072015-12-29T03:27:51  <maaku> petertodd: ideally, yes, but it is still an improvement without
1082015-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
1092015-12-29T03:28:28  *** jayd3e has quit IRC
1102015-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
1112015-12-29T03:29:32  <petertodd> maaku: at best, the hashing power can be turned off by force
1122015-12-29T03:29:47  <petertodd> maaku: equally, I'm not very worried about that kind of centralization, as cheap power has diseconomies of scale
1132015-12-29T03:30:08  <maaku> petertodd: turning off the hashers is a risk under any scenario
1142015-12-29T03:30:18  <maaku> DRM just makes it the only thing he can do
1152015-12-29T03:30:52  <petertodd> maaku: DRM puts you in possitions where mfg's are encouraged to produce back doorable hardware
1162015-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
1172015-12-29T03:31:36  <alpalp> .
1182015-12-29T03:31:40  <petertodd> "whole globe evens out"<- what do you mean by that?
1192015-12-29T03:32:21  *** Alopex has joined #bitcoin-core-dev
1202015-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
1212015-12-29T03:32:45  <petertodd> again, I think you're crazy and optimising for the wrong things
1222015-12-29T03:32:46  <sipa> but it seems like that may not be needed to combat the validationless mining degradation
1232015-12-29T03:32:58  <petertodd> maaku: ^^^
1242015-12-29T03:33:02  *** Alopex has quit IRC
1252015-12-29T03:33:09  <sipa> so stop arguing
1262015-12-29T03:33:14  <petertodd> heh
1272015-12-29T03:33:24  <sipa> whether you agree or not is not relevant
1282015-12-29T03:34:41  *** Alopex has joined #bitcoin-core-dev
1292015-12-29T03:35:38  <maaku> i'm not convinced we need to combat validationless mining, that's the issue :\
1302015-12-29T03:35:52  *** Alopex has quit IRC
1312015-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
1322015-12-29T03:36:35  <sipa> maaku: or validationless transaction selection, if you will
1332015-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
1342015-12-29T03:38:38  <petertodd> sipa: which we don't want
1352015-12-29T03:38:43  <sipa> agree
1362015-12-29T03:38:57  <sipa> but it may be inevitable...
1372015-12-29T03:39:08  *** Alopex has joined #bitcoin-core-dev
1382015-12-29T03:39:09  <petertodd> sipa: so? why hasten it?
1392015-12-29T03:39:19  <sipa> i'm not arguing either way
1402015-12-29T03:39:27  <sipa> just observing
1412015-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
1422015-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)
1432015-12-29T03:40:46  <sipa> no disagreement :)
1442015-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
1452015-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
1462015-12-29T03:41:53  *** Alopex has quit IRC
1472015-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
1482015-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
1492015-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%
1502015-12-29T03:43:04  <petertodd> maaku: currently the system assumes miners validate; if they stop validating we risk massive reorgs at best
1512015-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)
1522015-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
1532015-12-29T03:44:14  *** Alopex has joined #bitcoin-core-dev
1542015-12-29T03:44:30  <petertodd> sipa: and validationless blocks with txs in them are much more dangerous
1552015-12-29T03:44:41  <sipa> petertodd: though, compared to downloading the full block right now and disabling script verification, there is not much difference
1562015-12-29T03:45:04  <sipa> petertodd: segwit just makes that use a constant factor less bandwidth
1572015-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
1582015-12-29T03:45:15  <sipa> which may be an issue still
1592015-12-29T03:45:36  *** dcousens has joined #bitcoin-core-dev
1602015-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
1612015-12-29T03:45:49  <dcousens> why does OP_CLTV care about the transactions lock time?
1622015-12-29T03:46:09  <dcousens> (when it just checks the stack item pushed just prior?)
1632015-12-29T03:46:23  <sipa> dcousens: ?
1642015-12-29T03:46:36  <petertodd> dcousens: CLTV checks the stack item against nLockTime
1652015-12-29T03:46:40  <sipa> dcousens: it compares that stack item with tx.nLocktime
1662015-12-29T03:47:16  <dcousens> Need to re-read that BIP then
1672015-12-29T03:47:27  <petertodd> dcousens: read the source
1682015-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
1692015-12-29T03:48:37  <petertodd> sipa: creating such a block costs 25BTC - it's a good bet that they won't
1702015-12-29T03:48:44  <petertodd> sipa: exactly like today...
1712015-12-29T03:48:46  <sipa> yup
1722015-12-29T03:48:49  <sipa> yup
1732015-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
1742015-12-29T03:51:15  <sipa> same as with a relay network today
1752015-12-29T03:51:24  <sipa> if you don't fully validate
1762015-12-29T03:51:41  <petertodd> sipa: why? there's PoW proof that they're risking 25BTC, so the block is very probably valid
1772015-12-29T03:52:01  <petertodd> sipa: how many delibrately invalid blocks have *ever* been created? I'm guessing zero in recent history
1782015-12-29T03:53:09  <dgenr8> petertodd: how low is "low enough"?
1792015-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
1802015-12-29T03:53:21  <petertodd> dgenr8: huh?
1812015-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
1822015-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%
1832015-12-29T03:55:10  <petertodd> dgenr8: that's a business requirement for there to be a level playing field
1842015-12-29T03:55:40  <dgenr8> do you know what that measurement is today?
1852015-12-29T03:56:19  <petertodd> dgenr8: no I don't, because we're not under attack conditions
1862015-12-29T03:56:45  <dgenr8> what are those? not just full blocks / spam?
1872015-12-29T03:57:03  <petertodd> dgenr8: miners who aren't cooperating with other miners is the big one
1882015-12-29T03:57:19  <dgenr8> not relaying others' blocks?
1892015-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
1902015-12-29T03:57:45  <petertodd> dgenr8: making blocks that contain not-previously-relayed (or recently relayed) transactions
1912015-12-29T03:58:05  <dgenr8> ah
1922015-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
1932015-12-29T03:59:19  <dgenr8> maybe the relay network should be turned off
1942015-12-29T03:59:36  <petertodd> dgenr8: there's no way to force people to do that
1952015-12-29T04:01:51  <phantomcircuit> <petertodd> sipa: how many delibrately invalid blocks have *ever* been created? I'm guessing zero in recent history
1962015-12-29T04:02:01  <phantomcircuit> petertodd, that's only true when mining is largely centralized
1972015-12-29T04:02:09  <petertodd> phantomcircuit: huh?
1982015-12-29T04:02:50  <phantomcircuit> petertodd, there's effectively a reputation system at work with mining today
1992015-12-29T04:03:02  <phantomcircuit> the stratum mining stuff is whitelist based
2002015-12-29T04:03:03  <petertodd> phantomcircuit: huh?
2012015-12-29T04:03:34  <petertodd> phantomcircuit: well yeah, I want to stay *at* the status quo, and not make things *worse*
2022015-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
2032015-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
2042015-12-29T04:03:50  <petertodd> phantomcircuit: I'd rather make things better, but that's probably politically/technically impooossible right now
2052015-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
2062015-12-29T04:04:58  <phantomcircuit> petertodd, the problem is self correcting if mining becomes less centralized
2072015-12-29T04:05:24  <petertodd> phantomcircuit: why?
2082015-12-29T04:06:02  <phantomcircuit> petertodd, at least the stratum one does
2092015-12-29T04:06:14  <petertodd> phantomcircuit: I'm still not seeing your point
2102015-12-29T04:06:22  <phantomcircuit> reputation management is much more difficult with lots of players
2112015-12-29T04:06:34  <petertodd> phantomcircuit: this has nothing to do with reputation
2122015-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)
2132015-12-29T04:09:14  <phantomcircuit> petertodd, there's an asynmetry between smaller and larger pools though
2142015-12-29T04:09:22  <petertodd> phantomcircuit: how so?
2152015-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
2162015-12-29T04:10:13  <petertodd> phantomcircuit: sure, but you can weight that if you want, and it's still expensive
2172015-12-29T04:10:22  <petertodd> phantomcircuit: that also doesn't negate my segwit objections
2182015-12-29T04:11:05  <phantomcircuit> petertodd, maybe but the reasoning here isn't so simple
2192015-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
2202015-12-29T04:14:06  *** belcher has quit IRC
2212015-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)
2222015-12-29T04:22:51  *** brg444 has quit IRC
2232015-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)
2242015-12-29T04:36:39  *** arowser has quit IRC
2252015-12-29T04:37:12  *** arowser has joined #bitcoin-core-dev
2262015-12-29T04:38:07  *** Tera2342 has joined #bitcoin-core-dev
2272015-12-29T04:38:57  *** Tera2342 has quit IRC
2282015-12-29T04:40:42  *** alpalp has quit IRC
2292015-12-29T04:42:28  *** alpalp has joined #bitcoin-core-dev
2302015-12-29T05:03:57  *** p15 has joined #bitcoin-core-dev
2312015-12-29T05:08:30  *** Quent has quit IRC
2322015-12-29T05:08:56  *** Quent has joined #bitcoin-core-dev
2332015-12-29T05:24:52  *** PRab has quit IRC
2342015-12-29T05:25:44  *** PRab has joined #bitcoin-core-dev
2352015-12-29T06:01:18  *** Yoghur114 has quit IRC
2362015-12-29T06:01:43  *** Yoghur114 has joined #bitcoin-core-dev
2372015-12-29T06:35:43  *** frankenmint has joined #bitcoin-core-dev
2382015-12-29T06:44:30  *** Yoghur114 has quit IRC
2392015-12-29T06:44:49  *** smooth has joined #bitcoin-core-dev
2402015-12-29T06:44:50  *** Yoghur114 has joined #bitcoin-core-dev
2412015-12-29T06:48:42  <dcousens> anyone know of an up to date reference for coinswap?
2422015-12-29T06:49:13  <dcousens> (or is https://bitcointalk.org/index.php?topic=321228.0 still considered the latest?)
2432015-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.
2442015-12-29T06:53:34  <dcousens> I didn't necessarily mean impl, but, just in terms of an algorithm
2452015-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
2462015-12-29T06:55:04  <jcorgan> probably a good -wizards discussion
2472015-12-29T06:55:08  <dcousens> ok
2482015-12-29T07:09:50  *** zookolaptop has quit IRC
2492015-12-29T07:09:51  *** tripleslash_b has joined #bitcoin-core-dev
2502015-12-29T07:09:55  *** tripleslash_a has quit IRC
2512015-12-29T07:34:36  *** Alopex has quit IRC
2522015-12-29T07:43:22  *** mturquette has joined #bitcoin-core-dev
2532015-12-29T09:04:44  *** Ylbam has joined #bitcoin-core-dev
2542015-12-29T09:08:40  *** BashCo has quit IRC
2552015-12-29T09:15:16  *** Guyver2 has joined #bitcoin-core-dev
2562015-12-29T09:27:54  *** BashCo has joined #bitcoin-core-dev
2572015-12-29T09:47:23  *** JackH has joined #bitcoin-core-dev
2582015-12-29T10:05:00  *** teward has quit IRC
2592015-12-29T10:12:05  *** teward has joined #bitcoin-core-dev
2602015-12-29T10:19:50  *** frankenmint has quit IRC
2612015-12-29T10:23:24  *** Prattler has quit IRC
2622015-12-29T10:24:03  *** JackH has quit IRC
2632015-12-29T10:28:35  *** Yoghur114 has quit IRC
2642015-12-29T10:29:18  *** Yoghur114 has joined #bitcoin-core-dev
2652015-12-29T10:45:15  *** tripleslash_k has joined #bitcoin-core-dev
2662015-12-29T10:46:35  *** tripleslash_b has quit IRC
2672015-12-29T10:47:30  *** d_t has quit IRC
2682015-12-29T10:49:33  *** p15 has quit IRC
2692015-12-29T10:53:48  *** JackH has joined #bitcoin-core-dev
2702015-12-29T10:53:53  *** JackH has quit IRC
2712015-12-29T11:01:00  *** arowser has quit IRC
2722015-12-29T11:01:20  *** arowser has joined #bitcoin-core-dev
2732015-12-29T12:04:46  *** mturquette has quit IRC
2742015-12-29T12:05:06  *** mturquette has joined #bitcoin-core-dev
2752015-12-29T12:17:01  *** Prattler has joined #bitcoin-core-dev
2762015-12-29T12:19:28  *** maaku has quit IRC
2772015-12-29T12:36:35  *** xiangfu has quit IRC
2782015-12-29T13:32:23  *** maaku has joined #bitcoin-core-dev
2792015-12-29T13:32:47  *** maaku is now known as Guest87480
2802015-12-29T13:33:29  *** Guest87480 is now known as maaku
2812015-12-29T13:46:05  *** tripleslash_i has joined #bitcoin-core-dev
2822015-12-29T13:47:36  *** tripleslash_k has quit IRC
2832015-12-29T13:54:29  *** treehug88 has joined #bitcoin-core-dev
2842015-12-29T14:55:40  *** wangchun has quit IRC
2852015-12-29T14:57:41  *** wangchun has joined #bitcoin-core-dev
2862015-12-29T14:59:46  *** alpalp has quit IRC
2872015-12-29T15:07:39  *** davec has quit IRC
2882015-12-29T15:13:39  *** davec has joined #bitcoin-core-dev
2892015-12-29T15:24:39  *** zookolaptop has joined #bitcoin-core-dev
2902015-12-29T15:29:47  *** molz has joined #bitcoin-core-dev
2912015-12-29T15:34:23  *** moli has quit IRC
2922015-12-29T16:02:06  *** bsm117532 has joined #bitcoin-core-dev
2932015-12-29T16:09:21  *** tripleslash_q has joined #bitcoin-core-dev
2942015-12-29T16:10:58  *** tripleslash_i has quit IRC
2952015-12-29T16:15:47  *** d_t has joined #bitcoin-core-dev
2962015-12-29T17:28:14  *** brg444 has joined #bitcoin-core-dev
2972015-12-29T17:34:34  *** BashCo has quit IRC
2982015-12-29T17:50:18  *** BashCo has joined #bitcoin-core-dev
2992015-12-29T17:59:48  *** BashCo_ has joined #bitcoin-core-dev
3002015-12-29T18:02:44  *** BashCo has quit IRC
3012015-12-29T18:51:17  *** desantis has joined #bitcoin-core-dev
3022015-12-29T18:52:30  *** desantis has left #bitcoin-core-dev
3032015-12-29T19:09:31  *** JackH has joined #bitcoin-core-dev
3042015-12-29T19:27:35  *** Thireus has joined #bitcoin-core-dev
3052015-12-29T19:30:15  *** bsm117532 has quit IRC
3062015-12-29T19:42:22  *** Thireus has quit IRC
3072015-12-29T19:44:55  *** treehug88 has quit IRC
3082015-12-29T19:47:05  *** bsm117532 has joined #bitcoin-core-dev
3092015-12-29T19:49:09  *** Thireus has joined #bitcoin-core-dev
3102015-12-29T20:07:20  *** jayd3e has joined #bitcoin-core-dev
3112015-12-29T20:07:34  <jayd3e> how can nThreadsServicingQueue be called as a function in scheduler.cpp
3122015-12-29T20:07:42  <jayd3e> on line 13
3132015-12-29T20:08:00  <jayd3e> it's defined as an int in scheduler.h
3142015-12-29T20:10:39  <jayd3e> nvm figured it out
3152015-12-29T20:14:26  *** bsm117532 has quit IRC
3162015-12-29T20:18:57  *** bsm117532 has joined #bitcoin-core-dev
3172015-12-29T20:28:59  <jayd3e> what does the "<>" indicate in this line: newTaskScheduled.wait_until<>(lock, taskQueue.begin()->first)
3182015-12-29T20:29:17  <jayd3e> from line 58 of scheduler.cpp
3192015-12-29T20:34:50  <instagibbs> Not a c++ guy myself, but http://stackoverflow.com/questions/20398587/template-function-call-with-empty-angle-brackets
3202015-12-29T20:36:14  <jayd3e> instagibbs: nice, thanks.  That makes sense
3212015-12-29T20:46:33  *** d_t has quit IRC
3222015-12-29T20:47:14  *** d_t has joined #bitcoin-core-dev
3232015-12-29T21:12:02  *** fkhan_ has quit IRC
3242015-12-29T21:12:22  *** brg444 has quit IRC
3252015-12-29T21:17:12  *** jayd3e has quit IRC
3262015-12-29T21:23:13  *** fkhan_ has joined #bitcoin-core-dev
3272015-12-29T21:48:20  *** brg444 has joined #bitcoin-core-dev
3282015-12-29T21:53:39  *** Thireus has quit IRC
3292015-12-29T21:56:35  *** Thireus has joined #bitcoin-core-dev
3302015-12-29T21:59:51  *** Thireus1 has joined #bitcoin-core-dev
3312015-12-29T22:01:47  *** Thireus has quit IRC
3322015-12-29T22:07:26  *** Thireus has joined #bitcoin-core-dev
3332015-12-29T22:07:26  *** Thireus1 has quit IRC
3342015-12-29T22:09:29  *** Thireus1 has joined #bitcoin-core-dev
3352015-12-29T22:09:29  *** Thireus has quit IRC
3362015-12-29T22:09:49  *** Thireus has joined #bitcoin-core-dev
3372015-12-29T22:13:55  *** Thireus1 has quit IRC
3382015-12-29T22:40:30  *** go1111111 has quit IRC
3392015-12-29T22:40:49  *** Alopex has joined #bitcoin-core-dev
3402015-12-29T22:57:35  *** go1111111 has joined #bitcoin-core-dev
3412015-12-29T23:07:00  *** neha_ has quit IRC
3422015-12-29T23:09:00  *** go1111111 has quit IRC
3432015-12-29T23:09:58  *** tripleslash has joined #bitcoin-core-dev
3442015-12-29T23:11:30  *** tripleslash_q has quit IRC
3452015-12-29T23:18:44  *** jcorgan is now known as jcorgan|away
3462015-12-29T23:22:15  *** go1111111 has joined #bitcoin-core-dev