00:01:27	kanzure:	jaekwon: do you have a copy?
00:03:00	samson2:	samson2 is now known as samson
00:03:50	gmaxwell:	jaekwon: I think that being safe in the face of potential partitions requires a majority nodes agree already.
00:04:01	gmaxwell:	(in a classical consensus systems)
00:04:49	jaekwon:	classical meaning, nonauthenticated?
00:07:48	jaekwon:	i found that, in byzantine consensus papers, they have "plain" and "authenticated", where authenticated means signed with a public key cryptosystem.
00:08:36	jaekwon:	then, there's also "synchronous" and "asynchronous", with different levels of asynchrony.
00:08:54	nsh:	classical meaning pre-PoW, i would guess
00:09:03	jaekwon:	i think we're mostly interested in "asynchronous", because there is no guarantee on message delivery.
00:12:40	jaekwon:	so yeah, it's widely considered to be impossible to have asynchronous byzantine consensus (FLP impossibility). But that's only for completely deterministic nodes. In practice the impossibility proof is meaningless.
00:12:51	jaekwon:	http://brooker.co.za/blog/2014/01/12/ben-or.html
00:14:33	gmaxwell:	jaekwon: classical, meaning sync and non-anonymous. (I'm not sure what the plain / authenticated distinction is there; been a while since I was last reading consesnsus lit, but virtually all of it assumes the players are known in advance)
00:16:36	Guest95887:	Guest95887 is now known as roidster
00:29:32	rdymac-:	rdymac- is now known as rdymac
00:47:34	wallet421:	wallet421 is now known as wallet42
01:02:36	jaekwon:	gmaxwell: plain just means, without digital signatures. i figure it's because byzantine consensus algorithms were first considered before public key cryptography became widespread.
01:09:31	phantomcircuit:	nsh, Ripple(tm) is *vastly* more complicated than existing systems of issuing and transferring IOUs, it is however vastly simpler on the compliance front, because they are illegally operating as a securities broker, dealer, bank, and clearinghouse
01:10:00	nsh:	* nsh nods
01:10:12	phantomcircuit:	nsh, indeed as far as I can tell they have and are substantially violating every single major provision of the securities act
01:10:24	phantomcircuit:	which is impressive in a certain way
01:11:24	warren:	simpler is one way to put it
01:12:17	nsh:	heh heh
01:50:30	davispuhh:	davispuhh is now known as davispuh
03:31:36	emsid:	emsid is now known as hodor
03:33:09	hodor:	hodor is now known as emsid
07:00:19	luke-jr_:	luke-jr_ is now known as Luke-Jr
13:10:14	wallet42:	wallet42 is now known as Guest97085
13:10:15	wallet421:	wallet421 is now known as wallet42
13:40:55	andytoshi:	there was talk earlier about primecoin proof size -- they are not horrific, just a single number which is multiplied by the blockhash to find the prime chain
13:41:09	andytoshi:	that number is a varint tho so we'd have to look in the chain to see what they typically are
13:57:26	tromp_:	the prime i saw was 326 bits; how big is the blockhash?
13:58:18	tromp_:	if hash is 256 bits. then the multiplier is only 9 bytes
14:59:04	maaku:	I'm a little confused. how do you multiply two numbers to get a prime?
15:03:41	zooko:	* zooko laughs
15:05:21	Apocalyptic:	maaku, you multiply 1 with a prime, and you get a prime
15:06:23	Luke-Jr:	Apocalyptic: no, really? :P
15:06:46	zooko:	☺
15:06:58	zooko:	1 is a really strange number.
15:11:21	sipa:	you can also multiply -1 with a prime
15:12:03	Apocalyptic:	sipa, not sure negative numbers such that |p| is a prime are considered prime
15:12:13	Apocalyptic:	in fact i'm almost sure they are not
15:12:50	jtimon:	so does anybody think a private mode could be useful for bitcoin testing? Or should I just keep the private chains core out of bitcoind?
15:13:00	sipa:	Apocalyptic: they are
15:13:42	sipa:	Apocalyptic: a prime number is defined as one that cannot be factored, ignoring invertible elements (and in Z, {1,-1} are the invertible elements)
15:14:00	Apocalyptic:	not really
15:14:05	Apocalyptic:	"A prime number (or a prime) is a natural number greater than 1 that has no positive divisors other than 1 and itsel"
15:14:28	Apocalyptic:	that's how i saw it defined everywhere
15:14:53	sipa:	ah, prime number is stricter than prime element, ok :)
15:21:28	Luke-Jr:	jtimon: you mean testnet and regtest? :P
15:24:28	jtimon:	Luke-Jr I mean a -private mode for private chains in bitcoind, does it fit there for testing use cases or it belongs elsewhere? http://sourceforge.net/p/bitcoin/mailman/message/32238138/
15:25:05	Luke-Jr:	jtimon: sounds like a regtest feature
15:25:18	Snowleaksange:	Snowleaksange has left #bitcoin-wizards
15:25:42	jtimon:	yeah, the timedtest mode I have there extends regtest mode, just changes a couple of things
15:26:04	sipa:	-regtest already has such weird specific behavior
15:26:18	sipa:	i think it would be nice to separate those out to separate command line arguments
15:26:28	jtimon:	doesn't produce blocks on demand and produces them every x milliseconds
15:26:29	sipa:	and make -regtest just select a specific chain
15:27:00	Luke-Jr:	we should just rename regtest to "dogecoin" and ignore other namespaces
15:27:01	Luke-Jr:	<.<
15:28:08	jtimon:	mhmm, sipa so you would have blockondemand bool and blocktime int parameters and use regtest for both
15:28:54	jtimon:	what about the attack simulations in the private mode "the attacker only accepts blocks that he has signed himself"
15:28:57	jtimon:	?
15:29:37	jtimon:	that's defntely out of bitcoind, no?
15:29:58	sipa:	that can perfectly well be done outside, no?
15:30:51	jtimon:	yes, it would only make sense to do it on bitcoind if it's independtly useful for testing, that's what I'm asking about
15:31:01	jtimon:	is it useful enough for testing?
15:31:15	sipa:	i don't think so
15:31:38	sipa:	it's useful enough for testing whole-network behaviour, but that's not something bitcoind does (you need external simulations for that anyway)
15:32:15	sipa:	and the part about it that matters to bitcoind (convergence given particular blocks on the network), is tested using pulltester already
15:33:36	jtimon:	"it's useful enough for testing whole-network behaviour, but that's not something bitcoind does" it doesn't currently. Wouldn't it be a nice feature to add?
15:34:05	sipa:	my point is that bitcoind can't do that
15:34:17	sipa:	you need to simulate much more than what bitcoind does
15:34:38	sipa:	(network delays, for example)
15:35:08	tromp_:	maaku: you multiply to get the prime chain *origin* of the chain. the primes are origin*2^k +/- 1
15:35:26	jtimon:	so what's wrong with my simulation example? That you're not counting delays?
15:36:43	sipa:	i'll comment on your mail when i've read it in more details
15:36:46	jtimon:	I thought it could still be useful, maybe adding some optional simulated delays for transaction relay?
15:36:55	jtimon:	ok, sipa thanks
15:37:08	sipa:	(and i should stop commenting on things before reading them...)
15:55:53	zooko:	What's the name of that protocol for atomically swapping X Bitcoin for Y Litecoin without being vulnerable to betrayal in either direction?
15:56:05	zooko:	It is named after the inventor, who isn't amiller, although amiller then wrote it up.
16:12:37	jtimon:	zooko I know trading across chains (https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains) and coinswap, neither named after the author
16:44:42	nsh:	* nsh wonders if gmaxwell knows what zooko might be thinking of
17:45:13	adam_:	adam_ is now known as waxwing
18:02:02	Guest64460:	Guest64460 is now known as amiller
20:05:23	justanotheruser:	How will bitcoin scale to interplanetary use? Its impossible to have consensus without slower blocks if a planet is more than 10 light minutes away
20:05:57	Luke-Jr:	justanotheruser: yet another use for daughter-chains
20:06:24	Luke-Jr:	justanotheruser: we can hardfork the main blockchain to week blocks, and have daughter-chains for each planet
20:07:01	justanotheruser:	Luke-Jr: lsnt there a risk of miners 51%ing another planets blocks?
20:07:08	sipa:	justanotheruser: it's likely impossible already when it's 1 minute away
20:07:09	vetch:	justanotheruser: the limit is more than that really. anything more than a handful of seconds means that the remote planet can't have miners.
20:07:32	vetch:	can't have, illogical to have
20:07:58	vetch:	I doubt it's of concern really.
20:08:22	sipa:	just have separate chains for separate planets
20:08:35	sipa:	and do really-long-timeout cross chain trading
20:09:50	justanotheruser:	sipa: isnt there a risk of someminer merged mining on a planets chain? Its not profitable for them to process the planets tx because they're too slow to see them, but it might be profitable to just merged mine empty blocks
20:10:30	justanotheruser:	Perhaps the solution is for each planet to not have a merge mined chain,
20:11:42	Luke-Jr:	justanotheruser: or a slightly different PoW
20:12:05	Luke-Jr:	that would stop you from mixing different planets together, without breaking merged mining within the planet
20:12:29	justanotheruser:	What do you mean merged mine within the planet?
20:12:59	Luke-Jr:	presumably each planet would have numerous blockchains
20:13:02	sipa:	each planet has its set of merge-mined chains with one main chain
20:13:09	sipa:	but they are independent from those of other planets
20:13:49	justanotheruser:	Luke-Jr: oh, I agree.
20:14:35	justanotheruser:	I was thinking in terms of newly colonized planets, but in a scenario where we have big populations on each planet, there would be altchains
20:15:01	Luke-Jr:	I've taken to mother-chain/daughter-chain terminology.
20:15:20	Luke-Jr:	too many people are getting the idea you can move from "side-chain" to "side-chain" directly, and "side chain" has other reasonable uses :/
20:17:54	maaku:	Luke-Jr: well, I think if possible we still want to design something where arbitrary sidechain<-->sidechain pairing is possible
20:18:10	maaku:	but if we end up going with the hub-spoke model I suppose that is better terminology
20:18:41	maaku:	sipa: isn't it still the case that wherever has more hash rate can just overwrite the other planets chain (with delay, of course)?
20:18:43	Luke-Jr:	maaku: after thought, I can't see any obvious solution to side<->side transfers
20:18:58	sipa:	maaku: yes
20:19:21	sipa:	maaku: but consider that the other planet has little reason initially to try to work on the same chain
20:19:46	sipa:	so they may just decide to choose a different PoW function entirely
20:20:11	nsh_:	nsh_ is now known as nsh
20:20:20	Luke-Jr:	I'd just prefix the final PoW hash with 64 bytes to change the midstate :P
20:20:32	Luke-Jr:	and maybe hide the 64 bytes from Earth
20:21:23	maaku:	sipa: yes, but it is important to note that merged mining doesn't scale to significant astronomical distances
20:21:35	sipa:	indeed
20:21:44	maaku:	it's a very Earth-chauvinistic technology
20:22:30	maaku:	if anyone knows a solution to this, I'd be very interested. it's not as scifi an application as you might think
20:22:54	Luke-Jr:	maaku: encode spatial knowledge in the block?
20:23:02	Luke-Jr:	something only the other planet can observe in realtime
20:32:34	andytoshi:	mach's principle (no absolute reference frames) suggests that you can't single out planets like this by any purely physical mechanism, and probably you can't even have a "proof of distance travelled by a signal" which is immune to somebody just faking distance by shooting a signal into a system of mirrors
20:33:47	maaku:	andytoshi: yes you can fake distance, but you *can't* fake locality
20:34:12	maaku:	there may be some form of interactive construction which prevents overwrite-from-distant-nodes
20:34:28	andytoshi:	right, so you can get a system which works for earth men, but only on earth...but not one for earth men, but only on mars
20:34:38	maaku:	but how you do that without falling into a ripple-like centralized trust, i don't know
20:34:52	andytoshi:	maaku: yeah, that's what i was thinking, maybe there is some cryptographic material we can be assured only exists on mars
20:35:10	andytoshi:	say, there is part of the cosmic background radiation which mars sees before us
20:35:22	andytoshi:	we can verify it, since by the time any mars signal reaches us, we'll have seen that radiation too
20:35:51	petertodd:	andytoshi: it'll be easy if we find out that subatomic particle decay or something actually uses SHA256 as a PRNG
20:36:02	andytoshi:	petertodd: that would make me so happy
20:37:34	andytoshi:	and in seriousness i don't think it's too outlandish that there could exist a hash function built from QM. "unpredictable but reliably dependent on interactions with the environment" is basically what you want from a hash function
20:38:19	maaku:	andytoshi: hrm. isn't that assuming a hidden variable theory?
20:38:27	petertodd:	yeah, and something like oh-my-god particles are so high energy it's inconceivable that they could be created by your adversary
20:38:40	petertodd:	(if they are... crypto is the least of your worries)
20:38:56	andytoshi:	maaku: i don't think so, i think you can extract such a construction just from decoherence
20:39:13	andytoshi:	the problem is that it's not publically verifiable
20:39:19	maaku:	andytoshi: but it wouldn't be deterministic, right?
20:40:23	gmaxwell:	andytoshi: all these things need a "blind fuzzy extractor". Where you and I can recieve some random bits where some are maliciously corrupted (thus the same between us), and with some high probablity we can both extract the same (shorter) string, for useful parmeters of input size, output size, and corrupt bits... I don't know if these can exist.
20:40:38	andytoshi:	maaku: i'm not assuming an interpretation but this is easier to describe in terms of everett branches....in a typical observation of an electron spin say there'll be two branches "electron up and we perceive the electron up" and "electron down and we perceive the electron down" and the correlation between the two is deterministic even if the actual observation is not
20:41:14	andytoshi:	gmaxwell: i think in the strong physical sense i want, it can't
20:41:33	gmaxwell:	They exist if the random bits are specially prepared or if there is additional 'ground truth' based side information. (both just differnt takes on using error correcting codes).
20:41:56	gmaxwell:	so perhaps there is some QM property that can get you a useful specially prepared state.
20:41:57	andytoshi:	maaku: so people in every branch will see a different "hash" but they'll all agree, and the branches can't ever communicate so this is just a philosophical problem
20:42:20	andytoshi:	plus nobody can predict the hash, we actually get a random oracle from the born probabilites :)
20:42:59	andytoshi:	gmaxwell: i think the no-cloning theorem prevents you from getting a specially prepared, and verifiable, state
20:43:25	andytoshi:	ie you can specially prepare a state for a bunch of particles and pass half to me, but i have to trust that you actually did so
20:43:54	gmaxwell:	andytoshi: right but what if there is some distant astronomical object that happens to be preparing the right state for physical reasons?
20:44:06	maaku:	andytoshi: that's basically what I meant - it'd be a random oracle in practice
20:45:16	andytoshi:	maaku: oh, i gotcha. yeah, in that sense it's not deterministic. but it's a weak enough non-determinism that we already assume (completely illicitly) it for 'random oracle' hashes today
20:46:15	andytoshi:	gmaxwell: i think that should be possible in principle. there would be gravity lensing attacks but those should be pretty easy to detect and nigh-impossible to do
20:46:58	andytoshi:	you want something like "all the light from this quasar has the same polarization, but we can't predict what it'll be in advance"
20:48:39	petertodd:	andytoshi: and even if not everyone has the equipment to make the observations, it is still valuable by letting multiple completely independent trusted parties do them
20:49:49	gmaxwell:	yea observing quasars is kinda annoying, otherwise it would be fun to use them as the oscillator source for my decenteralized time proposal. :P
20:50:18	gmaxwell:	back to more pratical matters, Does anyone think people would mind bitcoin implementations using the audio device at startup to get extra randomness? or would they sketch out if they realize bitcoin was recoding their microphone for a second or two?
20:50:47	petertodd:	gmaxwell: probably not if you were upfront about it
20:50:55	andytoshi:	can you record with the mic on mute?
20:50:58	gmaxwell:	sure
20:51:01	andytoshi:	and get some sort of dac noise?
20:51:07	andytoshi:	adc noise*
20:51:15	gmaxwell:	some usb mics do digial muting, which is lame but oh well.
20:51:33	warren:	why not use the webcam? =)
20:51:44	gmaxwell:	audio device may be the best widely available portable source of non-OS entropy on systems it seems.
20:52:01	gmaxwell:	warren: far less universally available (even server hardware now usually has an audio device!)
20:52:21	warren:	how many servers are not VM?
20:52:30	andytoshi:	i'd be fine with the mic, for a second or two, even if it was unmuted. not the webcam, what if somebody heartbleed'd my system at the right time and got a picture of me?
20:53:04	warren:	imagine the media reports on bitcoin "spying on users"
20:53:34	gmaxwell:	andytoshi: right two seconds of audio is almost certant to not contain anything interesting except lots of yummy noise.
20:53:44	petertodd:	Actually... the way to solve the problem is tell users to say something into the mic for more randomness.
20:53:54	maaku:	petertodd: +1
20:54:08	gmaxwell:	then you run into problems with the users trying to figure out if their mic is working (as if it mattered).
20:54:11	gmaxwell:	:P
20:54:42	petertodd:	gmaxwell: well given digital zero muting, that is valuable - have some little level display thing to be sure it's working
20:54:47	maaku:	well it would matter with digital mute
20:55:30	gmaxwell:	Hm. I don't know if the OS RNG should be distrusted to the point that would justify burdening the user like that.
20:56:53	petertodd:	meh, perfectly ok for seed generation, especially on a phone where the mic is definitely going to work
20:56:58	maaku:	well if nothing else you should tell the user that's what you're doing, when you do it
20:57:02	maaku:	so people like me don't freak out
20:57:38	gmaxwell:	Yea, sure telling people makes sense, it should be documented. Though it seems no one has ever noticed that bitcoin-qt captures the screen on windows. :)
20:58:11	maaku:	well there's not a little green light that turns on when you capture the screen (there should be though...)
20:58:21	petertodd:	That is invisible... and sergio was talking about it as a way to brute-force satoshi's identity!
20:58:33	gmaxwell:	(I've been pondering a bit what we should do about randomness if we make it possible to build Bitcoin core without openssl, plus the increased randomness criticality of BIP32 wallets)
20:59:40	sipa:	with BIP32 + deterministic signatures, there is only one point in time when the high randomness is required though
20:59:55	warren:	why is randomness from screenshot only on windows?
21:00:00	gmaxwell:	yes, but it's perhaps one of the harder points to have some— right at start.
21:00:17	gmaxwell:	warren: because making screenshots is not very portable and thats where openssl implements it.
21:00:23	gmaxwell:	IIRC
21:01:24	gmaxwell:	Thats a problem in general with alternative randomness inputs, they're arn't very portable.
21:01:24	sipa:	just ask the user: please type an uppercase letter, a number, a punctuation mark, a gang sign, an extinct mammal and a hieroglyph
21:01:51	gmaxwell:	display an inkblot and ask for their interperation of it.
21:01:56	sipa:	ha!
21:02:18	sipa:	/dev/rorschach
21:02:22	petertodd:	sipa: "Advanced users should videotape an expedition attempting to find an extinct mammel, and hash that video for extra entropy. WARNING: DO NOT UPLOAD EXPEDITION VIDEO TO YOUTUBE"
21:02:28	gmaxwell:	I still like the idea of implementing an arcade game as a randomness source.
21:02:36	sipa:	gmaxwell: oooh!
21:02:38	petertodd:	gmaxwell: +1
21:02:43	sipa:	we should add 2048
21:02:45	gmaxwell:	but thats GUI only. :)
21:02:54	gmaxwell:	oh 2048 would be cute.
21:02:54	petertodd:	gmaxwell: nah, you can do commandline 2048
21:03:02	petertodd:	or nethack...
21:03:20	gmaxwell:	and dogecoin could replace it with doge2048.
21:03:32	sipa:	and quarkcoin with lhc2048
21:04:11	petertodd:	sipa: speaking of http://jamesdonnelly.github.io/Isotopic256/
21:04:22	gmaxwell:	LHC2048 is a real thing. :)
21:05:04	sipa:	so is isotopic256 :)
21:05:08	warren:	Is haveged's approach not safe?
21:05:35	sipa:	offtopic: evil2048 is actually quite challenging (though i expect that it's more predictable too, so perhaps easier to cheat)
21:05:44	gmaxwell:	warren: its not very portable, it's also a ton of code.
21:06:08	sipa:	"Please get 2048 in this game to generate your new wallet."
21:06:40	sipa:	2048: "Do you want to create a wallet now, or try to get an extra secure 4096 wallet?"
21:07:01	gmaxwell:	(also there is really no evidence to believe that the havage data is really random to someone who knows the cpu design, but ... more data is good even if some is not perfect)
21:07:04	warren:	my intern was amused at having to move the mouse for 10 minutes to generate a GPG key
21:07:05	maaku:	* maaku expects a working working 2048 entropy source addition to bitaddress.org by the end of the day
21:07:12	warren:	by amused I mean annoyed
21:07:19	gmaxwell:	maaku: http://amscata.blogspot.com/2014/03/tile-2048-game.html
21:07:25	gmaxwell:	(QT implementation of 2048)
21:07:44	gmaxwell:	in any case, I assume from the game you'd take both move and timing data.
21:08:32	sipa:	now the real question: where do you get the randomness to feed to the 2048 block appearances?
21:08:41	sipa:	from the same entropy pool? :p
21:08:42	gmaxwell:	the OS, of course.
21:08:52	petertodd:	sipa: a simpler game of snakes of course
21:09:00	sipa:	ooooh
21:09:06	sipa:	so we really need flappy 2048?
21:09:12	petertodd:	YES!
21:10:46	gmaxwell:	yea, one of the downsides of 2048 is that it won't result in much data quickly... probably only 1.5 bits per move or so.
21:11:11	gmaxwell:	less if the player is skilled.
21:11:12	sipa:	then again, you need probably ~1000 moves to get 2048 :)
21:11:26	sipa:	i think the timing data is more useful
21:11:37	sipa:	if you have microsecond precision measurement
21:11:55	gmaxwell:	well I'm assuming the timing data there too, but probably being pessimistic about clock precision.
21:12:09	gmaxwell:	(as the OS will end up quantizing event delivery and such)
21:13:18	gmaxwell:	I think you only get a fraction of a bit from the move itself, there is almost never more than one bit from the move assuming a player that has any clue what they're doing.
21:15:02	vetch:	gmaxwell: isn't 2048 pretty much deterministic, controlled by the seed prng?
21:15:13	vetch:	there's not that many possible moves, and not many sane ones.
21:15:17	nsh:	i would guess that games with convergent attractors (maximise points) are a poor source of entropy
21:15:22	nsh:	in general
21:15:38	gmaxwell:	vetch: as I said you only get a fraction of a bit from each move, but you get more from the timing data.
21:15:39	petertodd:	nsh: right, so instead do SimCity
21:15:45	nsh:	* nsh nods
21:16:20	gmaxwell:	really the point is to get the timing data, the moves are just a— why not. You'll feed it all to a urandom keyed hmac in any case.
21:16:36	sipa:	a flight simulator/racing game is probably more useful, if controller with a mouse
21:17:04	gmaxwell:	there should be 'block explorer' ... a nethack like dungeon explorer generated from blockchain data.
21:17:24	sipa:	petertodd: just made tin!
21:17:38	petertodd:	sipa: ?
21:17:39	andytoshi:	then there is an incentive for miners to generate blocks which correspond to dungeons with lots of forced moves
21:18:06	tromp_:	you are in a twisty little maze of transactions, all alike
21:18:09	vetch:	bitaddress.org asks people to "move their mouse" which I'm fairly sure has quite a small amount of entropy. I toyed with the idea of making a similar site just to monitor what people did.
21:18:27	sipa:	petertodd: isotopic 2048
21:18:34	petertodd:	sipa: lol
21:18:41	vetch:	gmaxwell: there was a post on HN about using the bitcoin blockchain as a source of entropy. almost put my palm through my head.
21:18:44	gmaxwell:	vetch: yea, the mouse data is terrible no doubt esp without any real motivation to actually do it.
21:18:57	gmaxwell:	'I don't think that word means what you think it means.'
21:19:14	petertodd:	gmaxwell: a useful experiment would be to put bitcoins in wallets made with especially insecure mouse input
21:19:18	gmaxwell:	'Wallet generated from NIST random beacon, provably random.'
21:19:52	warren:	Randomness from Reddit
21:20:03	vetch:	petertodd: well, the all and mostly null bip32 seeds Carbon Wallet used weren't ever noticed until people started getting collisions.
21:20:45	gmaxwell:	in any case the whole point of the thought excercise is that in the awful event of a total OS rng break (probably on some fringe OS we hope) the result is almsot no one losing their money instead of many... its important to not overdesign too much or you introduce weaknesses from software bugs with higher probablity than an operating system failure.
21:21:15	vetch:	(people added their own words not in the dictionary, the functions parsing it returned false, most of the seeds people chose themselves were all or mostly 0 as a result)
21:21:31	petertodd:	vetch: damn!
21:22:04	vetch:	yeah. danger of letting people pick their own seeds.
21:22:22	sipa:	this is worse
21:22:36	sipa:	as it was apparently designed to not support people choosing their own seeds
21:22:40	sipa:	but it appearing as if they could
21:23:13	Apocalyptic:	mindblowing
21:24:12	vetch:	sipa: to be fair, the instructions had something about a wallet being "12 random words", rather than being from a small subset of the dictionary. it's a massive flaw and a code oversight, but the users weren't to know.
21:25:17	gmaxwell:	I seem to recall that electrum had a similar bug, though not a fatal form, but it instead just became a feature. It had a decode function for its nicely encoded random seeds, but it just failed to call it and instead ended up hashing the string instead of the decoded value.
21:25:36	vetch:	oh man.
21:25:48	sipa:	And thus Brainwallets were born.
21:26:19	gmaxwell:	electrum ui does (did?) actually constrain you to the dictionary, but its big so it's not hard to brainwallet it.
21:28:07	vetch:	you really don't want your users picking seeds. people will turn then into phrases and suddenly you've made markov chain wallets.
21:28:25	vetch:	markov chain vulnerable wallets rather.
21:28:55	gmaxwell:	yes, this is why I favor encodings of 'checksummed' values for mnenomnics. :(
21:31:21	warren:	petertodd: mouse input is insecure?
21:31:35	petertodd:	warren: if it's not random it is
21:31:59	vetch:	if you ask a user to "shake the mouse" that's what they'll do.
21:32:32	gmaxwell:	vetch: maybe. I'm pretty sure I've never done that. :) but even if they do you will not extract many bits from it.
21:33:20	vetch:	gmaxwell: there's variants of bitaddress.org that use that method as the only source of entropy.
21:33:30	gmaxwell:	* gmaxwell cries
21:34:51	vetch:	it's interesting how the developers do everything to make bitcoin super secure and as private as possible, and you have popular groups like blockchain.info undoing it.
21:35:17	warren:	bitcoin.com now points at blcokchain wallet
21:35:25	gmaxwell:	it has for a long time.
21:35:25	vetch:	even if it's against The Greater Good, blockchain.info will keep trying to make themselves the center of attention.
21:35:26	petertodd:	vetch: such is life
21:35:29	gmaxwell:	oh bitcoin.com
21:35:49	gmaxwell:	vetch: there is some credience to the view that things won't get fixed unless attacked in any case.
21:36:14	gmaxwell:	It's f@#$@ annoying and it messes up priorities, but sometimes its what it takes.
21:36:17	vetch:	did anybody else read the "masting Bitcoin" book? every page is an advertisement for blockchain.info.
21:36:45	gmaxwell:	I'm glad that I won't again have to talk people out of trying to TLS the P2P protocol in bitcoin for another year or two... :P
21:36:50	vetch:	the first chapter is basically "making a blockchain.info web wallet"
21:37:23	warren:	I would be less afraid of blockchain.info wallet if you controlled when to update it
21:37:46	warren:	oh, and it was totally broken yesterday due to cloudflare
21:38:08	gmaxwell:	virtually all large bitcoin sites are behind cloudflare, its such a joke.
21:38:40	vetch:	warren: broken by their "DDoS" protection?
21:39:24	petertodd:	vetch: the point of DDoS protection is so that you have control of who you are DoS'd by, not whether you go down...
21:39:27	warren:	vetch: yes
21:39:56	warren:	vetch: disrupted access to API
21:40:26	vetch:	if anybody else was interested in mastering bitcoin, theres a fee champrers of the book avaliable. https://github.com/aantonop/bitcoinbook
21:40:34	vetch:	**few chapters
21:40:41	sipa:	i hope nobody here needs that
21:41:06	gmaxwell:	Well I personally have no idea about creating a blockchain.info wallet. :P
21:41:19	sipa:	same, tbh
21:41:56	sipa:	i've had two online bitcoin wallets before, but they didn't end very well
21:42:01	sipa:	mybitcoin and mtgox...
21:42:37	vetch:	ouch.
21:45:05	vetch:	it's mildly annoying that the book refers to addresses in the sense that blockchain.info uses them. singular and static.
21:45:30	gmaxwell:	::sigh::
21:45:35	nsh:	'mildly annoying'...
21:45:46	nsh:	i would not publish a book about bitcoin that misleads readers on such a fundamental point
21:45:53	vetch:	it sort of follows a lot of the common misconceptions, like addresses being stored in the blockchain and addresses having balances.
21:46:35	gmaxwell:	so you guys should write a review at least. So that when the book gets invoked to bludgeon people who are saying the right things there will at least be something to point people to.
21:47:10	gmaxwell:	oh .. hey, I just bought an ibm cryptocard sort of by accident.
21:47:25	vetch:	how do you accidentally buy something?
21:47:57	gmaxwell:	well whenever they show up on ebay with make an offer I put in a crazy low ball offer.
21:48:06	gmaxwell:	I've been doing this for eons and someone finally took one.
21:48:36	gmaxwell:	damn now I'll have to figure out how to get the devel kit for it.
21:49:50	vetch:	even better is people listing things without knowing what they are. I got a FLIR camera for a few dollars through that.
21:50:18	vetch:	is the development kit hardware or software?
21:50:23	gmaxwell:	software.
21:50:40	gmaxwell:	yea, I've hoped for that but it hasn't happened yet, the problem is that people who are clueless about what they are probably toss them. :(
21:50:53	gmaxwell:	(or mishandle them, which is just as bad)
21:52:05	vetch:	bet somewhere there's a skip full of them in perfect condition.
21:57:04	gmaxwell:	yea probably. New they cost about $15k. But like a lot of enterprise hardware they don't really have a secondary market.
21:57:35	andytoshi:	wtf 2nd paragraph of andreas' book he's claiming bitcoin uses encryption. also by the end of the intro it sounds like he is very confused about concepts like 'algorithm' or 'protocol', i don't know where to start writing a review of this
21:58:37	Apocalyptic:	andytoshi, it would be best if you ignored the book I think
21:59:03	Apocalyptic:	clearly not worth your time
21:59:12	andytoshi:	probably not. we'll see how often its claims show up on #bitcoin
22:00:27	vetch:	the issue is that the guy is a bitcoin "hero", yet can't explain that blocks don't happen every 10 minutes.
22:01:05	sipa:	sigh
22:01:45	andytoshi:	vetch: you should read, e.g. anything by dan dennett or eli yudkowsky on steven jay gould, who is the andreas of evolutionary biology. just to know we aren't alone :)
22:02:35	sipa:	isn't this guy in charge if security at b.i now or something?
22:02:39	sipa:	*of
22:02:39	Apocalyptic:	he is sipa
22:02:45	sipa:	?!
22:03:08	gmaxwell:	I hope he's not sipa!
22:03:10	vetch:	sipa: yes. he also published a recovery seed for his example wallet with only three of the words blurred out.
22:03:20	Apocalyptic:	ok,"he is , sipa"
22:03:37	Apocalyptic:	I hope he's not sipa! // kinda hope that too
22:04:08	cbeams:	Given Andreas' visibility, I imagine the book will be widely read (and regarded as authoritative). Thorough reviews and feedback certainly seem worthwhile with that in mind.
22:05:10	vetch:	gmaxwell: he is.
22:05:21	gmaxwell:	Do be kind enough to realize that the book is no doubt written for a not-very-technical audience (by our standards); that doesn't excuse being outright incorrect or giving dangerous advice, but I hope folks here will write reviews but also that they're not mired in pedantry. :)
22:05:58	sipa:	vetch: was it cracked already?
22:08:50	vetch:	andytoshi: sounds similar. hero without justification.
22:10:09	sipa:	being able to speak passionately about a topic is a gift :)
22:10:34	sipa:	unfortunately, it doesn't seem to correlate well with actually understanding the topic
22:10:51	nsh_:	* nsh_ smiles
22:11:01	nsh_:	nsh_ is now known as nsh
22:11:55	andytoshi:	vetch: right, and also responsible for creating a public idea of evolutionary theory which was completely unhinged from the actual scientific understanding, which has caused all sorts of weird PR and political problems. both bitcoin and evolution require paradigm shifts about the physicality of information, and sjg/andreas worked to make this shift extremely difficult through their confused
22:11:57	andytoshi:	popular-level writing. the analogy is very strong actually
22:12:53	nsh:	then it will outcompete other analogies for vital memetic resources...
22:13:11	nsh:	and be immortalized in the grokchain
22:13:13	nsh:	okay, i'll stop
22:13:57	andytoshi:	and refuting both involves, in a lot of cases, pedantry :(. andreas' book talks a lot about from addresses for example, and imo that's a very subtly incoherent concept
22:14:07	vetch:	"In bitcoin, addresses begin with the digit 1."
22:15:40	vetch:	andytoshi: it mixes low level concepts like deep EC math with a guide on how to clone repos (with cut and paste examples). I'm baffled as to who this is written for.
22:16:29	Apocalyptic:	vetch, given your last comment it indeed doesn't seem quite clear
22:16:41	Apocalyptic:	"confused" is the word that keeps coming to mind
22:17:34	andytoshi:	also, ch 3 is about the bitcoind RPC interface, and uses the word 'account' many times without ever defining it… i'm no longer worried. i bet we'll get a lot of people asking questions about this, but nobody will read this book and believe that they've learned something
22:18:32	Apocalyptic:	RPC accounts, from addresses, it seems to have it all
22:22:08	cbeams:	vetch: http://my.safaribooksonline.com/book/current-affairs/9781491902639/preface/_intended_audience_html
22:23:05	vetch:	amazing.
22:36:39	airbreather_1:	airbreather_1 is now known as airbreather
22:37:06	maaku:	* maaku needs to get off his butt and write the Bitcoin Wizardry book
22:38:06	nsh:	+1
22:40:02	Luke-Jr:	maaku: nah, you're doing more important things. andytoshi is just messing around with uni, he has time to spend writing things :P
22:42:53	andytoshi:	shhh!, i asure you i'm diligently earning every one of my taxpayer cents
23:07:59	andytoshi:	i also would like to see a book by maaku tho
23:08:23	warren:	http://opensslrampage.org/
23:15:49	vetch:	warren: I liked the one where RSA private keys were pushed to the entropy pool.
23:47:24	zzyzx:	zzyzx is now known as roidster
23:47:54	roidster:	roidster is now known as Guest89342