12015-10-04T00:22:32  *** jgarzik has joined #bitcoin-core-dev
  22015-10-04T00:34:23  *** fkhan has quit IRC
  32015-10-04T00:42:42  *** fkhan has joined #bitcoin-core-dev
  42015-10-04T01:32:49  *** PaulCape_ has quit IRC
  52015-10-04T01:33:41  *** PaulCapestany has joined #bitcoin-core-dev
  62015-10-04T01:35:01  *** sipa has quit IRC
  72015-10-04T01:35:53  *** sipa has joined #bitcoin-core-dev
  82015-10-04T02:10:41  <Luke-Jr> FYI: Someone in #bitcoin is actively trying to get a virus signature mined into the blockchain.
  92015-10-04T02:13:43  <phantomcircuit> gmaxwell, https://github.com/pstratem/bitcoinconsensus_fuzzer
 102015-10-04T02:47:15  *** PaulCape_ has joined #bitcoin-core-dev
 112015-10-04T02:49:40  *** PaulCapestany has quit IRC
 122015-10-04T02:51:46  <CodeShark> getting it mined is the easy part - it's figuring out something that will trip off scanners that's a little trickier ;)
 132015-10-04T02:52:42  <BlueMatt> there is a standard virus test signature that will trip up all virus scanners if they see it
 142015-10-04T02:52:53  <BlueMatt> eicar
 152015-10-04T02:53:10  <CodeShark> how big is it?
 162015-10-04T02:53:17  <BlueMatt> 68 bytes
 172015-10-04T02:53:18  <BlueMatt> X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
 182015-10-04T02:53:23  <BlueMatt> put that in a file
 192015-10-04T02:53:48  <BlueMatt> heh, i had hide parts turned on..did anyone just part?
 202015-10-04T02:54:17  <BlueMatt> oh, nvm, it only works at the beginning of a file that is not longer than 128 chars
 212015-10-04T02:54:47  <gmaxwell> the eicar thing triggers almost nothing.
 222015-10-04T02:54:51  <gmaxwell> because, that.
 232015-10-04T02:55:04  <BlueMatt> gmaxwell: oh? If you put it in by itself I've seen it trigger almost everything
 242015-10-04T02:55:14  <BlueMatt> you just cant put it in the middle of a file
 252015-10-04T02:56:57  <CodeShark> we should store all blocks using symmetric crypto with the block hash as the key :p
 262015-10-04T02:59:09  <Luke-Jr> CodeShark: you're aware we have an open PR to obfuscate the chainstate, right? ;)
 272015-10-04T02:59:09  <sipa> CodeShark: being done for the utxo set now
 282015-10-04T02:59:19  <CodeShark> oh?
 292015-10-04T02:59:36  <CodeShark> since when?
 302015-10-04T02:59:37  <sipa> just xor, not symmetric crypto
 312015-10-04T02:59:38  <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/6650
 322015-10-04T02:59:55  <Luke-Jr> sipa: eh? xor doesn't count as symm crypto? :P
 332015-10-04T03:00:07  <CodeShark> someone stole my idea! :p
 342015-10-04T03:01:04  <sipa> Luke-Jr: it's symmetric, but not cryptographic :)
 352015-10-04T03:01:05  <Luke-Jr> CodeShark: I've been recommending it to newbies for a while
 362015-10-04T03:01:15  <Luke-Jr> sipa: but.. but..
 372015-10-04T03:01:28  <CodeShark> it's ultimately a matter of degree
 382015-10-04T03:01:38  <CodeShark> an xor one-time pad is more secure than any asymmetric cypher
 392015-10-04T03:02:05  <CodeShark> *cipher
 402015-10-04T03:02:11  <sipa> well, if XOR is symmetric cryptography, then { return 4; } is a CSPRNG :)
 412015-10-04T03:02:16  <CodeShark> damn, I of all people should know how to spell that word :p
 422015-10-04T03:03:05  <gmaxwell> importantly it's an xor with a per node random key.. which should be more than enough.
 432015-10-04T03:03:31  <CodeShark> xor is as secure as any other symmetric cipher if the key is at least as long as the message ;)
 442015-10-04T03:03:40  <gmaxwell> unless there are virus signatures that deal with the xor relationships of 8 byte apart groups... I couldn't find anything like that.
 452015-10-04T03:03:44  <CodeShark> or even more secure
 462015-10-04T03:04:13  <CodeShark> and as long as you only use it once
 472015-10-04T03:08:44  <CodeShark> I suppose something similar could be said for { return 4; } as a CSPRNG...if you only call it once :p
 482015-10-04T03:09:17  <CodeShark> however, 4 is a rather improbable number given cryptograpically-sized output
 492015-10-04T03:10:00  <CodeShark> it's no less probable than any other...but it still looks suspiciously small :)
 502015-10-04T03:10:51  <CodeShark> moreover, in both cases you need external entrop
 512015-10-04T03:10:52  <CodeShark> *entropy
 522015-10-04T03:11:14  <sipa> yes yes yes
 532015-10-04T03:11:16  <sipa> :)
 542015-10-04T03:18:20  *** belcher_ has quit IRC
 552015-10-04T03:19:07  *** neha has quit IRC
 562015-10-04T03:19:30  *** morcos has quit IRC
 572015-10-04T03:19:38  *** neha has joined #bitcoin-core-dev
 582015-10-04T03:20:10  *** zxzzt_ has quit IRC
 592015-10-04T03:20:32  *** morcos has joined #bitcoin-core-dev
 602015-10-04T03:21:00  *** zxzzt has joined #bitcoin-core-dev
 612015-10-04T03:32:33  <CodeShark> a virus signature that involves xor relationships 8 bytes apart would likely give many false alarms :p
 622015-10-04T03:33:32  <CodeShark> just dividing two large numbers could trip it off :p
 632015-10-04T04:20:20  <Luke-Jr> CodeShark: has that ever stopped them?
 642015-10-04T04:20:50  <Luke-Jr> CodeShark: most AVs have at one time or another made a signature for BFGMiner just because it was a semi-common payload
 652015-10-04T04:44:25  *** lightningbot has joined #bitcoin-core-dev
 662015-10-04T05:03:41  <phantomcircuit> gmaxwell, the current version of the fuzzer logic only modifies the script portion
 672015-10-04T05:03:50  <phantomcircuit> it's significantly slower when the entire transaction can be modified
 682015-10-04T05:04:04  <phantomcircuit> i seem to have stopped finding interesting cases with 256 byte scripts though
 692015-10-04T05:08:15  <CodeShark> did you do an ordered search? or bruteforce?
 702015-10-04T05:09:41  <CodeShark> wasn't it 256-byte transactions that were of interest?
 712015-10-04T05:13:23  <phantomcircuit> CodeShark, afl-fuzz
 722015-10-04T05:13:28  <phantomcircuit> see https://github.com/pstratem/bitcoinconsensus_fuzzer
 732015-10-04T05:15:09  <phantomcircuit> CodeShark, definitely cant brute force all the 256 byte combinations :)
 742015-10-04T05:16:11  <CodeShark> is the goal simply to find valid transactions that are exactly 256 bytes long?
 752015-10-04T05:16:32  <BlueMatt> phantomcircuit: do you need a faster box to run that on?
 762015-10-04T05:18:02  <CodeShark> or nvm, I don't really know what you're trying to do :p
 772015-10-04T05:18:54  <phantomcircuit> CodeShark, no the goal is to find interesting transactions
 782015-10-04T05:18:58  <phantomcircuit> valid or otherwise
 792015-10-04T05:19:23  <phantomcircuit> BlueMatt, i dont think it would matter much, it's been running for about two days and hasn't found a new .... wait
 802015-10-04T05:19:32  <phantomcircuit> damn it i screwed up the afl-fuzz setup!
 812015-10-04T05:19:35  * phantomcircuit grubles
 822015-10-04T05:19:50  <CodeShark> by "valid" I'm just talking in terms of parser logic - not the chainstate and crypto validation stuff :p
 832015-10-04T05:19:57  <BlueMatt> phantomcircuit: if you send me the vm image I can run it on my workstation.....
 842015-10-04T05:19:58  <phantomcircuit> hmm actually maybe not
 852015-10-04T05:20:20  <phantomcircuit> looks like i didn't screw it up
 862015-10-04T05:20:44  <phantomcircuit> CodeShark, i have 1 testcase which fails the parser logic, but because of how afl-fuzz works it's only th eone
 872015-10-04T05:38:45  <phantomcircuit> gmaxwell, there seems to be an issue with the frequency of wallet flushes and the pruning logic
 882015-10-04T05:39:02  <phantomcircuit> the pruning logic can prune blocks where the wallet hasn't flushed indicating it's sync'd to them
 892015-10-04T05:39:15  <phantomcircuit> BlueMatt, you should fix! :P
 902015-10-04T05:39:50  <BlueMatt> huh?
 912015-10-04T05:40:00  <gmaxwell> hahah
 922015-10-04T05:40:21  <gmaxwell> phantomcircuit: yea that sounds bad. :P
 932015-10-04T05:42:45  <phantomcircuit> i would bet the same thing can happen with the block index, but i'd need to double check on that
 942015-10-04T05:43:34  <CodeShark> it would really be nice to put all the header logic into its own unit
 952015-10-04T05:45:16  <CodeShark> separate issue...but just thought I'd bring it up :p
 962015-10-04T05:46:07  <CodeShark> then other parts of the app can sync to the headers in different ways
 972015-10-04T05:46:38  <CodeShark> and the header index can carry additional state information
 982015-10-04T05:49:06  <CodeShark> (i.e. what rules to enforce for the particular block :) )
 992015-10-04T05:53:59  <CodeShark> we could also shave off 80 bytes of data from getblock if we always use getheader to grab the header
