00:28:16maaku_:maaku_ is now known as maaku
00:50:46tromp:interesting whitepaper by Charles Hoskinson at http://www.reddit.com/r/ethereum/comments/2m0j5l/why_was_my_post_removed/
01:02:06pigeons:suprise, he named it after himself
01:03:32wallet421:wallet421 is now known as wallet42
01:08:19gmaxwell:tromp: I'm very confused about that. It in the past he's tried pressuring me into endorsing varrious asset sales he was involved in, and responded quite rudely when I questioned the ethics of his behavior, citing some of the points this paper makes.
01:09:15gmaxwell:I suppose the plan is to cash out a huge amount from the ethereum presale and then position himself to get hired as an expert by regulators?
01:18:21rusty:gmaxwell: That's a novel theory at least :)
01:31:04dgenr8:justanotheruser: OP_NULL: thank you. i can see i have to give up saying a proper disincentive is possible without a soft-fork.
01:48:20tacotime:gmaxwell: that's the hoskinson way i would guess. bitshares --> ethereum --> regulation ???
01:48:46tacotime:and i figure he's already totally cashed out of ethereum
01:49:51tacotime:he did most of the budget for marketing and dev collection before the fundraiser, so i figure the goal was to push a lot in to pump and then make some money if the fundraiser was successful, which is why he's off the project now.
01:56:24tacotime:the whole document is terribly ironic given the history of the ethereum ipo.
01:57:58tacotime:the document is here as the ethereum subreddit appears to have removed it (lol) https://docs.google.com/document/d/1xG1hkPbk0uuavjPc_gt_eWxEUbWM1SlsxNmhGdRIUtg/edit?usp=sharing
01:58:52gmaxwell:It's just very weird.
01:59:13gmaxwell:I wonder if it actually was written by him, and isn't instead a really clever attack.
02:00:56penny:penny is now known as Guest71572
02:10:47user7779078:hoskinson is bad news, always has been always will be. i hear he got kicked out of bitshares for some proper sketchy stuff. that's all i'll say
02:18:38super3:its kind of interesting though, both bitshares and ethereum have been quite successful though
02:18:59phantomcircuit:super3, at collecting money
02:19:05phantomcircuit:important to make the distinction
02:19:31phantomcircuit:i expect them both to get in huge amounts of trouble
02:21:45super3:i worked at bitshares for a little while
02:25:07justanotheruser:phantomcircuit: aren't they just selling their product? They aren't selling shares in their company.
02:25:24super3:ethereum will be just fine
02:25:39phantomcircuit:justanotheruser, they're not though
02:25:49super3:they are very distributed, and have tons of resources and legal to protect them
02:26:47phantomcircuit:they're selling something which only has value if they make it valuable; but more so have promised to do a bunch of things to make them valuable which a naive person would expect they can do, which they almost certainly cannot do
02:27:16justanotheruser:phantomcircuit: ok, so there problem is false advertising, not running an IPO.
02:27:18phantomcircuit:and then they did a bunch of legal shenanigans which will look suppper incriminating when they finally do get charged with something
02:28:03phantomcircuit:justanotheruser, what they're doing looks, acts, and quacks like and ipo
02:28:22phantomcircuit:if the sec charges them they're going to have a very very hard time refuting the allegation
02:29:05phantomcircuit:justanotheruser, it's arguably fraud, the only distinction is whether they believed they could do it or not
02:29:33justanotheruser:phantomcircuit: what is fraud? them misrepresenting their cryptocurrency?
02:29:36phantomcircuit:their problem is that they were expressing supreme confidence that they can do it
02:29:39OP_NULL:phantomcircuit: there's more than that too. there's a lot of claims in their original promotion that it's just selling fuel, not a currency, and so forth. then they have an official blog right next to it with phrases like "ethereum exchanges" and "the price of ethereum".
02:29:46phantomcircuit:but certainly have internal emails which are less confident
02:29:57phantomcircuit:the distinction could be enough for a fraud suit
02:30:03woah:i gave them btc
02:30:10justanotheruser:woah: I'm sorry
02:30:11woah:i don't mind if it doesn't work out
02:30:38woah:the only thing that would make me mad is if they didnt spend the money on open source software development
02:30:47phantomcircuit:woah, sure, but im sure there are plenty of people who gave them btc and expect they will build what they said they would
02:31:05phantomcircuit:it would literally only take one person to hold them to it
02:32:40woah:idunno man, are you familiar with tech startups?
02:32:48justanotheruser:so are you saying this will be *the* shitshow of altcoins?
02:33:39justanotheruser:vitalek gets arrested, bitcoin community divided on how they feel about it, thousands of bitcoins lost, lots of I told you so's, don't trust this altcoin, nooooo this altcoin is different.
02:33:55phantomcircuit:woah, sure and any startup which did what they did would endup in jail
02:33:59phantomcircuit:general solicitation
02:34:02woah:what did they do?
02:34:03phantomcircuit:unaccredited investors
02:34:07woah:oh i see
02:34:11phantomcircuit:both serious sec violations
02:34:15woah:aren't they changing those laws?
02:34:31phantomcircuit:woah, not in a way that etherium would be compliant
02:34:38OP_NULL:doesn't matter if the law changes after the fact anyway.
02:34:41user7779078:and the SEC has stalled those for month
02:34:48phantomcircuit:general solicitation will be allowed through registered broker/dealers
02:35:04phantomcircuit:investor restrictions will be relaxed within limits through registered broker/dealers
02:35:05woah:so this is about accreditation?
02:35:05justanotheruser:poor vitalek then
02:35:14phantomcircuit:notice this all requires you use a registered broker/dealer
02:35:46woah:so, any coin ipo then?
02:35:49phantomcircuit:woah, accredited investor basically means someone with enough money that the sec isn't going to protect them from themself
02:36:07phantomcircuit:woah, if you build the software AND THEN sell the coins
02:36:09OP_NULL:justanotheruser: you could say that if he tripped and accidentally made a crowd funding website, not if it was done intentionally in another country to skirt around the law.
02:36:11phantomcircuit:you might be ok
02:36:24woah:no startups say that when getting investment
02:36:26phantomcircuit:(notice the might, that is super important here...0
02:36:31woah:seems to work out ok sometimes
02:37:26woah:anyway not trying to argue, we'll see
02:38:28woah:i, personally, have no great love for accreditation laws
02:38:34woah:woah has left #bitcoin-wizards
02:39:12justanotheruser:phantomcircuit: So what if microsoft had a presale of xboxlive points?
02:39:18justanotheruser:(before the xbox was made))
02:39:57phantomcircuit:justanotheruser, closed loop presale
02:40:03phantomcircuit:rules are clear
02:40:24phantomcircuit:not convertible, daily sale limits, etc etc
02:40:45justanotheruser:phantomcircuit: not convertible?
02:41:06OP_NULL:phantomcircuit: what part of Ethereum were you saying is impossible?
02:41:30phantomcircuit:justanotheruser, microsoft wont buy your points back
02:41:43phantomcircuit:they will sell you services for the points
02:41:47phantomcircuit:but will not give you cash
02:42:46justanotheruser:phantomcircuit: will ethereum buy my dollars back?
02:43:24phantomcircuit:justanotheruser, ethereum doesn't provide a service in return for ethers
02:43:58phantomcircuit:justanotheruser, but actually yeah if i was microsoft i would not be preselling xboxlive points
02:44:30phantomcircuit:regardless ethereum didn't follow the closed loop prepaid access requirements either
02:44:45phantomcircuit:specifically the limit of 10k/day/person
02:45:02phantomcircuit:and kyc requirements
02:45:27phantomcircuit:justanotheruser, as you can see they could have done a bunch of stuff that would have potentially gave them an arguement that what they did wasn't x but was y
02:45:36phantomcircuit:except they have also violated all the rules for doing y
02:45:44OP_NULL:they actually avoided even collecting email addresses, which was a weird choice.
02:46:02gmaxwell:might be forced to return the funds...
02:46:09phantomcircuit: phantomcircuit: what part of Ethereum were you saying is impossible?
02:46:59phantomcircuit:getting the incentives correct to make a distributed consensus for computationally intense transactions correct is likely impossible without snarks and that is moon maths
02:47:13phantomcircuit:(even then it is likely beyond their abilities)
02:47:38phantomcircuit:OP_NULL, the meaningful question is whether the level of confidence they put out to the world matches the level of confidence they had internally
02:47:46phantomcircuit:i very seriously doubt they match
02:49:02phantomcircuit:anyways standard
02:49:10phantomcircuit:im not a lawyer, im not your lawyer, blah blah
02:49:31gmaxwell:I wouldn't know if I should me more worried that there was an information asymmetry there, or more concerned that there might not be.
02:49:53phantomcircuit:gmaxwell, with asymmetry it's fraud, without it's just being stupid
02:51:44phantomcircuit:the magic of common law systems in which intent matters
02:57:32OP_NULL:gmaxwell: "refunds" in the same way that another crowd funded thing (buttercoin, I think) did it probably. they sent all the outputs they received back to the "from" address, naturally losing lots of people's money in the first place.
03:31:32maaku:maaku is now known as Guest34189
04:51:08Pan0ram1x:Pan0ram1x is now known as Guest36009
05:20:36phantomcircuit:OP_NULL, the way ethereum did the ether sale is extremely suspicious
05:20:46phantomcircuit:i dont think it's even technically possible for them to do refunds
05:23:36OP_NULL:phantomcircuit: yes, agreed. they set it up in a frankly insane way, I don't even understand how it can possibly work.
05:24:51OP_NULL:phantomcircuit: client made a seed k, made a bitcoin address sha256(k), sent money to it. made an ethereum address with sha256(k+0x01). I don't understand how they intend to prove the two are related.
05:28:13phantomcircuit:OP_NULL, surely you mean address as sha256(pubkey(k))
05:29:05OP_NULL:phantomcircuit: er, yeah in both cases I was talking about the private key. so the Bitcoin private key is sha256(k), ethereum one is sha256(k+0x01).
05:32:44phantomcircuit:OP_NULL, er doesn't that mean someone who sent them btc can reclaim it? or are they send a copy of k
05:34:07OP_NULL:phantomcircuit: no, the client made the bitcoin address, the buyer sent money to the bitcoin address, and then spent those outputs again to the ethereum presale address. there's no outputs left in the midway bitcoin address.
05:34:58phantomcircuit:OP_NULL, oh
05:36:21phantomcircuit:they cant correlate them unless you tell them k
05:37:02OP_NULL:yeah. that's the problem. you can sign each address with the other, but that seems terribly messy.
05:39:55OP_NULL:phantomcircuit: https://github.com/ethereum/pyethsaletool/blob/master/pyethsaletool.py#L124
05:44:17phantomcircuit:lol @ using unnecessarily bleeding edge crypto
05:44:41OP_NULL:that was when they had SHA3 based proof of work (better than crusty old Bitcoin's SHA256).
05:46:01phantomcircuit:assuming sha3 isn't broken
05:46:27phantomcircuit:there is no way for them to correlate pubkey(sha3(seed)) with pubkey(sha3(seed+1))
05:46:34phantomcircuit:unless you give them seedd
05:47:27OP_NULL:pub1 can sign pub2 and vice versa, but that's very ugly to put in your genesis block. I really don't think they thought that one through very well.
05:54:12OP_NULL:phantomcircuit: actually that can't be right either. the network will have no knowledge of the ethereum address at all.
06:25:49lclc_bnc:lclc_bnc is now known as lclc
06:51:19Taek:sha3 is bleeding edge crypto?
06:53:42OP_NULL:I don't think it's even finalized yet.
06:54:26OP_NULL:there's a joke there about bleeding edge and sponge functions, but I couldn't make it work.
06:55:07Taek:"The standardization process is in progress as of November 2014"
06:56:22BlueMatt:so....very bleeding edge
07:13:55gmaxwell:yea, they've changed the spec a bit a couple times too. Though mostly changed it back now.
07:29:05Taek:I guess I'm surprised because sha3 has been available in the go standard library for well over a year. I wouldn't have expected non-finalized crypto to be in standard libraries. Perhaps that was naive.
07:58:30BlueMatt:over a year is also very bleeding edge crypto....
08:28:22lclc:lclc is now known as lclc_bnc
08:43:34nsh:in crypto, all the edges are bleeding
08:43:44nsh:0/4 for TLS frameworks this year \o/
08:50:17phantomcircuit:nsh, i think libressl will help a lot there
08:50:25phantomcircuit:ssl/tls are massively complicated protocols
08:50:35nsh:* nsh nods
08:50:38phantomcircuit:and it seems like they're willing to break compatibility to fix security issues
08:51:30nsh:i wonder if the internet engineering community might want to take pause to reflect on how things got this bad
08:51:57gmaxwell:no one feels accountable for the whole system.
08:52:19nsh:* nsh nods
08:52:22gwillen:that seems fair, since nobody designed the whole system
08:52:23gwillen:it evolved
08:52:49gmaxwell:You have protocols whos design is messy, but thats the fault of legacy and of applications for demanding many things, ... and implementations which cannot be correct because the protocol is too complex, and 'surely' the protocol isn't at fault for that as far as anyone working on the protocol is concerned.
08:53:27BlueMatt:(or is that just what the nsa wants you to think)
08:56:10gmaxwell:example discussion from HTTP2 WG today, ... in HTTP2 they want to prohibit various old rubbish insecure TLS cipher suites; but the initial TLS handshake sent by the client doesn't know if the server supports HTTP2 or not... and if it doesn't advertise old crappy ciphers it may not be able to establish encryption at all with old hosts. SO... what they'll do is advertise the ciphers they support, including old crappy ones... and then ...
08:56:16gmaxwell:... there will be a blacklist of crappy ciphers, and if the server chooses to use HTTP2 it must not select any cipher on the blacklist, even though it was offered by the client. ... or the client will reject it. now this is all reasonable when seen in the context of the legacy infrastructure, ... but damn, just another layer of implementation complexity.
08:57:27gmaxwell:And the blacklist must be static, since if its desynced between the client and server the server may accidentally select a cipher the client offered but didn't really intend it to select. ... hopefully this is okay, since hopefully(?!) no more ciphers are being introduced that clients would need to continue to offer for purely legacy reasons.
08:57:28moa:it's a mess
08:57:39BlueMatt:http2 needs to switch ports and start over
08:58:09gmaxwell:well when things switch to the next version of TLS this should be cleared up (all those old ciphers will just not be supported)
08:58:56gmaxwell:BlueMatt: can't switch ports, since you don't want to take an enormous delay just to try http2 and figure out that the server doesn't have it.
08:59:21BlueMatt:gmaxwell: http2://
08:59:28gmaxwell:unless you also expect urls to change; in which case the protocol will basically never be substantially adopted
08:59:37gwillen:see also ipv6
08:59:39gmaxwell:since there are kabaziliions of links that will just never get updated.
08:59:59gmaxwell:even worse than ipv6, since at least DNS can give you IPv6 addresses right away. :)
09:00:12gwillen:* gwillen nod
09:00:22BlueMatt:meh, lets just reset and start it all over
09:00:30moa:on a sidechain
09:00:31phantomcircuit:gmaxwell, attempt simultaneous connections?
09:00:33BlueMatt:all new browsers, all new web :)
09:00:41phantomcircuit:seems like the only reasonable solution
09:00:43gmaxwell:phantomcircuit: ugh. I suppose you could do that, but ugh.
09:00:53phantomcircuit:i know but... well
09:00:55gmaxwell:well what it actually does is pretty reasonable.
09:01:02gmaxwell:just complex
09:01:29gwillen:isn't "simultaneous connections" even the current workaround for v4 vs v6 being terrible
09:02:02moa:secure handshake is not trivial problem
09:02:15phantomcircuit:gmaxwell, complexity is bad though
09:02:34phantomcircuit:every point for reasonableness is lost for complexity
09:03:46cbeams_:cbeams_ is now known as cbeams
09:05:14tepper.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
09:05:14tepper.freenode.net:Users on #bitcoin-wizards: andy-logbot jaekwon_ koshii_ cbeams AaronvanW MoALTz Aquent fanquake devrandom zooko [7] Guest36009 orik chris2000 PRab Guest34189 Dr-G3 justanotheruser lchill wallet42 null_radix c0rw1n_ moa OneFixt nickler waxwing SubCreative sneak otoburb mortale dgenr8 btcdrak shesek luny zenojis wumpus Starduster_ lclc_bnc kyletorpey jbenet artifexd Greed PaulCapestany EasyAt CryptOprah BlueMatt kumavis spinza _2539 HaltingState citizen11 tacotime
09:05:14tepper.freenode.net:Users on #bitcoin-wizards: zwischenzug starsoccer pi07r phawk Hunger- sdcdev HM bosma Adlai ebfull kefkius BananaLotus wizkid057 warptangent prepost hollandais go1111111 super3 Cory Meeh Nightwolf comboy epscy paperbot rasengan altoz fluffypony grandmaster2 K1773R gnusha fenn kanzure heath stonecoldpat copumpkin LarsLarsen Logicwax jaromil weex helo Alanius samson_ tromp_ Keefe Iriez Eliel jrayhawk crescendo Baz___ lnovy Luke-Jr coutts Fistful_of_Coins CodeShark
09:05:14tepper.freenode.net:Users on #bitcoin-wizards: DoctorBTC Grishnakh iddo gmaxwell Flyer33 [\\\] bobke_ napedia huseby GnarSith Anduck phedny iambernie MRL-Relay berndj phantomcircuit mmozeiko midnightmagic sl01 nsh Muis arowser sipa poggy NikolaiToryzin cfields coryfields mappum Taek optimator_ andytoshi BrainOverfl0w fds4345 gazab BigBitz Apocalyptic throughnothing warren gavinandresen dansmith_btc pigeons nanotube asoltys gribble Krellan kinlo a5m0 [d__d] LaptopZZ espes__ Graet livegnik
09:05:14tepper.freenode.net:Users on #bitcoin-wizards: hguux petertodd smooth @gwillen michagogo yoleaux amiller btc_ danneu catcow TD-Linux [Tristan] ryan-c roasbeef pajarillo Gnosis ahmed_ so harrow abc56889 lechuga_ @ChanServ myeagleflies Dyaheon firepacket kgk SomeoneWeird tromp zibbo_ mr_burdell AdrianG
09:08:26gmaxwell:Anyone done anything using the Rainbow signature system (multivariet polynomials)? Seems most people are interested in it due to it being presumed quantum hard, but it's perhaps interesting for some applications because its signing (and verifying) is stupidly fast, e.g. 270k signatures/sec/core on the implementation supercop.
09:11:23nsh:this one? https://www.google.com/patents/US20080013716
09:11:30phantomcircuit:gmaxwell, interesting the signatures aren't too big
09:11:40phantomcircuit:but the public keys are huge
09:12:03nsh:.wik Unbalanced oil and vinegar
09:12:04yoleaux:"In cryptography, the Unbalanced Oil and Vinegar (UOV) scheme is a modified version of the Oil and Vinegar scheme designed by J. Patarin. Both are digital signature schemes. They belong to the group of multivariate cryptography. The security of this signature scheme is based on an NP-hard mathematical problem." — http://en.wikipedia.org/wiki/Unbalanced_Oil_and_Vinegar
09:13:19gmaxwell:nsh: not that particular one.
09:18:45gmaxwell:There are people who want to propose extensions in http2 to explicitly enabled MITM by "trusted" parties. One issue is that if some 'trusted' MITM screws you over (e.g. replaces your download with a trojan) there is no way to extract a transferrable proof that you can send to a third party to convince them that the MITM was behaving evil. So how good can that trust really be if they can cheat infrequently with basically zero risk? ...
09:18:51gmaxwell:... So one possibility would be an TLS protocol suite that resulted in signing all traffic, so I was pondering how viable that actually could be... You can get an arbritary performance gain by instead of signing the running transcript hash for a single connection you sign a tree root over many connection hashes, but that has ugly implementation requirements... so I was looking into what really fast signature systems existed that ...
09:18:57gmaxwell:... still had small signatures.
09:19:57jrayhawk:gosh, it's almost like we should distribute signed objects
09:20:06jrayhawk:you know, that thing everyone else has been doing for decades
09:20:23gmaxwell:same kinds of considerations apply to future bitcoin potentially, e.g. you could have transitive DOS-banning, e.g. by extracting transcripts that showed particular peers (IDed by keys) misbehaved.
09:20:55gmaxwell:jrayhawk: "signed objects" are mostly a farce online because PKI is nearly a complete failure for fundimentally hard reasons that are unlikely to be solved anytime soon.
09:21:17gmaxwell:(not that it shouldn't be done; but it doesn't especially help)
09:22:53jrayhawk:what failures have you observed in the PGP strong set
09:23:19gmaxwell:jrayhawk: the total lack of anyone verifying signatures.
09:24:31jrayhawk:because i do one heck of a lot of verification of mailing list traffic
09:24:40gmaxwell:For example, for bitcoin-qt-- probably one of the most duh-obvious targets for malicious changes, download rates for pgp signatures are something like under one in 10,000 downloads, and people failed to notice for days when the keys changed without any obvious announcement to one not even connected to anything else.
09:25:04gmaxwell:Thats worse security theater than the TSA.
09:25:11jrayhawk:but most people aren't using direct downloads, they're using distributions
09:26:56gmaxwell:jrayhawk: Of Bitcoin? thats not true. and again, it's security theater there too. For fedora 20 the distribution (which obviously contains the keys used to verify everything else) was signed by a key that was signed by nothing else. I complained... and was told that no no the public key can be found in the same directory as the iso.. gee thanks. Eventually I got someone else at rhat to sign that key, but the signed copy is off on ...
09:27:02gmaxwell:... some url that no one will find, etc.
09:27:21jrayhawk:wait, seriously signed by nothing else?
09:27:38gmaxwell:Or, for example, in gentoo the ebuild rsync stuff isn't actually signed... so while the packages have hashes for their data there is no strong authentication of the builds.
09:29:22jrayhawk:but, regardless, saying "http doesn't need object signing and verification because PKI is broken because look at the things people download over HTTP without verification" is pretty bonkers.
09:29:38jrayhawk:at least we agree it would be an improvement.
09:29:55gmaxwell:jrayhawk: ... Uh. I very very explicitly did not say that.
09:29:57jrayhawk:I come from the debian community, where we use the PGP WOT extensively and quite well.
09:30:03Pan0ram1x:Pan0ram1x is now known as Guest78642
09:31:40gmaxwell:jrayhawk: Not, really, there are plenty of debian people who've signed my keys based on no strong connection. There is really a strong amount of security theater in this space, and not much looking at things with an adversarial perspective. I haven't evaluated the actual in-distro practices in debian, but it's inconceavable to me that they're actually strong when what I have directly evaluated is completely broken and no one even ...
09:31:46gmaxwell:... notices.
09:32:35gmaxwell:WRT the strong set, there are easily compromised RSA512 keys in the PGP strong set, and AFAIK none of the current clients ignore those signatures by default.
09:32:37jrayhawk:Can you point me at the signatures?
09:32:49gmaxwell:jrayhawk: No because I don't want to get specific people in trouble. :)
09:33:05jrayhawk:Yeah, and lots of infrastucture like the WOT toolchains are still using short keyids, which is also embarassing
09:33:15jrayhawk:http://pgp.cs.uu.nl/stats/FEEDBEEF.html because those are pretty easy to make
09:33:39gmaxwell:indeed, (yea, also fedora does this... their website has instructions on 'verifying they keys' which basically tell you to check the short IDs)
09:35:09jrayhawk:So, there's various classes of trust in a signature based on confidence, I could see doing that, at least.
09:35:16jrayhawk:I mean, using a lower class of trust.
09:35:25jrayhawk:Without in-person verification.
09:36:20gmaxwell:which might actually be better than debian ... with a quick glance, I can't find any mention of verifying signatures or keys in the debian install manual: https://www.debian.org/releases/stable/amd64/
09:37:08gmaxwell:jrayhawk: sure but people set the trust flags pretty randomly, I'm not sure that I've ever seen evidence of people using them for anything (and current versions of GPG don't prompt you when signing keys to even set them)
09:38:02gmaxwell:nor does the install page have any links to signatures that I can see: https://www.debian.org/distrib/netinst just an ISO link.
09:39:55gmaxwell:not to mention that zillions of people have access to the debian build hosts, as I understand it. ... and Linux has been chalk full of privledge escilatiation exploits for eons, and the builds are not determinstic, so for all we know the official debian infrastructure is putting out compromised binaries and there would, I think, be no easy way to detect it. Especially on less common architectures.
09:40:34gmaxwell:(don't think I'm ragging on debian here; it's just broken everywhere. I've started trying to verify signatures on everything I download months ago, and it's ... damn near a lost cause, pratically everything is busted)
09:41:24jrayhawk:Huh, the installation manual is no longer pushing jigdo.
09:42:10jrayhawk:I usually use debootstrap directly, myself, but, yeah, that lack of sigs on installation media images is pretty bad.
09:42:15gmaxwell:Plus then everyone pratically has to keep their keys online on single devices.. outside of bitcoin there is basically zero threshold cryptography deployed. Online keys are easily stolen (as we've seen very clearly demonstrated w/ Bitcoin).
09:42:53gmaxwell:jrayhawk: yea, without authenticated install media, it's game over. ... but it's also game over from many other perspectives (e.g. the lack of determinstic install media means that no one can verify the build hosts are doing the right thing)
09:43:57jrayhawk:There's a patchset against GCC for verifiable builds that isn't too big; NixOS is using it IIRC
09:44:01jrayhawk:I have high hopes for them.
09:45:29gmaxwell:jrayhawk: Bitcoin is determinstically built... I believe we were pretty much the first widely used thing that was, and it was a large effort. Hopefully those GCC patches go upstream so that its easier to get more things going that way. (though usually it takes more than GCC, e.g. you need to fake time because of autogenerated data passing timestamps into things)
09:48:26gmaxwell:(and things to prevent the filesystem from influencing file order in archives... or ...)
09:51:26jrayhawk:I suppose if HTTP object signing did become a thing, it would become common for jerks to do machine-automated signing, which would get us back to transport-encryption levels of mediocrity.
09:51:51jrayhawk:manipulating incentives is complicated :/
09:55:28phantomcircuit:gmaxwell, you effectively have to set all keys as ultimately trusted in your local keyring to use them
09:55:37phantomcircuit:the gpg wot is horribly broken
09:55:49jrayhawk:GPG is pretty broken in many ways
09:58:30jrayhawk:It's really, really annoying that our only widely used OpenPGP implementation has no library abstraction and melts your computer if you actually try to load the strong set into it.
09:58:38gmaxwell:yea, I know. I mean I use this stuff too. But I have little doubt that state level attackers either have or easily could have my keys or any of many other people. ... I'd like to point out that better crypto could help (non-interactive forward secrecy, threshold cryptography, etc.), but it seems we can't even get the implementation basics right for the constructs we have now... in even _simple_ ways like not using @#*(@ 32 bit IDs ...
09:58:44gmaxwell:... all over the place.
10:02:21jrayhawk:With sufficiently clumsy automated HTTP object signing, XSS could produce a signed certificate revocation.
10:02:37jrayhawk:An egalitarian outlet for blackhat tendencies!
10:03:12gmaxwell:jrayhawk: yea, I've thought about publishing PGP revocations for crackable keys in the strong set... but worried I'd get myself in trouble.
10:03:38jrayhawk:That sounds like a public service.
10:03:49gmaxwell:A while back I cracked some of them and tried contacting some of the key owners in the hopes of writing up an article on how easy RSA-512 cracking had become (this was uh.. probably 2008) but got no responses.
10:04:20gmaxwell:and after a while it became more widely known how easy rsa-512 cracking was, so it stopped being interesting to write about.
10:20:59petertodd:jrayhawk: it's interesting how more than one tor dev I've spoken too firmly believes Werner Koch - gnupg maintainer - is a NSA/BND plant with the goal of ensuring gnupg remains unusable (e.g. strong opposition to any attempt to make it into a library)
10:21:27jrayhawk:holy shit that explains so much
10:22:02petertodd:jrayhawk: it's the thing with the idea of a nsa plant: the most effective ones simply need to ensure that good software can't get written, and exploit the inevitable holes
10:22:24petertodd:jrayhawk: unfortunately often indistinguishable from stupidity...
10:22:48jrayhawk:And there's been mention of meddling with standardization processes, which would also explain one hell of a lot of OpenPGP.
10:22:56moa:the old "incompetent or corrupt argument?"
10:23:09petertodd:and equally unfortunate, is how many kinds of stupidity there are: someone may be perfectly good at crypto math and terrible at software development
10:23:13jrayhawk:Don't have to make it broken, just have to make it unspeakably difficult to implement.
10:23:35gmaxwell:it's all going to be difficult to implement; it's crypto.. and even simple software is widely broken. :)
10:23:45petertodd:jrayhawk: yup, but equally, trying very hard to ensure people don't use OpenPGP and simply reinvent the wheel over and over again is *also* a useful policy goal
10:26:38gmaxwell:who knows. If it helps people to adopt an adversarial posture to assume that random people are NSA plants... then I suppose thats fine.
10:26:39petertodd:gmaxwell: I dunno, the more crypto software I write, the more I think "This isn't *that* bad." - but then again, look at how well I do deadlines...
10:26:44gmaxwell:I suspect reality is probably more boring.
10:27:18gmaxwell:petertodd: well get back to me in 5 years when you've got more of an idea of if any of it was right. :)
10:27:35petertodd:I think the "boring" part of the reality is that all it takes is some subtle efforts rather than actual planted holes
10:27:48gmaxwell:Considering how much stuff out there is just broken ... I dunno.
10:30:23petertodd:gmaxwell: btw, mind merging that BIP draft pull-req so I can say the number is official?
10:30:38gmaxwell:oh sure.
10:34:02petertodd:gmaxwell: thing is, with crypto I get the feeling that how to do things correctly is at least relatively clear, although time consuming; a much better feeling that say my last job where often you had no clue if what you were doing was even possible
10:34:58gmaxwell:petertodd: dunno, been spending a lot of time verifying work on secp256k1 and it almost feels hopeless being confident that it's all exactly right.
10:36:02gmaxwell:Did you know that the curve25519 reference code was broken for a couple years? typo would have made e.g. ~1/2^60pubkeys incorrect.
10:36:41petertodd:gmaxwell: yeah, I'm less confident about consensus; and I am talking about cases where you can use pre-made low-level primitives, which people fail at constantly anyway
10:37:32gmaxwell:the distributed protocols I think are even harder, but its less obvious how doomed we are because so much of the complexity is latent.
10:39:33petertodd:my writeup on how hard consensus is really surprised the non-bitcoin dev I wrote it for... she just didn't get how my CHECKLOCKTIMEVERIFY patch could have almost two orders of magnitude more tests than code until I explained it in detail
10:40:29petertodd:but still, there's *so* much basic stuff that we're also failing at, and shouldn't be, and people view that basic stuff as magic far too often
10:54:50SubCreative:SubCreative is now known as Sub|zzz
11:49:05CoinMuncher:petertodd: gnupg objections to becoming a library might be a general GNU thing. Their compiler (GCC) was deliberately not made as a library or even modular either because of Stallmann politics. Now that LLVM is quickly gaining ground they have started work on making GCC more modular. (I'm not saying their reasoning is good or bad, just saying.)
11:51:54sipa:iirc for gnupg (part of) the reason was that dealing with locked memory was very hard as a library
11:53:26petertodd:yeah, which is silly, as you don't need locked memory for verification, which would be hugely useful as a library
11:53:51petertodd:gpgme for instance leaves out access to huge amounts of the WoT code and other stuff you need to actually use PGP
12:51:11lclc_bnc:lclc_bnc is now known as lclc
13:00:30cbeams_:cbeams_ is now known as cbeams
13:55:25lclc:lclc is now known as lclc_bnc
14:14:34bosma_:bosma_ is now known as bosma
14:17:25kanzure:DHT stuffhttp://www.freedomlayer.org/articles/dht_intro.html https://news.ycombinator.com/item?id=8591782
14:17:38kanzure:DHT stuff http://www.freedomlayer.org/articles/dht_intro.html https://news.ycombinator.com/item?id=8591782 (oops)
14:43:45lclc_bnc:lclc_bnc is now known as lclc
16:50:46fenn:.title http://linux-poetry.com/blog/12/
16:50:46yoleaux:A Note on Deterministic Builds: Morgan (Reece) Phillips @linuxpoetry
16:54:22fenn:https://github.com/mrrrgn/simple-rootkit "Here we'll compile a kernel module which intercepts every "read" system call, searches for a string and replaces it if it looks like the gcc compiler or the python interpreter. This is meant to demonstrate how a compromised system can build a malicious binary from perfectly safe source code."
16:54:46hearn:i've had quite some luck with making java builds reproducible
16:54:53hearn:you don't seem to need a vm
16:58:50fenn:i'm not sure how you verify that builds are deterministic; how do you know you've remove all potential variables?
16:59:16kanzure:at minimum two separate builds should hash the same
17:00:21fenn:but what if the hostname is different, or some path has been changed...
17:00:50kanzure:oops sorry i mean two separate runs of the build process for the same build
17:00:56kanzure:since "build" sometimes means "build artifact"
17:02:45fenn:ccache does something similar in that it hashes intermediate build products; perhaps looking at which build products changed could help narrow down where the changes are introduced
17:04:21fenn:if hash(src1) == hash(src2) then hash(build1) should = hash(build2)
17:05:42kanzure:at the moment bitcoind is using gitian
17:06:43fenn:i wonder if it would be more useful to somehow automatically bug the developers if there is a hash mismatch, so you can gather data on what changed and why, and also uncover any attacks in the wild
17:07:36fenn:of course then you have to verify the automatic bug notification
17:07:48fenn:building on shifting sand :)
17:27:28coutts:From seaman's post: " Put them in the same kind of equation we get a value of bitcoin and that value is a million dollars. Now, you’ll never hear an analyst say this—but I don’t mind this—I could be wrong by 90%, and it’s still worth $100,000." What a blanket statement, that's the dumbest claim I've ever heard.
17:27:42coutts:Woops wrong channel again ha
17:30:50Guest34189:Guest34189 is now known as maaku
17:31:38devrandom:fenn: the gitian process is specifically designed for repeatable builds
19:47:24tromp:what's the best place to find criticism of Eyal&Sirer's proposed Two Phase POW for disincentivizing large mining pools?
19:54:44mappum:has this proposal made any headway? https://gist.github.com/gavinandresen/88be40c141bc67acb247
19:55:02mappum:i don't think i've heard anything about it since that document
19:56:47mappum:(sorry, maybe #bitcoin-dev was a better channel for this question)
20:11:33petertodd:mappum: it's merged
20:11:50Starduster_:Starduster_ is now known as Starduster
20:12:30mappum:petertodd: really? can you point me to a commit? i can't seem to find it
20:12:33petertodd:mappum: blockchain.info/pushtx even relays non-std redeemScripts! and they get mined! really the only thing holding you back from experimenting on mainnet is lack of an actual use-case:)
20:13:13petertodd:mappum: 7f3b4e95695d50a4970e6eb91faa956ab276f161 in git HEAD
20:14:24mappum:oh snap, i didn't realize that happened. thanks! :)
20:15:59petertodd:mappum: do me a favor and comment at the bottom of that page saying it got merged...
20:16:11mappum:good idea
20:17:02amiller:tromp, good question, i don't know if anyone has talked about it
20:17:32petertodd:amiller: I had some criticisms, though I forget if I wrote them down or just told the authors in person
20:17:54amiller:you should write them down, start a bitcointalk post or something and i'll add to it too
20:18:22petertodd:amiller: you writing up something on mining centralization?
20:19:04amiller:actually to be perfectly honest my nonoutsoureable puzzle paper has been rejected 3x times now, but each time i've improve it substantially and resubmitted
20:19:31amiller:a couple of times it got really unfair review IMO.
20:20:00petertodd:heh, sometimes I'm glad my peer reviewers are in the form of angry reddit trolls :P
20:20:23tromp:i'm amending my cuckoo cycle paper and wondering what form their proposal could take with my pow
20:20:45tromp:so i want to be up-to-date about its possible failings
20:21:34tromp:amiller: did yo submit to bitcoin 2015 workshop?
20:22:51amiller:tromp, no, bitcoin'14, ccs, ndss... hopefully oakland
20:23:30amiller:2ppow is compatible with cuckoo cycle, sure
20:28:15gmaxwell:tromp: the primary criticism is that it isn't disincentivizing _large_ pools, it's disincentivizing bascally _all_ pools; and breaking pooling is a cure worse than the disease. It's inherently compatible with any kind of Po*x, since really most of what its doing is blinding if something is a solution or not.
20:29:51amiller:gmaxwell, well that applies to all weak/strong nonoutsourceable puzzles and doesn have anything to do with the 2ppow specifically
20:30:01gmaxwell:Also their specific proposal is broken because of DSA randomization (which makes it not progress free)
20:30:07gmaxwell:amiller: yes sure.
20:30:29gmaxwell:(but it's 'easily' fixed by precommiting to a nonce.)
20:38:43tacotime:https://www.cryptocoinsnews.com/counterparty-recreates-ethereum-bitcoin/ ohhh nooo. not sure how it'd be any better of an idea on bitcoin via coloured coins though.
20:47:10instagibbs:and it indeed appears they are claiming with out a doubt they're using their 12 second block time scheme
20:48:42tacotime:yeah, i don't know how much i trust the assumptions that are in that blog post.
21:16:50tromp:gmaxwell: i don't understand how, but the authors claim in section "Clarification (June 21, 2014)" that they can control X and Y to deter only large pools
21:18:25helo:just make the algorithm emit radiation by necessity, so they have to be widely dispersed to avoid poisoning without costly shielding
21:19:16tromp:their scheme seems to rely on having to do an amount of signature computation that's a significant fraction of the sha256 computation (else only the latter would be outsourced)
21:19:47tromp:which means it won't work well with cuckoo cycle
21:20:19tromp:which does billions of steps before needing a signature
21:21:05gmaxwell:tromp: I thought you were able to pick parameters where you were effectively progress free?
21:21:24tromp:progress-free is a continuous scale, not a binary thing
21:21:55tromp:i aim for a single cuckoo attempt to take a few percent of block interval time
21:22:14gmaxwell:oy, okay. Then indeed you may have issues.
21:24:03phantomcircuit:helo, lol
21:24:27tromp:my latest version of the cuckoo paper describes a way to do dynamic sizing
21:24:50tromp:where the graph size will go up over time
21:25:29tromp:keeping it from being completely progress free
21:26:00tromp:but more importantly preserving the (presumed) memory-hardness
21:31:44coinheavy:Wizards - please check out the research index just released at http://smithandcrown.com/research. We have collected ~170 papers from ~300 authors but I am sure there are more to add. Any feedback or submissions would be much appreciated. The index will be actively maintained.
21:38:34kanzure:all of these papers are on different servers?
21:40:59kanzure:you have a typo "Sythetic Commodity Money"
21:51:39coinheavy:kanzure: thanks for the heads up. I'll clean up that record.
21:52:12coinheavy:kanzure: yes, we are linking to their original hosting locations.
21:52:34kanzure:do you have copies of those pdfs?
21:52:37kanzure:and can you send them to me
21:54:05coinheavy:Much of the research is relatively open but we are not serving files directly ourselves because many of these papers have been published through academic journals. While they're still accessible via urls, wholesale redistribution is not possible for every paper.
22:09:03maaku:maaku is now known as Guest99985
22:37:39Sub|zzz:Sub|zzz is now known as SubCreative
23:03:26zooko`:zooko` is now known as zooko
23:53:11samson2:samson2 is now known as samson_