1 2015-10-04T00:22:32  *** jgarzik has joined #bitcoin-core-dev
  2 2015-10-04T00:34:23  *** fkhan has quit IRC
  3 2015-10-04T00:42:42  *** fkhan has joined #bitcoin-core-dev
  4 2015-10-04T01:32:49  *** PaulCape_ has quit IRC
  5 2015-10-04T01:33:41  *** PaulCapestany has joined #bitcoin-core-dev
  6 2015-10-04T01:35:01  *** sipa has quit IRC
  7 2015-10-04T01:35:53  *** sipa has joined #bitcoin-core-dev
  8 2015-10-04T02:10:41  <Luke-Jr> FYI: Someone in #bitcoin is actively trying to get a virus signature mined into the blockchain.
  9 2015-10-04T02:13:43  <phantomcircuit> gmaxwell, https://github.com/pstratem/bitcoinconsensus_fuzzer
 10 2015-10-04T02:47:15  *** PaulCape_ has joined #bitcoin-core-dev
 11 2015-10-04T02:49:40  *** PaulCapestany has quit IRC
 12 2015-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 ;)
 13 2015-10-04T02:52:42  <BlueMatt> there is a standard virus test signature that will trip up all virus scanners if they see it
 14 2015-10-04T02:52:53  <BlueMatt> eicar
 15 2015-10-04T02:53:10  <CodeShark> how big is it?
 16 2015-10-04T02:53:17  <BlueMatt> 68 bytes
 17 2015-10-04T02:53:18  <BlueMatt> X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
 18 2015-10-04T02:53:23  <BlueMatt> put that in a file
 19 2015-10-04T02:53:48  <BlueMatt> heh, i had hide parts turned on..did anyone just part?
 20 2015-10-04T02:54:17  <BlueMatt> oh, nvm, it only works at the beginning of a file that is not longer than 128 chars
 21 2015-10-04T02:54:47  <gmaxwell> the eicar thing triggers almost nothing.
 22 2015-10-04T02:54:51  <gmaxwell> because, that.
 23 2015-10-04T02:55:04  <BlueMatt> gmaxwell: oh? If you put it in by itself I've seen it trigger almost everything
 24 2015-10-04T02:55:14  <BlueMatt> you just cant put it in the middle of a file
 25 2015-10-04T02:56:57  <CodeShark> we should store all blocks using symmetric crypto with the block hash as the key :p
 26 2015-10-04T02:59:09  <Luke-Jr> CodeShark: you're aware we have an open PR to obfuscate the chainstate, right? ;)
 27 2015-10-04T02:59:09  <sipa> CodeShark: being done for the utxo set now
 28 2015-10-04T02:59:19  <CodeShark> oh?
 29 2015-10-04T02:59:36  <CodeShark> since when?
 30 2015-10-04T02:59:37  <sipa> just xor, not symmetric crypto
 31 2015-10-04T02:59:38  <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/6650
 32 2015-10-04T02:59:55  <Luke-Jr> sipa: eh? xor doesn't count as symm crypto? :P
 33 2015-10-04T03:00:07  <CodeShark> someone stole my idea! :p
 34 2015-10-04T03:01:04  <sipa> Luke-Jr: it's symmetric, but not cryptographic :)
 35 2015-10-04T03:01:05  <Luke-Jr> CodeShark: I've been recommending it to newbies for a while
 36 2015-10-04T03:01:15  <Luke-Jr> sipa: but.. but..
 37 2015-10-04T03:01:28  <CodeShark> it's ultimately a matter of degree
 38 2015-10-04T03:01:38  <CodeShark> an xor one-time pad is more secure than any asymmetric cypher
 39 2015-10-04T03:02:05  <CodeShark> *cipher
 40 2015-10-04T03:02:11  <sipa> well, if XOR is symmetric cryptography, then { return 4; } is a CSPRNG :)
 41 2015-10-04T03:02:16  <CodeShark> damn, I of all people should know how to spell that word :p
 42 2015-10-04T03:03:05  <gmaxwell> importantly it's an xor with a per node random key.. which should be more than enough.
 43 2015-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 ;)
 44 2015-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.
 45 2015-10-04T03:03:44  <CodeShark> or even more secure
 46 2015-10-04T03:04:13  <CodeShark> and as long as you only use it once
 47 2015-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
 48 2015-10-04T03:09:17  <CodeShark> however, 4 is a rather improbable number given cryptograpically-sized output
 49 2015-10-04T03:10:00  <CodeShark> it's no less probable than any other...but it still looks suspiciously small :)
 50 2015-10-04T03:10:51  <CodeShark> moreover, in both cases you need external entrop
 51 2015-10-04T03:10:52  <CodeShark> *entropy
 52 2015-10-04T03:11:14  <sipa> yes yes yes
 53 2015-10-04T03:11:16  <sipa> :)
 54 2015-10-04T03:18:20  *** belcher_ has quit IRC
 55 2015-10-04T03:19:07  *** neha has quit IRC
 56 2015-10-04T03:19:30  *** morcos has quit IRC
 57 2015-10-04T03:19:38  *** neha has joined #bitcoin-core-dev
 58 2015-10-04T03:20:10  *** zxzzt_ has quit IRC
 59 2015-10-04T03:20:32  *** morcos has joined #bitcoin-core-dev
 60 2015-10-04T03:21:00  *** zxzzt has joined #bitcoin-core-dev
 61 2015-10-04T03:32:33  <CodeShark> a virus signature that involves xor relationships 8 bytes apart would likely give many false alarms :p
 62 2015-10-04T03:33:32  <CodeShark> just dividing two large numbers could trip it off :p
 63 2015-10-04T04:20:20  <Luke-Jr> CodeShark: has that ever stopped them?
 64 2015-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
 65 2015-10-04T04:44:25  *** lightningbot has joined #bitcoin-core-dev
 66 2015-10-04T05:03:41  <phantomcircuit> gmaxwell, the current version of the fuzzer logic only modifies the script portion
 67 2015-10-04T05:03:50  <phantomcircuit> it's significantly slower when the entire transaction can be modified
 68 2015-10-04T05:04:04  <phantomcircuit> i seem to have stopped finding interesting cases with 256 byte scripts though
 69 2015-10-04T05:08:15  <CodeShark> did you do an ordered search? or bruteforce?
 70 2015-10-04T05:09:41  <CodeShark> wasn't it 256-byte transactions that were of interest?
 71 2015-10-04T05:13:23  <phantomcircuit> CodeShark, afl-fuzz
 72 2015-10-04T05:13:28  <phantomcircuit> see https://github.com/pstratem/bitcoinconsensus_fuzzer
 73 2015-10-04T05:15:09  <phantomcircuit> CodeShark, definitely cant brute force all the 256 byte combinations :)
 74 2015-10-04T05:16:11  <CodeShark> is the goal simply to find valid transactions that are exactly 256 bytes long?
 75 2015-10-04T05:16:32  <BlueMatt> phantomcircuit: do you need a faster box to run that on?
 76 2015-10-04T05:18:02  <CodeShark> or nvm, I don't really know what you're trying to do :p
 77 2015-10-04T05:18:54  <phantomcircuit> CodeShark, no the goal is to find interesting transactions
 78 2015-10-04T05:18:58  <phantomcircuit> valid or otherwise
 79 2015-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
 80 2015-10-04T05:19:32  <phantomcircuit> damn it i screwed up the afl-fuzz setup!
 81 2015-10-04T05:19:35  * phantomcircuit grubles
 82 2015-10-04T05:19:50  <CodeShark> by "valid" I'm just talking in terms of parser logic - not the chainstate and crypto validation stuff :p
 83 2015-10-04T05:19:57  <BlueMatt> phantomcircuit: if you send me the vm image I can run it on my workstation.....
 84 2015-10-04T05:19:58  <phantomcircuit> hmm actually maybe not
 85 2015-10-04T05:20:20  <phantomcircuit> looks like i didn't screw it up
 86 2015-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
 87 2015-10-04T05:38:45  <phantomcircuit> gmaxwell, there seems to be an issue with the frequency of wallet flushes and the pruning logic
 88 2015-10-04T05:39:02  <phantomcircuit> the pruning logic can prune blocks where the wallet hasn't flushed indicating it's sync'd to them
 89 2015-10-04T05:39:15  <phantomcircuit> BlueMatt, you should fix! :P
 90 2015-10-04T05:39:50  <BlueMatt> huh?
 91 2015-10-04T05:40:00  <gmaxwell> hahah
 92 2015-10-04T05:40:21  <gmaxwell> phantomcircuit: yea that sounds bad. :P
 93 2015-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
 94 2015-10-04T05:43:34  <CodeShark> it would really be nice to put all the header logic into its own unit
 95 2015-10-04T05:45:16  <CodeShark> separate issue...but just thought I'd bring it up :p
 96 2015-10-04T05:46:07  <CodeShark> then other parts of the app can sync to the headers in different ways
 97 2015-10-04T05:46:38  <CodeShark> and the header index can carry additional state information
 98 2015-10-04T05:49:06  <CodeShark> (i.e. what rules to enforce for the particular block :) )
 99 2015-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
