00:27:27	qwertyoruiop_:	qwertyoruiop_ is now known as qwertyoruiop
00:28:51	maaku:	andytoshi: can you explain?
00:44:27	tt_away:	andytoshi: are you asking if you can you solve the two general's problem in the same way Bitcoin does using zkps for total obfuscation of tx inputs/outputs and instead using miner verification of zkps?
00:45:03	tt_away:	because that's what the zerocash alpha is supposed to be doing in may i guess
00:46:32	tt_away:	Green presented on how the system is supposed to work here: https://www.youtube.com/watch?v=Uh6erfE9HYE
00:47:29	tt_away:	The only thing I don't totally understand about that is how the new accumulator works
00:47:50	tt_away:	(well, and all the SNARK black magic)
00:49:53	HobGoblin:	HobGoblin is now known as Guest36983
00:49:56	tt_away:	I wonder if he'll publish the paper around the same time as the implementation
00:51:36	jarpiain:	jarpiain is now known as Guest13025
00:51:56	tt_away:	It's scary to me too because it's implementing something so new to the cryptography field -- I guess we'll see whether it sinks or swims. Alt chains are a good field for testing the stability/security of signature schemes and hash functions.
00:52:53	tt_away:	I mean, we once thought SHA1 was pretty secure. :P
00:58:38	kinlo_:	kinlo_ is now known as kinlo
01:00:05	OneFixt_:	OneFixt_ is now known as OneFixt
01:54:09	Fistful_1f_Coins:	Fistful_1f_Coins is now known as Fistful_of_Coins
02:32:58	hno`:	hno` is now known as hno
03:05:35	justanotheruser:	justanotheruser is now known as just[dead]
03:38:24	just[dead]:	just[dead] is now known as justanotheruser
04:35:18	justanotheruser:	If I made a quantum computer and mined 2014 blocks and they all had the same timestamp, would difficulty be infinity (or as high as it can be)?
04:51:41	Luke-Jr:	justanotheruser: no, the blocks would be invalid
04:51:48	Luke-Jr:	at least the majority of them
05:09:04	justanotheruser:	Isn't the allowed timestamp of a block based on the average of previous blocks Luke-Jr
05:09:21	Luke-Jr:	justanotheruser: it's GREATER THAN, not GREATER-OR-EQUAL
05:09:37	Luke-Jr:	so, after like 6 blocks, you MUST increment
05:11:02	tt_away:	also diff increases are capped at 400%
05:11:08	justanotheruser:	Luke-Jr: I see.
05:11:31	justanotheruser:	tt_away: oh really? So that's why quantum computers would take forever to increase diff
05:11:46	justanotheruser:	at least to the point that it takes 2 weeks
05:11:50	gmaxwell:	4x still gives you quartic convergence.
05:12:02	tt_away:	quantum computers don't crack sha256 i thought too, but ecdsa, unless i'm mistaken
05:12:22	gmaxwell:	quantum computers don't crack anything at all yet.
05:12:41	gmaxwell:	Though if you had a sutably large one it could potentially be used in an adventagious manner for mining.
05:12:47	gmaxwell:	perhaps.
05:13:05	gmaxwell:	you'd have to compare the throughput slowness to the fact that it has to do sqrt() the amount of operations.
05:13:20	tt_away:	sha256 has a weakness solvable with shore's algorithm? or is it something else?
05:13:51	gmaxwell:	has nothing to do with shors algorithim.
05:13:56	tt_away:	shors sorry
05:14:21	gmaxwell:	In theory QC gives you a tightly bounded sqrt() speedup on _all_ non-linear search.
05:14:22	tt_away:	derp, yeah, that's rsa
05:14:33	gmaxwell:	(via grovers algorithim)
05:14:57	tt_away:	oh, neat.
05:15:14	gmaxwell:	though, it requires your function be implemented as a special grover-oracle, and converting your problem to that has polynomial overhead.
05:15:55	gmaxwell:	and of course any QC that comes into existance will likely be much slower (ops/sec, ops in parallel) than classical computers built using compariable technology and cost... so unclear that it would ever be interesting for mining.
05:53:12	maaku:	or anything
05:54:36	gmaxwell:	indeed.
05:55:36	gmaxwell:	I certantly hope they are. There are important problems that QCs would make far more tractable which would contribute materially to our species odds of long term survival.
07:07:32	Guest13025:	Guest13025 is now known as jarpiain
07:31:42	area_:	area_ is now known as area
10:00:19	justanotheruser:	justanotheruser is now known as just[dead]
10:05:48	Guest36983:	Guest36983 is now known as UukGoblin
14:28:03	helo_:	helo_ is now known as helo
14:44:13	andytoshi:	maaku, tt_away: my earlier question was, "how can the p2p network function securely for a snarkchain?" it's nice to get txes out of the blockchain but if they have to be broadcast in order that miners see them, then an adversary can still record every one.
14:48:34	stonecoldpat:	what is a snarkchain? out of interest
14:48:57	stonecoldpat:	as snarks reminds me half-life
14:50:44	andytoshi:	stonecoldpat: an alt in which blocks were zero-knowledge proofs of chainstate diffs, rather than giant lists of transactions that everybody has to evaluate and verify
14:51:36	andytoshi:	zk-snark == zero-knowledge succinct noninteractive argument for knowledge, that is an efficient zero-knowledge proof which can be written down
14:53:44	gmaxwell:	andytoshi: because you could give transactions just to a couple single miners.
14:53:53	gmaxwell:	they don't have to be broadcast.
14:54:39	gmaxwell:	you could even do something wacky like write 20 versions of a transaction, all conflicting each other, each paying to a different output. give each miner a different one.. you're happy so long as any one of them makes it in.
14:54:50	gmaxwell:	all miners but the successful one don't learn the input-output mapping.
14:58:30	stonecoldpat:	i suppose the miner becomes a trusted party then? he essentially obsecures the transfer and based on some proof of work - tells people about a change that cannot be linked ?
14:58:39	andytoshi:	stonecoldpat: no!
14:59:13	andytoshi:	gmaxwell: oh, that's clever. my original concern was that anyone can claim to be a miner -- but if every miner receives a different output mapping this does not help them at all
15:01:50	gmaxwell:	andytoshi: yea, thats why they pay me the big bucks. ... I still have no clue if it's really remotely pratical. It's interesting to consider.
15:03:09	andytoshi:	one 'practical' idea is to have a miner directory like tor's hidden-service directory, and connect to miners in the same way.
15:03:29	andytoshi:	but this (a) means the directory is a single point of failure and (b) is susceptible to sybil attacks
15:03:42	jtimon:	I guess you could have an hybrid system with both public and blinded txs, with fees buing paid with public funds so miners can see them
15:04:12	andytoshi:	perhaps the miners could put their HS address in their actual blocks instead, that wouldh solve both problems
15:04:44	jtimon:	well, this snark approach is different but that's what I had in mind for "blinded tx" proposals
15:05:21	andytoshi:	jtimon: ah, ok. with snarks i think the person mining the tx has to see it, period. (i could be wrong about this). then there is no problem since this person is the fee recipient
15:05:59	jtimon:	I think blinded -tx can be processed with snark too, no?
15:07:13	jtimon:	but, yes, if everything is snark, I guess miners can just pay the fees to themselves "explictly"
15:07:39	andytoshi:	i'm not sure exactly what you mean..you cannot blind the inputs because then nobody can verify your txes. and if you blind the outputs, you have to unblind them upon spending for the same reason
15:07:53	andytoshi:	so again your miner (at least) can see everything
15:08:36	jtimon:	adam3us calls them "committed transactions" I think, petertodd also posted an inputs-only chain proposal
15:09:13	jtimon:	but they didn't solved how miners got rewarded, that's why I thought an hybrid system is necessary
15:09:51	jtimon:	the outputs are transmitted off-chain directly between the parties involved
15:10:10	andytoshi:	ok, i see what you're sayng
15:10:12	jtimon:	and the chain only validates that the inputs are not repeated
15:10:41	jtimon:	adam had more complex approaches using crypto
15:11:37	jtimon:	another problem with that is the evergrowing set of spent inputs, which could "perish" after certain time
15:12:47	jtimon:	then you may need a mechanism to turn the blind coins back into public coins so that you can "restart" the blinded history
15:14:27	jtimon:	but I guess the main purpose of using snark is bandwidth and computing scalability rather than privacy
15:15:27	andytoshi:	yeah, gmaxwell had a neat high-level comment a while back about how you get privacy 'accidentally' by minimizing bandwidth
15:15:38	gmaxwell:	jtimon: this is mostly something different.
15:16:08	gmaxwell:	and yea, was mostly a thought expirement about the fundimental linkage between privacy and efficiency.
15:17:04	jtimon:	I see
15:17:15	comboy_:	comboy_ is now known as comboy
15:38:05	pigeons_:	pigeons_ is now known as pigeons
16:18:17	andytoshi:	a great easy-to-read article about program obfuscation: http://blog.cryptographyengineering.com/2014/02/cryptographic-obfuscation-and.html
16:40:01	gmaxwell:	andytoshi: indeed, a much better article than the wired one.
16:42:40	andytoshi:	the link i posted yesterday about punctured programs also has some cool applications of obfuscated programs. i'm still reading it..would be cool if there was some application there toward my public fhe problem
16:43:15	andytoshi:	also btw re ecdsa malleability, i can show that an adversary without a signing oracle (that is, he has access to only one sig) has no more 'simple' malleability. he needs to use all of (r, s, H(m)) in his malleability formula. also he can't leave r alone, he has to create a malleated sig (r', s') where r' != r --- but while learning nothing about his own k'
16:43:47	andytoshi:	this is far from the general result, but it makes me think that malleating ecdsa is probably impossible
16:44:39	gmaxwell:	I think I'd gotten as far before as showing r and s both had to change.
16:45:40	sipa:	5~that's not strong enough
16:46:07	sipa:	knowing that it would be impossible given only one signature would already be very interesting, i think
16:50:50	andytoshi:	what you can do against a single-sig malleator is give him a completely random (r,s). for any message H you can compute a public key for which this is a valid signature (though you don't get the private key ofc, and you can't make any more signatures with this key)
16:51:41	andytoshi:	i thought, maybe if i set r = X(g^k) i'd be able to trick the malleator into finding k and solving discrete log. but that doesn't seem to work
16:53:15	andytoshi:	the general problem here is that the owner of the private key can make as many malleated sigs as he wants, just by changing k. so any proof technique has to detect doing this without the privkey somehow. but ECDSA has no numbers which can be convincingly be replaced with random numbers so it's hard to express this lack of information
17:33:56	gmaxwell:	so people keep showing up in #bitcoin-dev saying that they want to build some thing that will handle people's money.
17:34:12	gmaxwell:	And then they ask really scarry questions which suggest that they are likely to lose all the aformentioned money.
17:34:50	gmaxwell:	If we respond to these people OH CRAP. DO NOT DO THIS! YOU ARE NOT PREPARED FOR THIS! ... won't that just make them stop asking?
17:36:11	andytoshi:	yeah, perhaps i can write a faq which gives correct answers which are designed to be completely overwhelming
17:36:34	andytoshi:	i worry that that would seem like we're condoning that behaviour, and ofc no faq can fix muddy thinking
17:38:53	Luke-Jr:	gmaxwell: more likely they ask someone less competent
17:39:09	gmaxwell:	right.
17:39:24	gmaxwell:	well worse, the kind of people who would even read the instructions are the half more likely to get things right.
17:39:30	gmaxwell:	So if the instructions say "go away!" ...
17:40:56	gmaxwell:	maybe there does need to be an EL5 explination about why this is much harder than most any other business you could be in... because mistakes are irreversable, because attackers actually exist (vs elsewhere where targeted attacks at 95% theory), because the legal liabilities are unclear, etc.
17:41:17	gmaxwell:	and then covers some best practices.
17:50:22	justanotheruser:	justanotheruser is now known as just[dead]
17:50:52	sipa:	that's the biggest lesson people need to learn from cryptocurrencies: handling real money requires a ton of measures, and it's one of the things banks have learned to do (pretty wel) for us
17:57:40	gmaxwell:	banks have an easier time. For example, two months ago coinbase double paid all their ACHs from a one or two day period.
17:57:48	gmaxwell:	Probably hundreds of thousands of dollars.
17:57:56	gmaxwell:	Two days latter.. poof gone, all fixed.
17:58:02	gmaxwell:	didn't even make a headline.
17:58:22	gmaxwell:	virtually everything banks do is reversible.
18:01:03	sipa:	at least they know (probably by learning the hard way) how to protect physically valuable things (gold, cash, ...) in vaults
18:01:39	gmaxwell:	Thats true.
18:07:53	gmaxwell:	andytoshi: I can't bare to read this, but you might want to http://imgur.com/a/DNeAI
18:08:15	eristisk:	I think protecting physical assets in meatspace is an incomparable profession to cybersecurity and preservation of purely digital assets.
18:08:54	eristisk:	More apt to bring up that modern banks are also protecting virtual USD and are already forced to be adept at cybersecurity.
18:12:42	andytoshi:	gmaxwell: omg "it can be potentially much easier to memorize than a random 256-bit number"
18:13:01	gmaxwell:	andytoshi: please, I don't want to know
18:13:44	andytoshi:	oh, sorry :) i'll say no more. except that whatever you fear, it's probably worse than that
18:14:51	gmaxwell:	It's always worse than you think, even when you take into account maxwells law.
18:30:42	maaku:	gmaxwell: did you see the top news item on HN?
18:31:49	helo:	such famous
18:32:03	maaku:	somehow your nick has become a household name it seems, at least among techy crowds
18:36:20	helo:	gmaxwell: awesome idea btw
18:40:13	helo:	where do we sign up to collectively boycott all bitcoin holding services that don't do this?
18:41:42	gmaxwell:	anyone have the log of that conversation up already?
18:41:49	gmaxwell:	that was ultimately from a conversation here.
18:42:11	gmaxwell:	petertodd: mind if I post the log from March 1st 2013?
18:42:42	just[dead]:	just[dead] is now known as justanotheruser
18:52:48	Luke-Jr:	helo: ?
18:56:30	antephialtic:	gmaxwell: you mean this (http://download.wpsoftware.net/bitcoin/wizards/2013/0%23bitcoin-wizards.log) starting from 20:13
19:12:37	andytoshi:	antephialtic: the article's content start and ends at 20:13 :P
20:01:27	midnightmagic:	gmaxwell: Hey man. The proof of non-insolvency doesn't work if MT knows someone with lots of coins, correct?
20:03:16	midnightmagic:	(or includes his personal coin stash in the totals)
20:33:55	maaku:	midnightmagic: that would be fraud
20:39:04	helo:	3rd party auditing would be pretty potent
20:42:46	maaku:	midnightmagic: by which I mean MT could lie about gox's balance sheet only by means of incontrovertible fraud/incompetence
20:43:53	maaku:	either case would be probably be suffient to pierce the corporate veil and take those funds through bankruptsy
20:56:49	gmaxwell:	midnightmagic: and then when the shit goes to court you go after those coins.
20:58:01	gmaxwell:	midnightmagic: nothing in that space can be air tight— they could prove they have the coins then send them all to a gambling site a moment later.
21:07:25	Luke-Jr:	maaku: would it be fraud, or would it make him liable for that moneys? ;)
21:08:42	sipa:	gmaxwell: which would make it mismanagement, rather than fraud
21:09:06	maaku:	Luke-Jr: it would be either criminal fraud or gross negligence, in either case it'd probably be sufficient to pierce the corporate veil, which would make him liable
21:09:15	maaku:	but, one big fat IANAL
21:10:57	midnightmagic:	gmaxwell: I was thinking about the things people are saying about your method and I'm worried that this "proof" word they keep throwing around is dangerous. "Hey where are my 10kbtc?" "Prove you had it!" "Okay screenshot!" "Wow I'm an uneducated user who's gambling with money I can't afford to lose and that's proof enough for me. I believe you, Sir!"
21:12:09	gmaxwell:	midnightmagic: But is that worse? Some of this is growing pains, we need to become more sophicated— if not every single adult, at least a critical mass that can sniff out problems and alert others.
21:12:33	gmaxwell:	If too often we shy away from improvements because they'll be misapplied we won't get a chance to learn.
21:13:14	gmaxwell:	I did a number of goxbtc buys two weeks ago and escrowed for a bunch more last week and people's security practices were uniformly awful.
21:13:39	midnightmagic:	No it's not worse at all.
21:13:44	gmaxwell:	E.g. almost no one waited for even a single confirm when they should have... they were surprised when I suggested they do so in the future.
21:14:16	midnightmagic:	But from MtGox's perspective, why should I supply a proof that people (trolls especially) can game?
21:14:38	gmaxwell:	A bunch of people wanted screenshots. I changed my balance to say "right click; inspect element; edit text".
21:15:04	midnightmagic:	lol
21:15:57	poggy:	haha gmaxwell
21:16:30	gmaxwell:	Well I don't care if MTGox does this, they already have enough problems— I think their competition should. Plus setting up this sort of thing encourages good hygiene. I would not be surprised if— if ubiquitiously deployed— this prevented a bunch of bad practies like sites going temporarily fractional. In fact, if it didn't uncover at least 10,000 BTC in fraud if ubiquitiously deployed I would eat my hat.
21:16:52	midnightmagic:	i get that mtgox in order to falsify stuff might perhaps have to guess who isn't going to actualy verify their balances, or find someone who has a big balance to join with his. I saw comboy advocating it on bitcoinity.
21:17:15	poggy:	gmaxwell presumably exchanges would just refuse to do it before publishing their fraud?
21:17:32	gmaxwell:	poggy: Which is why we shouldn't do business with ones who won't.
21:17:56	poggy:	sure, I just meant it might not actually expose anything
21:18:09	gmaxwell:	well I said ubiquitiously for a reason. :)
21:18:31	gmaxwell:	midnightmagic: of course, if mtgox did turn out to lose a lot of funds, a system like this would have detected it even when their own controls failed.
21:19:15	gmaxwell:	so basically having a system like this guarantees a minimum level of controls, and at least requires any misconduct to be outright criminal.
21:19:17	midnightmagic:	lots of cooperating users.
21:19:20	poggy:	It would mean exchanges would need more start up capital though
21:19:38	midnightmagic:	poggy: What? Why?
21:20:21	gmaxwell:	They shouldn't, unless you're cynically saying they're already engaging in fraud.
21:20:31	midnightmagic:	that's how i interpreted it too
21:20:38	poggy:	oh haha
21:20:39	poggy:	I guess
21:20:39	gmaxwell:	Besides, if they really did want to run fractional— this wouldn't prohibit that, it would just make them disclose it.
21:21:05	poggy:	Do the big exchanges explicitly say they don't run fractional?
21:21:19	gmaxwell:	MTGox's terms of service are very explicit about this.
21:21:26	midnightmagic:	There's no reason for them to.
21:21:32	midnightmagic:	Also it's evil.
21:21:41	poggy:	is it?
21:21:51	poggy:	if you haven't said you wouldn't?
21:22:05	midnightmagic:	Yes because finite supply.
21:22:30	midnightmagic:	Also user expectations. Bank runs on a non-bank, etc.
21:22:34	Luke-Jr:	midnightmagic: there is reason for them to, for the immoral masses who practice usury..
21:23:00	midnightmagic:	Luke-Jr: :-)
21:23:22	Luke-Jr:	if you practice usury, it makes sense to do fractional reserve as you loan out funds
21:23:34	gmaxwell:	In any case, I can't stomp out evil, but at least people should be explicit about it so a discussion could be had.
21:24:02	sipa:	i wonder whether a totally explicitly and transparently fractional exchange could work
21:24:24	Luke-Jr:	sipa: I don't see why not
21:24:26	sipa:	like, publish graphs of which percentage of coins they hold
21:24:45	Luke-Jr:	frankly, MtGox should have a ton of abandoned bitcoins that unidentifiable users deposited before the 2011 fiasco
21:25:17	jrmithdobbs:	i can't think of a reason it wouldn't ... other than the obvious one of self-interest preventing those who benefit from gaming the fractional mechanics from being found out
21:26:03	poggy:	wait gmaxwell were you buying into mtgox?
21:26:14	poggy:	(didn't catch that on first skim)
21:26:22	maaku:	"buying into"?
21:26:41	poggy:	buying mt gox bitcoins
21:28:46	poggy:	nvm I read back
21:29:14	poggy:	Unrelated: the other day you were talking about how the low power requirement of scrypt could be a weakness in certain circumstances (e.g. long term attacks). I was trying to remember if there was a way that it applied to blockchains as well. Is there?
21:33:01	gmaxwell:	poggy: I think the same argument probably applies.
21:33:38	gmaxwell:	hardware costs are amortized, power cost is not. amortization may benefit attackers.
21:34:15	gmaxwell:	also hardware designs for sha256 appear to be thermally limited, so lowering the power density may help achieve better hardware usage.
21:36:30	gmaxwell:	hard to say— requires careful analysis from a very low level to really know how these tradeoffs play out.
21:43:15	poggy:	thanks
21:54:59	tt_away:	tt_away is now known as tacotime_
21:55:44	tacotime_:	can you do P2SH with requirements for m of n signers && one of these signers is mandatory?
21:56:07	Luke-Jr:	tacotime_: yes
21:56:07	sipa:	with P2SH you can do anything
21:56:19	sipa:	whether the script you need for that is standard, is something else
21:56:45	tacotime_:	If it's non-standard, will the network still communicate this?
21:56:57	sipa:	no
21:57:04	sipa:	at least, most nodes won't
21:57:06	tacotime_:	Hm.
21:57:09	sipa:	but you can send it to a miner directly
21:57:13	sipa:	if they accept it
21:57:26	tacotime_:	Are there pools you can pay to do this?
21:58:35	tacotime_:	I'm not looking to mangle the blockchain, just to use it as an escrow with one member signing mandatory.
21:59:50	gmaxwell:	I'm pretty sure that eligius will mine these, or it would at least somewhat recently.
22:00:01	gmaxwell:	it could be enabled pretty easily.
22:00:12	tacotime_:	Okay, thanks.
22:00:51	gmaxwell:	There have been other people who wanted {A&&B} || ( (A||B) && 2-of-3 {C,D,E} ) which sounds kinda similar to what you want.
22:03:28	tacotime_:	Yeah. I'm trying to figure out how to safely protect people wanting to donate to development for my project and keep it help in the blockchain as escrow/bank. Ideally I want the blockchain as an escrow and m of n to spend, but I want the original donator to have to sign.
22:03:46	tacotime_:	So they can be assured that me and the other people on the project just can't run off with it.
22:04:30	tacotime_:	That seemed like the easiest way.
22:04:36	gmaxwell:	why not just do 2 of 2, you and the donor?
22:04:55	rastapopuloto:	rastapopuloto has left #bitcoin-wizards
22:05:08	tacotime_:	Well, that works in all cases except if I were to die and the rest of the people on the project wanted it to continue. Or if I lost the keys somehow.
22:05:15	tacotime_:	Just for fault tolerance, I guess.
22:05:30	gmaxwell:	tacotime_: so you can split up your private key N ways and give it to all the other project people.
22:05:49	jrmithdobbs:	so why not 2 of 2 with an out-of-band split of your share with the other project members?
22:05:49	tacotime_:	This is true.
22:06:05	jrmithdobbs:	still can't hit ^x fast enough to beat gmaxwell ;p
22:06:15	gmaxwell:	I used more words too.
22:06:34	tacotime_:	Right, yeah, I suppose that's functionally equivalent except when we want to require the input of multiple people.
22:06:50	tacotime_:	In that case we have only one member of my group required to spend.
22:06:51	jrmithdobbs:	no it's functionally equivilent in that case too
22:07:04	tacotime_:	Oh, right
22:07:15	tacotime_:	derp
22:07:30	tacotime_:	Yeah, and then I don't have to bother with non-standard scripts.
22:07:39	gmaxwell:	yea, or special signing software
22:07:41	jrmithdobbs:	anyone involved that should be able to single-handedly approve/sign just gets their own m shares, eg
22:17:50	tacotime_:	Alright, thanks guys :)
22:19:31	petertodd:	gmaxwell: go for it
22:35:45	poggy:	looks like this exchange idea is gaining traction
22:35:59	sipa:	which exchange idea?
22:36:39	poggy:	oh sorry the verifying funds one
22:38:32	gmaxwell:	poggy: where?
22:39:15	poggy:	r/bitcoin has a thread where a few people claim to have pestered some exchanges
22:40:28	poggy:	and https://bitcointalk.org/index.php?topic=22929.msg5286474#msg5286474
22:42:12	poggy:	(I didn't mean actual reaction from exchanges, sorry if that was unclear)
22:43:09	petertodd:	poggy: at the may conference I approached a bunch of exchanges/funds/etc. and they were all interested too, of course, they themselves never initiated any work along those lines...
22:44:14	gmaxwell:	if any of you want work implementing this stuff, I'll be happy to pass on recommendations if people come to me looking for implementation work.
22:46:01	petertodd:	gmaxwell: the last thing I need is yet more work, but worst comes to worst send them my way
22:55:36	petertodd:	hey, initial implementation: https://github.com/ConceptPending/proveit
22:55:52	petertodd:	slightly worrying they included emacs backup files in their repo though...
22:56:43	tacotime_:	yay python heh
22:57:29	petertodd:	tacotime_: why write up a pseudocode description of your algorithm when you can write python instead? :P
22:59:05	tacotime_:	I guess they're pretty close to the same thing, and more easily testable.
23:00:00	petertodd:	tacotime_: only thing python really needs is optional types, and crazy enough they've added initial support for that in the syntax, so now there are third-party type-checking metaclasses out there
23:00:21	sipa:	i hate python
23:00:43	gmaxwell:	The dirac specification contains pseudocode ... but the pseudocode is really python, and if you extract all the code and cat them togeater you get a working (but REALLY slow!) decoder.
23:01:03	petertodd:	gmaxwell: lol!
23:01:20	petertodd:	gmaxwell: they could have written it in cython so you would get a working and reasonably fast decoder...
23:01:21	tacotime_:	petertodd: I think types would help but there are still efficiency issues with the compiler
23:01:46	tacotime_:	Yeah, you pretty much have to hook c for anything you need to execute quickly
23:01:48	petertodd:	tacotime_: compiler? what compiler? :P
23:02:02	gmaxwell:	petertodd: a video decoder that isn't stuffed with SIMD is usually pretty much unusable..
23:02:04	petertodd:	tacotime_: look up cython - basically a python + types that can be compiled to c
23:02:05	sipa:	the other day i had a unit test for some python code, and it referred to a non-existing class (!!!) and all tests succeeded
23:02:10	jtimon:	wow, a lot of log to read, but sipa hates python? only likes C?
23:02:18	sipa:	i'll let you all guess what was wrong
23:02:34	gmaxwell:	Python is dirty.
23:02:35	petertodd:	gmaxwell: IIRC cython can do SIMD actually
23:03:17	gmaxwell:	I use it, it's slow, and it encourages you to write underspecified code that mostly works.
23:03:20	jtimon:	python is readable
23:03:22	tacotime_:	petertodd: that sounds useful. when you execute the program doesn't it run some kind of compiler? pyc files?
23:03:44	petertodd:	jtimon: yes, one of the most important things in a language
23:03:55	sipa:	too much freedom
23:04:05	jtimon:	I'm loving python more each day
23:04:10	petertodd:	jtimon: I have my usual story of a bug that could have killed someone caused by how C doesn't have indentation as syntax
23:04:12	sipa:	readable until you realize what this small piece of code you didn't check is doing
23:04:31	tacotime_:	yeah i used to use it for anything scripting when i was doing protein modeling stuff, then hook things that were slow to c.
23:04:34	petertodd:	sipa: meh, like I said, python needs to add types to solve that problem
23:04:34	sipa:	yes, python is readable at the syntax level, and very much so
23:04:50	gmaxwell:	sipa: was the non-existing class call in a try block that ate the error?
23:04:53	petertodd:	sipa: it's not perfect, but it's a good deal closer than any other language IMO
23:04:56	sipa:	gmaxwell: nope
23:05:08	gmaxwell:	the syntax is readable but that doesn't mean you understand what its actually doing.
23:05:14	sipa:	^- that
23:05:23	sipa:	gmaxwell: it's using a framework where all test classes are automatically unit tests
23:05:24	jtimon:	sipa: I think you're confusing with ruby, python rule "there should be only one best way of doing each thing" well, IIRC
23:06:02	petertodd:	gmaxwell: hence, add some types. programming in cython is an eye-opener that way
23:07:13	tacotime_:	* tacotime_ reads about the magic of the python interpreter
23:07:18	jtimon:	gmaxwell, not only the syntax, the whole language is designed to be able to write extreamly readable code
23:07:32	sipa:	... and then you have metaclasses
23:07:39	gmaxwell:	jtimon: readable does not mean understandable, not when the fine details count.
23:07:51	petertodd:	sipa: and metaclasses are the most readable implementation of magic that I've ever seen
23:08:05	petertodd:	sipa: (lisp, )
23:08:11	sipa:	or the ability to overwrite class methods
23:08:15	gmaxwell:	often fine details don't matter but when they do, they do.
23:08:40	sipa:	if python was statically typed, compiled, and didn't have these runtime overrides... i'd probably love it
23:08:53	jtimon:	gmaxwell: the programmer hhas a responsability to write readable code, python enables that, of course it doesn't guarantee it
23:09:24	petertodd:	sipa: exactly, you'd love cython, modulo the fact that it's main userbase is scientists doing numeric stuff so it's just not at the level of, say, C++ gcc
23:10:14	jtimon:	sipa that sounds like "if vanilla tasted like chocolate I would love it"
23:10:22	sipa:	jtimon: i know
23:10:34	sipa:	but i'm not disagreeing about the syntax being very readable
23:10:44	gmaxwell:	jtimon: its not hard to write a few lines of python with a computational complexity or memory complexity that basically _no one on earth_ could tell you at a glance what it is— not without careful though or profiling, using only built in features of the language.
23:10:56	tacotime_:	I'll have to read up on metaclasses, I remember seeing about them a while back but not really ever using them.
23:10:57	gmaxwell:	and without it being terribly obfscuated.
23:11:01	petertodd:	jtimon: well considering people are trying to promote the wonders of lutefisk in comparison vanilla and chocolate are pretty similar...
23:11:18	zooko:	☺
23:11:30	sipa:	gmaxwell: not really a useful argument, even though it's probably true
23:11:40	sipa:	gmaxwell: we're in any case talking about at least apparently readable code
23:11:42	zooko:	tacotime_: metaclasses are one of the things that I've used quite a bit, but will probably avoid using in the future.
23:11:42	jtimon:	not starting a project in python is always early optimization ;)
23:12:22	andytoshi:	everyone whining about python's lack of types should check out rust if they haven't already
23:12:26	petertodd:	jtimon: heh, I was just saying to amir in another channel that if your decentralized consensus system can't be implemented fast enough with python, assuming enough cheap boxen, it's not scalable enough :P
23:12:28	tacotime_:	zooko: why is that?
23:12:42	andytoshi:	i'm on sipa's side, but that's the only thing i'll add to this language war..
23:12:49	zooko:	tacotime_: it's because of that Kernighan quip about being clever. You know that one?
23:13:02	tacotime_:	No, how's it go?
23:13:04	petertodd:	andytoshi: gah, curly braces
23:13:08	antephialtic:	andytoshi: rust is really cool, but not ready for production (they haven't nailed down the standard library, syntax changes from release to release, etc)
23:13:19	zooko:	It is twice as hard to debug code as to write it.
23:13:23	tacotime_:	It looks like I've hacked on metaclasses before from the description by didn't know it
23:13:28	zooko:	So, if you write code as cleverly as you can, then you're not smart enough to debug it.
23:13:36	tacotime_:	Heh.
23:13:39	petertodd:	zooko: ten times harder if it's firmware and you don't have a debugger
23:13:40	jtimon:	petertodd, yeah, a consensus language shouldn't have to be as powerful as python is
23:13:57	zooko:	Ooh, you folks were talking about a *consensus* language ‽
23:13:58	jtimon:	shouldn't be
23:14:03	sipa:	zooko: not really
23:14:15	zooko:	I thought this was just Bullshit About Your Favorite Programming Languages Hour.
23:14:19	petertodd:	jtimon: no, I just mean you should have good enough basic algorithms that even a slow interpreted language is good enough
23:14:19	gmaxwell:	it was.
23:14:26	sipa:	zooko: which on itself should be a very good reason for avoiding features that complicate debugging, even if they simplify writing some things
23:14:42	gmaxwell:	though the things I don't like about python are many of the the same things that make it a poor tool in consensus.
23:14:47	jtimon:	rpython is compilable to C
23:15:42	petertodd:	gmaxwell: what exactly don't you like about python and consensus?
23:16:31	gmaxwell:	petertodd: that the exact behavior in all cases is difficult to discern. Perhaps its a lot better if you slather it with types, I've never used typed python.
23:16:55	jtimon:	gmaxwell, your argument about the language obscuring the complexity of your algorithm doesn't seem very solid, you should know it independtly of the language implementing it
23:17:03	petertodd:	gmaxwell: yeah, straight python is kinda scary there, typed however I think is a different matter
23:17:51	petertodd:	gmaxwell: excellent example is how python-bitcoinlib (currently) makes it easy to stick a floating point into a CTxOut.nValue, which fails later at serialization - I'm going to add some type checking to things like that once I decide the best way to do it
23:17:59	jtimon:	I love using a class as parameter without importing that class
23:18:09	gmaxwell:	jtimon: python operations often have hidden computational or (esp) memory complexity which is not obvious from the algorithim, even still where the language avoids copying in a bunch of places where doing so would be intutive and the lack of copying causes severe bugs for inexpirenced developers.
23:18:32	gmaxwell:	petertodd: or easily lets you seralize something that is entirely non-portable.
23:18:59	jtimon:	I think python causes LESS bugs, performance is another matter
23:19:17	sipa:	less bugs for simple things, harder to maintain larger things
23:19:28	gmaxwell:	something surprisingly using 10GB ram is no less a bug. :P
23:19:36	jtimon:	but in my experience you tend to need to optimize a little part of your whole program, not all of it
23:20:17	petertodd:	gmaxwell: python-bitcoinlib's serialization code does check that actually
23:20:23	jtimon:	gmaxwell if you "suprinsingly" use 10 GB ram you're clearly doing something wrong
23:21:00	petertodd:	gmaxwell: but I'm a rather odd python programmer potentially - the bulk of my experience using it has been for embedded systems development where python code was used to support crazy low-level c, asm, and even vhdl code
23:21:10	jtimon:	it's not python, it's maybe a missing "raise" in your code
23:21:20	gmaxwell:	jtimon: it's not too hard to do things in python which break the GC. or things which cause copying behind the scenes...
23:21:53	sipa:	gmaxwell: well, copying behind the scenes is pretty common in C++ too
23:22:10	jtimon:	more work than needed behinf the scenes is a cost you can cleanup later
23:22:12	gmaxwell:	sipa: yea well, I am also not an enormous fan of C++ either. :)
23:22:20	gmaxwell:	(also for that reason!)
23:22:25	petertodd:	anything that has dynamic memory allocation and reference counting and/or gc can have that happen
23:22:50	petertodd:	if anything, I kinda like python's reference counting + cycle-detection rules there as being predictable
23:23:36	jtimon:	say you're running 1 function 90% of the time and 90 functions the rest of the 10%, write it all in python and then single out that function and write assembly if you want
23:24:23	zooko:	jtimon: yes, that's something that I love about Python, contrasted with Java and many other languages --
23:24:36	zooko:	that the culture and the tools have encouraged polyglotism all along.
23:24:50	tacotime_:	yeah, that's what i had mainly used python for before.
23:24:55	zooko:	If there was a good C lib, then the Python culture was for someone to write a wrapper and everyone else to use that wrapper.
23:25:14	petertodd:	jtimon: generally true, although sometimes you get into situations where you're, say, memory limited so it's tricky to figure out how to make that 10% into compiled code... which is why they came up with cython (and previously, the really solid C/C++ interfaces)
23:25:30	sipa:	gmaxwell: the reason my unit test didn't run, was because i had two classes with the same name
23:25:34	petertodd:	zooko: yup, writing C/C++ wrappers is remarkably easy, even usign the library directly
23:25:38	sipa:	gmaxwell: the second one just overwrote the first
23:26:03	antephialtic:	jtimon: that approach limits the usefulness of alternative runtimes like pypy that JIT the code for speed
23:26:29	sipa:	petertodd: it took me several hours to figure out how to pass a list of numbers in python to a vector in C++
23:26:49	tacotime_:	my alt coin i'm supposed to be coding in golang, i'm curious to see how i like that when i get into it.
23:27:02	sipa:	(with no experience with swig whatsoever beforehand)
23:27:07	jtimon:	antephialtic calling an external optimized tool for something you're running a lot? I don'tt see how
23:27:32	Luke-Jr:	needing a wrapper is lame <.<
23:27:56	antephialtic:	jtimon: pypy has issues running code that uses c-extensions
23:27:57	jtimon:	it's interessting that the fastest python implementation is written in python and not in C though
23:28:09	tacotime_:	the only thing so far i really like from golang from the documentation is ease of multithreading, but i haven't read through all of it yet.
23:28:21	petertodd:	tacotime_: what's your alt going to do?
23:28:28	gmaxwell:	the concurrency in rust is nicer. :P
23:28:53	jtimon:	tacotime not a new language _zeromq
23:29:22	jtimon:	I think I'm loving zmq even more than python
23:29:47	tacotime_:	I'm hearing about zmq a lot lately too
23:30:03	tacotime_:	My alt coin is implementing an alternative to PoS that's more like PoA
23:30:12	sipa:	proof of ...?
23:30:14	petertodd:	tacotime_: proof-of-asshole?
23:30:21	tacotime_:	activity, proposed by coblee
23:30:22	petertodd:	tacotime_: aardvark?
23:30:35	gmaxwell:	tacotime_: It has LDAP XML Synergy for advanced RDBMS LAMP stacks in the cloud at webscale.
23:30:37	sipa:	proof of altcoin?
23:30:59	Luke-Jr:	petertodd: hahah
23:31:10	Luke-Jr:	proof-of-attack is my serious guess
23:31:10	tacotime_:	But basically has per block verification of the chain by stakeholders.
23:31:11	Luke-Jr:	<.<
23:31:19	tacotime_:	Ouch luke-jr
23:31:21	zooko:	antephialtic: the right way forward is to use https://pypi.python.org/pypi/cffi to interface Python to native code, and then pypy (and also CPython) have no problems with it.
23:31:21	sipa:	gmaxwell: you'll love this: http://pic.dhe.ibm.com/infocenter/wsdatap/v6r0m0/index.jsp?topic=%2Fcom.ibm.dp.xm.doc%2Fjson_jsonx.html
23:31:38	gmaxwell:	LOLOL
23:31:51	qwertyoruiop_:	qwertyoruiop_ is now known as qwertyoruiop
23:31:53	tacotime_:	Then second it's implementing a fiat-like system using a public oracle system.
23:31:58	zooko:	* zooko laughs
23:31:59	petertodd:	ooh! an appliance! that sounds enterprisey
23:32:09	tacotime_:	That's most of what it does.
23:32:18	petertodd:	tacotime_: you still haven't told us what the 'A' stands for
23:32:22	sipa:	petertodd: actifity
23:32:25	tacotime_:	activity
23:32:28	petertodd:	ah!
23:32:29	zooko:	tacotime_: by "fiat-like", you mean the size of the monetary base can change in response to politics?
23:32:34	tacotime_:	sorry heh
23:32:35	gmaxwell:	JSON-enterprise-edition
23:32:44	petertodd:	tacotime_: ok, so it's proof-of-internal-sacrifice really
23:32:46	sipa:	gmaxwell: cloud JSON
23:32:51	tacotime_:	zooko: yes, according to the politics of the stakeholders and the PoW miners.
23:32:52	antephialtic:	zooko: cool, will look into that
23:33:02	tacotime_:	petertodd: yes
23:33:19	sipa:	gmaxwell: now with over 99.8% redundancy!
23:33:27	petertodd:	tacotime_: good luck - such schemes are probably on the threshold of being possible at best
23:33:41	zooko:	antephialtic: hope it helps! cffi is developed by the pypy devs (at least partly), and those folks are very good engineers, and you can find them on #pypy
23:33:59	Luke-Jr:	petertodd: are you on the altcoin panel in Texas?
23:34:07	tacotime_:	petertodd: At worst I'll end up with something that doesn't work very well and a lot of experience coding cryptos, which I'm okay with.
23:34:10	petertodd:	Luke-Jr: early march? no, at the financial crypto conf
23:34:12	Luke-Jr:	tacotime_: ^
23:34:34	gmaxwell:	"coding cryptos"
23:34:34	petertodd:	tacotime_: good attitude - I'd love to see such a thing get coded up if only to see how exactly they fail
23:34:36	Luke-Jr:	* Luke-Jr wonders who else is on it <.<
23:34:45	gmaxwell:	* gmaxwell gets out the staff of smiting.
23:35:03	sipa:	tacotime_: and you may spend a ton of time convincing yourself you're creating something safe
23:35:16	petertodd:	tacotime_: take sipa's advice and break it for us :)
23:35:21	tacotime_:	sipa: I'm not that delusional, heh
23:35:25	gmaxwell:	tacotime_: see andy's protopaper.
23:35:32	tacotime_:	andy's protopaper?
23:35:36	andytoshi:	one sec
23:35:38	sipa:	1
23:35:39	sipa:	over
23:35:41	andytoshi:	lol
23:35:50	Luke-Jr:	2
23:35:55	gmaxwell:	/exec -o sleep 1; echo how about now?
23:35:55	jgarzik:	he did not specify when the second would occur
23:35:56	andytoshi:	http://download.wpsoftware.net/bitcoin/alts.pdf
23:36:14	antephialtic:	andytoshi: a couple nights ago gmaxwell mentioned that you had proved that schnorr signatures were non-malleable. can you link the paper?
23:36:29	andytoshi:	sorry, i ran 'cat docs/scrap/bitcoin-links', but then it wasn't in there, so i had to find it and add it..
23:36:49	andytoshi:	antephialtic: sure, http://download.wpsoftware.net/bitcoin/wizardry/schnorr-mall.pdf
23:36:50	zooko:	tacotime_: aren't the incentives of currency holders always to minimize creation of new currency, and the incentives of miners always to maximize it?
23:37:00	antephialtic:	andytoshi: thanks
23:37:15	zooko:	full disclosure: I'm toying with related notions myself.
23:37:33	zooko:	Not that I expect you to be interested in my ideas, but I started feeling a bit guilty about pumping you for information without mentioning that.
23:37:43	andytoshi:	gmaxwell: regarding snarkcoin tx security, you said "just give different outputs to every miner" to minimize who can see the actual transactions
23:37:47	tacotime_:	Regardless of how much your cc breaks to you can usually make it continue running by switching to something that does work temporarily while you fix what was broken, eg just enforce pow for a while with a hardfork. So long as how it's broken not involving something like people spending other people's money (counterparty)
23:38:25	tacotime_:	zooko: Yes, so they should find common ground when you average them, no? ;)
23:38:28	petertodd:	zooko: you should think in terms of security against rational actors, and irrational ones - don't design systems that assume too much that attackers are economically rational
23:38:36	gmaxwell:	andytoshi: Yes.
23:38:36	andytoshi:	gmaxwell: how about, rather than signing outputs, you sign a pubkey (which the recipient provides) along with the inputs and change outputs, then pass this to the recipient. and the recipient adds and signs the outputs himself
23:38:36	austinhill:	@zooko the alt coin model is very broken and a new incentive mechanism for innovation is required
23:38:52	petertodd:	zooko: proof-of-work is good for that precisely because it's a huge barrier to the irrational ones, at least once the system is established
23:39:09	andytoshi:	gmaxwell: then the recipient is in charge of getting this to miners -- he can do the output-swapping thing, and set his own fee, and the sender doesn't get to find out the outputs
23:39:13	zooko:	petertodd: good point about irrational attackers.
23:39:29	zooko:	Hiya austinhill!
23:40:05	zooko:	austinhill: yes, I've been intending to ask you about that, in fact.
23:40:05	gmaxwell:	andytoshi: sounds great. I mean, it's an extra ecdsa validation under proof, but this wasn't an immediately pratical idea.
23:40:30	petertodd:	zooko: did you see my conversation a few weeks (?) ago on bitcoin-dev about merge-mining? that's exactly what I'm talking about - it's insecure against the irrational actors no matter how much you handwave about economic incentives
23:40:47	zooko:	petertodd: I'll look for it on the mailing list archiuves.
23:40:52	tacotime_:	petertodd: in practice too, see lukejr and coiledcoin.
23:41:01	austinhill:	the co-operation of a large part of blockchain miners / minning pools in allocating hasing power & infrastructure to an alt coin can be very beneficial or abused (pump&dump difficulty rate on a new SHA proof of work coin)
23:41:15	gmaxwell:	I think the CLC stuff was rational. FWIW.
23:41:18	petertodd:	tacotime_: I forget whether or not luke denies that, but certainely easy to see how it could happen
23:41:23	Luke-Jr:	(nevertheless, merged mining is the best system currently, and practically secure as long as you have rational actors on your side)
23:41:53	gmaxwell:	you certantly don't want to merge mine something that the existing miners might outright oppose though. Woe be it to you who do.
23:42:10	tacotime_:	gmaxwell: yes
23:42:14	Luke-Jr:	austinhill: the goal of any legit crypocurrency is to keep difficulty as high as possible
23:42:28	Luke-Jr:	austinhill: the pump&dump refers to valuation
23:42:45	petertodd:	Well, good case in point: Would existing miners want to merge-mine my tree-chains idea? It can be done as an economically neutral way to increase scalability... but it has the side effect of making pools much less relevant.
23:43:02	gmaxwell:	petertodd: I don't think thats a problem.
23:43:07	tacotime_:	Andrew's draft is rather damning
23:43:09	petertodd:	Existing miners might very well kill it off because those miners are pools and may not want it to exist.
23:43:26	gmaxwell:	Esp if any attack is provable, the goodwill loss would fix the incentive alignment.
23:43:28	Luke-Jr:	petertodd: does it make bitcoin (or whatever system) more valuable as a system?
23:43:33	Luke-Jr:	that is an incentive there
23:43:44	tacotime_:	I think anyone putting money into altcoins should more or less be aware that it could disappear at any time
23:43:48	gmaxwell:	and yea, I think virtually every pool is more aligned to bitcoin long term than their particular position as a pool.
23:43:52	Luke-Jr:	tacotime_: that's true of bitcoin
23:43:52	petertodd:	Luke-Jr: probably yes, but as I say, it makes pools unneeded
23:43:54	austinhill:	problem is when everyone starts merge minning different coins & the ecosystem starts to encourage more alt coins which frankly affects the perception of all cryptocurrencies as monopoly money
23:44:11	sipa:	so currency, many alt!
23:44:18	gmaxwell:	tacotime_: I'm not sure thats ever really all that useful advice to people. I mean people should give that advice, but lets not fool ourselves that it really is all that protective.
23:44:34	jcrubino:	how does one convert an address to the public key?
23:44:41	Luke-Jr:	jcrubino: you don't.
23:44:45	sipa:	jcrubino: not here, please
23:44:54	Luke-Jr:	jcrubino: you should be in #bitcoin-dev or something, this channel is for wizards <.<
23:45:01	tacotime_:	Yeah, I do feel kind of antsy about taking anyone's money to hack on my alt coin
23:45:13	tacotime_:	I'm not sure what the legal liabilities are
23:45:27	gmaxwell:	austinhill: yep, my long time worry is if there is every a switch where Foo coin replaces Bitcoin without any real migration then the whole thing will unravel when people say — wait, but when will Foo coin be replaced??!
23:45:27	Luke-Jr:	tacotime_: the bigger problem is the people who will pump your altcoin and rip off the fools they convince to invest in it
23:45:39	tacotime_:	I'm just saying it may or may not work and that you might end up with a leviathan of horrendously malformed code
23:45:41	petertodd:	tacotime_: fwiw the legal advice I got was to stick to consulting, not actually writing code too directly
23:45:47	gmaxwell:	er, s/every/ever/
23:45:50	tacotime_:	Luke-Jr: Yeah
23:45:58	Luke-Jr:	tacotime_: even legit altcoins have problems with scammers trying to take advantage of them
23:46:02	jcrubino:	#bitcoin-dev seems to be off limits except to devs and invited guests, #bitcoin is usually full of shit, so i came here
23:46:05	austinhill:	Spoke with vitalik yesterday about Ethereum and their doing a mastercoin type issuance through switzerland for millions of dollars - this I think is bad for the ecosystem
23:46:09	petertodd:	tacotime_: the legal advice also was that in reality basically anyone in a position of *social* influence in this space may be seen by the courts as being the "administrator" of these systems, and hence legally liable
23:46:22	Luke-Jr:	jcrubino: #bitcoin-dev is not restricted beyond topic
23:46:44	tacotime_:	petertodd: Hrm. If I write it myself without taking anyone's money and release it, am I still liable?
23:46:58	petertodd:	tacotime_: probably yes
23:46:58	austinhill:	Petertodd: you also face minimum qualified investor rules in Canada, US and Europe
23:47:09	gmaxwell:	tacotime_: you're always liable, hurray for civil liability. What advice do you want?
23:47:20	Luke-Jr:	lol
23:47:38	sipa:	austinhill: ethereum is a fully independent chain, no?
23:47:43	sipa:	austinhill: not embedded in bitcoin
23:47:55	austinhill:	you could always release it pseudonymously - worked for someone we know, no one to sue
23:47:56	petertodd:	gmaxwell: note the lawyers I talked to specifically spoke in terms of being liable for administering a financial system, more than just civil liability
23:49:00	austinhill:	sipa: ethereum is trying to bootstrap independent blockchain and using BTC to fund it with a crazy DAC model (mastercoin with a twist of trying to build turing complete scripting into system)
23:49:24	sipa:	austinhill: yeah, i've met with ethereum people
23:49:39	petertodd:	it's notable that ethereum has moved from talking about the fundraising as an investment to talking about it as people buying something in a standard exchange of goods for money
23:49:57	sipa:	didn't know about how they were going to bootstrap it
23:50:19	gmaxwell:	petertodd: IRC has had a bunch of people really confused about ethereum the last few days.
23:50:46	petertodd:	sipa: right now it's sell ethereum coins from the premine on the basis that people are buying a standard digital good, not on the basis that they are buying a right or any kind of share
23:50:53	petertodd:	gmaxwell: not surprised...
23:51:01	gmaxwell:	People are thinking that it will turn all the nodes into some ec2 instance and that the internet infrastructure will migrate into ethereum and other disconnected from anything proposed by anyone stuff.
23:51:02	antephialtic:	regarding legal issues, I wonder what impact Arista Records LLC v. Lime Group LLC could have on bitcoin developers. While the underlying crime in that case was copyright infringement, it's not hard to imagine a similar one for money laundering
23:51:12	petertodd:	gmaxwell: lolololol
23:51:29	petertodd:	antephialtic: ?
23:51:34	gmaxwell:	petertodd: I think people don't at all get what it actually does and are just pattern matching to the nearest thing they understand.
23:51:35	sipa:	gmaxwell: lolwut
23:51:59	austinhill:	gmaxwell: well when you breathe enough ether anything is possible lol
23:52:09	gmaxwell:	sipa: you didn't also see the person in #bitcoin-dev who was asking about us using OP_RETURN to give URLs to javascript for miners to run?
23:52:14	gmaxwell:	austinhill: hahahahahhaha
23:52:19	sipa:	gmaxwell: ugh, no
23:52:20	petertodd:	gmaxwell: probably quite true - it's notable how many people just didn't get my last post about proof-of-publication and decentralized markets when I was talking about it at the local meetup
23:52:32	sipa:	gmaxwell: i regularly quit -dev... i waste time being annoyed
23:52:33	petertodd:	austinhill: +1
23:52:41	petertodd:	sipa: +1
23:53:04	sipa:	* sipa invokes xkcd 386
23:53:25	gmaxwell:	19:25 < linagee> would it be possible to use the 80 extra bytes from bitcoin 0.9 to point to a URL with .js that nodes can run?
23:53:43	sipa:	ugh
23:53:43	gmaxwell:	19:28 < linagee> gmaxwell: adapt or die. I'm trying to adapt.
23:54:07	sipa:	someone should really try to explain bitcoin's consensus and trust model
23:54:09	gmaxwell:	I don't bring it up to make fun of linagee, that kind of helpful clueness seems to by common among people newly interested in ethereum.
23:54:10	petertodd:	gmaxwell: we should write a BIP for that to be published in just over a month...
23:54:28	gmaxwell:	We did need a bit that specified something really dumb.
23:54:31	gmaxwell:	er bip.
23:54:54	gmaxwell:	(As an example that the existance of a BIP is not itself proof that an idea is good)
23:55:30	petertodd:	We could get Eligius to implement it with a Javascript interpreter that always returns 42, and then make it Accepted on the basis of community acceptance.
23:55:48	sipa:	* sipa proposed OP_FORK: let's you create infinite amount of money - you can spend everything you had once for each separate node
23:56:03	austinhill:	I would love to build a proof-of-knowledge credentialing system based on web-of-trust & Dr. Stefan Brands blinded credential tokens to build a "k/n bitcoin-wizards think you are A) not an idiot, B) ask good questions & C) have the right to join this chat" …..nice credentialing system for decentralized authenticated chat
23:56:25	petertodd:	sipa: in highschool I actually worked out the economics for essentailly just that after reading the hashcash paper - was trying to figure out how to make it into a useful decentralized currency...
23:56:40	petertodd:	sipa: (I knew I was getting desperate...)
23:56:53	sipa:	i actually *used* hashcash
23:56:56	sipa:	does that count?
23:57:07	petertodd:	ha, yeah, me too
23:57:14	gmaxwell:	I believe I have some RPOW. Someplace.
23:57:20	tacotime_:	original gangster. i'd never heard of it before bitcoin.
23:57:32	austinhill:	sipa: petertodd: I actually went out & hired hashcash inventor to come work for me for 3 years trying to figure this shit out
23:57:34	petertodd:	though the only person who'se ever sent me a hashcash email is adam back
23:57:44	petertodd:	austinhill: adam?!
23:57:49	sipa:	austinhill: i'm aware you know the hashcash inventor, yes :p
23:57:58	austinhill:	Yeah, I hired Adam Back back in 2000
23:58:09	petertodd:	austinhill: lol, hilarious, did he figure that shit out? :P
23:58:28	austinhill:	Maybe this time, we recently co-founded a new company….more on this later :)
23:58:39	petertodd:	austinhill: interesting!
23:59:06	gmaxwell:	In any case, I think that mostly this stuff with random people being confused about ethereum is that the developers of it must be giving some clearly excited talks about it, and that kind of excitement is more contagious than the understanding is...
23:59:22	petertodd:	vitalik doesn't really explain it well either
23:59:37	sipa:	gmaxwell: some ethereum people recently visited the zurich bitcoin meetup
23:59:41	gmaxwell:	Explaining things is hard.
23:59:43	austinhill:	Company was ZeroKnowledge (we tried to buy Digicash from David Chaum, but bought the rights to Brands eCash system which was superior) think .tor + Bitcoin + Identity blinded credentials….$80million raised - 300 people
23:59:44	sipa:	interestingly, none were actually technical