00:23:29	pigeons:	pigeons is now known as Guest7074
01:46:46	aaDJADJASDA:	Is there any way to have a fast game of poker that is trustless on the Bitcoin blockchain
01:48:17	Ursium:	probably not, because the data is in plain text. But if someone knows how, please do prove me wrong, cuz that's been bothering me with ethereum, too.
01:48:46	nsh:	discussed here: https://bitcointalk.org/index.php?topic=358106.0
01:49:25	nsh:	(synopsis: kinda. but you'd want to do it on a alt/side-chain, and even then there's gotchas...)
01:53:46	nsh:	and https://bitcointalk.org/index.php?topic=1487.0
01:57:43	aaDJADJASDA:	nsh: thanks
02:00:10	wyager:	You can probably achieve most/all of the security properties you want, and more effectively, with a centralized servic
02:01:05	nsh:	and you can achieve the taxation properties you want, more effective, through bribery
02:01:06	nsh:	:)
02:01:10	nsh:	*more effectively
02:01:36	nsh:	still, an interesting problem
02:03:28	aaDJADJASDA:	wyager: how does one make it trustless?
02:03:39	wyager:	Well, you can make it so you can’t steal their money
02:03:52	wyager:	using provably fair random number generation and multisig/advanced scripts
02:04:19	aaDJADJASDA:	wyager: sounds like i can just steal their money, I just need enough central authorities
02:04:27	aaDJADJASDA:	... to agree with me
02:04:50	wyager:	Huh? You can make it so that no number of malicious parties can be unfair to anyone else
02:05:06	wyager:	You can create a system where at each step of the game, everyone can verify that no one has cheated so far
02:05:34	wyager:	This system probably won’t be resistant to trolling
02:05:57	wyager:	But you could probably make it relatively fair
02:06:06	gmaxwell:	In general the strategy you want to use to build that sort of thing with wizardly techniques (instead of centeralization), is to use domain specific multiparty computation (google mental poker) that produces a transacript that either can be used to abtritrate a 2 of 3 escrow in bitcoin (not possible in script right now) or be fed to some (quorum of?) computational oracles that arb your multisig.
02:06:39	gmaxwell:	The reason for the escrow and transcrtipt is so that if the normal game gets jammed you've got a way for the last player to release.
02:07:40	aaDJADJASDA:	gmaxwell: what opcodes would need to be available?
02:08:35	aaDJADJASDA:	I feel like if this problem can be solved, most games can be bet on trustlessly (like checkeras)
02:10:29	gmaxwell:	Yes, most can be... though a much simpler solution is one that has minimized trust instead of zero trust. (e.g. you have some quourm of arbritrators which can only cheat by helping the wrong player win). In any case the functionlity to do it trustlessly is that the script needs to be able to validate that moves are consistent with the game. This is complicated in poker since there needs to be a virtual dealer that keeps secrets.
02:10:36	gmaxwell:	In games with no secret state its simpler.
02:12:00	nsh:	hmm
02:12:19	nsh:	can the virtual dealer role be distributed amongst the players somehow?
02:12:53	nsh:	i suppose the complexity overhead is irreducible, it would just manifest differently
02:12:55	wyager:	Look up secure multiparty computation. Possibly
02:13:06	aaDJADJASDA:	gmaxwell: very true. Any really simple games like tic tac toe been played decentralized and trustlessly?
02:13:46	aaDJADJASDA:	One could probably make a really long tic tac toe game using a set of bitcoin scripts
02:15:00	aaDJADJASDA:	but I'm interested in ways where you force a script to eval to true if a set of events happen in a game
02:16:17	wyager:	Events in the game could reveal a secret that allows someone to control a script
02:18:12	gmaxwell:	aaDJADJASDA: for something with a small state space (like tictactoe) it should be possible today though perhaps not very efficiently. :)
02:19:27	gmaxwell:	basically you'd make a series of releases from escrow the follow the game tree.. in the case no one cheats you just shortcut the move transactions at the end, but if someone won't sign the final transaction you expose the move transactions.
03:57:55	Guest33600:	Guest33600 is now known as ageis
06:12:32	aaDJADJASDA:	So between the supposedly bad incentives for nodes and grindable mining algorithm, does Ethereum have any chance of success? They seem to have an impressive dev lineup.
06:25:14	timbu:	timbu is now known as lenticulis
06:28:49	Luke-Jr:	aaDJADJASDA: impressive in what way? not a single one of their devs has ever worked on Bitcoin afaik
06:42:21	aaDJADJASDA:	Luke-Jr: They have Merkle and Vitelik
06:42:43	aaDJADJASDA:	Vitelik worked on a Bitcoin library IIRC
06:43:10	aaDJADJASDA:	*Vitalik
07:01:48	gmaxwell:	Semi-OT, has anyone here looked at the loophole-free bell test, I don't quite understand how puting the branch detectors outside of each others light cones actually precludes local realism, since the choice of basis presumably depends on information which actually (e.g. because the expiremental apparatus existed before the expirement began) is in light cone of the other detector.
07:18:54	jctb_:	jctb_ is now known as jctb
09:06:35	gmaxwell:	oh, I see Zooko has a commit in the rust repository now.
09:20:55	Luke-Jr:	gmaxwell: is rust relevant? I saw it mentioned in one of the channels I'm in, but the promoter was giving me the impression I got from Ruby
09:21:48	gmaxwell:	wow. no way.
09:22:15	gmaxwell:	It's squarely aimed at the kind of software we work on, though it still not final yet.
09:23:47	gmaxwell:	It's a systems language (e.g. the kind of thing you'd write an OS, browser, or other high performance service or system library in) targeted at existing C++/C developers that merges in and makes use friendly a bunch of safty and efficiency ideas from Haskell and especially ML languages.
09:26:10	gmaxwell:	Normal rust software should be completely free of memory safty bugs and data race bugs, but without a huge performance overhead. (you can write memory unsafe or concurrency unsafe code in rust using unsafe blocks, so the safety features don't preclude writing fast or low level software where its really needed)
10:16:40	nsh:	gmaxwell, physics is locally real, just that the locality mean null-separation in (minkowski) spacetime, which is a generalization of no-separation in space and no-separation in time...
10:16:51	nsh:	(so i don't believe the loopholes are closed)
10:17:08	nsh:	*means
10:19:51	nsh:	such thinking is somewhat elaborated here: http://www.mathpages.com/home/kmath238/kmath238.htm
12:05:23	nsh:	is it possible to have (or does there already exist) a formal mathematical treatment of what is possible using escrow and timelock'd transaction techniques to enable stuff like the game (poker) fairness conformance properties?
12:06:52	nsh:	do there exist formalisms for incentive modelling in general?
12:07:09	nsh:	i suppose that's pretty vanilla game theory
14:55:45	andytoshi:	gmaxwell: link to "loophole-free bell test"? iirc i saw something by that name recently, thought exactly what you did, then shrugged and thought "stupid bohmians" and went about my day
14:57:32	nsh:	* nsh takes offence, demands satisfaction
14:57:39	nsh:	actually, maybe i don't want to duel with someone living in austin texas
14:57:41	andytoshi:	oh, not quite exactly, i thought that there is no violation of locality because you can't actually verify the correlation FTL
14:57:46	nsh:	that might be an idea that ends in speed-holes
14:57:56	andytoshi:	nsh: it's ok, i'm back in vancouver where only the criminals have guns :)
14:58:00	nsh:	ah, sweet :)
14:58:38	andytoshi:	gmaxwell: suppose your detectors choose their bases using information from far-away stars in opposite directions?
14:59:43	nsh:	the detectors and the emission/splitting/rotation/polarization event are all still on the same hyper-ellipse of simultaneity
14:59:54	nsh:	or hyperplane, whatever, some 4d shenanigan
15:00:13	nsh:	nature, reality has access to all that information
15:03:10	andytoshi:	nsh: sure, but there doesn't seem a way for information to move around in the space of simultaneity (and if there were, iirc it would make P = PSPACE because you could send data backward in time)
15:03:56	andytoshi:	also locality has an emotional appeal because it grants scoping rules to the laws of physics
15:04:02	nsh:	my intuition is that there's no moving around necessary. that whole space is equivalent to a local point in newtonian causality
15:04:46	nsh:	but that leaves open the question of whether or not the entire 'set' of information in that hyperwhatsit is employed and if not, on what basis is the 'decision' made by the physical process in question
15:05:20	nsh:	i certainly think that there has to be some generalized concept of locality that holds
15:07:34	andytoshi:	i think locality is stronger than that, i'm betting on spacetime being made of discrete cells which only communicate via their boundaries
15:07:47	andytoshi:	but i'm certainly no physicist
15:07:56	nsh:	* nsh neither, for now :)
15:09:50	jcorgan:	i used to want to become a physicist, but am content now just knowing the other copies of me in other multiverse branches must have :)
15:11:51	nsh:	* nsh smiles
15:54:30	kanzure:	nsh: "do there exist formalisms for incentive modelling in general?" have some stuff, http://diyhpl.us/~bryan/papers2/incentives/
15:54:39	nsh:	o/ yay \o
15:56:32	kanzure:	as far as i can tell, the answer is no, or if the answer is yes then these are rather weak formalisms..
15:57:00	kanzure:	http://diyhpl.us/~bryan/papers2/incentives/Mathematical%20modeling%20of%20incentive%20policies%20in%20p2p%20systems.pdf
15:58:42	nsh:	should ask zooko if he's thought about this in the context of tahoe
16:00:21	kanzure:	it is also difficult because incentives can often exist due to externalities that may seem unrelated to your system design
16:00:33	nsh:	right
16:00:46	nsh:	though there ought to be some useful mitigation principles for externalities from economics
16:00:53	nsh:	*scoffs*
16:01:04	nsh:	no, really, i'm sure there's something that's not entirely without merit
16:01:16	kanzure:	and i am not sure if there is a physical limit to the extent to which you can block external-incentive-compatibility
16:01:23	kanzure:	(or if it's a good idea)
16:02:29	nsh:	a system will have to pick a suitable complexity (bounded range) for internal state representation of the effects of externalities
16:02:33	nsh:	there will be trade-offs
16:03:00	nsh:	but generally there's a way to allow the system to internalize adaptations that tend towards convergence
16:03:12	nsh:	(i say, off the top of my head, having no experience in the matter at all)
16:04:02	kanzure:	is there even a measurement of incentive compatibility?
16:04:13	kanzure:	incentive impedance or something
16:04:31	nsh:	if you can quantify payoff, you can determine mutuality
16:04:42	nsh:	but i suspect it gets nontrivial in certain contexts
16:05:09	nsh:	also, irl you're dealing with psychology, not actual game-theoretical reality
16:05:18	nsh:	the two are rarely rationally aligned
16:05:41	kanzure:	just because most of your users are psychologically uninterested in a certain incentive does not mean that all actors share that psychological block
16:27:15	nsh:	* nsh nods
16:27:29	nsh:	but you have to model perceived benefit alongside actual benefit
19:47:06	gmaxwell:	hurray for DJB for picking some less nutty EC curves! http://safecurves.cr.yp.to/bada55.html
19:52:01	sipa:	is that supposed to look like "badass"?
19:52:56	Apocalyptic:	obv
19:53:51	nsh:	(sponsored by geocities)
20:02:19	sipa:	ha
20:02:52	gmaxwell:	sipa: yep.
20:03:00	gmaxwell:	Read the bottom.
20:08:29	jctb_:	jctb_ is now known as jctb
20:16:01	jaekwon:	does ethereum have a tragedy of the commons problem? what if one miner decides to accept a ton of transactions for cheap gas (because it can afford to do so), but other miners aren't able to process those transactions quickly?
20:17:50	gmaxwell:	that was a complaint about that approach, as a result they've bounced between making fees get burned and miners collecting fees; I don't know what they're doing now.
20:18:35	gmaxwell:	and s/other miners/other nodes/ ... other nodes validating is part of what keeps miners honest, otherwise they have a common interest to cheat in particular ways.
20:19:18	jaekwon:	it looks like they're going for a block-level gas-limit. http://www.reddit.com/r/ethereum/comments/25qrue/two_questions_about_perblock_gaslimit/
20:23:42	gmaxwell:	the comments don't sound like a real limit, alas.
20:24:13	jaekwon:	"to solve them we simply institute a floating cap: no block can have more operations than BLK_LIMIT_FACTOR times the long-term exponential moving average.
20:24:16	gmaxwell:	(it sounds like they're just going to let the miners pick the limit, effectively— prevent a single out of line block, but doesn't prevent the harm from miner's self interest looking entirely unlike other nodes self interest)
20:24:17	jaekwon:	" https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-White-Paper#fees
20:25:25	gmaxwell:	right, so a rational strategy for all miners is to always pad blocks with more operations until the limit approaches what they can handle.
20:25:25	jaekwon:	ah, you mean, miners would collectively lift the limit, such that only miners can catch up?
20:25:50	gmaxwell:	(and then also rational to agressively deny transactions when the limit is getting too close to their own capacity)
20:26:58	gmaxwell:	(thus it would probably be better— but still broken— to just let them 'vote' on the limit so they don't need to play games with padding fake txn or droping txn, since they control it anyways)
20:28:06	jaekwon:	there's probably some moving average functions that can tolerate differing ratios of "aggressive" vs "casual" miners. like, one moving average function might be able to tolerate up to half the miners trying to aggressively lift the limit.
20:28:47	gmaxwell:	the pooling function that tolerates 50% outliers is called "median". :)
20:29:34	jaekwon:	oh wow, english fail :)
20:30:06	jaekwon:	it's what happens when i read too many whitepapers.
20:31:24	sipa:	there's one that allows 99% outliers (in the upward direction at least) too
20:31:34	gmaxwell:	jaekwon: the problem there is that fundimentally miners (who can get paid for accepting transactions) have different motivations from other users (who are only compensated by the utility and integrity of the network)
20:31:40	sipa:	called the 1st percentile
20:32:03	gmaxwell:	yea, taking a min() is more robust against people trying to inflate it, indeed.
20:32:32	gmaxwell:	you can also do thinge like a min() with an EWMA floor so that a single rude min doesn't suddenly crank it down.
20:32:48	sipa:	bitcoin automatically limits it using the block size limit for storage and bandwidth
20:33:09	sipa:	and as cpu is within a constant factor bound by script size, it limits cpu as well
20:34:08	nsh:	gmaxwell, EWMA?
20:34:09	gmaxwell:	I'm pretty fond of the style where all resources get turned into 'bytes' and then bytes is the only limit.
20:34:15	jaekwon:	i don't understand, gmaxwell. it seems that, with block gas limits, there's the potential for some sane incentive structure that is reasonably "resilient", e.g. with a moving average that seeks the median. if you assume, say, that half the miners intend to keep the gas limit at a "reasonable" level that is acceptable to most users, as that preserves the value of the network, how is that any different than bitcoin's incentives?
20:34:18	gmaxwell:	nsh: sorry, exponentially weighed moving average.
20:34:21	nsh:	ty
20:35:19	gmaxwell:	jaekwon: Bitcoin has hard limits that keep the validation accessible for all users. Mining isn't a vote of users, it's a vote of _miners_ (or rather pools), who have can have very different incentives.
20:36:09	gmaxwell:	(because unlike users who are only compensated by the utility of the network, miners can get paid to include transactions)
20:36:57	gmaxwell:	so it can be in miners interest globally to increase transactions even when doing so reduces the utility of the network (e.g. by making such that no one but miners can afford to verify it)
20:38:03	gmaxwell:	so basically what you might be demanding there is that a majority of miners behave locally irrationally to hurt miners for the benefit of non-mining users. Which might be a viable assumption, but its generally weaker than the ones in bitcoin.
20:38:17	jaekwon:	ok, i agree.
20:39:14	gmaxwell:	(thats also why an operation like a min() ~might~ be more robust, since e.g. you might only then need 1% of altruistic miners, assuming that the majority won't just orphan them to keep them in line)
20:41:28	gmaxwell:	(well perhaps min is too likely to produce orphaning, a 1%-tile over 1000 blocks or whatever would indeed be more robust)
20:42:24	jaekwon:	interesting. can it be fixed in another way? burning the fees and keeping the rewards at a constant sounds interesting.
20:42:40	sipa:	basically, everything that full nodes (users) demand from the system should ideally be encoded as consensus rules
20:42:55	sipa:	and those are never voted upon
20:43:01	sipa:	at least not in a technical way
20:43:01	gmaxwell:	jaekwon: seems not because you can pay fees out of band.
20:43:48	gmaxwell:	jaekwon: e.g. some blockchains have made fees get burned if blocks are over a certian size, but anyone can escape the fee burning just by paying the fee to the miner directly and making the transaction zero fees.
20:44:42	jaekwon:	you'd have to know which miner is going to win, no?
20:45:08	jaekwon:	oh i suppose you could publish many conflicting transactions each to different miners.
20:45:28	gmaxwell:	Yep, or even you can pay one, and if someone else mines it.. fine. :)
20:45:49	jaekwon:	out of band is weird though, isn't it? one could imagine incentivizing miners to enable a double-spend of some huge transaction.
20:46:06	gmaxwell:	you don't even need to do that out of band, just put high fees in the double spend.
20:46:20	jaekwon:	aye.
20:46:47	jaekwon:	but the miners would have to be more intelligent, to go back beyond 6 block commits.
22:02:08	gmaxwell:	So, I've realized that the FCC regs make it completely plausable to operate a beacon station serving up bitcoin blocks on 33cm+ (900MHz). http://www.w5yi.org/page.php?id=127
22:02:39	gmaxwell:	The normal ham rules prohibit one way transmissions so I thought I wouldn't be able to run such a thing without getting a variance from the FCC, but as a beacon station its already permitted.
22:28:27	john3213:	john3213 has left #bitcoin-wizards
22:31:33	petertodd:	gmaxwell; planning om an index number; thats a feauture i want to add to xheck that backeards compatible upgrades work
22:32:34	nsh:	petertodd, any notes on this stuff? sounds interesting...
22:51:31	gmaxwell:	petertodd: in bytecoin the indexes end up in the transactions, encrypted. I believe.
22:51:53	petertodd:	gmxwell: thats my plan too
22:52:26	petertodd:	gmaxwell: how manu bits is therr index?
22:55:19	gmaxwell:	64.
22:55:21	gmaxwell:	I believe.
22:55:32	gmaxwell:	which is probably bigger than it needs to be.
22:56:41	gmaxwell:	(another fun thing about bytecoin is that the design totally prevents key reuse)
22:57:17	gmaxwell:	or rather, you can pay to a single key as many times as you like, as far as I can tell, but it can only spend once since thats inticimal to how the double spending prevention works in the face of the ring signatures.
22:59:26	gmaxwell:	petertodd: you see the novena cround funding thing has blown the doors off? they're up to 600k raised (context: http://www.crowdsupply.com/kosagi/novena-open-laptop)
23:03:25	midnightmagic:	is he leaving the fpga coprocessor in?
23:04:53	gmaxwell:	of course.
23:05:20	gmaxwell:	though it's only a S6-45 part. kinda small.
23:05:22	gmaxwell:	but still big enough to implement a softcore.
23:05:39	midnightmagic:	ehh doesn't matter, as long as it's there.
23:06:29	gmaxwell:	They also added a nice gpio breakout to all units and the desktop/laptop systems will include a pretty sweet SDR board.
23:06:40	Luke-Jr:	gmaxwell: I wonder if one can upgrade later on :p
23:06:55	Luke-Jr:	4 months delay to get the $5k laptop
23:07:30	Luke-Jr:	otoh, I hate laptops, so maybe I should just get the board :x
23:07:41	gmaxwell:	they suggested that the sdr boards at least would likely be available later for something around the normal MyriadRF price.
23:08:27	Luke-Jr:	gmaxwell: I was a bit annoyed that the SDR specs have it exposed outside the laptop case
23:08:27	gmaxwell:	I've got a board on order.. I think it'll be really powerful to have a bunch of OSS hackers with a common hardware platform.
23:09:04	Luke-Jr:	on order, being distinct or the same as the "Back this project"?
23:09:23	gmaxwell:	same as back this project.
23:10:08	Luke-Jr:	I wonder if the RAM is upgradable
23:10:15	Luke-Jr:	4 GB is pretty low
23:10:16	midnightmagic:	hrm. it's not completely open, since it's using intel ssd, so the onboard guts of that are still closed aren't they?
23:10:32	Luke-Jr:	midnightmagic: the board itself is - you don't have to add the SSD
23:10:37	gmaxwell:	Though if someone really just cares about SDR stuff, USRP B200 is a better buy as a sdr device. ($675 USB3 attached board with LX75 FPGA on it and 70mhz-6ghz tx/rx)
23:11:07	Luke-Jr:	gmaxwell: is it documented anywhere which products will have the SDR?
23:11:11	midnightmagic:	there's a usb usrp now? is that ettus still?
23:11:52	midnightmagic:	* midnightmagic looks an stop sbeing lazy
23:11:53	gmaxwell:	midnightmagic: the original USRP was USB1. then they came out with some gig-e attached stuff that is quite expensive, and more recently they have new USB3 attached things which are more reasonably priced.
23:12:02	gmaxwell:	(and have awesome specs)
23:12:24	Luke-Jr:	hm, found a page that implies minimum of desktop
23:12:28	gmaxwell:	midnightmagic: ettus was acquired by national instruments, but other than having more high end products not much seems to have chaned.
23:12:43	gmaxwell:	Luke-Jr: yea the SDR is only bundled with laptop and desktop (and fancy laptop).
23:13:43	gmaxwell:	Which is reasonable in the sense that the non-novena wired MyriadRF board is $300 by itself.
23:14:22	midnightmagic:	the B200 doesn't accommodate daughterboards looks like
23:14:56	gmaxwell:	midnightmagic: right, doesn't really need to, since the integrated tranciever is, by itself, a single part that does 70MHz to 6GHz. (pretty insane capability!)
23:15:18	Luke-Jr:	gmaxwell: in what sense is the $675 SDR better than this one?
23:16:01	Luke-Jr:	* Luke-Jr ponders if the FPGA is actually setup to handle the heat of mining
23:16:14	petertodd:	gmaxwell: 64 bits seems usrful re: anti collissions
23:16:32	petertodd:	gmaxwell: yeah, i bought a novena board today
23:17:05	midnightmagic:	whoah ettus sells a gpsdo https://www.ettus.com/product/details/GPSDO-TCXO-MODULE
23:18:20	gmaxwell:	larger fpga, wider tunablity 70-6ghz instead of 300 to 3.8ghz, and simultanious capture of 25mhz of spectrum instead of I think 14? (more realistically you'll be bottleneked by processing power and usrp b200 can plug into a much faster machine). Also the B200 has external refclock input if you want to do things that need synched timing (like using multiple ones for direction finding or phased arrays)... also B200 probably a lot ...
23:18:26	gmaxwell:	... better supported in gnuradio... though perhaps that will balance out with like >200 people getting SDR boards with their novenas.
23:18:36	gmaxwell:	why the @#$@ am I talking about SDR stuff here when jcorgan is in the room? He does this stuff for a living. :P
23:19:13	gmaxwell:	midnightmagic: yea the on board ones are bling bling expensive, but I think everything USRP2 and later has a refclock in so you can plug in an external gspdo.
23:19:25	petertodd:	gmaxwell: note though how the 40 byted op-return screws wuth this stuff...
23:19:33	Luke-Jr:	* Luke-Jr sends them an email asking about FPGA cooling and later upgrade and/or SDR addons
23:19:40	midnightmagic:	neato. I always liked ettus, even though they're super expensive. :)
23:20:24	gmaxwell:	midnightmagic: so there is also bladerf now— which uses the same phy as the myriadrf. It's a bit less expensive and it seems not as nice as the B200. Competition is good. :)
23:21:23	Luke-Jr:	* Luke-Jr wonders if the Novena SDR can do 6lowpan
23:24:11	Luke-Jr:	maybe I should just buy the bare board plus one of the finished products
23:25:21	gmaxwell:	Luke-Jr: looks like there is 802.15.4 code for gnuradio floating around. Seems not unlikely that its possible. Though in my expirence a lot of the SDR stuff out there is basically only toy grade. like.. it kinda works, but not reliably. Not the hardware— but the software is often ducttaped togeather. :) I understand that it's getting better (and openbts is basically usable commercially) though... I haven't done much SDR stuff in a ...
23:25:27	gmaxwell:	... while.
23:26:28	gmaxwell:	if any of you want to just futs around with SDR stuff too, I did dig up my USRPs recently and could throw one online.
23:27:02	Luke-Jr:	I don't really "get" radio. :P
23:27:28	gmaxwell:	It's like a long cat. You are pulling the tail at one end and it is meowing at the other, except there is no cat.
23:28:37	nsh:	* nsh smiles
23:28:43	nsh:	shades of feynmann
23:29:09	gmaxwell:	nsh: it's actually a Einstein quote (well my vague recollection of it)
23:29:17	nsh:	ah
23:30:00	gmaxwell:	though god news I might have learned it via one of the feynman books, its very much his sense of humor too.
23:30:07	gmaxwell:	er s/news/knows/
23:31:20	nsh:	indeed
23:32:28	gmaxwell:	Luke-Jr: dunno radio is pretty simple. Works like sound, except it doesn't need a medium of air particles. Instead its directly oscillations of electromagnetic fields and moves at the speed of light. Devices can tune particluar frequencies of radio waves like you can listen to particular pitches of audio. A typical SDR works like a sound card with a very high sampling rate— to recieve RF enegy is captured and amplified, and ...
23:32:35	gmaxwell:	... digitized directly, usually a huge swath at a time.
23:33:09	gmaxwell:	then, with the data digitized, you can go ahead and do whatever processing is interesting to you... using DSP software that would do the same stuff some dedicated signal processing hardware would do.
23:33:54	Luke-Jr:	so why can't it just record all frequencies all the time? :D
23:34:32	gmaxwell:	Would need a really really fast analog to digital converter and an insane amount of storage. Otherwise— sure why not.
23:35:00	Luke-Jr:	sound just has much smaller range?
23:35:42	gmaxwell:	yea, audiable sound is just ~20hz to 20kHz. so about 20khz of range, which means you need about 40k samples per second to capture the whole thing.
23:37:27	gmaxwell:	You can buy SDRs now that can capture 120MHz at once. which needs 240M samples per second. If the samples are 16 bits each (in order to be able to sense weak signals in the presence of loud ones) then 240M * 16bits is about 5gbit/sec... these devices are pcie or 10gbe attached.. and good luck saving that data to anything. :P
23:38:43	Luke-Jr:	hm
23:39:02	nsh:	you don't need to save, just buffer and filter
23:39:06	nsh:	(like the NSA)
23:39:39	gmaxwell:	but the moderately inexpensive current SDR hardware (e.g. a B200) can basically capture, for example, all of the FM commercial broadcast band (87.5-108MHz) all at once, and then you're free to save it if you like, or demodulate every station at once... if you've got the cpu cycles for it.
23:40:29	gmaxwell:	(the MyriadRF could too but it can't tune below 300MHz; the USRP1 because of USB bandwidth limits could only capture 8MHz of spectrum IIRC, so not quite all of broadcast FM)
23:41:09	gmaxwell:	nsh: I have some understanding that the state department has sdr based listening posts at embassy that do things like capture all the broadcast radio.
23:41:42	nsh:	gmaxwell, makes sense
23:41:44	gmaxwell:	a lot of this stuff is pretty pricy for expirementation but pretty cheap from the perspective of spook budgets. :)
23:41:49	nsh:	* nsh nods
23:45:18	Luke-Jr:	too bad the Novena CPU is slower than some phones
23:45:30	gmaxwell:	there are other neat things you can do with the data than just plain recieving, e.g. using spaced antennas with a common in-phase clock source you can determine the direction signals are coming from, and do things like sense airplane locations based on reflections from other people's radio broadcasting.
23:46:02	gmaxwell:	Luke-Jr: yea, kinda limits some of the SDR usage. I do believe the novena is the fastest thing which you could claim was completely open software wise.
23:46:23	Luke-Jr:	gmaxwell: more than Intel? :p
23:46:52	Guest7074:	Guest7074 is now known as pigeons
23:48:31	gmaxwell:	Luke-Jr: intel has encrypted microcode updates, but indeed, I was mostly thinking in the context of embedded hardware which is notoriously closed.
23:50:53	Luke-Jr:	gmaxwell: and you're sure ARM doesn't (maybe unused)? ;)
23:52:45	gmaxwell:	the old arms did not, I know for sure (their decoders were too simple), I've never _seen_ an microcode update on current stuff, though I believe some of their instructions are microcoded now.
23:53:20	Luke-Jr:	http://www.mediatek.com/en/products/mobile-communications/mobile-chipsets/smartphone/mt6592/ ?
23:53:48	gmaxwell:	thats big.little
23:53:59	Luke-Jr:	?
23:54:04	gmaxwell:	hm maybe its not
23:54:06	gmaxwell:	* gmaxwell googles
23:55:12	gmaxwell:	ah neat. thats actually 8 core. There are a bunch of 8core arm socs out there that are basically 4 fast cores and 4 slow but more power efficient cores and you only really use 4 at once.
23:55:48	gmaxwell:	though that is all a7.. so.. meh
23:57:02	gmaxwell:	(the fast cores in bit.little are A15 which is a wide issue out of order superscalar part, while the slow cores are a7 which is a quasi-two issue in-order design)
23:58:06	Luke-Jr:	are the differences between A7 and A9 that significant? I know the older ARM cores had major performance differences, but I didn't know even the newer ones did
23:59:55	gmaxwell:	it's fairly big... I'd say A9 is probably about 30% faster than A7 clock per clock... and I'd say that A15 is probably also 30% faster clock per clock over A9, though obviously it depends on the workload.