1 2015-12-08 00:51:54 <mrkent> Is there a standard for ordering the addresses for a P2SH?
  2 2015-12-08 01:16:17 <Luke-Jr> mrkent: that doesn't make sense. P2SH is a type of an address.
  3 2015-12-08 01:16:18 <Luke-Jr> mrkent: that doesn't make sense. P2SH is a type of an address.
  4 2015-12-08 01:18:44 <mrkent> Luke-Jr: the creation of that address requires multiple regular address i mean
  5 2015-12-08 01:18:54 <mrkent> is there a standard of ordering them
  6 2015-12-08 01:19:46 <phantomcircuit> mrkent, you're actually asking whether there is a standard for ordering pubkey hashes in OP_CHECKMULTISIG
  7 2015-12-08 01:19:51 <phantomcircuit> i believe the answer is no btw
  8 2015-12-08 01:20:02 <phantomcircuit> (could totally be wrong though)
  9 2015-12-08 01:20:46 <mrkent> @phantomcircuit: yes that's the question :)
 10 2015-12-08 01:23:13 <mrkent> @phantomcircuit: yes that's the question :)
 11 2015-12-08 01:24:54 <tulip> mrkent: not that I've noticed.
 12 2015-12-08 02:09:55 <GAit> FYI cfields created #bitcoin-hk-dev for those participating to the hackaton today and tomorrow
 13 2015-12-08 02:15:02 <phantomcircuit> cfields, why not just take over -dev or -core-dev ?
 14 2015-12-08 02:15:03 <phantomcircuit> cfields, why not just take over -dev or -core-dev ?
 15 2015-12-08 02:15:10 <phantomcircuit> i somehow doubt anybody will mind
 16 2015-12-08 02:15:13 <phantomcircuit> i somehow doubt anybody will mind
 17 2015-12-08 02:15:44 <cfields> phantomcircuit: i figured we may end up with a good bit of local discussion that wouldn't make sense without context
 18 2015-12-08 02:18:41 <phantomcircuit> cfields, ok
 19 2015-12-08 02:18:42 <phantomcircuit> cfields, ok
 20 2015-12-08 02:24:09 <jtoomim> cfields hi
 21 2015-12-08 02:24:10 <jtoomim> cfields hi
 22 2015-12-08 02:28:21 <jouke> jtoomim: I meant to ask yesterday, but what service provider did you use for the VPSses in China?
 23 2015-12-08 02:28:22 <jouke> jtoomim: I meant to ask yesterday, but what service provider did you use for the VPSses in China?
 24 2015-12-08 02:32:49 <jtoomim> aliyun
 25 2015-12-08 02:32:51 <jtoomim> they're cheap
 26 2015-12-08 02:32:58 <jtoomim> they seem to have good bandwidth within china
 27 2015-12-08 02:33:04 <jtoomim> but their hong kong server seemed a bit off
 28 2015-12-08 02:33:18 <jtoomim> not as cheap as non-chinese VPSs, but still fairly cheap
 29 2015-12-08 02:33:19 <jtoomim> jouke
 30 2015-12-08 02:33:42 <jtoomim> i was paying $25/mo for a 2-core 2GB VPS with 100 Mbps peak plus a per-GB fee
 31 2015-12-08 02:33:52 <jtoomim> except in HK, which is inexplicably more expensive for the same thing ($30)
 32 2015-12-08 02:34:25 <jtoomim> their web interface mostly has english, but there are a few sections that haven't been translated
 33 2015-12-08 02:34:48 <jtoomim> and you don't need any special hoops to get the servers, unlike many other cloud providers
 34 2015-12-08 02:35:03 <jtoomim> the "yun" in aliyun means cloud, by the way
 35 2015-12-08 02:35:21 <jtoomim> so it's alibaba/alipay/aligroup's cloud offering
 36 2015-12-08 02:35:48 <jtoomim> it's intended to be basically a clone of amazon ec2
 37 2015-12-08 02:36:19 <jtoomim> i didn't compare aliyun to other providers to see if they're the best
 38 2015-12-08 02:36:45 <jtoomim> i merely followed thbluematt's and wangchun's recommendation
 39 2015-12-08 02:43:07 <jouke> jtoomim: thanks!
 40 2015-12-08 02:59:53 <kanzure> jcorgan: not sure whether to approve the keyrun email......
 41 2015-12-08 03:00:37 <kanzure> it's more OP_RETURN data stuff. and an advertisement sorta.
 42 2015-12-08 03:01:03 <kanzure> jcorgan: i think we should reject it, and then let others argue for its inclusion, then we can let it go through if the author resubmits.
 43 2015-12-08 03:19:33 <phantomcircuit> jtoomim, in the interest of being useful aliyun in Beijing is the best for reasons i wont get into
 44 2015-12-08 03:19:34 <phantomcircuit> jtoomim, in the interest of being useful aliyun in Beijing is the best for reasons i wont get into
 45 2015-12-08 03:19:42 <jcorgan> lemme look
 46 2015-12-08 03:22:11 <jcorgan> yeah, i agree
 47 2015-12-08 03:27:02 <phantomcircuit> jtoomim, i like how they call you from an international number
 48 2015-12-08 03:29:16 <jtoomim> jouke phantomcircuit one source of more information on cloud hosting providers in china is http://www.chinanetcloud.com/sites/default/files/Clouds%20in%20China_en.pdf
 49 2015-12-08 03:29:47 <phantomcircuit> jtoomim, i have super special info that says aliyun in beijing is the best
 50 2015-12-08 03:29:48 <phantomcircuit> jtoomim, i have super special info that says aliyun in beijing is the best
 51 2015-12-08 03:29:57 <jtoomim> ack
 52 2015-12-08 03:30:32 <jtoomim> zone a or zone b, do you know?
 53 2015-12-08 03:30:34 <phantomcircuit> also their damned billing site uses super outdated crypto which firefox refuses to allow
 54 2015-12-08 03:30:40 <phantomcircuit> jtoomim, that i dont know
 55 2015-12-08 03:30:47 <jtoomim> i'm in zone a
 56 2015-12-08 03:30:51 <Luke-Jr> jtoomim: FYI, that thing you went up during WIP to suggest to reduce stale blocks..
 57 2015-12-08 03:30:55 <jtoomim> but i don't really care that much because i'm just on testnet
 58 2015-12-08 03:31:00 <phantomcircuit> probably doesn't matter im sure they're connected via low latency fiber links
 59 2015-12-08 03:31:05 <Luke-Jr> jtoomim: both BFGMiner and cgminer have been doing it for *years*
 60 2015-12-08 03:31:17 <phantomcircuit> Luke-Jr, which thing?
 61 2015-12-08 03:31:33 <Luke-Jr> phantomcircuit: switching to whatever pool notifies of a new block earliest, until your main pool(s) catch up
 62 2015-12-08 03:31:34 <Luke-Jr> phantomcircuit: switching to whatever pool notifies of a new block earliest, until your main pool(s) catch up
 63 2015-12-08 03:31:44 <phantomcircuit> oh
 64 2015-12-08 03:31:46 <jtoomim> luke-jr really? i haven't seen that actually happen on any of my miners. does that require load balancing *miner.conf files?
 65 2015-12-08 03:31:50 <phantomcircuit> yeah there's a risk to doing that
 66 2015-12-08 03:31:59 <Luke-Jr> jtoomim: no, just multiple pools and not --failover-only
 67 2015-12-08 03:32:20 <phantomcircuit> the risk being some third tier pool you configured as a failover goes stupid and you stop mining valid blocks
 68 2015-12-08 03:32:51 <jtoomim> perhaps a time limit on mining on the non-main pool could help with that?
 69 2015-12-08 03:32:56 <phantomcircuit> this is where someone starts yelling about market dynamics and people removing it from their configs
 70 2015-12-08 03:32:58 <Luke-Jr> phantomcircuit: yes, probably there should be a timeout when you have a trusted local node to check against
 71 2015-12-08 03:33:01 <jtoomim> as well as a block height difference maximum?
 72 2015-12-08 03:33:18 <jtoomim> i.e. only if they're at most 2 blocks ahead?
 73 2015-12-08 03:33:27 <phantomcircuit> Luke-Jr, i was under the impression that cgminer would refuse to go backwards but that doesn't appear to be the case (at least not in master)
 74 2015-12-08 03:33:28 <phantomcircuit> Luke-Jr, i was under the impression that cgminer would refuse to go backwards but that doesn't appear to be the case (at least not in master)
 75 2015-12-08 03:33:48 <Luke-Jr> phantomcircuit: no?
 76 2015-12-08 03:33:49 <phantomcircuit> i could also be seeing a bug in the logic around the work id not changing
 77 2015-12-08 03:33:53 <phantomcircuit> not sure yet
 78 2015-12-08 03:34:12 <jtoomim> well, cool, i'm glad you guys are looking into this, because i don't have the time to follow up on it
 79 2015-12-08 03:34:19 <phantomcircuit> Luke-Jr, there's a function that returns false if you go backwards and prints a stale work warning, but nothing uses the return value of the function
 80 2015-12-08 03:35:19 <Luke-Jr> phantomcircuit: lol!
 81 2015-12-08 03:35:47 <Lightsword> phantomcircuit, I think the changeover would be in the else part of the statement right?
 82 2015-12-08 03:36:03 <Lightsword> https://github.com/ckolivas/cgminer/blob/master/cgminer.c#L4740
 83 2015-12-08 03:39:50 <phantomcircuit> Lightsword, what im talking about is if the pool goes from block height 1 to 2 and back to 1
 84 2015-12-08 03:39:58 <phantomcircuit> i've been told this results in cgminer refusing to work on 1
 85 2015-12-08 03:40:23 <Lightsword> I think that’s right since it thinks it is stale data
 86 2015-12-08 03:40:46 <phantomcircuit> yes which is the check right before the line you linked to (the if part of the if/else)
 87 2015-12-08 03:41:00 <phantomcircuit> notice it sets ret = false
 88 2015-12-08 03:41:19 <phantomcircuit> but nothing checks the result of test_work_current
 89 2015-12-08 03:41:20 <phantomcircuit> but nothing checks the result of test_work_current
 90 2015-12-08 03:42:20 <Lightsword> yeah, I noticed that…it seems it doesn’t trigger a change to the previous blockhash in that case
 91 2015-12-08 03:42:39 <Lightsword> basically does nothing from the looks of it
 92 2015-12-08 03:43:27 <phantomcircuit> i tested this but with something where the workid didn't change
 93 2015-12-08 03:43:38 <phantomcircuit> but after looking at the code it seems it doesn't do that
 94 2015-12-08 03:43:46 <phantomcircuit> and just mines on whatever the pool tells it to
 95 2015-12-08 03:44:56 <Lightsword> so it would start mining on the older blockhash?
 96 2015-12-08 03:44:57 <Lightsword> so it would start mining on the older blockhash?
 97 2015-12-08 03:45:02 <Lightsword> what does the workid have to do with it?
 98 2015-12-08 03:45:03 <Lightsword> what does the workid have to do with it?
 99 2015-12-08 03:56:24 <phantomcircuit> Lightsword, it's not clear to me what it should be doing actually
