1 2016-01-18 01:01:06 <Chris_Stewart_5> AaronvanW: I like the idea on the weekly AMA for the devs that are actively working on the bitcoin repo
  2 2016-01-18 01:01:45 <midnightmagic> :-o  \o roconnor nice to see you
  3 2016-01-18 01:01:55 <roconnor> hi
  4 2016-01-18 01:09:05 <Chris_Stewart_5> mabye it would save time explaining things in other threads for devs as well :/
  5 2016-01-18 01:10:08 <midnightmagic> roconnor: I really like that you show up at the cusp of every major technology change. Very nice to see you dude.
  6 2016-01-18 01:10:37 <roconnor> I was reading about segwit.
  7 2016-01-18 01:10:52 <roconnor> I didn't realize such a magical soft-fork was eve possible.
  8 2016-01-18 03:23:42 <rusty> kanzure: hmm, that post in the queue proposing a reduced tx format wedged in the coinbase.  Do you have a convenient ref to a previous proposal, otherwise I'm tempted to let it through so I can respond.
  9 2016-01-18 06:00:06 <X1smpl1c1ty> \
 10 2016-01-18 06:02:01 <kanzure> rusty: nope, i don't have a reference on that, i'm approving the email
 11 2016-01-18 06:02:05 <kanzure> rusty: thanks for checking with me
 12 2016-01-18 06:02:27 <kanzure> er, to be clear, not only do i not have a convenient reference, i have no reference. is there one that you are thinking of?
 13 2016-01-18 06:02:51 <kanzure> rusty: changed my mind, i'll let you approve it
 14 2016-01-18 06:03:39 <rusty> kanzure: am sure there was a previous discussion on how little this buys, but I'm lazy...
 15 2016-01-18 09:30:37 <cluelessperson> How can I help bitcoin?
 16 2016-01-18 09:34:39 <Lauda> cluelessperson depends on your expertise.
 17 2016-01-18 09:35:28 <Guest73650> whats the purpose for the C prefix in CCoinsView?
 18 2016-01-18 09:35:43 <Guest73650> doesn't seem to stand for concrete since CCoinsView is an abstract class
 19 2016-01-18 09:35:45 <hasha> Lauda: they asked the same question in the main chan
 20 2016-01-18 09:40:32 <cluelessperson> Lauda, I'd be best for groundwork :/
 21 2016-01-18 09:40:51 <Lauda> cluelessperson please discuss in #bitcoin, this is off-topic here.
 22 2016-01-18 10:03:09 <wumpus> Guest73650, C stands for just "class", it's satoshi's coding convention, no longer used in new code
 23 2016-01-18 10:07:20 <Guest73650> was there a purpose for this convention?
 24 2016-01-18 10:07:55 <wumpus> ask satoshi...
 25 2016-01-18 10:08:04 <Guest73650> ah. of course.
 26 2016-01-18 10:08:38 <wumpus> to me it looks like it was inherited from 90's windows MFC programming
 27 2016-01-18 10:08:56 <Guest73650> any value in refactoring the C prefix out of all of the classes?
 28 2016-01-18 10:09:20 <Guest73650> or is it preferred to be left in
 29 2016-01-18 10:13:26 <wumpus> no, don't do that
 30 2016-01-18 10:13:43 <wumpus> it's a useless change, just breaks patches
 31 2016-01-18 10:14:29 <wumpus> a good guideline for contributionsi s to try to keep code changes focused and solving a problem that faces users
 32 2016-01-18 10:14:38 <wumpus> not just 'I like this convention better'
 33 2016-01-18 10:17:13 <Guest73650> makes sense. i was stepping through code, and some of it wasn't clear.
 34 2016-01-18 10:19:51 <frankenmint> how is bitcoin simulated?  I mean testnet still lmits by consensus rules so how did gavin simulate 8mb blocks?
 35 2016-01-18 10:20:57 <frankenmint> is the simulation to 'backtest' from 08 to 15 using diff blocksize as a frame?  is it just dummy data and random blocks? and what metrics are measured (I presume latency with regards to propagation)
 36 2016-01-18 10:20:58 <kinlo> nobody prevents you from creating a fork/own seperated testnet
 37 2016-01-18 10:22:12 <frankenmint> also, would it even hold relevancy in the real world (how do i account for geograpical latency differences with simulation tests)?
 38 2016-01-18 10:23:24 <wumpus> simulating bitcoin realistically is a non-trivial problem, but there has been some previous research you could look at
 39 2016-01-18 10:24:21 <wumpus> (not sure in how far they realize 'relevancy in the real world', a simulation always makes some simplifications, but you can try to account for as much as possible, or even try to replay 'real data')
 40 2016-01-18 10:25:49 <wumpus> this comes to mind: https://shadow.github.io/
 41 2016-01-18 10:28:04 <gdm85> I guess one could also use regtest for that purpose, no?
 42 2016-01-18 10:28:05 <frankenmint> I've seen that but couldn't make out how to set it up - I understand that its made for an old version of BTC I think .09??? I didn't understand how to go about updating the framework to point to a newer version
 43 2016-01-18 10:30:46 <frankenmint> I get that it creates a thin instance and allows you to specify the number of instantiations but I couldn't quite grasp if Im to write the interaction points as a type of test (like the regtester) and if that's even applicable
 44 2016-01-18 11:25:27 <Lauda> It�s possible to construct a transaction that takes up almost 1MB of space and which takes 30 seconds or more to validate on a modern computer (blocks containing such transactions have been mined). In 2MB blocks, a 2MB transaction can be constructed that may take over 10 minutes to validate which opens up dangerous denial-of-service attack vectors. Other lines of code would need to be changed to prevent these problems.
 45 2016-01-18 11:26:48 <Lauda> What kind of transaction would this be?
 46 2016-01-18 11:27:38 <Lauda> I only know something similar that  Mark Friedenbach presented;  3.2MB - 10 minutes.
 47 2016-01-18 11:34:11 <Rebroad> Lauda, the only sensible way forward is to not set in stone the blocksize now, but to allow it to change based upon future findings. The only way to do this would be to let the miners votes with each block whether to increase it or decrease it
 48 2016-01-18 13:10:48 <MarcoPon> Hi! A quick question: does anyone here know if there's some alt-coin, blockchain based, that use a base58 encoding but with a different order/values from Bitcoin?
 49 2016-01-18 13:12:00 <aj> MarcoPon: base58 is purely a wallet thing, bitcoin's testnet varies the base58 encoding compared to the main bitcoin net
 50 2016-01-18 13:13:07 <MarcoPon> aj: I was not aware of that. Will have to look into it. Thx!
 51 2016-01-18 13:14:43 <MarcoPon> aj: are you sure that the "base58 encoding" is different? from what I see the version bytes changes, but that's a different thing
 52 2016-01-18 13:14:48 <MarcoPon> https://en.bitcoin.it/wiki/Base58Check_encoding
 53 2016-01-18 13:16:40 <MarcoPon> for example ripple instead use a different order of the symbols (but that's not blockchain based so I'm not interested)
 54 2016-01-18 13:18:27 <aj> MarcoPon: yeah, it's just the version that changes it, but you could trivially change any wallet to use your own format if you wanted. no one else would be able to work it out without your version of the wallet though :)
 55 2016-01-18 13:19:16 <MarcoPon> of course.
 56 2016-01-18 13:24:07 <MarcoPon> aj: have to go now. thanks. Bye!
 57 2016-01-18 13:40:29 <Lauda> ReBroad that makes sense but does not answer my question
 58 2016-01-18 13:40:38 <Lauda> What kind of 2 MB transaction takes more than 10 minutes to validate?
 59 2016-01-18 13:44:27 <aj> Lauda: a large transaction with a lot of SIGHASH_ALL signatures, basically
 60 2016-01-18 13:45:14 <Lauda> Thank you for the answer.
 61 2016-01-18 15:09:45 <Lauda> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html
 62 2016-01-18 15:10:14 <Lauda> does SegWit requal to a 2MB block size or less? I'm unsure because of different numbers found
 63 2016-01-18 15:11:27 <Chris_Stewart_5> Lauda: It depends. It doesn't not equate to EXACTLY 2 MB.
 64 2016-01-18 15:11:44 <Lauda> Close to, or 1.6 as said in this email?
 65 2016-01-18 15:12:09 <jl2012> Lauda: depends on how many people use it
 66 2016-01-18 15:12:25 <Lauda> Let's say that the whole network is using it?
 67 2016-01-18 15:12:27 <jl2012> if everyone use it, it is around 2.5MB
 68 2016-01-18 15:12:31 <Chris_Stewart_5> For instance, on pay-to-pubkey-hash transactions result in a smaller increase in block size. Pay-to-script-hash (P2SH) txs result in a larger increase in block size.
 69 2016-01-18 15:14:38 <Lauda> Thank you.
 70 2016-01-18 15:34:25 <aj> Lauda: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012248.html is an update; i redid the math
 71 2016-01-18 15:34:49 <Lauda> Thank aj.
 72 2016-01-18 15:34:52 <Lauda> thanks*
 73 2016-01-18 15:35:23 <aj> jl2012: (i don't think you can realistically get to 2.5MB though; you'd have to do away with a lot of p2pkh users...?)
 74 2016-01-18 15:35:56 <jl2012> I said " if everyone use it"
 75 2016-01-18 15:37:05 <aj> jl2012: yeah, but even if everyone used it, p2pkh will only get 1.7MB worth, and 2/2 multisig will only get 2MB worth, so you'll need everyone using it *and* a majority of payments being much more complicated than either of those
 76 2016-01-18 15:38:14 <jl2012> historically, 60% of data could be moved to witness
 77 2016-01-18 15:38:29 <jl2012> this is from sipa's presentation in Hong Kong
 78 2016-01-18 15:39:01 <aj> jl2012: yeah, which gives 1.8MB equivalence
 79 2016-01-18 15:39:04 <jl2012> so the max possible block size = 1/(1-0.6) = 2.5
 80 2016-01-18 15:39:14 <jl2012> not 1.8
 81 2016-01-18 15:39:18 <aj> jl2012: 1/(0.4 + 0.6/4)
 82 2016-01-18 15:39:24 <jl2012> oh, sorry
 83 2016-01-18 15:39:53 <jl2012> you are right
 84 2016-01-18 15:40:00 <aj> jl2012: yeah, it'd be so much more scalable if the witness data were discounted to 0 :)
 85 2016-01-18 15:45:28 <Chris_Stewart_5> aj: jl2012 Do either of you two have stats on the usage of p2pkh vs p2sh currently?
 86 2016-01-18 15:49:03 <aj> Chris_Stewart_5: no, i haven't tried figuring that out
 87 2016-01-18 15:50:15 <jl2012> may be p2sh.info ?
 88 2016-01-18 15:50:16 <Lauda> aj wouldn't it be possible to prevent that transaction
 89 2016-01-18 15:50:17 <Lauda> aj wouldn't it be possible to prevent that transaction
 90 2016-01-18 15:50:22 <Lauda> that would validate 10minutes or longer
 91 2016-01-18 15:50:23 <Lauda> that would validate 10minutes or longer
 92 2016-01-18 15:50:27 <Lauda> by introducing a limit per transaction
 93 2016-01-18 15:50:29 <Lauda> of some sort
 94 2016-01-18 15:50:36 <Lauda> as a temporary workaround
 95 2016-01-18 15:53:03 <aj> Lauda: bitcoin xt introduced a limit per transaction like that; segwit solves the problem more directly with https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki
 96 2016-01-18 15:54:36 <Lauda> Is it fully implemented already on testnet or?
 97 2016-01-18 15:56:20 <aj> Lauda: there's also https://github.com/bitcoin/bitcoin/pull/7081 which is related
 98 2016-01-18 15:56:43 <aj> Lauda: hmm, i haven't looked if it's implemented or not actually
 99 2016-01-18 15:57:28 <Lauda> @luke-jr Not sure what you want to do here instead of rebasing, but this somehow needs to be made suitable for merge if you still want it included in 0.12