1002015-10-04T05:54:33  <CodeShark> not that 80 bytes is that much when put into context of downloading the entire block :p
1012015-10-04T05:54:42  <CodeShark> but we could have more sophisticated queries for partial blocks
1022015-10-04T05:56:00  <CodeShark> I'm very much not satisfied with the filteredblock mechanism we currently have ;)
1032015-10-04T05:57:27  <CodeShark> even pruned nodes could serve useful data if the query structure were better
1042015-10-04T05:58:58  <CodeShark> in retrospect, perhaps Satoshi should have tried to implement SPV first :p
1052015-10-04T06:00:35  <gmaxwell> he did.
1062015-10-04T06:00:49  <gmaxwell> there was a begin a it in bitcoin core that was long since stripped out
1072015-10-04T06:01:03  <CodeShark> begin a it?
1082015-10-04T06:01:10  <gmaxwell> at
1092015-10-04T06:01:38  <CodeShark> I'm saying perhaps the header sync should have been the first consensus code written
1102015-10-04T06:01:44  <gmaxwell> today it will be much easier to do, but long ago the architecture was probably a bit too alien.
1112015-10-04T06:02:54  <gmaxwell> CodeShark: you have some hindsight benefit of how we think about the architecture of the system in modern times. :)
1122015-10-04T06:03:10  <CodeShark> yes, I said "in retrospect"
1132015-10-04T06:05:03  <CodeShark> in terms of what we can do now, I think if we really want to build a consensus library we should think in terms of isolating header sync into a standalone unit
1142015-10-04T06:05:25  <CodeShark> then we can build whatever kind of node on top of that
1152015-10-04T06:05:33  <CodeShark> whether it be full validation, pruned or not, SPV, etc...
1162015-10-04T06:07:03  <CodeShark> it will also help in avoiding unintended forks and other such issues in the future as we can explicitly know which rules can and cannot be enforced by a given node
1172015-10-04T06:07:39  <CodeShark> there's a whole spectrum here
1182015-10-04T06:07:48  <CodeShark> from "check absolutely everything" to "check nothing"
1192015-10-04T06:09:18  <gmaxwell> the structure of bitcoin core today is much more agreeable to that than it was in the past.
1202015-10-04T06:09:34  <CodeShark> yes, sipa did a good job with the headers-first sync
1212015-10-04T06:09:53  <CodeShark> so it's going in the right direction
1222015-10-04T06:11:31  <CodeShark> I did some outlining of everything that happens in ProcessNewBlock...there's a lot of redundancy and plenty of things that can be cleaned up
1232015-10-04T06:12:06  <CodeShark> ContextualCheckBlockHeader gets called twice
1242015-10-04T06:12:34  <CodeShark> it would be nice to just make all the state info checked in that part of the header index itself
1252015-10-04T06:29:34  *** ParadoxSpiral has joined #bitcoin-core-dev
1262015-10-04T06:31:50  <CodeShark> ultimately, I'd even like the version bits logic itself to be directly part of the header index - so instead of doing something like Rules rules  GetRulesFromBlockIndex(pblockIndex); you can just do blockHeader.GetRules();
1272015-10-04T06:33:19  <CodeShark> or headerIndex(block_hash).getRules();
1282015-10-04T06:33:22  <CodeShark> or whatever
1292015-10-04T06:33:26  <CodeShark> something pretty like that :)
1302015-10-04T06:35:43  <CodeShark> then the rest of the block checking stuff can have conditionals like if(rules.contains(BIP66)) { }
1312015-10-04T06:36:44  <CodeShark> and from that point on we can easily isolate ANY changes to consensus checks and test them independently
1322015-10-04T06:38:05  <CodeShark> even alt coins could be built that can contribute useful ideas back to Bitcoin ;)
1332015-10-04T06:38:40  <CodeShark> rather than having to constrain our refactoring efforts to avoid pushback from people who long ago forked Bitcoin Core :p
1342015-10-04T08:18:13  *** randy-waterhouse has joined #bitcoin-core-dev
1352015-10-04T08:37:29  *** n0n0_ has joined #bitcoin-core-dev
1362015-10-04T09:12:15  *** BashCo_ has quit IRC
1372015-10-04T09:28:13  *** adam3us has quit IRC
1382015-10-04T09:31:53  *** adam3us has joined #bitcoin-core-dev
1392015-10-04T09:51:53  *** NLNico has joined #bitcoin-core-dev
1402015-10-04T11:09:42  <sipa> phantomcircuit: no, that can't happen with the block index afaik, as the flushing and pruning logic are aware of each other
1412015-10-04T11:10:16  <sipa> phantomcircuit: but for the wallet... i guess that's possible
1422015-10-04T11:32:24  *** randy-waterhouse has quit IRC
1432015-10-04T11:43:13  *** belcher_ has joined #bitcoin-core-dev
1442015-10-04T11:58:32  *** paveljanik has joined #bitcoin-core-dev
1452015-10-04T11:58:32  *** paveljanik has joined #bitcoin-core-dev
1462015-10-04T12:22:03  *** dcousens has joined #bitcoin-core-dev
1472015-10-04T12:26:08  <morcos> phantomcircuit: sipa: yeah wumpus and i went through the block index / pruning logic a week or so ago, and it is a tiny bit scary, but it works.  i promised him i'd write it up in an issue, its still on my to do list.  we'll check into the wallet
1482015-10-04T12:27:13  <morcos> actually i guess for the block index, is more about just commenting the code as to why it works, so no one changes it
1492015-10-04T12:27:24  <CodeShark> after the 0.12 release, I propose we work towards breaking out headers sync as the first part of modularizing and encapsulating the consensus code :)
1502015-10-04T12:27:26  *** randy-waterhouse has joined #bitcoin-core-dev
1512015-10-04T12:28:13  <CodeShark> we should have a standalone module that can do a headers sync and provide query and subscription services
1522015-10-04T12:31:01  <CodeShark> not necessarily even as a standalone library - just a unit that can be built along with a simple demo app that only uses stable dependencies
1532015-10-04T12:34:53  <CodeShark> I had designed such an interface but it can probably be done even better: https://github.com/ciphrex/mSIGNA/blob/master/deps/CoinQ/src/CoinQ_blocks.h#L79
1542015-10-04T12:35:50  <CodeShark> all the protocol rule changes (including versionbits) can naturally be fit into this
1552015-10-04T12:42:41  <CodeShark> I'll write up a more detailed document if enough people seem sufficiently interested to make this worthwhile pursuing and encourage anyone to join in
1562015-10-04T12:43:39  <sipa> CodeShark: synchronization is very different from consensus :)
1572015-10-04T12:43:40  <CodeShark> this obviously needs to be done in coordination with all our other refactoring efforts
1582015-10-04T12:43:47  <CodeShark> sipa, I should clarify...
1592015-10-04T12:43:59  <CodeShark> I meant block header consensus - this example I'm sharing has no networking code
1602015-10-04T12:44:29  <CodeShark> it allows you to insert block headers (that can come from any source) and it can validate PoW, timestamp, and version
1612015-10-04T12:45:28  <CodeShark> and can allow clients to subscribe to signals for events...and we can plug in modules for doing more verification with actual block data
1622015-10-04T12:46:19  <CodeShark> then we'll have total flexibility - we can do headers-only sync...or we can do full validation...or anything in between
1632015-10-04T12:46:50  <sipa> CodeShark: i've suggested something similar, by moving full validation to a separate module with its own state
1642015-10-04T12:47:05  <randy-waterhouse> a hybrid node
1652015-10-04T12:47:12  <sipa> which uses the main signals to trigger full validation
1662015-10-04T12:47:20  <CodeShark> yeah, I think it's the way to go
1672015-10-04T12:49:37  <sipa> i think my point is that that interface already exists
1682015-10-04T12:49:45  <sipa> and we should reuse it
1692015-10-04T12:49:51  <CodeShark> can I see it?
1702015-10-04T12:49:56  <sipa> but rather than extract header validation from it
1712015-10-04T12:50:04  <sipa> move full validation out of it
1722015-10-04T12:50:26  <sipa> eh, look at main.h, there is a signals interface
1732015-10-04T12:52:17  <sipa> though i'd start with the wallet
1742015-10-04T12:52:47  <sipa> allow it to have its own "active block", which can be different from that of main
1752015-10-04T12:53:16  <sipa> ot only subscribes to updatetip events, and then requests the block data asynchronously to sync
1762015-10-04T12:53:59  <sipa> full validation can work the same way, but needs a slightly more featureful interface, where it can mark a block as invalid
1772015-10-04T12:54:36  <sipa> CodeShark: also, i disagree with moving more logic into basic data structure classes
1782015-10-04T12:55:02  <sipa> we've been moving the opposite direction mostly, because it really interferes with modularization
1792015-10-04T12:55:25  <CodeShark> well, it doesn't have to be implemented in the interface classes - we can either use templates or inheritance or something ;)
1802015-10-04T12:55:44  <sipa> bleh, even uglier
1812015-10-04T12:55:50  <CodeShark> or delegation
1822015-10-04T12:55:55  <CodeShark> why uglier?
1832015-10-04T12:56:14  <sipa> let me give an example to elaborate, so we're talking about the same thing
1842015-10-04T12:56:36  <sipa> imagine ctransaction had a sign function
1852015-10-04T12:56:48  <sipa> sounds awesome, very useful and elegant
1862015-10-04T12:56:49  <CodeShark> oh, that's not what I'm saying at all!!!
1872015-10-04T12:56:54  <CodeShark> I actually think that's hideous
1882015-10-04T12:57:16  <sipa> you were saying the block should have a function to ask what bips apply to it
1892015-10-04T12:57:21  <CodeShark> CTransaction should just contain the transaction data in a way that's easily accessible by the app and provide serialization
1902015-10-04T12:57:25  <sipa> i think that's very similar
1912015-10-04T12:57:30  <sipa> ok, we agree there
1922015-10-04T12:59:26  <CodeShark> regarding asking what bips apply, we need to maintain an index for this...so it seems like it would be convenient to have the same entrypoints we use to grab other block header info...but there are several alternatives to this
1932015-10-04T13:00:07  <CodeShark> and in fact, it makes sense to NOT build this logic into the core header consensus stuff
1942015-10-04T13:00:16  <CodeShark> at least not directly
1952015-10-04T13:00:35  <sipa> good :)
1962015-10-04T13:01:45  <CodeShark> I'd even leave room for flexibility on PoW and timestamp verification :)
1972015-10-04T13:03:29  <CodeShark> and if we want to go further, we can even make the header structure itself abstract
1982015-10-04T13:03:49  <CodeShark> the key structural element at this level is the notion of a block header tree
1992015-10-04T13:04:28  <CodeShark> which branch is "active" and the rules we apply to connect new headers needn't be specified at this level
2002015-10-04T13:06:11  <CodeShark> this stuff can be provided by a number of different mechanisms
2012015-10-04T13:07:42  <sipa> it makes more sense to do a writeup together with some minimal idea for code changes then talk here
2022015-10-04T13:08:07  <sipa> irc is good for discussion, but not really for monologue
2032015-10-04T13:08:22  <CodeShark> yeah :)
2042015-10-04T13:09:28  <CodeShark> so google docs?
2052015-10-04T13:10:51  <sipa> or issue
2062015-10-04T13:10:54  <sipa> or a branch
2072015-10-04T13:12:23  <CodeShark> I'd like to approach this from both directions, top-down and bottom up. I'd like to consider high level architectural stuff to set some goals...and then consider the practical implementation issues...and then put together a plan that can get us to our goals in incremental steps that are palatable
2082015-10-04T13:13:28  <sipa> so i prefer a high-level plan (without code) to show the intent, and then low-level changes that help get therr
2092015-10-04T13:13:49  <CodeShark> yes, absolutely agreed - the high-level plan should be much more about diagrams and ideas than about code
2102015-10-04T13:15:33  <CodeShark> we'll inevitably need to make some design decisions along the way that are largely determined by practical considerations...but our ultimate objectives should be clear
2112015-10-04T13:19:35  <CodeShark> moreover, we don't need to spell out all the individual steps up front - it is sufficient that we specify a few initial steps that, regardless of what we decide later, move us in the right direction
2122015-10-04T13:19:57  <CodeShark> but we should have a basic plan
2132015-10-04T13:21:00  *** sipa has left #bitcoin-core-dev
2142015-10-04T13:21:19  <CodeShark> ?
2152015-10-04T14:30:15  *** NLNico has quit IRC
2162015-10-04T15:51:02  *** CodeShark has quit IRC
2172015-10-04T15:51:17  *** CodeShark_ is now known as CodeShark
2182015-10-04T16:10:15  *** n0n0__ has joined #bitcoin-core-dev
2192015-10-04T16:13:40  *** n0n0_ has quit IRC
2202015-10-04T17:05:29  *** pigeons has quit IRC
2212015-10-04T17:12:50  *** BashCo has joined #bitcoin-core-dev
2222015-10-04T17:27:35  *** BashCo has quit IRC
2232015-10-04T17:35:04  *** pigeons has joined #bitcoin-core-dev
2242015-10-04T17:35:27  *** pigeons is now known as Guest22695
2252015-10-04T18:07:26  *** randy-waterhouse has quit IRC
2262015-10-04T18:32:40  *** ParadoxSpiral_ has joined #bitcoin-core-dev
2272015-10-04T18:35:55  *** ParadoxSpiral has quit IRC
2282015-10-04T18:52:40  *** randy-waterhouse has joined #bitcoin-core-dev
2292015-10-04T19:07:16  *** jl2012 has joined #bitcoin-core-dev
2302015-10-04T19:09:23  <GitHub106> [bitcoin] jgarzik pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/3ab3de8ba1a63d5ec0f97ae12e660d9730c60156
2312015-10-04T19:09:23  <GitHub106> bitcoin/master 3ab3de8 Jeff Garzik: qa/pull-tester/rpc-tests.py: chmod 0755...
2322015-10-04T19:24:48  *** jl2012 has quit IRC
2332015-10-04T19:25:07  *** jl2012 has joined #bitcoin-core-dev
2342015-10-04T19:25:35  *** gribble has quit IRC
2352015-10-04T19:26:17  *** Anduck_ has joined #bitcoin-core-dev
2362015-10-04T19:26:50  *** GAit_Alt has joined #bitcoin-core-dev
2372015-10-04T19:27:48  *** stonecoldpat1 has joined #bitcoin-core-dev
2382015-10-04T19:28:19  *** Guest1235 has joined #bitcoin-core-dev
2392015-10-04T19:29:02  *** aj_ has joined #bitcoin-core-dev
2402015-10-04T19:29:02  *** grubles_ has joined #bitcoin-core-dev
2412015-10-04T19:29:26  *** grubles_ is now known as Guest78185
2422015-10-04T19:30:29  *** baldur_ has joined #bitcoin-core-dev
2432015-10-04T19:30:41  *** GAit has quit IRC
2442015-10-04T19:30:42  *** challisto has quit IRC
2452015-10-04T19:30:43  *** evoskuil has quit IRC
2462015-10-04T19:30:43  *** baldur has quit IRC
2472015-10-04T19:30:43  *** isis has quit IRC
2482015-10-04T19:30:43  *** grubles has quit IRC
2492015-10-04T19:30:43  *** evoskuil has joined #bitcoin-core-dev
2502015-10-04T19:30:43  *** GAit_Alt is now known as GAit
2512015-10-04T19:30:53  *** challisto has joined #bitcoin-core-dev
2522015-10-04T19:30:53  *** challisto has joined #bitcoin-core-dev
2532015-10-04T19:31:12  *** GAit is now known as Guest11115
2542015-10-04T19:32:22  *** Anduck has quit IRC
2552015-10-04T19:32:23  *** aj has quit IRC
2562015-10-04T19:32:24  *** stonecoldpat has quit IRC
2572015-10-04T19:32:25  *** Guest1234 has quit IRC
2582015-10-04T19:34:23  *** isis has joined #bitcoin-core-dev
2592015-10-04T19:35:52  *** gribble has joined #bitcoin-core-dev
2602015-10-04T19:39:35  *** Guest78185 is now known as grubles
2612015-10-04T19:39:42  *** grubles has quit IRC
2622015-10-04T19:39:42  *** grubles has joined #bitcoin-core-dev
2632015-10-04T19:44:56  *** grubles has quit IRC
2642015-10-04T20:15:12  *** gribble has quit IRC
2652015-10-04T20:16:02  *** adam3us1 has joined #bitcoin-core-dev
2662015-10-04T20:18:37  <gmaxwell> If we're going to backport BIP65 to 0.8 we should also apply lowS signatures there, (a28fb70e45d764e558966ba3b02bd16e02b11c14 from 0.9).
2672015-10-04T20:18:42  *** adam3us has quit IRC
2682015-10-04T20:30:03  *** gribble has joined #bitcoin-core-dev
2692015-10-04T20:36:38  <btcdrak> are there any miners on 0.8?
2702015-10-04T20:36:56  <gmaxwell> who knows?
2712015-10-04T20:40:11  *** Anduck_ is now known as Anduck
2722015-10-04T20:50:20  *** ParadoxSpiral_ has quit IRC
2732015-10-04T21:03:39  *** randy-waterhouse has quit IRC
2742015-10-04T21:39:48  *** n0n0__ has quit IRC
2752015-10-04T22:27:24  *** dcousens has quit IRC
2762015-10-04T22:35:51  *** fkhan has quit IRC
2772015-10-04T22:54:39  *** fkhan has joined #bitcoin-core-dev
2782015-10-04T23:29:19  <maaku> one would hope not, but one should not operate based on hope
2792015-10-04T23:29:26  *** CodeShark has quit IRC
2802015-10-04T23:56:03  *** CodeShark has joined #bitcoin-core-dev
2812015-10-04T23:59:25  <Luke-Jr> I think we moved the last 0.8 miners off it during the BIP66/OpenSSL fiasco
2822015-10-04T23:59:41  <Luke-Jr> although we never quite figured out why their 0.8 was mining the problematic txns