100 2015-12-08 03:56:57 <phantomcircuit> probably what it's doing now (but not what people seem to think it's doing) is the best behavior
101 2015-12-08 03:57:14 <phantomcircuit> if you configure a pool even as a failover which you do not trust then you have made a mistake
102 2015-12-08 03:57:18 <Lightsword> phantomcircuit, from what I can tell it does nothing if it’s an old blockhash
103 2015-12-08 03:57:31 <phantomcircuit> but that has a bunch of really nasty consequences
104 2015-12-08 03:58:21 <Lightsword> not sure why one would configure a failover they do not trust though
105 2015-12-08 03:59:37 <phantomcircuit> Lightsword, "better than doing nothing"
106 2015-12-08 03:59:38 <phantomcircuit> Lightsword, "better than doing nothing"
107 2015-12-08 03:59:44 <phantomcircuit> trust isn't black and white
108 2015-12-08 04:00:00 <phantomcircuit> is a pool with a 25% default risk better than not mining at all? maybe
109 2015-12-08 04:01:00 <phantomcircuit> jtoomim, lol wat the aliyun console isn't over https
110 2015-12-08 04:01:02 <phantomcircuit> that's crazy
111 2015-12-08 04:01:35 <Lightsword> I think it’s mainly an issue if one pool is only issueing stale work
112 2015-12-08 04:01:36 <Lightsword> I think it’s mainly an issue if one pool is only issueing stale work
113 2015-12-08 04:02:06 <Lightsword> but if bitcoind was completely dead it would get replaced by the next update from a working pool
114 2015-12-08 04:02:30 <Lightsword> the only case I could see it being an issue was if bitcoind was say always 10 blocks out of date
115 2015-12-08 04:02:34 <phantomcircuit> Lightsword, i suspect that the optimal behavior is to have a preferred pool and then to switch to whichever pool gives you the highest work chain to build on but only for 1-2 seconds at a time
116 2015-12-08 04:03:26 <phantomcircuit> and yeah then if the preferred pool is super out of date you're screwed but at least one of the smaller ones cant trick you into wasting a bunch of hashing power
117 2015-12-08 04:03:32 <phantomcircuit> er
118 2015-12-08 04:03:36 <phantomcircuit> less preferred
119 2015-12-08 04:03:38 <phantomcircuit> not smaller
120 2015-12-08 04:03:41 <phantomcircuit> brainfart
121 2015-12-08 04:03:50 <Lightsword> I mean, there is the —failover-only option for that right?
122 2015-12-08 04:04:14 <phantomcircuit> Lightsword, yes but then you dont potentially benefit from a less trusted but faster pool
123 2015-12-08 04:05:31 <Lightsword> yeah, it’s complex…maybe need a stratum command for the pool to invalidate a blockhash
124 2015-12-08 04:05:32 <Lightsword> yeah, it’s complex…maybe need a stratum command for the pool to invalidate a blockhash
125 2015-12-08 04:06:38 <phantomcircuit> Lightsword, except stratum clients dont have enough of the block header to know which fork they're mining on
126 2015-12-08 04:06:44 <phantomcircuit> wait yes they do
127 2015-12-08 04:06:46 <phantomcircuit> derp ignore
128 2015-12-08 04:07:02 <Lightsword> I think it just tracks the previous headers
129 2015-12-08 04:07:04 <phantomcircuit> Lightsword, yeah that's a more flexible approach than using a timer
130 2015-12-08 04:07:31 <phantomcircuit> except then if you have a rogue pool that's telling you to work on total nonsense
131 2015-12-08 04:07:35 <phantomcircuit> you're screwed
132 2015-12-08 04:07:48 <phantomcircuit> since the higher priority pool will never get the block and thus wont invalidate it
133 2015-12-08 04:07:52 <Lightsword> I think the problem is it’s mixing in a global newest with individual pool chains
134 2015-12-08 04:08:36 <Lightsword> that’s true but I don’t think a rogue pool situation was ever something it was designed to handle
135 2015-12-08 04:10:08 <Lightsword> “A: No, cgminer keeps a database of the block it's working on to ensure it does
136 2015-12-08 04:10:09 <Lightsword> “A: No, cgminer keeps a database of the block it's working on to ensure it does
137 2015-12-08 04:10:09 <Lightsword> not work on stale blocks, and having different blocks from two networks would
138 2015-12-08 04:10:10 <Lightsword> make it invalidate the work from each other.”
139 2015-12-08 04:10:57 <Lightsword> yeah, so if the block on the bad pool is not in the database it will just keep flipping back and forth I guess
140 2015-12-08 04:11:54 <Lightsword> hmm, maybe the best way to handle it would be to use priority in that case and not switch to the outdated pool
141 2015-12-08 04:12:17 <Lightsword> but then failover wouldn’t work if the primary froze
142 2015-12-08 04:12:47 <Lightsword> phantomcircuit, is there a way to get the blockheight over stratum?
143 2015-12-08 04:15:34 <phantomcircuit> Lightsword, it's in the coinbase
144 2015-12-08 04:15:42 <phantomcircuit> (dirty dirty hack i know)
145 2015-12-08 04:17:22 <Lightsword> phantomcircuit, that would be good to use to ensure it doesn’t start mining on some ancient chain
146 2015-12-08 04:24:48 <Lightsword> oh, ck says that readme is inaccurate and only applies to getwork(which was removed)
147 2015-12-08 04:49:02 <btcdrak> mrkent: there is a BIP that encourages ordering yes.
148 2015-12-08 07:38:08 <Lightsword> phantomcircuit, well I added blockheight to cgminer https://github.com/ckolivas/cgminer/pull/686/files
149 2015-12-08 08:34:43 <jtimon> devrandom: #7091, also #6625 is not really necessary for libconsensus but it will help to avoid later blocksize-related patches (say, common preparations for bip102, etc) to get in the way of consensus encapsulation
150 2015-12-08 08:47:50 <Lightsword> oh, BIP65 is now enforcing
151 2015-12-08 08:48:03 <Lightsword> "found" : 753,
152 2015-12-08 08:48:04 <Lightsword> "found" : 753,
153 2015-12-08 08:49:00 <gmaxwell> yea, it's filickering on and off w/ enforcing.
154 2015-12-08 08:49:13 <gmaxwell> antpool is producing a fair number of v3 blocks still.
155 2015-12-08 08:53:38 <Lightsword> gmaxwell, they were planning to switch fully in a few days AFAIK
156 2015-12-08 08:53:39 <Lightsword> gmaxwell, they were planning to switch fully in a few days AFAIK
157 2015-12-08 08:53:48 <Lightsword> they held off so that more small pools could ugprade
158 2015-12-08 08:55:13 <gmaxwell> Lightsword: I'm just as well having it not lock while everyone is in route back from HK.
159 2015-12-08 08:55:25 <gmaxwell> But, ... any idea who else needes to get updated?
160 2015-12-08 08:55:34 <Lightsword> gmaxwell, for antpool?
161 2015-12-08 08:55:45 <Lightsword> or other pools?
162 2015-12-08 08:56:06 <Lightsword> ghash maybe and mybtccoin
163 2015-12-08 08:56:17 <Lightsword> and the pool with this address 19f8Pk3m1GySyowWb8qLy93R5ngAUoVoUE
164 2015-12-08 08:56:18 <Lightsword> and the pool with this address 19f8Pk3m1GySyowWb8qLy93R5ngAUoVoUE
165 2015-12-08 08:56:25 <Lightsword> ghash was producing mixed blocks for a while
166 2015-12-08 13:39:56 <shock143> Hello
167 2015-12-08 14:35:44 <kanzure> jcorgan: welp it looks like someone approved it...
168 2015-12-08 14:35:45 <kanzure> jcorgan: welp it looks like someone approved it...
169 2015-12-08 14:36:17 <kanzure> jl2012: btw, the mailing list interface says that you have been unsubscribed again
170 2015-12-08 14:36:41 <jcorgan> i noticed
171 2015-12-08 14:37:27 <jl2012> kanzure: you mean bitcoin-dev? No wonder I received nothing recently....
172 2015-12-08 14:39:17 <jl2012> I never unsubscribe it
173 2015-12-08 14:40:03 <kanzure> jl2012: i believe it is because of bounces
174 2015-12-08 14:40:04 <kanzure> jl2012: i believe it is because of bounces
175 2015-12-08 14:43:14 <jl2012> so it's problem in my side? I don't know why there's bounces from me but I'll see
176 2015-12-08 14:48:19 <jl2012> how many bounces will trigger unsubscription?
177 2015-12-08 17:10:05 <kanzure> bip112 does not actually explicitly mention "OP_CSV" (the abbreviation)
178 2015-12-08 17:10:06 <kanzure> bip112 does not actually explicitly mention "OP_CSV" (the abbreviation)
179 2015-12-08 17:20:19 <aschildbach> sipa: Hi! About your segregated witness proposal, I'd like to point out that while SPV wallets indeed do not need the signature, they desperately need the values for inputs (mainly for fee estimation). I wonder if we could add the value to the "transaction side", rather than the "witness side".
180 2015-12-08 17:30:59 <jl2012> aschildbach: that will add 8 bytes to all scriptPubKey
181 2015-12-08 17:33:00 <jl2012> or......the value is actually in the tx side in the first place? Value is part of the UTXO set
182 2015-12-08 17:33:32 <jl2012> ignore my comments for adding 8 bytes to scriptPubKey
183 2015-12-08 17:33:33 <Yoghur114> you mean their size?
184 2015-12-08 17:42:12 <aschildbach> jl2012: SPV wallets do not have access to the utxo set.
185 2015-12-08 17:42:36 <aschildbach> jl2012: At least not those that are irrelevant to the wallet.
186 2015-12-08 18:09:40 <Luke-Jr> aschildbach: maybe the witness tree can commit to values too?
187 2015-12-08 18:09:57 <Luke-Jr> and then you only need the proof, not the contents of the witness..
188 2015-12-08 18:11:04 <aschildbach> Luke-Jr: wouldn't that require 3 trees (transaction, witness, input values)?
189 2015-12-08 18:11:43 <Luke-Jr> aschildbach: it can be encoded into the witness tree i think
190 2015-12-08 18:11:57 <aschildbach> Ah you mean into the hashes themselves?
191 2015-12-08 18:12:14 <Luke-Jr> well, the leaves would be hash+value  instead of just the hash; or somethign
192 2015-12-08 18:12:32 <aschildbach> Ok understood.
193 2015-12-08 18:13:36 <Luke-Jr> maybe there's a way to make it extensible in case we want to add more in the future
194 2015-12-08 18:14:39 <aschildbach> Luke-Jr: Hmm, I think it can't work that way.
195 2015-12-08 18:14:40 <aschildbach> Luke-Jr: Hmm, I think it can't work that way.
196 2015-12-08 18:14:48 <aschildbach> First, there can be multiple inputs per txn.
197 2015-12-08 18:15:21 <aschildbach> And second, then the leaves would be bigger (in bytes) than the nodes of the tree.
198 2015-12-08 18:15:24 <Luke-Jr> aschildbach: do you care about per-input values?
199 2015-12-08 18:15:37 <Luke-Jr> the leaves really *should* be bigger than nodes
200 2015-12-08 18:15:51 <Luke-Jr> right now, we have an impractical exploit because that is not true in the transaction tree
201 2015-12-08 18:15:52 <aschildbach> Wouldn't that break the simplicity of merkle trees?
202 2015-12-08 18:17:30 <aschildbach> I admit the sum of the input values is probably enough for the estimate fee usecase. However I'm sure there are tons of other usecases.
203 2015-12-08 18:17:52 <aschildbach> What's that exploit?
204 2015-12-08 18:20:24 <Luke-Jr> aschildbach: I think gmaxwell was going to confirm the impracticality further, before the details were made public. That was weeks ago, but I don't know his conclusion.
205 2015-12-08 18:21:02 <aschildbach> ok
206 2015-12-08 18:22:14 <Luke-Jr> aschildbach: (PM)
207 2015-12-08 19:33:25 <BW^-> any particularly good BIP 38/39, hashing and HD wallet and key derivation library in JS?
208 2015-12-08 19:37:18 <morcos> Would anybody object if we redefined BIP 68 to only use MTP semantics
209 2015-12-08 19:37:29 <morcos> We'd still need MTP to affect LockTimes
210 2015-12-08 19:37:40 <morcos> But if we were planning on rolling out these two softforks together anyway
211 2015-12-08 19:38:06 <morcos> It doesn't seem like it makes sense to write consensus code that can handle BIP 68 without MTP when we never expect that to happen
212 2015-12-08 19:38:21 <morcos> so let's just define BIP 68 as using MTP from the beginning
213 2015-12-08 19:38:51 <morcos> btcdrak ^
214 2015-12-08 19:38:57 <morcos> sipa gmaxwell ^
215 2015-12-08 19:40:48 <btcdrak> morcos: no objection from me.
216 2015-12-08 19:41:28 <btcdrak> morcos: i like your proposed PR.
217 2015-12-08 19:42:34 <btcdrak> kanzure: why would it?
218 2015-12-08 19:43:27 <btcdrak> kanzure: BIP65 doesnt use OP_CLTV abbreviation either...
219 2015-12-08 19:43:28 <btcdrak> kanzure: BIP65 doesnt use OP_CLTV abbreviation either...
220 2015-12-08 19:56:12 <morcos> ehh, maybe it doesn't change as much as i thought it did.
221 2015-12-08 19:58:12 <morcos> maybe still worth doing, depends on which people think is clearer
222 2015-12-08 19:59:10 <kanzure> btcdrak: stuff is often already hard-enough as-is to find :) good point about bip65/OP_CLTV
223 2015-12-08 20:04:13 <gmaxwell> morcos: yes, makes sense to me.
224 2015-12-08 20:27:14 <nwilcox> Makefile.am uses $(JAVA_COMPARISON_TOOL) in the check-local and block_test.info targets, but only the latter is surrounded with "if USE_COMPARISON_TOOL". Is this a bug?
225 2015-12-08 20:27:30 <nwilcox> Sorry, only the former, check-local has the if guard.
226 2015-12-08 21:45:09 <btcdrak> jtimon: There is every possibility we close #6312 in favour of a new PR.