100 2016-01-18 15:57:32 <Lauda> that's what it says
101 2016-01-18 15:57:33 <Lauda> hm
102 2016-01-18 15:57:33 <Lauda> that's what it says
103 2016-01-18 15:57:34 <Lauda> hm
104 2016-01-18 15:59:16 <wumpus> that's no longer relevant, it's been merged
105 2016-01-18 16:03:03 <aj> Lauda: yes, bip 143 looks implemented to me; https://github.com/sipa/bitcoin/commit/cebda8e169bb8dc73d2df39bbdebd610bd482a7c
106 2016-01-18 16:03:54 <jl2012> yes, it's implemented
107 2016-01-18 16:07:08 <Lauda> Isn't 2 MB block size then safe?
108 2016-01-18 16:07:20 <Lauda> If someone is unable to construct a transaction that would take too long to validate?
109 2016-01-18 16:07:21 <Lauda> If someone is unable to construct a transaction that would take too long to validate?
110 2016-01-18 16:07:38 <wumpus> this is just node policy; miners still can
111 2016-01-18 16:08:02 <Lauda> How can that be solved?
112 2016-01-18 16:12:26 <Chris_Stewart_5> Lauda: If I am not mistake i think the root cause is the ECDSA algorithm used
113 2016-01-18 16:15:12 <Chris_Stewart_5> I'm not sure if the 'monster transaction' is validated using our old ECDSA algo or the new libsecp256k1 that sipa and gmaxwell wrote though :/
114 2016-01-18 16:15:54 <Chris_Stewart_5> because I think libsecp256k1 is 3 or 4 times faster
115 2016-01-18 16:16:45 <Lauda> I think libsecp256k1 doesn't validate what you think it does.
116 2016-01-18 16:19:30 <Amnez777> is there a way to check if some  random public address with btc on it uses multisig or not?
117 2016-01-18 16:19:40 <Lauda> [�]gavinandresen 16 points 18 days ago
118 2016-01-18 16:19:40 <Lauda> Most of the time is hashing to create 'signature hashes', not ECDSA verification. So libsecp256k1 doesn't help.
119 2016-01-18 16:20:44 <aj> Lauda: yes, that's what bip142 above fixes
120 2016-01-18 16:20:52 <aj> err 143?
121 2016-01-18 16:21:04 <Lauda> Yeah 143. Well technically doesn't fix, but scales it down.
122 2016-01-18 16:21:18 <Lauda> but wumpus just said that miners can still create a transaction that would take too long to validate
123 2016-01-18 16:21:23 <Chris_Stewart_5> Thanks for that Lauda
124 2016-01-18 16:21:25 <Lauda> that doesn't make sense if BIP143 is functioning properly
125 2016-01-18 16:21:26 <Lauda> to me
126 2016-01-18 16:21:32 <aj> Lauda: no, it does fix it
127 2016-01-18 16:21:43 <Lauda> Then 2 MB is safe?
128 2016-01-18 16:21:46 <aj> Lauda: bip143 is proposed and implemented, but not merged or deployed
129 2016-01-18 16:21:46 <Lauda> because of BIP143?
130 2016-01-18 16:21:49 <Lauda> oh
131 2016-01-18 16:22:07 <Lauda> Why not?
132 2016-01-18 16:22:26 <aj> Lauda: it's still undergoing testing and review
133 2016-01-18 16:22:44 <Lauda> So it's going to arrive after 0.12?
134 2016-01-18 16:23:22 <aj> Lauda: yes. it's part of the segwit patchset, so will be part of that soft-fork activation (or however else segwit might get deployed, i guess)
135 2016-01-18 16:25:49 <Lauda> Oh I did not know that.
136 2016-01-18 16:26:10 <aj> Lauda: it's mentioned towards the bottom of that bip iirc
137 2016-01-18 16:29:07 <Lauda> I don't think that a lot of people are aware of BIP143.
138 2016-01-18 16:31:57 <aj> Lauda: not really, it's not good gossip material. :) https://www.reddit.com/r/Bitcoin/comments/3zl96x/johnson_lau_proposes_new_bip_for_solving_on2/ was the reddit post
139 2016-01-18 16:34:01 <Lauda> I must have missed it.
140 2016-01-18 16:53:52 <Chris_Stewart_5> where is the 'scriptCode' variable defined at in interpreter.cpp
141 2016-01-18 16:53:55 <Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L829
142 2016-01-18 17:03:15 <Giszmo> For testing, is there any RBF focet on testnet?
143 2016-01-18 17:03:51 <Giszmo> oops. "faucet" i mean
144 2016-01-18 17:09:59 <Lauda> aj
145 2016-01-18 17:10:14 <Lauda> someone claimed XT had a per block limit, not a per transaction limit for those sig ops?
146 2016-01-18 17:12:05 <instagibbs> Lauda, there is a per block limit for both
147 2016-01-18 17:12:22 <instagibbs> differently counted and limited
148 2016-01-18 17:12:31 <Lauda> so doesn't that prevent the creation of blocks that would take too long to validate?
149 2016-01-18 17:12:46 <instagibbs> mitigates, yes
150 2016-01-18 17:13:33 <instagibbs> havent made "bad" blocks for XT myself so unsure how well it works
151 2016-01-18 17:13:34 <instagibbs> havent made "bad" blocks for XT myself so unsure how well it works
152 2016-01-18 21:33:09 <bsm1175321> Doesn't the merging of libsecp256k1 mean that 0.12 will verify blocks about twice as fast (or faster), so that if bandwidth were not a concern, we could bump the block size by roughly a factor of two at the same orphan rate?
153 2016-01-18 21:33:33 <bsm1175321> So with 0.12 we should expect to see orphan rates and empty blocks go down, because of faster verification, no?
154 2016-01-18 21:36:11 <phantomcircuit> bsm1175321, we've been continuously overshooting the increased capacity of the hardware since 2009
155 2016-01-18 21:36:27 <phantomcircuit> libsecp256k1 is another in a long line of software fixes that bring us back in line with that
156 2016-01-18 21:36:41 <phantomcircuit> so
157 2016-01-18 21:36:42 <phantomcircuit> no
158 2016-01-18 21:38:51 <Chris_Stewart_5> bsm1175321: Also according to gavin most of the time is spent hashing on verification, not ECDSA operations
159 2016-01-18 21:39:27 <Chris_Stewart_5> [�]gavinandresen 16 points 18 days ago
160 2016-01-18 21:39:29 <sdaftuar> bsm1175321: we already cache signature verifications when transactions enter the mempool
161 2016-01-18 21:39:44 <Chris_Stewart_5> Most of the time is hashing to create 'signature hashes', not ECDSA verification. So libsecp256k1 doesn't help.
162 2016-01-18 21:39:46 <sdaftuar> the caching system was improved for 0.12 as well
163 2016-01-18 21:39:52 <belcher> phantomcircuit how does hardware getting better make the problem worse? or have i misunderstood
164 2016-01-18 21:40:00 <bsm1175321> Gotcha, thanks
165 2016-01-18 21:40:39 <phantomcircuit> belcher, the cost of completing initial block verification has been growing faster then hardware has been getting faster
166 2016-01-18 21:40:48 <belcher> ah right yes
167 2016-01-18 21:40:48 <phantomcircuit> belcher, mostly we've been making up for this in software
168 2016-01-18 21:41:20 <belcher> though i think bsm1175321 was talking about mining rather than initial blockchain sync
169 2016-01-18 21:41:36 <Luke-Jr> bsm1175321: there is presently a plan to bump the block size by about 2x in April
170 2016-01-18 21:42:02 <bsm1175321> I'm not going to hold my breath on that...
171 2016-01-18 21:42:12 <Luke-Jr> bsm1175321: eh? why not?
172 2016-01-18 21:42:39 <bsm1175321> Just commit it to core already and stop making forks...
173 2016-01-18 21:42:40 <Luke-Jr> almost the entire Core team signed off on it, and it's a softfork so easy to deploy
174 2016-01-18 21:42:56 <bsm1175321> You mean an evil fork?
175 2016-01-18 21:42:59 <Luke-Jr> no
176 2016-01-18 21:43:02 <Luke-Jr> regular softfork
177 2016-01-18 21:43:03 <phantomcircuit> belcher, time to synchronize at the tip is FAR less important than time to complete initial block verification
178 2016-01-18 21:43:18 <phantomcircuit> if IBV takes too long nobody new can join the network...
179 2016-01-18 21:43:25 <bsm1175321> Luke-Jr: are you talking about segwit?
180 2016-01-18 21:44:02 <belcher> phantomcircuit yep ok, but the tip sync taking longer contributes to miner centralization because they get more orphans, either that or they use spv
181 2016-01-18 21:44:36 <Luke-Jr> bsm1175321: of course
182 2016-01-18 21:44:37 <Luke-Jr> bsm1175321: of course
183 2016-01-18 21:44:44 <Chris_Stewart_5> bsm1175321: For more information on CPU usage in the network you can look at the 'CPU' section on this web page
184 2016-01-18 21:44:45 <Chris_Stewart_5> https://en.bitcoin.it/wiki/Scalability
185 2016-01-18 21:50:37 <zookolaptop> Chris_Stewart_5: that web page contradicts what you said -- it says that the hashing time is negligible.
186 2016-01-18 21:50:43 <zookolaptop> You said that it was > the ECDSA time.
187 2016-01-18 21:50:45 <phantomcircuit> belcher, the effect is basically not measurable with 0.12.0 and a proper configuration
188 2016-01-18 21:50:53 <instagibbs> zookolaptop, worst-case hashing can dominate
189 2016-01-18 21:50:54 <belcher> okay
190 2016-01-18 21:50:57 <instagibbs> due to signing alg
191 2016-01-18 21:51:12 <zookolaptop> instagibbs: can you point me to some docs or measurements I can use to understand this?
192 2016-01-18 21:51:14 <instagibbs> this will be largely fixed with SegWit rollout
193 2016-01-18 21:51:15 <instagibbs> this will be largely fixed with SegWit rollout
194 2016-01-18 21:51:32 <Chris_Stewart_5> see this thread wrt malicious txs
195 2016-01-18 21:51:34 <Chris_Stewart_5> https://www.reddit.com/r/Bitcoin/comments/3yulwv/any_examples_of_the_10_minute_script_thats_a/
196 2016-01-18 21:51:36 <zookolaptop> instagibbs: I'm not sure if you mean SHA256 hashing or the process to sign a transaction, with that old O(N^2) problem in it...
197 2016-01-18 21:51:37 <instagibbs> ^^
198 2016-01-18 21:51:44 <instagibbs> sha hashing the txn
199 2016-01-18 21:51:57 <Luke-Jr> why is the java comparison tool so slow? :x
200 2016-01-18 21:52:20 <instagibbs> signing is linear in txn size, hashing is quadratic in txn size
201 2016-01-18 21:52:36 <instagibbs> hashing for the signing*
202 2016-01-18 21:52:59 <zookolaptop> Yeah, so that O(N²) problem wouldn't be changed much by using a faster or slower implementation of SHA256.
203 2016-01-18 21:53:00 <zookolaptop> Yeah, so that O(N²) problem wouldn't be changed much by using a faster or slower implementation of SHA256.
204 2016-01-18 21:53:17 <instagibbs> correct, just how it's hashed
205 2016-01-18 21:53:31 <zookolaptop> Ok.
206 2016-01-18 21:53:36 <Chris_Stewart_5> new hasing algorithm would have to be implemented to solve that problem? instagibbs?
207 2016-01-18 21:53:51 <instagibbs> yes
208 2016-01-18 21:54:12 <instagibbs> already developed
209 2016-01-18 21:54:41 <instagibbs> https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki
210 2016-01-18 21:57:12 <Chris_Stewart_5> wow super interesting. Thanks.
211 2016-01-18 21:59:33 <instagibbs> also notice the other bonus we get
212 2016-01-18 22:00:18 <Chris_Stewart_5> whats that?
213 2016-01-18 22:00:55 <instagibbs> 6. value of the output spent by this input
214 2016-01-18 22:01:13 <Chris_Stewart_5> ahh ok yes, that can be used by cold storage wallet software right?
215 2016-01-18 22:01:22 <instagibbs> yep
216 2016-01-18 22:03:00 <Chris_Stewart_5> It really is amazing how all these pieces fall together under the segwit umbrella
217 2016-01-18 22:03:17 <Chris_Stewart_5> wish the wider community would appreciate that :/
218 2016-01-18 22:06:45 <Angelo544> bit
219 2016-01-18 22:09:45 <Luke-Jr> BlueMatt: seriously, is there any way to make the comparison tool fast?
220 2016-01-18 22:13:18 <jtoomim> bsm1175321: orphan rates (or 1-tx blocks) are driven by three factors: 1. block prop time, 2. verification time, and 3. CreateNewBlock() time
221 2016-01-18 22:13:34 <jtoomim> 2 and 3 are made much faster in 0.12, but 1 is not helped
222 2016-01-18 22:14:18 <jtoomim> at least not much. i suppose the verify-before-relay in conditions where the relay network is missing may be relevant.
223 2016-01-18 22:17:25 <Luke-Jr> 2 helps 1 somewhat
224 2016-01-18 22:17:53 <jtoomim> yes
225 2016-01-18 22:34:44 <Lightsword> jtoomim, technically you missed mining stack latency stratum cgminer hardware etc but that’s less important
226 2016-01-18 23:28:59 <Luke-Jr> >1 hour for comparison tests :|
227 2016-01-18 23:29:00 <Luke-Jr> >1 hour for comparison tests :|