00:00:41	phantomcircuit:	vetch, the performance is literally identical to the bitfury chips
00:01:00	phantomcircuit:	either they stole their design, or it's the same chip
00:01:07	vetch:	phantomcircuit: they're a different package size
00:01:16	phantomcircuit:	vetch, so?
00:01:57	[\\\]:	phantomcircuit, aren't you helping out cloudhashing? what are they using?
00:02:32	phantomcircuit:	[\\\], whatever makes sense to buy when we have money
00:02:49	phantomcircuit:	basically we have hw from everybody who has actually delivered
00:03:00	vetch:	phantomcircuit: I don't know man, it just never struck me as being the same. using a different package size means it is at least not just another production run with different laser etching.
00:03:01	phantomcircuit:	at scale it's all crap
00:03:35	vetch:	I can't find any dox for their chip, so I'm dead in the water in finding a difference.
00:03:35	[\\\]:	yes
00:03:41	[\\\]:	I agree
00:04:37	phantomcircuit:	[\\\], basically, bitfury stuff is all running over components spec
00:04:46	phantomcircuit:	so they have issues sometimes
00:04:51	phantomcircuit:	mostly in power cycles
00:04:57	phantomcircuit:	kcn stuff is all garbage
00:05:09	phantomcircuit:	easily underperforms by 60%
00:05:14	[\\\]:	are any bitfury chips able to run at 1w/GH?
00:05:22	phantomcircuit:	ct stuff has water cooling which sucks
00:05:22	vetch:	if you run them slow.
00:05:36	vetch:	if you run them fast the efficiency drops off a cliff
00:05:53	phantomcircuit:	vetch, if you fiddle with the voltage you can get them to operate correctly for about 30 minutes
00:06:03	phantomcircuit:	their automated voltage regulation does not work
00:06:05	phantomcircuit:	at all
00:06:15	phantomcircuit:	im sure they have a firmware in which it does
00:06:20	phantomcircuit:	but they haven't released it to customers
00:07:24	vetch:	phantomcircuit: I concede in that I can't find any documentation refuting that bit main and bit fury use the same design. the different package size at least means they're not the same chip / same run though.
00:08:35	phantomcircuit:	vetch, i dont think it's the same run for sure
00:08:49	phantomcircuit:	i doubt they're even made at the same facility
00:09:12	vetch:	phantomcircuit: actually, I believe you. the performance characteristics are too similar for it to be coincidental. stolen or licensed.
00:09:32	vetch:	different package, different foundry (different trays), same core.
00:10:26	vetch:	I finally found the dox for that chip.
00:11:02	adam3us:	phantomcircuit: do u know the W/GH off hand? whats the best? cloudhashing tried any spondoolies? (i think 0.8W/GH)
00:11:07	vetch:	phantomcircuit: yep. I confirm it's exactly the same.
00:11:25	phantomcircuit:	adam3us, ha im actually in the office right now looking at one
00:11:32	phantomcircuit:	but i forgot the key for the office so i cant get in
00:11:33	phantomcircuit:	derp
00:12:04	vetch:	adam3us: this is for the bitfury clone http://i.imgur.com/j7BtLva.jpg
00:12:35	adam3us:	phantomcircuit: (i should disclaim i consulted for them briefly) i was just curious on your comparison views. and if it actually is the best W/GH. i guess its easily the most dense anyway (1.25u for 1.4TH)
00:12:35	vetch:	running it slow is almost double the efficiency. nobody runs it slow though.
00:13:07	phantomcircuit:	adam3us, well it's not really 1.25U, you have to use 2U at least since it dissipates heat into the case
00:13:27	vetch:	adam3us: bitfury is 0.6W/GH if you run it at the minimum voltage
00:14:04	adam3us:	vetch: would anyone do that? i suppose they might as diff goes up run the miners slower
00:14:38	phantomcircuit:	adam3us, absolutely people will do that
00:14:41	phantomcircuit:	but not for a long time
00:14:42	vetch:	adam3us: if you had a lot of them available cheaply, sure. depends if your purchase cost is higher than the higher electricity cost of running them hard.
00:15:07	adam3us:	phantomcircuit: i think SP10 is 0.8W at normal speed.
00:15:15	phantomcircuit:	adam3us, yeah it is
00:15:18	phantomcircuit:	and i've confirmed that
00:15:52	vetch:	wonder if bitmain would send me a reel of those chips, and how much they'd sting me for them.
00:16:03	adam3us:	phantomcircuit: https://www.dropbox.com/s/68dfsslw68xlce0/ds_hammer_14041.pdf looks like it goes down to 0.55 if u underclock/volt. mabe lower?
00:16:30	phantomcircuit:	adam3us, im not sure i was mostly testing for maximum power draw
00:16:59	vetch:	phantomcircuit: do you know if bitmain is actually selling the raw chips? there's a topic on the forums that says they are, but it looks abandoned.
00:17:00	phantomcircuit:	i did things like restrict the airflow
00:17:08	phantomcircuit:	vetch, im sure they would
00:17:44	phantomcircuit:	but i bet the minimum order would be hundreds of thousands of dollars
00:18:08	vetch:	sure they'd do a pocket full of samples for me. even bitfury did that.
00:18:53	phantomcircuit:	lol hashfast got all mad about 1 of their chips
00:19:00	phantomcircuit:	they wanted like $800 for one of them
00:19:02	phantomcircuit:	insane
00:19:08	vetch:	wow what
00:19:30	vetch:	if you want people to design stuff that uses your chips, you give them samples
00:19:50	vetch:	I'm not going to buy $100,000 worth of shit I might not be able to use
00:19:56	phantomcircuit:	vetch, they're broke, they were trying to sell development kits
00:20:11	phantomcircuit:	basically give them like 20 grand for something that might be useless
00:20:31	vetch:	they're having a laugh
00:21:34	vetch:	there's even bitfury samples for 5 euro a pop on their store
00:34:58	phantomcircuit:	vetch, really all the manufacturers have problems
00:35:00	phantomcircuit:	some worse than others
00:51:55	contrapumpkin:	contrapumpkin is now known as copumpkin
01:29:30	phantomcircuit:	gmaxwell, huh
01:29:40	phantomcircuit:	chrome doesn't even check OCSP if the response is stapled
01:29:42	phantomcircuit:	that's bizarre
03:17:42	jgarzik:	Calling all early seeders, for soon-to-be-announced bootstrap.dat updated torrent @ block 295000: http://gtf.org/garzik/bitcoin/bootstrap.dat.torrent If you have an old bootstrap.dat, bittorrent will automatically extend it when you switch to the new torrent. You effectively already have 81% of the new bootstrap.dat.
03:52:04	[\\\]:	jgarzik, how large is the new bootstrap.dat?
03:52:14	jgarzik:	17G
03:52:38	[\\\]:	thanks.
04:58:37	jaekwon:	in zerocash, does the zero knowledge proof for the pour-tx require as input, the full merkle tree of all the known coin commitments?
05:00:04	gmaxwell:	no, it requires a merkel path (for each input coin) to show the coins being consumed exist.
05:00:12	gmaxwell:	Oh, have they published the paper?
05:00:28	justanotheruser:	Are decentralized jamming resistant networks possible?
05:00:39	jaekwon:	i don't know. i'm watching https://www.youtube.com/watch?v=l7LSSE0bRRo
05:00:57	jaekwon:	@18:05
05:01:38	gmaxwell:	Because the tree is append only its 'easy' to keep track of what the path is for each of your coins.
05:03:16	gmaxwell:	(whereby 'easy', I mean easy in universes where all developers and users aren't the sort of people who eat suppositories, reuse addresses, and engauge in all manner of other illadvised behaviors because it was the simplest thing to implement :) )
05:04:13	jaekwon:	makes sense. so the one creating the proof just needs the merkel path to create a ZK-SNARK proof of the statement, "i know the secret address for the coins whose coin commitments hash to to the known merkel root hash r"
05:06:50	gmaxwell:	yes.
05:08:05	gmaxwell:	you actually reveal the scriptPubkey for the coins you consume, so that they can be placed into the spent coins tree. The spent coins tree isn't subject the the ZKP however.
05:08:33	jaekwon:	right. but you didn't reveal the private address, so nobody can steal them.
05:11:50	gmaxwell:	E.g. the ZKP tells you Coin A and Coin B are coins committed someplace in root X, and that coins Y and Z are new coin commitments and F is a fee with consistent values (A+B>=Y+Z+F). Nodes verify the A and B aren't spent yet, and add Y and Z to the unspentcoins tree.
05:12:18	gmaxwell:	(and that the signatures required by A and B are satisfied, of course)
05:14:15	jaekwon:	what is this about the setup requiring a trusted party using a random trapdoor? what is this random trapdoor function for? is it the same function f where address_public = f(address_private) ?
05:17:48	gmaxwell:	no.
05:18:01	gmaxwell:	address_public = f(address_private) is just ecdsa.
05:18:13	gmaxwell:	the trusted initiliztation is for the ZKP system.
05:18:43	gmaxwell:	The ZKP is such that if someone keeps the random data used to initilize it (or cracks it somehow) they can create false proofs.
05:18:55	gmaxwell:	"This coins exists in root X" when it really didn't.
05:19:15	gmaxwell:	Which, since values are hidden in zero cash gives you unbounded, undetectable, inflation. wee. :P
05:25:51	jaekwon:	oh interesting
05:26:39	jaekwon:	like a magnetic dipole. :P
05:27:54	jaekwon:	like, you can't have one without the other.
05:28:00	jaekwon:	ok bad analogy.
05:29:19	gmaxwell:	better ZKP systems are possible but are not as close to pratical yet.
05:32:14	kayann_:	cool!
09:45:13	Guest51740:	Guest51740 is now known as UukGoblin
12:28:37	jgarzik:	jgarzik is now known as home_jg
14:25:18	michagogo|cloud:	...oh, wait, this is -wizards, not -mining
14:55:51	tromp_:	you can still discuss wizardly-mining...
16:39:46	WOODMAN:	http://bitcoinmacroeconomics.com/2014/04/13/interview-with-director-of-cryptoeconomy-engineering-at-blocktech-mr-bryce-weiner/
16:40:03	Apocalyptic:	...
17:20:48	aynsteindash:	aynsteindash is now known as aynstein-
17:21:20	aynstein-:	aynstein- is now known as astein
17:22:31	astein:	astein has left #bitcoin-wizards
19:35:55	vetch:	phantomcircuit: https://www.kncminer.com/products/mini-neptune-third-batch
19:36:18	vetch:	phantomcircuit: I'm at a loss to explain this
19:39:00	phantomcircuit:	vetch, seems like a straight up scam to me
19:39:37	vetch:	phantomcircuit: yep. I was fully expecting for their "neptunes" just to end up with the "hosted mining" bullshit and that would be the end of that
19:39:52	vetch:	the interesting bit is that these are "non-refundable"
19:40:18	phantomcircuit:	vetch, all hardware orders have always been non refundable
19:40:42	Apocalyptic:	not the first BFL's one
19:40:52	vetch:	phantomcircuit: KNC always gave refunds up until a few days before they started shipping, I read that thread before
19:41:07	phantomcircuit:	Apocalyptic, please they only let people refund when it was profitable for bfl
19:41:38	Apocalyptic:	sure, i should have added they were stated as such
19:41:51	vetch:	at least the "neptune mini" seems to at least be slightly plausible
19:42:11	phantomcircuit:	Apocalyptic, hell BFL even had a cut out company for processing cc payments
19:42:53	phantomcircuit:	vetch, it looks like they just took the jupiter design and switched out the chip
19:42:58	vetch:	though you'd actually be more sensible to buy their "upgrade modules" and throw together some sort of controller for them. it works out at the same price and you'd get the hash power today, not in months time.
19:43:02	phantomcircuit:	except in fact it looks like a picture of a jupiter
19:43:12	vetch:	it is a photo of a jupiter
19:44:19	vetch:	it doesn't actually say when the "second" and "first" batches are meant to ship, so presumably it's not for the foreseeable future
19:44:34	home_jg:	home_jg is now known as jgarzik
19:44:37	phantomcircuit:	vetch, my money is on never
19:44:47	vetch:	phantomcircuit: do you know what sort of communication those modules need?
19:45:09	phantomcircuit:	vetch, they plugin to a backpane
19:45:14	vetch:	I know there's a beaglebone black and some sort of FPGA on the controller
19:45:41	vetch:	the DC-DC are SPI controlled though, logically they'd just all be thrown on the same bus. I don't know what the FPGA is doing.
19:47:02	vetch:	oh i2c not SPI.
19:47:09	vetch:	hm. maybe not then.
19:50:07	vetch:	there's no photo of the back of the board, but the KNCminer firmware must have the FPGA bitstream in it
19:50:25	vetch:	looks like you could probably clone that controller board
19:52:52	vetch:	actually looks like there's a carry output and input on the boards. could be that the FPGA is there so that they can chain multiple boards together and have the SPI control the communication back to the laptops that I saw in the photo of their farm. that would make the most sense. it means they wouldn't have to have a beagle bone black for every single miner.
19:56:17	vetch:	yeah, it's SPI only. you could get one of those modules and control it with a raspberry pi.
19:56:33	vetch:	phantomcircuit: that might be one for you to investigate ;)
20:01:51	gmaxwell:	The mining talk is totally relevant to my interests, but unless we're talking about something kinda technically far out or researchy— things like smart property miners or what have you— we should probably move those discussions to #bitcoin-mining :)
20:02:18	vetch:	eh, sorry, it was on topic when I first talked about it a day ago
20:18:09	johntramp_:	johntramp_ is now known as johntramp
20:39:00	gmaxwell:	I'm the primary perp for continuing those discussions. :)
20:40:27	sipa:	you suffer from a severe case of xkcd386
20:44:31	vetch:	http://xkcd.com/386/
20:44:47	vetch:	sipa: that's accurate.
22:25:43	shinybro_:	shinybro_ is now known as MoltenSea
22:34:25	amiller:	gmaxwell, you know how i complained about recursive snarks
22:34:27	amiller:	and the problem is that every time you have a recursive application of a proof about the verification algorihtm applied to an earlier proof etc.
22:34:33	amiller:	well, my advisor says i've been applying that wrong, and the polynomial expansion is only with regard to the size of the *witness*, not the prover program that created the witness.
22:34:39	amiller:	i might just be wrong in either direction i dunno
22:34:44	amiller:	http://www.cs.tau.ac.il/~tromer/papers/bootsnark-20120403.pdf
22:35:05	amiller:	Remark 6.3 is the part that complains about this.
22:37:59	gmaxwell:	I never quite completely understood your complaint because a basic verifier should be polynomial (nearly linear in fact) in the size of the original witness
22:38:59	gmaxwell:	In general, though, I don't really know that any of these extractability assumptions can result in a statement of security which has any real applicability to _real_ security.
23:27:18	phantomcircuit:	gmaxwell, well this is odd
23:27:32	phantomcircuit:	i have two systems running ntpd out of clock by quite a margin
23:27:36	phantomcircuit:	using the public pool servers
23:27:49	phantomcircuit:	1397518036 1397518060
23:28:16	vetch:	is one of them a Mac?
23:28:23	phantomcircuit:	nope
23:28:46	sipa:	he said 'systems', not 'toys'
23:28:53	vetch:	they currently have massive NTP issues. you can drift minutes in a day. I thought I was going insane.
23:30:03	phantomcircuit:	ah one of them is stuck in init
23:30:03	gmaxwell:	I think these NTP reflection/amplification attacks have severely broken the ntp infrastructure.
23:30:23	gmaxwell:	phantomcircuit: you should run your own ntp time source. super awesome gps clocks are cheap as dirt now.
23:30:24	phantomcircuit:	it's a ddos protected server so i bet they're just blocking ntp entirely
23:30:57	phantomcircuit:	screwing up all my hashrate statistics
23:32:00	gmaxwell:	IMO all major bitcoin mining pools should be running a local atomic clock. They're cheap now commercially, and dirt cheap bought on the surplus market.
23:32:11	vetch:	* vetch raises an eyebrow
23:32:34	vetch:	some of the pools are out by like 20 minutes, and you want them using atomic clocks?
23:32:42	phantomcircuit:	gmaxwell, i'll futz around with installing one when i finally few my new servers
23:32:43	phantomcircuit:	>.>
23:33:29	gmaxwell:	phantomcircuit: If I setup a webpage or whatever and it was like buy-this-thing and it was a couple grand do you think that people would actually go and do so?
23:34:00	phantomcircuit:	gmaxwell, maybe
23:34:03	vetch:	what sort of sample do atomic clocks use? can you even ship them?
23:34:22	phantomcircuit:	gmaxwell, probably the annoying part would be installing it in a rack in a facility with metal roof
23:34:25	gmaxwell:	vetch: oh certantly you can ship them. atomic clocks are not radioactive. :)
23:34:57	vetch:	oh I thought they measured decay or something
23:35:19	gmaxwell:	phantomcircuit: it's totally normal for telecom folks to require a gps clock, anything doing cellular does, so facilities will permit you to run an antenna for gps.
23:35:28	vetch:	right. nothing to do with radiation. got it.
23:35:29	Burrito:	GPS clocks are easy to implement if people are too lazy for atomic clocks, aren't they?
23:35:33	phantomcircuit:	gmaxwell, sigh
23:35:39	phantomcircuit:	yeah i see ntp requests going out with no reply
23:35:54	phantomcircuit:	damn it black lotus
23:36:06	vetch:	Burrito: yeah, you can get GPS chips for < $20, that'd do
23:36:14	gmaxwell:	vetch: yea, common misconception. No, what an atomic clock does is that it uses some molecular resonance of some sample atom in a oscillator with feedback.
23:36:28	gmaxwell:	Burrito: yes, though you're vulnerable to denial of gps. :)
23:36:38	vetch:	GLONASS then
23:37:01	gmaxwell:	yea, there are new timing gps chips coming out that are gps+glonass: e.g. LEA-M8F
23:37:27	phantomcircuit:	gmaxwell, how reliable is an atomic clock setup?
23:37:29	vetch:	I actually have one coming in the post this week sometime, as luck would have it
23:37:53	gmaxwell:	But you can go find devices like http://www.ebay.com/itm/HP-SYMMETRICOM-Z3805A-GPS-Disciplined-Oscillator-GPS-Frequency-Time-Receiver-/290832846664?pt=LH_DefaultDomain_0&hash=item43b6fd0f48 surplus dirt cheap that give you 1e-12 - 1e-13 frequency accuracy, basically as good as a cesium beam standard, at least so long as the gps network is up.
23:38:03	gmaxwell:	phantomcircuit: the new stuff should be trouble free for a decade.
23:38:23	gmaxwell:	surplus stuff, depends on what condition it was in.
23:38:30	vetch:	gmaxwell: I think I was thinking of smoke alarms, which have random isotopes in them. I have a picture in my head of an isotope, an air gap and a detector that I attributed to atomic clocks.
23:39:05	vetch:	gmaxwell: surely a $20 GPS chip would be more efficient for people than a 3RU box
23:39:46	phantomcircuit:	gmaxwell, lol that has been beat to hell
23:39:54	gmaxwell:	vetch: that 3ru box will keep ~one second level accuracy when disconnected from gps for ~a year.
23:40:01	Burrito:	Does the job. :P
23:40:49	vetch:	gmaxwell: if you lose both GPS and GLONASS.. you can probably just suffer along with NTP. you can assume you'll never want to mine without an internet connection for NTP, a better time sync is just gravy.
23:41:17	gmaxwell:	vetch: what GPS module did you order?
23:41:36	gmaxwell:	vetch: NTP is super duper insecure though.
23:42:23	Burrito:	Complete infrastructure independence is nice and all, at least to the highest degree possible so maybe atomic clock is better than something that needs satellites. The UK government (sometimes) does military tests which involve GPS disruption. While Ofcom issues warnings to citizens and businesses about such tests, it's really annoying.
23:42:43	Burrito:	Wouldn't affect a clock, still, though. Because the test doesn't last long enough.
23:42:49	gmaxwell:	vetch: in a couple years I'll be telling people to use these: http://www.jackson-labs.com/index.php/products/hd_csac but right now the atomic clocks on them are about $1500 for just the part.
23:42:53	phantomcircuit:	gmaxwell, i get the distinct impression installing that in a real facility would be super annoying :P
23:42:58	gmaxwell:	they have a 10 year MTBF though.
23:43:09	vetch:	gmaxwell: SkyTraq.. something. it's a hybrid GLONASS/GPS
23:43:41	gmaxwell:	phantomcircuit: hm? nah. as I said virtually all the telcom companies have gpsdos as part of their required equipment.
23:44:39	gmaxwell:	phantomcircuit: if you tell a facility you want to install a gps antenna it will be no big deal.
23:44:42	phantomcircuit:	gmaxwell, well that one in particular requires a dc power source
23:44:46	gmaxwell:	vetch: any trouble finding external antennas.
23:45:34	gmaxwell:	phantomcircuit: just needs about 30w of 24v.. you can find people selling nicer versions of the same hardware with a psu: http://www.ebay.com/itm/Z3805A-58503A-GPS-Frequency-Time-Receiver-10-Mhz-1pps-/281294190956?pt=US_Ham_Radio_Receivers&hash=item417e70b96c
23:45:45	vetch:	gmaxwell: apparently their supplier had a nasty time finding adequate ones
23:47:24	gmaxwell:	vetch: yea, I didn't see pretty much anything for good external antennas for gps+glonass.
23:49:19	vetch:	gmaxwell: guess we'll see how it goes. I won't be too cut up if it isn't any good, purchased out of curiosity not necessity
23:49:34	gmaxwell:	vetch: I have a hankering to build a tamper resistant/detecting box that contains a small highly reliable computer, a small very low power atomic clock, and internal power (e.g. an ultracap), and then the device functions as an oracle for timestamping and timelock encryption.
23:50:06	gmaxwell:	and for that kind of thing you really do want it to be robust against garbage gps signals, since someone could try to force you to advance the timelock by sending in a spoofed gps input.
23:51:28	vetch:	could be interesting. I was imagining a large concrete block but you wouldn't get much in the way of signal though that.
23:52:46	vetch:	I suppose if it just needs to be tamper resistant you'd build a mounted plastic case with a continuous copper fibre going through it and back to some sort of volatile memory. any breaks in the surface and you permanently destroy it.
23:53:17	gmaxwell:	vetch: a box with an atomic clock in it only needs the gps for initial time and fine tuning, with the gps denied a 1e-12 clock will only slip a couple milliseconds in a year.
23:53:31	vetch:	they do similar tricks with credit card POS terminals. lots of tripwires that brick the device if you try to tamper with it.
23:53:34	gmaxwell:	vetch: yea, the ibm cryptocards have some wire mesh embedded in epoxy.
23:54:42	gmaxwell:	I was thinking that it should be pretty cheap to produce plastic sheets with a metallized layer with a wire in a space filling curve.. and have a couple layers of this and it would be basically impossible to penetrate while breaking the wire.
23:54:57	gmaxwell:	er without breaking the wire. :)
23:55:00	vetch:	finally a use for hilbert curves.
23:55:31	vetch:	actually no, you wouldn't want that!
23:56:27	vetch:	somebody could follow the line of the hilbert curve between the lines and cut it with a scalpel. eventually you'd end up with a long, wobbly chain that could be parted and the insides accessed.
23:56:40	gmaxwell:	vetch: thats why you have multiple layers.
23:57:03	gmaxwell:	e.g. rotate/offset it on the different layers.
23:57:09	vetch:	multiple layers laminated, right. I was thinking they would be separate sheets for some reason.
23:57:43	gmaxwell:	right. I was surprised I couldn't find this commercially. seems like something you should just be able to buy.
23:58:09	vetch:	you could also just do the whole thing in a resin block. you can embed circuits in solid resin without issue. hilbert wires around the outside, processor and battery and junk in the middle.
23:58:35	vetch:	resins are annoying to get into. you can't shatter them or you'd break the wire, same with cutting, sanding