1 2015-12-16 00:03:48 <tyler__> What's the "official-ness" of libbitcoin and libbitcoinconsensus?
  2 2015-12-16 00:04:17 <tyler__> I want to use a library for consensus code (for a port of bitcoin to another lang).
  3 2015-12-16 00:04:54 <sipa> bitcoin core has distributed a library that implements part of the consensus logic (built from the same code as bitcoin core itself)
  4 2015-12-16 00:05:03 <sipa> in particular, script validation
  5 2015-12-16 00:11:00 <tyler__> Is there any library that exports an API for full block verification?
  6 2015-12-16 00:11:35 <tyler__> Not to be lazy, it's just that that seems the safest way to do it.
  7 2015-12-16 00:12:38 <sipa> well what do you need full block validation for?
  8 2015-12-16 00:13:16 <sipa> in general my advice is that whatever you need it for, don't do it, and instead connect to a full node you trust
  9 2015-12-16 00:13:59 <sipa> there have been plenty of issues with library or compiler environment issues that interfere with correctness of the code
 10 2015-12-16 00:14:18 <tyler__> I want to write a full node implementation in Rust, for fun mostly.
 11 2015-12-16 00:14:32 <tyler__> But one already exists, sans consensus.
 12 2015-12-16 00:14:57 <tyler__> The author doesn't recommend using his consensus code because that isn't safe.
 13 2015-12-16 00:15:05 <sipa> good advice :)
 14 2015-12-16 00:15:19 <tyler__> So I thought I could contribute by adding support for it to use the official consensus code.
 15 2015-12-16 00:15:40 <sipa> there is work towards extending libconsensus' API to include more of full block validation
 16 2015-12-16 00:15:45 <pigeons> andytoshi has some good rust bitcoin tools. i havent looked in a while rust was in really rapid development a year ago
 17 2015-12-16 00:15:54 <sipa> but it's very nontrivial to do that in a 1) clean 2) safe) 3) efficient way
 18 2015-12-16 00:16:28 <sipa> as it means exposing an interface to a UTXO database, for starters, and we already rely on several layers of caching to make that efficient enough
 19 2015-12-16 00:16:53 <sipa> and caches have the annoying property of often breaking clean layering
 20 2015-12-16 00:23:23 <tyler__> That's a good point. This is probably a lot more than I expected. Thanks for the info.
 21 2015-12-16 02:00:09 <jl2012> jouke: you can find the orphaned blocks on blockchain.info
 22 2015-12-16 02:00:38 <sipa> only the ones they heard about
 23 2015-12-16 02:09:30 <jl2012> Since most nodes do not support CLTV it's likely they hear
 24 2015-12-16 02:20:07 <rusty> jl2012: oops, just realized your redirect-to-r/bitcoinwizards email is still in the mod queue for bitcoin-dev.  I think it comes across as a bit upset (I'd rather you directly quote me, as "Rusty feels this thread is not making progress and attracting confusion" if you prefer), but I can release it as-is if you prefer.
 25 2015-12-16 02:23:50 <Lightsword> has anyone seen an orphaned v3 block yet after activation?
 26 2015-12-16 02:26:48 <jl2012> rusty, please delete it. I'll have a better reply
 27 2015-12-16 03:33:38 <rusty> jl2012: done, thanks!
 28 2015-12-16 04:22:12 <btcdrak> Hi Rusty. Do you have any thoughts about #7184?
 29 2015-12-16 04:23:38 <rusty> btcdrak: no, I don't, sorry.
 30 2015-12-16 06:01:07 <moa> Is there a BIP for the 2-4-8 block expansion proposal?
 31 2015-12-16 06:03:43 <tyler__> How can I unsafely copy a box?
 32 2015-12-16 06:04:03 <tyler__> I'm implementing my own Rc, sorta.
 33 2015-12-16 06:04:36 <aj> moa: no bip, i think it was just proposed via a tweet?
 34 2015-12-16 06:09:05 <moa> tweet: "2-4-8 who do we appreciate?"
 35 2015-12-16 07:20:16 <da2ce7> hello, from memory sipa was writing hardened random mixer and source for bitcoin; was that completed? if not is there publicly available code to look over?
 36 2015-12-16 09:44:47 <bung_whole> I'm still reading through, but hopefully quck question for anyone, do pooled miners get allocated staggered nonce numbers?
 37 2015-12-16 10:57:13 <BW^-> the OpenSSL dependency will be kicked out soon, right?
 38 2015-12-16 10:57:14 <BW^-> in what version?
 39 2015-12-16 10:57:29 <Luke-Jr> BW^-: probably 0.13 or 0.14
 40 2015-12-16 10:58:18 <BW^-> aha
 41 2015-12-16 10:58:25 <BW^-> how does BitcoinD depend on Berkeley DB now?
 42 2015-12-16 10:58:29 <BW^-> as of 0.11.2
 43 2015-12-16 10:58:39 <BW^-> luke-jr: ?
 44 2015-12-16 10:58:52 <Luke-Jr> yes, for the wallet
 45 2015-12-16 10:58:57 <BW^-> luke-jr: ah..
 46 2015-12-16 10:59:01 <BW^-> luke-jr: but only for the wallet?
 47 2015-12-16 10:59:09 <Luke-Jr> yes
 48 2015-12-16 11:15:24 <BW^-> when you do "-connect=127.0.0.1:8333" (or other port number), what's the default connect resume logics?
 49 2015-12-16 11:15:37 <BW^-> I'm not sure but it seems that mine got stuck during sync with "socket receive timeout: 1201s"
 50 2015-12-16 11:16:36 <BW^-> luke-jr: any idea?
 51 2015-12-16 11:17:10 <Luke-Jr> nope
 52 2015-12-16 11:24:11 <BW^-> starting with what BitcoinD version will I be able to specify the max mempool size?
 53 2015-12-16 11:24:14 <BW^-> 0.12?
 54 2015-12-16 11:27:41 <Luke-Jr> BW^-: probably
 55 2015-12-16 11:27:55 <BW^-> aha
 56 2015-12-16 12:03:09 <BW^-> umm.. can BitcoinD have memory fragmentation issues?
 57 2015-12-16 12:03:31 <BW^-> like, you should restart it every 2 weeks for that reason?
 58 2015-12-16 12:08:08 <BW^-> luke-jr: the max mempool size, is there any patch i coudl apply to 0.11.2 already?
 59 2015-12-16 12:08:19 <Luke-Jr> BW^-: no, it's too complex
 60 2015-12-16 12:08:37 <Luke-Jr> you can set a higher min fee though
 61 2015-12-16 12:09:50 <BW^-> ah
 62 2015-12-16 12:10:12 <BW^-> luke-jr: wait.. the minimum fee, that will be like a criteria for which TRANSACTIONS are accepted to my mempool
 63 2015-12-16 12:10:44 <BW^-> luke-jr: but, it will still accept all blocks as usual?
 64 2015-12-16 12:11:05 <BW^-> luke-jr: so if I set like 1000 Bitcoins min fee, i will guaranteedly have no mempool issues? :)
 65 2015-12-16 12:11:28 <BW^-> luke-jr: and maybe a more seazoned choice would be like 0.0005 just to weed out crap?
 66 2015-12-16 12:11:33 <BW^-> or 0.0001
 67 2015-12-16 12:11:45 <Luke-Jr> BW^-: there is no options you can change that will break the consensus code
 68 2015-12-16 12:12:06 <Luke-Jr> note that the fee you set, will also be used by your wallet in some cases
 69 2015-12-16 12:12:47 <BW^-> aha
 70 2015-12-16 12:12:57 <BW^-> luke-jr: ok so you basically confirmed - neat, thanks!
 71 2015-12-16 12:22:32 <BW^-> um.. if BitcoinD is overloaded with transactions from the network, will it stop sending blocks to its whitelisted client then?
 72 2015-12-16 12:23:58 <Luke-Jr> BW^-: it shouldn't
 73 2015-12-16 12:24:17 <Luke-Jr> but if a peer it requests a block from refuses to send it in a timely manner, it might take 20 minutes to timeout
 74 2015-12-16 12:24:31 <BW^-> aha - but if it thinks it needs to catch up (e.g. it's on 0.999 progress), then it won't forward blocks until it itself synced
 75 2015-12-16 12:24:47 <BW^-> aha got it
 76 2015-12-16 12:59:28 <BW^-> so weird, my BitcoinD went up to 800MB heap consumption yesterday, and then just stopped - didn't accept any more connections, nothing.
 77 2015-12-16 12:59:45 <BW^-> and "kill":ing caused lots of paging. weird.
 78 2015-12-16 12:59:49 <BW^-> 0.11.2 on AMD64
 79 2015-12-16 13:01:22 <Ylbam> ltc est tombé à 0.00801 chez btce
 80 2015-12-16 13:01:26 <Ylbam> sorry
 81 2015-12-16 13:02:24 <BW^-> are there any common reports like this?
 82 2015-12-16 13:02:52 <sipa> BW^-: all versions before 0.12 do not have any effective memory limiting on utxo set size and memory pool
 83 2015-12-16 13:02:55 <BW^-> so I should expect that BitcoinD can go down and I need to restart it every so often, and have monitoring tools plugged in to it?
 84 2015-12-16 13:02:56 <BW^-> could there be memory fragmentation issues that would have made a malloc() somewhere fail?
 85 2015-12-16 13:03:18 <BW^-> sipa: right - but if it runs into the ceilign, *and* my OS has a "ulimit" that would kill it if it reached 1GB,
 86 2015-12-16 13:03:21 <BW^-> sipa: then it shouldn't go zombie right?
 87 2015-12-16 13:03:30 <BW^-> sipa: the only thing i could think of would be that some malloc() would have returned NULL
 88 2015-12-16 13:03:37 <BW^-> sipa: and that BitcoinD *NOT* would have responded properly to it!
 89 2015-12-16 13:03:42 <BW^-> sipa: thus making it go into a zombie state! :O
 90 2015-12-16 13:03:51 <Luke-Jr> BW^-: #bitcoin
 91 2015-12-16 13:03:54 <sipa> if malloc fails, bitcoind will most definitely crash immediately
 92 2015-12-16 13:03:56 <BW^-> okay
 93 2015-12-16 13:04:11 <sipa> your problem sounds like your OS went thrashing
 94 2015-12-16 13:04:58 <BW^-> sipa: as in paging..  right.. considering what happened when I finally "kill":ed it, I agree.
 95 2015-12-16 13:05:10 <BW^-> sipa: if so, what would the "antidote" be against that happening in the future?
 96 2015-12-16 13:05:47 <BW^-> sipa: for now I'll just set "-limitfreerelay=0 -minrelaytxfee=100000000", and when 0.12 is out, i'll specify a max mempool of some hundreds of MB?
 97 2015-12-16 13:05:55 <sipa> yes
 98 2015-12-16 13:06:20 <sipa> in 0.12 you can use -blocksonly
 99 2015-12-16 13:06:59 <BW^-> sipa: or some mempool size anyhow like "I give 200MB"?
100 2015-12-16 13:07:16 <BW^-> sipa: "-blocksonly" will have same effect as "-limitfreerelay=0 -minrelaytxfee=100000000" right?
101 2015-12-16 13:10:06 <BW^-> sipa: okay thanks for your thoughts, also Luke-jr gave some suggestiosn - i'll try it again and hope it will run perfectly indefinitely now
102 2015-12-16 13:12:57 <BW^-> sipa: if it was thrashing, then, with 0.12 and a mempool max limit of say 25% of what I want it to use at most, so say mempool max of 200MB,
103 2015-12-16 13:13:07 <BW^-> sipa: effectively that will make thrashing *never* happen right?
104 2015-12-16 13:14:38 <BW^-> sipa: because the probability that thrashing would come up from turbulence of fragmentation that would cause more than 4x memory allocation inefficiency is simply so low that it won't happen - sounds reasonable?
105 2015-12-16 16:01:04 <bung_whole> I'm still reading through, but hopefully quck question for anyone, do pooled miners get allocated staggered nonce numbers? (posted before didn't see an answer though)
106 2015-12-16 18:29:54 <jaclupi> Hi, is there a way to git clone always the last stable branch (tag)? without the -b it goes for the master that I do not want..
107 2015-12-16 18:30:22 <bung_whole> I wish I could help, but this place is a ghost-town
108 2015-12-16 18:34:01 <WeiJunLi> which requirements is necessary to a server run bitcoin core? ram etc...
109 2015-12-16 18:34:47 <bung_whole> prob just enough hd to store the blockchain
110 2015-12-16 18:35:02 <sipa> if you run with pruning enabled you don't need to store the entire blockchain
111 2015-12-16 18:35:19 <sipa> RAM... depends on the size of the cache you choose, but 0.12 should be default run with ~1Gb of memory max
112 2015-12-16 18:36:19 <WeiJunLi> what is the blockchain size actually?
113 2015-12-16 18:36:34 <sipa> 55 GB
114 2015-12-16 18:43:38 <bung_whole> I'm still reading through, but hopefully quck question for anyone, do pooled miners get allocated staggered nonce numbers?
115 2015-12-16 18:43:44 <bung_whole> quick*
116 2015-12-16 18:44:12 <sipa> afaic they just get their own block templates
117 2015-12-16 18:44:26 <kanzure> sipa: thank you for the email. reads well.
118 2015-12-16 18:44:34 <sipa> it only requires 4 Thash/s to cycle through an entire nonce range in 1ms
119 2015-12-16 18:45:00 <bung_whole> huh so why does it take much longer than that
120 2015-12-16 18:45:33 <sipa> ?
121 2015-12-16 18:46:52 <bung_whole> the nonce range you mean like 0 - say 5,000,000,000?
122 2015-12-16 18:47:00 <sipa> the nonce is a 32-bit integer
123 2015-12-16 18:47:08 <sipa> so there are only 4 billion values for it
124 2015-12-16 18:47:10 <WeiJunLi> sipa: can you show me any server sspecification that would just run btc core just fine during 1 year at least (blockchain size is going to increase so gotta prevent)
125 2015-12-16 18:47:25 <WeiJunLi> sipa: like an amazon server, whatever provider, just need to see its specification
126 2015-12-16 18:47:41 <sipa> WeiJunLi: no currently released version can guarantee that; i hope that 0.12 will
127 2015-12-16 18:49:09 <bung_whole> Maybe I haven't read enough but I thought finding the correct nonce was essentially finding the block hash?(and the reward)
128 2015-12-16 18:49:43 <sipa> yes
129 2015-12-16 18:49:49 <sipa> ;;difficulty
130 2015-12-16 18:49:50 <gribble> Error: "difficulty" is not a valid command.
131 2015-12-16 18:49:52 <sipa> ;;diff
132 2015-12-16 18:49:53 <gribble> 7.910238090022598E10
133 2015-12-16 18:50:21 <gribble> 339747323134943887360
134 2015-12-16 18:50:21 <sipa> ;;calc 2**48/65535*7.910238090022598*10000000000
135 2015-12-16 18:50:35 <sipa> only one in 339747323134943887360 attempts results in a valid block though
136 2015-12-16 18:51:46 <sipa> so you need to search though (on average) 80 billion full nonce ranges before finding a block
137 2015-12-16 18:52:44 <bung_whole> ok so what is the math relationship between the nonce and the target difficulty?
138 2015-12-16 18:53:13 <sipa> 1 difficulty = 1 in 2^48/65535 hashes is valid
139 2015-12-16 18:53:26 <sipa> N difficulty 1 in N*2^48/65535 hashes is valid
140 2015-12-16 18:59:00 <bung_whole> thanks I'm just trying to figure out how the nonces, coinbase, merkle root all relate to minig
141 2015-12-16 19:29:04 <wangchun> Luke-Jr: I talked to antminer last week and we both agree that we need a new mining protocol to replace stratum
142 2015-12-16 20:08:07 <rusty> jgarzik, kanzure, btcdrak: moderated the "$200 full node decentralisation threshold".  It doesn't belong on a -dev list, and unlikely to make progress.
143 2015-12-16 20:08:18 <jgarzik> +1
144 2015-12-16 20:23:26 <BlueMatt> wangchun: I know some people are already working on something more dense on-the-wire
145 2015-12-16 20:23:32 <BlueMatt> that sends just the info you need and nothing else
146 2015-12-16 20:23:48 <BlueMatt> and doesnt do it in fucking hex-in-json
147 2015-12-16 20:25:29 <Lightsword> wangchun, they are so horrible about updating cgminer though that I’m kind of surprized
148 2015-12-16 20:27:33 <Lightsword> wangchun, I don’t neccesarially diagree that we need a new protocol, the issue IMO is cost/benefit of upgrading tons of legacy hardware
149 2015-12-16 20:31:40 <BlueMatt> Lightsword: meh, writing an adapter that converts new-good-protocol to stratum should be easy
150 2015-12-16 20:32:34 <Lightsword> BlueMatt I mean, just need a stratum proxy basically.
151 2015-12-16 20:33:02 <BlueMatt> yup
152 2015-12-16 20:39:52 <wangchun> BlueMatt Lightsword: we've sent out boxes with stratum proxy ready to run to big mining operators, but most of them just seized and turn them into gaming consoles.
153 2015-12-16 20:40:21 <wangchun> Some mining farms have thousands of miners, what a waste
154 2015-12-16 20:40:24 <Lightsword> wangchun, got a posted online at all?
155 2015-12-16 20:40:28 <Lightsword> it*
156 2015-12-16 20:40:37 <wangchun> posted online?
157 2015-12-16 20:40:42 <Lightsword> like on github
158 2015-12-16 20:40:50 <Lightsword> the stratum proxy
159 2015-12-16 20:41:09 <wangchun> what you mean?
160 2015-12-16 20:41:33 <Lightsword> have you posted the source code for the stratum proxy on github or another website to download?
161 2015-12-16 20:41:54 <wangchun> Lightsword: no i haven't, it is highly customized only working for our pool
162 2015-12-16 20:42:40 <wangchun> haobtc is running it, the bandwidth requirement for them is only 40Kbps in total
163 2015-12-16 20:42:55 <wangchun> and they have like 14PH/s
164 2015-12-16 20:42:58 <Lightsword> wangchun, I mean, I can do the same thing with a stratum proxy as well :P
165 2015-12-16 20:43:15 <Lightsword> actually I could probably use less, only need a single tcp connection
166 2015-12-16 20:43:59 <wangchun> they used tangpool's proxy (like stratum proxy) in the past, but it does not work very well with the latest antminer s7, which has higher hashrate
167 2015-12-16 20:44:33 <Lightsword> wangchun, tangpool’s? I’m use a variant of ckproxy myself with antminers and it works quite well
168 2015-12-16 20:44:44 <wangchun> but for most mining farm operators, they do not know how to set up a stratum proxy... you know
169 2015-12-16 20:44:52 <Lightsword> true…
170 2015-12-16 20:45:00 <Lightsword> well at least the smaller ones
171 2015-12-16 20:45:06 <Lightsword> bigger ones usually hire someone
172 2015-12-16 20:45:56 <Lightsword> wangchun, what do you having in mind as a replacement for stratum, just a different format for the same sort ot TCP socket protocol?
173 2015-12-16 20:46:53 <wangchun> simply change hex in json to binary could save us a lot
174 2015-12-16 20:47:07 <wangchun> most of the lag we have now comes from stratum update delay
175 2015-12-16 20:48:01 <Lightsword> yeah, I could see that helping in China, US I don’t think it would make much difference since we can scale up bandwidth a bit easier
176 2015-12-16 20:49:11 <Lightsword> wangchun, would you have it support all the existing stratum features like redirects etc?
177 2015-12-16 20:49:21 <wangchun> I think US China the same on this matter
178 2015-12-16 20:50:13 <wangchun> If you have 150000 long-live TCP connections and you want broadcast like 300 bytes every minute hope that 300 bytes to arrive to all of their destinations within a fraction of a second
179 2015-12-16 20:50:25 <wangchun> you'v got some problem
180 2015-12-16 20:50:40 <Lightsword> well you scan scale it up across many backend servers at least
181 2015-12-16 20:51:04 <wangchun> Lightsword: This is what we are doing right now
182 2015-12-16 20:52:09 <Lightsword> wangchun, any idea why antpools stratum servers are so slow?
183 2015-12-16 20:52:12 <wangchun> anyway we can do it as is, at a higher unnecessary cost
184 2015-12-16 20:52:46 <Lightsword> yeah, IMO the easist way to do it may be via extension
185 2015-12-16 20:52:49 <wangchun> Lightsword: I suppose they may have too many users on each of their servers
186 2015-12-16 20:53:18 <Lightsword> or reformatting while retaining backwards copatibility
187 2015-12-16 20:53:20 <wangchun> They have 197673 active connections right now
188 2015-12-16 20:54:51 <Lightsword> yeah, that’s quite a few :P with good bandwidth 4 gigabit servers could probably handle that easially with very good update times
189 2015-12-16 20:55:31 <wangchun> at 100Mbps each, they need 40 of them.
190 2015-12-16 20:55:37 <Lightsword> wangchun, how easy do you think it would be to have you stratum servers handle multiple stratum formats at once?
191 2015-12-16 20:56:25 <wangchun> Unless I have been told a good reason to have multiple stratum format
192 2015-12-16 20:56:31 <wangchun> But I think it should be easy
193 2015-12-16 20:57:07 <Lightsword> I’m just thinking for backwards copatibility, have cgminer and the stratum server attempt to negotiate the newer protocol first then fall back
194 2015-12-16 20:58:17 <wangchun> That is easy, check whether the first byte received to be "{"
195 2015-12-16 20:58:29 <Lightsword> yep
196 2015-12-16 21:45:44 <mr_burdell> sipa, I think your fee calculation is too simple. don't miners need to maximize fee per byte transferred over the network? not just maximize total fee per block?
197 2015-12-16 21:46:36 <sipa> mr_burdell: if they're not fine with the worst case situation it creates, they shouldn't accept the proposal
198 2015-12-16 21:47:06 <mr_burdell> I just mean with respect to the economics of how they would value fees on transactions
199 2015-12-16 21:47:11 <sipa> plus, IBLT and other improved relay mechanisms make the bytes transferred over the network in non-adverserial conditions irrelevant
200 2015-12-16 21:47:21 <mr_burdell> that's fair
201 2015-12-16 21:48:00 <mr_burdell> my current understanding was that the opportunity cost of including a transaction in a block was roughly correlated with the size in bytes of the transaction
202 2015-12-16 21:48:40 <mr_burdell> and I don't follow how valuing the witness data at 0.25x would mean the fees would be discounted the same way
203 2015-12-16 21:49:07 <mr_burdell> since that data still needs to be transferred
204 2015-12-16 21:49:38 <mr_burdell> so until IBLT is implemented, it makes sense that witness data would not get a fee discount
205 2015-12-16 21:49:45 <sipa> see it this way: as miners are concerned, blocks are max 4 MB with this proposal. If they're not fine with that, they shouldn't accept the proposal period (or, alternatively, full nodes shouldn't accept the proposal if they fear that 4 MB would result in unacceptable mining centralization pressure)
206 2015-12-16 21:50:11 <sipa> but mining centralization pressure is not the only cost; there is also the growing resource cost to full nodes and the centralization that results from this
207 2015-12-16 21:50:56 <sipa> and that is where the modified formula comes it: it increases capacity but without worsening several of the operation costs (UTXO operations, UTXO size, block size, historic sync bandwidth, ...)
208 2015-12-16 21:51:25 <sipa> so the assumption behind the proposal is that we are fine with 4x larger blocks in terms of relay efficiency, but not with an outright 4x capacity increase
209 2015-12-16 21:51:31 <mr_burdell> I understand the formula from a risk perspective... I'm saying that the formula may not apply to valuing transaction fees
210 2015-12-16 22:00:17 <Luke-Jr> wangchun: maybe interested parties can form a "working group"?
211 2015-12-16 22:01:42 <Luke-Jr> wumpus: maybe the default git branch ought to be the latest stable?
212 2015-12-16 22:03:11 <kanzure> bitcoin-dev moderation is going to be bumpy for a while. note that jgarzik is operating as a moderator.
213 2015-12-16 22:03:56 <Luke-Jr> wangchun: Lightsword: btw BFGMiner haqs stratum proxy builtin
214 2015-12-16 22:04:01 <sipa> i personally feel that a few of my last mails were off-topic... apologies for that
215 2015-12-16 22:04:12 <jgarzik> kanzure, true as a disclaimer but not true in fact - I do not think I have logged into the admin interface in weeks
216 2015-12-16 22:04:20 <jgarzik> and don't intend to
217 2015-12-16 22:04:41 <kanzure> i have no way of verifying that and i don't care
218 2015-12-16 22:06:38 <kanzure> making claims that are non-verifiable is sort of ugh; now i have to deal with an additional unverifiable factoid? that's not fair.
219 2015-12-16 22:10:40 <gijensen> D:
220 2015-12-16 22:27:07 <Luke-Jr> kanzure: benefit of the doubt…
221 2015-12-16 22:27:55 <kanzure> Luke-Jr: a good and useful principle. i don't care what the reality happens to be in this instance, only that i have to keep track of increasingly unverifiable details.
222 2015-12-16 22:45:14 <AaronvanW> can someone explain to me how SW would provide for "4MB" blocks? (rather than 1.75MB)
223 2015-12-16 22:45:21 <AaronvanW> what's the math behind the number 4
224 2015-12-16 22:47:12 <AaronvanW> (or point me to an explanation somewhere else)
225 2015-12-16 22:49:03 <Guest45712> hey whoever runs the mailing list moderation: we're seeing BlueMatt's replies to Jameson Lopp's post but not the original posts
226 2015-12-16 22:49:06 <kanzure> a bunch of these emails are increasingly off-topic
227 2015-12-16 22:49:15 <kanzure> yes, we are moderating some of the off-topic stuff
228 2015-12-16 22:49:30 <Guest45712> how can the reply be ontopic but the original message off-topic
229 2015-12-16 22:49:35 <kanzure> BlueMatt: keep in mind some of those emails aren't getting delivered to the mailing list, so don't reply in public to everything. check with someone with access to the moderator queue.
230 2015-12-16 22:49:49 <kanzure> Guest45712: because jgarzik is an insider and has rigged things.
231 2015-12-16 22:49:55 <Guest45712> lol rigged things
232 2015-12-16 22:49:59 <kanzure> sorry for this interruption in service please don't blame me
233 2015-12-16 22:50:07 <Guest45712> how did he rig things?
234 2015-12-16 22:50:17 <kanzure> you are asking how a moderator can rig a message to go through?
235 2015-12-16 22:50:20 <kanzure> or are you asking a different question?
236 2015-12-16 22:50:54 <Guest45712> i dont have time to play aspegers babysitter, fix ur list pls thanks
237 2015-12-16 22:50:59 <kanzure> note that i don't mean to use "rig" in a nefarious way here.
238 2015-12-16 22:51:20 <kanzure> haha moderating is now aspie, apparently. sigh.
239 2015-12-16 23:54:17 <BlueMatt> kanzure: ack, though in this case I was responding to something that was on-topic
240 2015-12-16 23:54:19 <BlueMatt> so...oh well
241 2015-12-16 23:56:32 <rusty> Yes, our moderation is statistical.  I expect that to be tested sorely in the coming days.