100 2015-10-04T05:54:33  <CodeShark> not that 80 bytes is that much when put into context of downloading the entire block :p
101 2015-10-04T05:54:42  <CodeShark> but we could have more sophisticated queries for partial blocks
102 2015-10-04T05:56:00  <CodeShark> I'm very much not satisfied with the filteredblock mechanism we currently have ;)
103 2015-10-04T05:57:27  <CodeShark> even pruned nodes could serve useful data if the query structure were better
104 2015-10-04T05:58:58  <CodeShark> in retrospect, perhaps Satoshi should have tried to implement SPV first :p
105 2015-10-04T06:00:35  <gmaxwell> he did.
106 2015-10-04T06:00:49  <gmaxwell> there was a begin a it in bitcoin core that was long since stripped out
107 2015-10-04T06:01:03  <CodeShark> begin a it?
108 2015-10-04T06:01:10  <gmaxwell> at
109 2015-10-04T06:01:38  <CodeShark> I'm saying perhaps the header sync should have been the first consensus code written
110 2015-10-04T06:01:44  <gmaxwell> today it will be much easier to do, but long ago the architecture was probably a bit too alien.
111 2015-10-04T06:02:54  <gmaxwell> CodeShark: you have some hindsight benefit of how we think about the architecture of the system in modern times. :)
112 2015-10-04T06:03:10  <CodeShark> yes, I said "in retrospect"
113 2015-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
114 2015-10-04T06:05:25  <CodeShark> then we can build whatever kind of node on top of that
115 2015-10-04T06:05:33  <CodeShark> whether it be full validation, pruned or not, SPV, etc...
116 2015-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
117 2015-10-04T06:07:39  <CodeShark> there's a whole spectrum here
118 2015-10-04T06:07:48  <CodeShark> from "check absolutely everything" to "check nothing"
119 2015-10-04T06:09:18  <gmaxwell> the structure of bitcoin core today is much more agreeable to that than it was in the past.
120 2015-10-04T06:09:34  <CodeShark> yes, sipa did a good job with the headers-first sync
121 2015-10-04T06:09:53  <CodeShark> so it's going in the right direction
122 2015-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
123 2015-10-04T06:12:06  <CodeShark> ContextualCheckBlockHeader gets called twice
124 2015-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
125 2015-10-04T06:29:34  *** ParadoxSpiral has joined #bitcoin-core-dev
126 2015-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();
127 2015-10-04T06:33:19  <CodeShark> or headerIndex(block_hash).getRules();
128 2015-10-04T06:33:22  <CodeShark> or whatever
129 2015-10-04T06:33:26  <CodeShark> something pretty like that :)
130 2015-10-04T06:35:43  <CodeShark> then the rest of the block checking stuff can have conditionals like if(rules.contains(BIP66)) { }
131 2015-10-04T06:36:44  <CodeShark> and from that point on we can easily isolate ANY changes to consensus checks and test them independently
132 2015-10-04T06:38:05  <CodeShark> even alt coins could be built that can contribute useful ideas back to Bitcoin ;)
133 2015-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
134 2015-10-04T08:18:13  *** randy-waterhouse has joined #bitcoin-core-dev
135 2015-10-04T08:37:29  *** n0n0_ has joined #bitcoin-core-dev
136 2015-10-04T09:12:15  *** BashCo_ has quit IRC
137 2015-10-04T09:28:13  *** adam3us has quit IRC
138 2015-10-04T09:31:53  *** adam3us has joined #bitcoin-core-dev
139 2015-10-04T09:51:53  *** NLNico has joined #bitcoin-core-dev
140 2015-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
141 2015-10-04T11:10:16  <sipa> phantomcircuit: but for the wallet... i guess that's possible
142 2015-10-04T11:32:24  *** randy-waterhouse has quit IRC
143 2015-10-04T11:43:13  *** belcher_ has joined #bitcoin-core-dev
144 2015-10-04T11:58:32  *** paveljanik has joined #bitcoin-core-dev
145 2015-10-04T11:58:32  *** paveljanik has joined #bitcoin-core-dev
146 2015-10-04T12:22:03  *** dcousens has joined #bitcoin-core-dev
147 2015-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
148 2015-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
149 2015-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 :)
150 2015-10-04T12:27:26  *** randy-waterhouse has joined #bitcoin-core-dev
151 2015-10-04T12:28:13  <CodeShark> we should have a standalone module that can do a headers sync and provide query and subscription services
152 2015-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
153 2015-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
154 2015-10-04T12:35:50  <CodeShark> all the protocol rule changes (including versionbits) can naturally be fit into this
155 2015-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
156 2015-10-04T12:43:39  <sipa> CodeShark: synchronization is very different from consensus :)
157 2015-10-04T12:43:40  <CodeShark> this obviously needs to be done in coordination with all our other refactoring efforts
158 2015-10-04T12:43:47  <CodeShark> sipa, I should clarify...
159 2015-10-04T12:43:59  <CodeShark> I meant block header consensus - this example I'm sharing has no networking code
160 2015-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
161 2015-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
162 2015-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
163 2015-10-04T12:46:50  <sipa> CodeShark: i've suggested something similar, by moving full validation to a separate module with its own state
164 2015-10-04T12:47:05  <randy-waterhouse> a hybrid node
165 2015-10-04T12:47:12  <sipa> which uses the main signals to trigger full validation
166 2015-10-04T12:47:20  <CodeShark> yeah, I think it's the way to go
167 2015-10-04T12:49:37  <sipa> i think my point is that that interface already exists
168 2015-10-04T12:49:45  <sipa> and we should reuse it
169 2015-10-04T12:49:51  <CodeShark> can I see it?
170 2015-10-04T12:49:56  <sipa> but rather than extract header validation from it
171 2015-10-04T12:50:04  <sipa> move full validation out of it
172 2015-10-04T12:50:26  <sipa> eh, look at main.h, there is a signals interface
173 2015-10-04T12:52:17  <sipa> though i'd start with the wallet
174 2015-10-04T12:52:47  <sipa> allow it to have its own "active block", which can be different from that of main
175 2015-10-04T12:53:16  <sipa> ot only subscribes to updatetip events, and then requests the block data asynchronously to sync
176 2015-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
177 2015-10-04T12:54:36  <sipa> CodeShark: also, i disagree with moving more logic into basic data structure classes
178 2015-10-04T12:55:02  <sipa> we've been moving the opposite direction mostly, because it really interferes with modularization
179 2015-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 ;)
180 2015-10-04T12:55:44  <sipa> bleh, even uglier
181 2015-10-04T12:55:50  <CodeShark> or delegation
182 2015-10-04T12:55:55  <CodeShark> why uglier?
183 2015-10-04T12:56:14  <sipa> let me give an example to elaborate, so we're talking about the same thing
184 2015-10-04T12:56:36  <sipa> imagine ctransaction had a sign function
185 2015-10-04T12:56:48  <sipa> sounds awesome, very useful and elegant
186 2015-10-04T12:56:49  <CodeShark> oh, that's not what I'm saying at all!!!
187 2015-10-04T12:56:54  <CodeShark> I actually think that's hideous
188 2015-10-04T12:57:16  <sipa> you were saying the block should have a function to ask what bips apply to it
189 2015-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
190 2015-10-04T12:57:25  <sipa> i think that's very similar
191 2015-10-04T12:57:30  <sipa> ok, we agree there
192 2015-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
193 2015-10-04T13:00:07  <CodeShark> and in fact, it makes sense to NOT build this logic into the core header consensus stuff
194 2015-10-04T13:00:16  <CodeShark> at least not directly
195 2015-10-04T13:00:35  <sipa> good :)
196 2015-10-04T13:01:45  <CodeShark> I'd even leave room for flexibility on PoW and timestamp verification :)
197 2015-10-04T13:03:29  <CodeShark> and if we want to go further, we can even make the header structure itself abstract
198 2015-10-04T13:03:49  <CodeShark> the key structural element at this level is the notion of a block header tree
199 2015-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
200 2015-10-04T13:06:11  <CodeShark> this stuff can be provided by a number of different mechanisms
201 2015-10-04T13:07:42  <sipa> it makes more sense to do a writeup together with some minimal idea for code changes then talk here
202 2015-10-04T13:08:07  <sipa> irc is good for discussion, but not really for monologue
203 2015-10-04T13:08:22  <CodeShark> yeah :)
204 2015-10-04T13:09:28  <CodeShark> so google docs?
205 2015-10-04T13:10:51  <sipa> or issue
206 2015-10-04T13:10:54  <sipa> or a branch
207 2015-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
208 2015-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
209 2015-10-04T13:13:49  <CodeShark> yes, absolutely agreed - the high-level plan should be much more about diagrams and ideas than about code
210 2015-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
211 2015-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
212 2015-10-04T13:19:57  <CodeShark> but we should have a basic plan
213 2015-10-04T13:21:00  *** sipa has left #bitcoin-core-dev
214 2015-10-04T13:21:19  <CodeShark> ?
215 2015-10-04T14:30:15  *** NLNico has quit IRC
216 2015-10-04T15:51:02  *** CodeShark has quit IRC
217 2015-10-04T15:51:17  *** CodeShark_ is now known as CodeShark
218 2015-10-04T16:10:15  *** n0n0__ has joined #bitcoin-core-dev
219 2015-10-04T16:13:40  *** n0n0_ has quit IRC
220 2015-10-04T17:05:29  *** pigeons has quit IRC
221 2015-10-04T17:12:50  *** BashCo has joined #bitcoin-core-dev
222 2015-10-04T17:27:35  *** BashCo has quit IRC
223 2015-10-04T17:35:04  *** pigeons has joined #bitcoin-core-dev
224 2015-10-04T17:35:27  *** pigeons is now known as Guest22695
225 2015-10-04T18:07:26  *** randy-waterhouse has quit IRC
226 2015-10-04T18:32:40  *** ParadoxSpiral_ has joined #bitcoin-core-dev
227 2015-10-04T18:35:55  *** ParadoxSpiral has quit IRC
228 2015-10-04T18:52:40  *** randy-waterhouse has joined #bitcoin-core-dev
229 2015-10-04T19:07:16  *** jl2012 has joined #bitcoin-core-dev
230 2015-10-04T19:09:23  <GitHub106> [bitcoin] jgarzik pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/3ab3de8ba1a63d5ec0f97ae12e660d9730c60156
231 2015-10-04T19:09:23  <GitHub106> bitcoin/master 3ab3de8 Jeff Garzik: qa/pull-tester/rpc-tests.py: chmod 0755...
232 2015-10-04T19:24:48  *** jl2012 has quit IRC
233 2015-10-04T19:25:07  *** jl2012 has joined #bitcoin-core-dev
234 2015-10-04T19:25:35  *** gribble has quit IRC
235 2015-10-04T19:26:17  *** Anduck_ has joined #bitcoin-core-dev
236 2015-10-04T19:26:50  *** GAit_Alt has joined #bitcoin-core-dev
237 2015-10-04T19:27:48  *** stonecoldpat1 has joined #bitcoin-core-dev
238 2015-10-04T19:28:19  *** Guest1235 has joined #bitcoin-core-dev
239 2015-10-04T19:29:02  *** aj_ has joined #bitcoin-core-dev
240 2015-10-04T19:29:02  *** grubles_ has joined #bitcoin-core-dev
241 2015-10-04T19:29:26  *** grubles_ is now known as Guest78185
242 2015-10-04T19:30:29  *** baldur_ has joined #bitcoin-core-dev
243 2015-10-04T19:30:41  *** GAit has quit IRC
244 2015-10-04T19:30:42  *** challisto has quit IRC
245 2015-10-04T19:30:43  *** evoskuil has quit IRC
246 2015-10-04T19:30:43  *** baldur has quit IRC
247 2015-10-04T19:30:43  *** isis has quit IRC
248 2015-10-04T19:30:43  *** grubles has quit IRC
249 2015-10-04T19:30:43  *** evoskuil has joined #bitcoin-core-dev
250 2015-10-04T19:30:43  *** GAit_Alt is now known as GAit
251 2015-10-04T19:30:53  *** challisto has joined #bitcoin-core-dev
252 2015-10-04T19:30:53  *** challisto has joined #bitcoin-core-dev
253 2015-10-04T19:31:12  *** GAit is now known as Guest11115
254 2015-10-04T19:32:22  *** Anduck has quit IRC
255 2015-10-04T19:32:23  *** aj has quit IRC
256 2015-10-04T19:32:24  *** stonecoldpat has quit IRC
257 2015-10-04T19:32:25  *** Guest1234 has quit IRC
258 2015-10-04T19:34:23  *** isis has joined #bitcoin-core-dev
259 2015-10-04T19:35:52  *** gribble has joined #bitcoin-core-dev
260 2015-10-04T19:39:35  *** Guest78185 is now known as grubles
261 2015-10-04T19:39:42  *** grubles has quit IRC
262 2015-10-04T19:39:42  *** grubles has joined #bitcoin-core-dev
263 2015-10-04T19:44:56  *** grubles has quit IRC
264 2015-10-04T20:15:12  *** gribble has quit IRC
265 2015-10-04T20:16:02  *** adam3us1 has joined #bitcoin-core-dev
266 2015-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).
267 2015-10-04T20:18:42  *** adam3us has quit IRC
268 2015-10-04T20:30:03  *** gribble has joined #bitcoin-core-dev
269 2015-10-04T20:36:38  <btcdrak> are there any miners on 0.8?
270 2015-10-04T20:36:56  <gmaxwell> who knows?
271 2015-10-04T20:40:11  *** Anduck_ is now known as Anduck
272 2015-10-04T20:50:20  *** ParadoxSpiral_ has quit IRC
273 2015-10-04T21:03:39  *** randy-waterhouse has quit IRC
274 2015-10-04T21:39:48  *** n0n0__ has quit IRC
275 2015-10-04T22:27:24  *** dcousens has quit IRC
276 2015-10-04T22:35:51  *** fkhan has quit IRC
277 2015-10-04T22:54:39  *** fkhan has joined #bitcoin-core-dev
278 2015-10-04T23:29:19  <maaku> one would hope not, but one should not operate based on hope
279 2015-10-04T23:29:26  *** CodeShark has quit IRC
280 2015-10-04T23:56:03  *** CodeShark has joined #bitcoin-core-dev
281 2015-10-04T23:59:25  <Luke-Jr> I think we moved the last 0.8 miners off it during the BIP66/OpenSSL fiasco
282 2015-10-04T23:59:41  <Luke-Jr> although we never quite figured out why their 0.8 was mining the problematic txns