00:55:47	gmaxwell:	gmaxwell is now known as Guest17871
00:56:14	Guest17871:	Guest17871 is now known as gmaxwell
01:27:55	iddo:	andytoshi: i didn't understand your link above, you don't need obfuscation for timelock encryption, just witness encryption (and Bitcoin)
01:32:42	iddo:	andytoshi: why you say that we don't know parts of future blocks? we do know, that blockhash
02:34:08	jae:	jae is now known as Guest6213
02:43:01	nsh:	* nsh frowns
03:56:55	andytoshi:	note to self: my argument about trusted setup being required had something to do with definition of simulation security, i think
03:57:15	andytoshi:	iddo: oh, that's a good point re witness encryption, i used timelock encryption because that's what i was trying to build when i encountered the "result" typed up
03:57:31	andytoshi:	re your second point, i need to think about that, i had considered it but for some reason did not think it affected my result
03:59:59	andytoshi:	iddo: i think: in the random oracle model, `blockhash < target` implies that the blockhash is uniformly random in [0, target] which is still a large space, so "no information about the blockhash" is still a reasonable way to describe the state of affairs
04:00:57	andytoshi:	oh, i see, witness encryption works despite this
04:01:06	andytoshi:	weeeird
04:02:19	andytoshi:	i guess, modulo the existence of secure witness encryption, i'm wrong then :)
04:52:53	jae:	jae is now known as Guest31937
04:55:53	zmachine:	zmachine has left #bitcoin-wizards
06:15:57	Taek:	apparently a think tank today hypothesized that one day Bitcoin mining could be consuming 60+% of all of the world's total energy
06:16:30	Taek:	this would make for some interesting security conditions, as I think it's reasonable to assume that 1 entity would control more than 30% of the world's total energy
06:16:56	Taek:	economies of scale start to fall apart as you grow to such an extreme percentage of all of the resources available
06:17:28	Taek:	s/would control/would NOT control/
06:18:03	Taek:	furthermore, dark hashing power also becomes less of a concern, because it's unlikely that someone has so much energy available but isn't putting it to use
06:18:38	Taek:	if they are putting it to use, it would necessarily need to fit inside of the remaining 40% of the world's available energy
06:19:04	Taek:	and thus isn't enough to spring a surprise 51% attack unless they also controll more than 30% of the Bitcoin hashing power
06:19:34	amiller:	Taek, link?
06:19:34	Taek:	you do still need to be paranoid about bursty-hashing schemes, and you need to be concerned about technological advances that make hashing more energy efficient
06:20:57	amiller:	i like comparing bitcoin miner spending to spending on "defense" and militaries, or maybe physical security more generally
06:21:18	amiller:	obviously if a society spends all of its resources on defense, there's not much else left to defend in the first place
06:21:18	Taek:	http://www.coinfox.info/news/2113-environmentalists-bitcoin-mining-might-eventually-consume-60-of-global-electricity-supply
06:21:23	Taek:	.title
06:21:25	yoleaux:	Environmentalists: bitcoin mining might eventually consume 60% of global electricity supply | Coinfox
06:22:11	Taek:	I think the idea of spending 60% of available energy on mining is completely absurd and very unlikely to happen
06:22:23	Taek:	but it was fun to think about how the economic security assumptions changed at that scale
06:22:41	amiller:	it would look pretty insane if 60% of the world's energy expenditure were spent on military too
06:23:10	amiller:	"There are also hopes that the efficiency of bitcoin mining will grow so the electricity consumption and CO2 emission would decrease." this is meaningless too
06:36:42	jcorgan:	click-bait as a journalistic fitness function has really skewed the shitty end of distribution
08:05:14	verne.freenode.net:	topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
08:05:14	verne.freenode.net:	Users on #bitcoin-wizards: andy-logbot thrasher` Tiraspol bosma gill3s ttttemp mountaingoat antanst kmels Relos hktud0 Transisto2 jmcn wallet42 paveljanik oleganza priidu d1ggy BallsMahoney nivah Mably koshii daira1 hulkhogan_ [7] zooko`` Dr-G2 gmaxwell DrWat spinza PRab gielbier go1111111 sparetire_ dc17523be3 GAit wizkid057 arubi_ justanotheruser rustyn Luke-Jr Iriez akrmn robogoat cdecker afk11 harrow dansmith_btc face metamarc Keefe mkarrer jrayhawk b_lumenkraft
08:05:14	verne.freenode.net:	Users on #bitcoin-wizards: K1773R Guest95228 luny Emcy wonk_unit melvster tromp_ prodatalab stonecoldpat theymos waxwing Apocalyptic LeMiner Logicwax copumpkin ebfull prosodyContext ggreer tromp Hunger- PaulCapestany c0rw|zZz Pan0ram1x jcorgan isis dgenr8 nickler Cory cryptowest_ mengine EasyAt lmatteis sneak HM grandmaster Starduster bsm117532 zz_lnovy harrigan andytoshi scoria brand0 larraboj bedeho2 OneFixt superobserver kyletorpey vonzipper mappum MoALTz Jouke weex
08:05:15	verne.freenode.net:	Users on #bitcoin-wizards: gnusha nsh triazo jonasschnelli CryptoGoon berndj leakypat pollux-bts platinuum Oizopower jbenet dasource btcdrak tucenaber kyuupichan helo Taek Madars iddo GreenIsMyPepper amiller epscy adams__ wiz michagogo mikolalysenko artifexd lmacken yrashk cfields Krellan coryfields Meeh catlasshrugged Alanius null_radix kanzure bliljerk_ azariah warptangent sparetire davout comboy TD-Linux yorick crescend1 veox mm_1 Zouppen huseby _whitelogger wumpus
08:05:15	verne.freenode.net:	Users on #bitcoin-wizards: binaryatrocity heath BananaLotus maaku [d__d] optimator Eliel narwh4l mr_burdell throughnothing_ elastoma fluffypony Fistful_of_Coins yoleaux Jaamg xabbix mariorz catcow a5m0 smooth dignork runeks Sqt poggy livegnik petertodd richardus nephyrin phedny so BrainOverfl0w @ChanServ gwillen kinlo sl01 STRML espes AdrianG Anduck BlueMatt midnightmagic otoburb kumavis starsoccer d9b4bef9 gribble jessepollak ryan-c indolering Graet jaromil sturles [ace]
08:05:15	verne.freenode.net:	Users on #bitcoin-wizards: merlincorey morcos CryptOprah s1w roasbeef eric sdaftuar Xzibit17 warren Muis forrestv nanotube ajweiss guruvan SwedFTP pigeons afdudley phantomcircuit
08:41:31	c0rw|zZz:	c0rw|zZz is now known as c0rw|away
09:29:10	Eliel:	yep, that 60% is calculated using current block reward (25 BTC) and assuming the exchange rate is 1000000 USD/BTC :P
09:30:53	Eliel:	(and assuming 50% of the block reward ends up being used for electricity)
09:35:54	Taek:	TIL we spend $72m / hr on electricity. I guess that's a lot.
09:38:32	Taek:	actually that's a gross simplification of how things work. Also I forgot to divide by 2
09:49:35	nsh:	heavy electricity should be counted separately to regular electricity tbh
11:37:28	Eliel:	regarding this bc.i randomness fail. Would it generate acceptable randomness to use the camera, then sha256 the raw image data and use that for private key or random seed?
11:40:33	jonasschnelli:	Eliel: why not. But adding some accelerometer "true" randomness is probably more straight forward and end user friendlier.
11:41:23	Eliel:	ah, true, accelerometer data has quite a bit of noise in it too.
11:41:24	wumpus:	do be aware the all kinds of devices can pretend to be there, but not actually send true data. At least you should combine it with OS entropy (eg /dev/random).
11:42:42	jonasschnelli:	Agree with wumpus: only extend the system provided (/dev/random) entropy and not replace it.
11:42:54	STRML:	Try haveged if you're feeling brave
11:44:42	Eliel:	wumpus: that's a good point. Would need to verify there's entropy available somehow before using.
11:45:22	wumpus:	and that's not really possible to verify; the CCD chip could be sending you random-looking test patterns
11:51:34	hearn:	Eliel: it should be unnecessary
11:51:52	hearn:	Eliel: remember that if the OS is doing its job correctly *all* sensor data is fed into the entropy pool
11:52:19	hearn:	Eliel: also good luck explaining to users why you want them to take a photo of anything at all :)
11:57:15	Eliel:	does an app with rights to use the camera need the user to knowingly take a picture for the picture to be taken?
11:57:29	nsh:	(no)
11:57:38	nsh:	(but the inside of one pocket looks a lot like another)
11:58:16	nsh:	how many GPS sats is the average phone connected to at once?
11:58:17	hearn:	the user will be looking at the screen at the moment the photo is taken anyway
11:58:30	hearn:	nsh: average phone? zero :) bear in mind lots of users will be indoors
11:58:32	nsh:	that's a lot of pretty casually-independent fine-grained timers with other jitter
11:58:36	nsh:	good point
11:58:42	hearn:	anyway, like i said, the hardware drivers are meant to feed data into the entropy pool anyway
11:58:46	nsh:	* nsh nods
11:58:53	hearn:	without a doubt, some phones have some drivers that ignore some entropy and don't do that
11:58:54	wumpus:	Eliel: the user will hear the photo-sound
11:59:09	hearn:	a survey of how badly phone kernel developers screw this up would be an interesting academic exercise
12:00:00	jonasschnelli:	Ha. Right. That's why it would be probably a good idea to force add some accelerometer data to the entropy.
12:00:18	Eliel:	nsh: I don't expect good entropy from the picture. I expect good entropy from the noise :P
12:00:47	jonasschnelli:	i remember the last android RNG flaw we had.
12:01:11	nsh:	* nsh nds
12:01:58	STRML:	has anyone run haveged on android?
12:02:04	Eliel:	there's millions of pixels sampled with the worst of the cameras. Would take pretty darn good camera to not manage to get 256 bits of entropy in there :)
12:03:55	jonasschnelli:	Eliel: i kinda like the idea with the camera. It proved independence from the system RNG. If i would use a smartphone wallet, i would use a such feature during creation of a bip32 master seed.
12:03:58	wumpus:	but how random and independent is sensor noise?
12:05:36	jonasschnelli:	Imaging: "creating random seed" (then show some accelerometer movement and slowly build up a pixel-art with some sensor noise during loading of multiple camera pictures)
12:06:11	jonasschnelli:	(and it could truly be a marketing booster. :)
12:06:59	wumpus:	anyhow - feeding extra data into your entropy pool is never harmful (as long as you combine it in a sensible way, there have been mistakes with that too), but don't rely on it, and always combine in OS's cryptographic randomness as well
12:07:07	Eliel:	wumpus: Well, if it was easy to predict, I'd expect we'd have noiseless cameras by now.
12:10:24	wumpus:	Eliel: it may be too expensive to predict on the hardware itself, but still possible to reduce entropy by analysing the specific camera's noise profile (e.g. by looking at other photo's of the user)
12:10:28	nsh:	wumpus, adding extra data never harmful is disproved iirc constructively by djb or someone
12:10:49	nsh:	(if you know the details of the mixing/whitening then you can add harmful data)
12:10:57	wumpus:	nsh: if you combine it in a sensible way, e.g. hash it together with sha256 I don't see how it can be harmful
12:11:00	sl01:	http://blog.cr.yp.to/20140205-entropy.html
12:11:20	nsh:	it may be contingent on suboptimal mixing
12:11:27	wumpus:	nsh: (that's why I said combine it in a sensible way, if your combination algorithm can be exploited, sure...)
12:11:41	nsh:	* nsh nods
12:12:04	sl01:	it depends on the evil random source knowing the other randomness, then brute forcing a certain output (in the case of hashing)
12:12:19	Eliel:	wumpus: that's why I'm not trying to get more than 256 bits of entropy out of it, even though I believe there's enough in a picture for a few hundred kilobytes of random.
12:12:25	wumpus:	sl01: yes, the random sources need to be as independent as possible
12:12:53	wumpus:	if they can 'collude' in some way, no amount of mixing will save you
12:16:21	Eliel:	many years ago, I tested recording microphone channel from the soundcard (without a microphone connected), took only the least significant bit of each byte and then fed the data to an open source tool designed to analyze the quality of randomness. It passed all tests no problems.
12:16:48	sl01:	just read the blockchain issue, that's so lol
12:16:49	nsh:	(also, collusion can be coerced by external influence / entrainment. cf.
12:16:59	nsh:	.wik injection locking
12:17:00	yoleaux:	"Injection locking and injection pulling are the frequency effects that can occur when a harmonic oscillator is disturbed by a second oscillator operating at a nearby frequency." — http://en.wikipedia.org/wiki/Injection_locking
12:17:00	nsh:	)
12:17:07	STRML:	unfortunately there isn't a good way to know if random data that passes the tests is unpredictable or not
12:17:44	STRML:	best you can hope for IMO is to mix a lot of good sources together and hope nobody has the means or the motivation to untangle it
12:19:58	wumpus:	Eliel: another thing to consider: could another application take a photo at exactly the same moment?
12:22:07	Eliel:	wumpus: Wouldn't that mean you're already compromised?
12:23:58	sl01:	why not just host their own randomness web service and sign randomness with a predistributed key
12:24:14	sl01:	seems better than "phone randomness hacks"
12:24:21	wumpus:	Eliel: well it depends on what you call compromised, many android users have milder and more serious forms of malware on their phone without knowing
12:25:15	wumpus:	Eliel: ... with different levels of access, e.g. maybe it could access the camera too, or the sd card, but not your application's private key store
12:25:48	wumpus:	sl01: that's creepily centralized
12:26:00	sl01:	better than random.org w/ no http header check
12:26:52	wumpus:	the server could even target people, e.g. have a if(userid=='crook') return 'predictabelentropy'
12:27:37	sl01:	obviously i mean itd still be mixed in as they do with random.org, just seems like thatd be a simple improvement to what they already had
12:28:15	wumpus:	well sure it's better than random.org than no http header check, but what isn't... :)
13:51:05	blackwraith:	blackwraith is now known as priidu
14:25:50	zooko`:	zooko` is now known as zooko
16:46:06	zz_lnovy:	zz_lnovy is now known as lnovy
16:58:56	jae:	jae is now known as Guest96492
17:31:13	lnovy:	lnovy is now known as zz_lnovy
18:17:12	wallet42:	wallet42 is now known as Guest75406
18:17:12	wallet421:	wallet421 is now known as wallet42
18:33:58	c0rw|away:	c0rw|away is now known as c0rw1n
18:46:54	GGuyZ_:	GGuyZ_ is now known as GGuyZ
18:57:22	jae:	jae is now known as Guest60456
19:06:09	wallet42:	wallet42 is now known as Guest98770
19:06:09	wallet421:	wallet421 is now known as wallet42
19:40:06	zz_lnovy:	zz_lnovy is now known as lnovy
19:49:15	lnovy:	lnovy is now known as zz_lnovy
21:55:02	zz_lnovy:	zz_lnovy is now known as lnovy
22:49:08	jae:	jae is now known as Guest95656
23:05:13	kyletorpey:	kyletorpey has left #bitcoin-wizards
23:44:32	c0rw1n:	c0rw1n is now known as c0rw|zZz
23:49:30	jae:	jae is now known as Guest8382