| 00:28:16 | maaku_: | maaku_ is now known as maaku |
| 00:50:46 | tromp: | interesting whitepaper by Charles Hoskinson at http://www.reddit.com/r/ethereum/comments/2m0j5l/why_was_my_post_removed/ |
| 01:02:06 | pigeons: | suprise, he named it after himself |
| 01:03:32 | wallet421: | wallet421 is now known as wallet42 |
| 01:08:19 | gmaxwell: | 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:15 | gmaxwell: | 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:21 | rusty: | gmaxwell: That's a novel theory at least :) |
| 01:31:04 | dgenr8: | 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:20 | tacotime: | gmaxwell: that's the hoskinson way i would guess. bitshares --> ethereum --> regulation ??? |
| 01:48:46 | tacotime: | and i figure he's already totally cashed out of ethereum |
| 01:49:51 | tacotime: | 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:24 | tacotime: | the whole document is terribly ironic given the history of the ethereum ipo. |
| 01:57:58 | tacotime: | 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:52 | gmaxwell: | It's just very weird. |
| 01:59:13 | gmaxwell: | I wonder if it actually was written by him, and isn't instead a really clever attack. |
| 02:00:56 | penny: | penny is now known as Guest71572 |
| 02:10:47 | user7779078: | 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:38 | super3: | its kind of interesting though, both bitshares and ethereum have been quite successful though |
| 02:18:59 | phantomcircuit: | super3, at collecting money |
| 02:19:05 | phantomcircuit: | important to make the distinction |
| 02:19:06 | super3: | yes |
| 02:19:31 | phantomcircuit: | i expect them both to get in huge amounts of trouble |
| 02:21:45 | super3: | i worked at bitshares for a little while |
| 02:25:07 | justanotheruser: | phantomcircuit: aren't they just selling their product? They aren't selling shares in their company. |
| 02:25:24 | super3: | ethereum will be just fine |
| 02:25:39 | phantomcircuit: | justanotheruser, they're not though |
| 02:25:49 | super3: | they are very distributed, and have tons of resources and legal to protect them |
| 02:26:47 | phantomcircuit: | 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:16 | justanotheruser: | phantomcircuit: ok, so there problem is false advertising, not running an IPO. |
| 02:27:18 | phantomcircuit: | and then they did a bunch of legal shenanigans which will look suppper incriminating when they finally do get charged with something |
| 02:28:03 | phantomcircuit: | justanotheruser, what they're doing looks, acts, and quacks like and ipo |
| 02:28:22 | woah: | who? |
| 02:28:22 | phantomcircuit: | if the sec charges them they're going to have a very very hard time refuting the allegation |
| 02:29:05 | phantomcircuit: | justanotheruser, it's arguably fraud, the only distinction is whether they believed they could do it or not |
| 02:29:33 | justanotheruser: | phantomcircuit: what is fraud? them misrepresenting their cryptocurrency? |
| 02:29:36 | phantomcircuit: | their problem is that they were expressing supreme confidence that they can do it |
| 02:29:39 | OP_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:46 | phantomcircuit: | but certainly have internal emails which are less confident |
| 02:29:57 | phantomcircuit: | the distinction could be enough for a fraud suit |
| 02:30:03 | woah: | i gave them btc |
| 02:30:10 | justanotheruser: | woah: I'm sorry |
| 02:30:11 | woah: | i don't mind if it doesn't work out |
| 02:30:38 | woah: | the only thing that would make me mad is if they didnt spend the money on open source software development |
| 02:30:47 | phantomcircuit: | 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:05 | phantomcircuit: | it would literally only take one person to hold them to it |
| 02:32:40 | woah: | idunno man, are you familiar with tech startups? |
| 02:32:48 | justanotheruser: | so are you saying this will be *the* shitshow of altcoins? |
| 02:33:39 | justanotheruser: | 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:55 | phantomcircuit: | woah, sure and any startup which did what they did would endup in jail |
| 02:33:59 | phantomcircuit: | general solicitation |
| 02:34:02 | woah: | what did they do? |
| 02:34:03 | phantomcircuit: | unaccredited investors |
| 02:34:07 | woah: | oh i see |
| 02:34:11 | phantomcircuit: | both serious sec violations |
| 02:34:15 | woah: | aren't they changing those laws? |
| 02:34:31 | phantomcircuit: | woah, not in a way that etherium would be compliant |
| 02:34:38 | OP_NULL: | doesn't matter if the law changes after the fact anyway. |
| 02:34:41 | user7779078: | and the SEC has stalled those for month |
| 02:34:44 | user7779078: | months* |
| 02:34:48 | phantomcircuit: | general solicitation will be allowed through registered broker/dealers |
| 02:35:04 | phantomcircuit: | investor restrictions will be relaxed within limits through registered broker/dealers |
| 02:35:05 | woah: | so this is about accreditation? |
| 02:35:05 | justanotheruser: | poor vitalek then |
| 02:35:14 | phantomcircuit: | notice this all requires you use a registered broker/dealer |
| 02:35:46 | woah: | so, any coin ipo then? |
| 02:35:49 | phantomcircuit: | woah, accredited investor basically means someone with enough money that the sec isn't going to protect them from themself |
| 02:36:07 | phantomcircuit: | woah, if you build the software AND THEN sell the coins |
| 02:36:09 | OP_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:11 | phantomcircuit: | you might be ok |
| 02:36:24 | woah: | no startups say that when getting investment |
| 02:36:26 | phantomcircuit: | (notice the might, that is super important here...0 |
| 02:36:31 | woah: | seems to work out ok sometimes |
| 02:37:26 | woah: | anyway not trying to argue, we'll see |
| 02:38:28 | woah: | i, personally, have no great love for accreditation laws |
| 02:38:34 | woah: | woah has left #bitcoin-wizards |
| 02:39:12 | justanotheruser: | phantomcircuit: So what if microsoft had a presale of xboxlive points? |
| 02:39:18 | justanotheruser: | (before the xbox was made)) |
| 02:39:57 | phantomcircuit: | justanotheruser, closed loop presale |
| 02:40:03 | phantomcircuit: | rules are clear |
| 02:40:24 | phantomcircuit: | not convertible, daily sale limits, etc etc |
| 02:40:45 | justanotheruser: | phantomcircuit: not convertible? |
| 02:41:06 | OP_NULL: | phantomcircuit: what part of Ethereum were you saying is impossible? |
| 02:41:30 | phantomcircuit: | justanotheruser, microsoft wont buy your points back |
| 02:41:43 | phantomcircuit: | they will sell you services for the points |
| 02:41:47 | phantomcircuit: | but will not give you cash |
| 02:42:46 | justanotheruser: | phantomcircuit: will ethereum buy my dollars back? |
| 02:43:24 | phantomcircuit: | justanotheruser, ethereum doesn't provide a service in return for ethers |
| 02:43:31 | phantomcircuit: | http://fincen.gov/news_room/nr/html/20111102.html |
| 02:43:58 | phantomcircuit: | justanotheruser, but actually yeah if i was microsoft i would not be preselling xboxlive points |
| 02:44:30 | phantomcircuit: | regardless ethereum didn't follow the closed loop prepaid access requirements either |
| 02:44:45 | phantomcircuit: | specifically the limit of 10k/day/person |
| 02:45:02 | phantomcircuit: | and kyc requirements |
| 02:45:27 | phantomcircuit: | 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:36 | phantomcircuit: | except they have also violated all the rules for doing y |
| 02:45:44 | OP_NULL: | they actually avoided even collecting email addresses, which was a weird choice. |
| 02:46:02 | gmaxwell: | might be forced to return the funds... |
| 02:46:09 | phantomcircuit: | phantomcircuit: what part of Ethereum were you saying is impossible? |
| 02:46:59 | phantomcircuit: | 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:13 | phantomcircuit: | (even then it is likely beyond their abilities) |
| 02:47:38 | phantomcircuit: | 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:46 | phantomcircuit: | i very seriously doubt they match |
| 02:49:02 | phantomcircuit: | anyways standard |
| 02:49:10 | phantomcircuit: | im not a lawyer, im not your lawyer, blah blah |
| 02:49:31 | gmaxwell: | 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:53 | phantomcircuit: | gmaxwell, with asymmetry it's fraud, without it's just being stupid |
| 02:51:44 | phantomcircuit: | the magic of common law systems in which intent matters |
| 02:57:32 | OP_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:32 | maaku: | maaku is now known as Guest34189 |
| 04:51:08 | Pan0ram1x: | Pan0ram1x is now known as Guest36009 |
| 05:20:36 | phantomcircuit: | OP_NULL, the way ethereum did the ether sale is extremely suspicious |
| 05:20:46 | phantomcircuit: | i dont think it's even technically possible for them to do refunds |
| 05:23:36 | OP_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:51 | OP_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:13 | phantomcircuit: | OP_NULL, surely you mean address as sha256(pubkey(k)) |
| 05:29:05 | OP_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:44 | phantomcircuit: | 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:07 | OP_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:58 | phantomcircuit: | OP_NULL, oh |
| 05:36:01 | phantomcircuit: | uh |
| 05:36:21 | phantomcircuit: | they cant correlate them unless you tell them k |
| 05:37:02 | OP_NULL: | yeah. that's the problem. you can sign each address with the other, but that seems terribly messy. |
| 05:39:55 | OP_NULL: | phantomcircuit: https://github.com/ethereum/pyethsaletool/blob/master/pyethsaletool.py#L124 |
| 05:44:00 | phantomcircuit: | sha3 |
| 05:44:01 | phantomcircuit: | wat |
| 05:44:17 | phantomcircuit: | lol @ using unnecessarily bleeding edge crypto |
| 05:44:41 | OP_NULL: | that was when they had SHA3 based proof of work (better than crusty old Bitcoin's SHA256). |
| 05:45:42 | phantomcircuit: | huh |
| 05:46:01 | phantomcircuit: | assuming sha3 isn't broken |
| 05:46:27 | phantomcircuit: | there is no way for them to correlate pubkey(sha3(seed)) with pubkey(sha3(seed+1)) |
| 05:46:34 | phantomcircuit: | unless you give them seedd |
| 05:47:27 | OP_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:12 | OP_NULL: | phantomcircuit: actually that can't be right either. the network will have no knowledge of the ethereum address at all. |
| 06:25:49 | lclc_bnc: | lclc_bnc is now known as lclc |
| 06:51:19 | Taek: | sha3 is bleeding edge crypto? |
| 06:53:42 | OP_NULL: | I don't think it's even finalized yet. |
| 06:54:26 | OP_NULL: | there's a joke there about bleeding edge and sponge functions, but I couldn't make it work. |
| 06:55:07 | Taek: | "The standardization process is in progress as of November 2014" |
| 06:56:22 | BlueMatt: | so....very bleeding edge |
| 07:13:55 | gmaxwell: | yea, they've changed the spec a bit a couple times too. Though mostly changed it back now. |
| 07:29:05 | Taek: | 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:30 | BlueMatt: | over a year is also very bleeding edge crypto.... |
| 08:28:22 | lclc: | lclc is now known as lclc_bnc |
| 08:43:34 | nsh: | in crypto, all the edges are bleeding |
| 08:43:44 | nsh: | 0/4 for TLS frameworks this year \o/ |
| 08:50:17 | phantomcircuit: | nsh, i think libressl will help a lot there |
| 08:50:25 | phantomcircuit: | ssl/tls are massively complicated protocols |
| 08:50:35 | nsh: | * nsh nods |
| 08:50:38 | phantomcircuit: | and it seems like they're willing to break compatibility to fix security issues |
| 08:51:30 | nsh: | i wonder if the internet engineering community might want to take pause to reflect on how things got this bad |
| 08:51:57 | gmaxwell: | no one feels accountable for the whole system. |
| 08:52:19 | nsh: | * nsh nods |
| 08:52:22 | gwillen: | that seems fair, since nobody designed the whole system |
| 08:52:23 | gwillen: | it evolved |
| 08:52:49 | gmaxwell: | 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:27 | BlueMatt: | (or is that just what the nsa wants you to think) |
| 08:56:10 | gmaxwell: | 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:16 | gmaxwell: | ... 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:56:57 | BlueMatt: | whaaa? |
| 08:57:16 | BlueMatt: | ewwww |
| 08:57:27 | gmaxwell: | 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:28 | moa: | it's a mess |
| 08:57:39 | BlueMatt: | http2 needs to switch ports and start over |
| 08:58:09 | gmaxwell: | 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:56 | gmaxwell: | 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:21 | BlueMatt: | gmaxwell: http2:// |
| 08:59:28 | gmaxwell: | unless you also expect urls to change; in which case the protocol will basically never be substantially adopted |
| 08:59:37 | gwillen: | see also ipv6 |
| 08:59:39 | gmaxwell: | since there are kabaziliions of links that will just never get updated. |
| 08:59:42 | gwillen: | |
| 08:59:59 | gmaxwell: | even worse than ipv6, since at least DNS can give you IPv6 addresses right away. :) |
| 09:00:12 | gwillen: | * gwillen nod |
| 09:00:22 | BlueMatt: | meh, lets just reset and start it all over |
| 09:00:30 | moa: | on a sidechain |
| 09:00:31 | phantomcircuit: | gmaxwell, attempt simultaneous connections? |
| 09:00:33 | BlueMatt: | all new browsers, all new web :) |
| 09:00:41 | phantomcircuit: | seems like the only reasonable solution |
| 09:00:43 | gmaxwell: | phantomcircuit: ugh. I suppose you could do that, but ugh. |
| 09:00:53 | phantomcircuit: | i know but... well |
| 09:00:55 | gmaxwell: | well what it actually does is pretty reasonable. |
| 09:01:02 | gmaxwell: | just complex |
| 09:01:29 | gwillen: | isn't "simultaneous connections" even the current workaround for v4 vs v6 being terrible |
| 09:02:02 | moa: | secure handshake is not trivial problem |
| 09:02:15 | phantomcircuit: | gmaxwell, complexity is bad though |
| 09:02:18 | phantomcircuit: | :/ |
| 09:02:34 | phantomcircuit: | every point for reasonableness is lost for complexity |
| 09:03:46 | cbeams_: | cbeams_ is now known as cbeams |
| 09:05:14 | tepper.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:14 | tepper.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:14 | tepper.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:14 | tepper.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:14 | tepper.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:26 | gmaxwell: | 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:23 | nsh: | this one? https://www.google.com/patents/US20080013716 |
| 09:11:30 | phantomcircuit: | gmaxwell, interesting the signatures aren't too big |
| 09:11:40 | phantomcircuit: | but the public keys are huge |
| 09:12:03 | nsh: | .wik Unbalanced oil and vinegar |
| 09:12:04 | yoleaux: | "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:19 | gmaxwell: | nsh: not that particular one. |
| 09:18:45 | gmaxwell: | 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:51 | gmaxwell: | ... 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:57 | gmaxwell: | ... still had small signatures. |
| 09:19:57 | jrayhawk: | gosh, it's almost like we should distribute signed objects |
| 09:20:06 | jrayhawk: | you know, that thing everyone else has been doing for decades |
| 09:20:23 | gmaxwell: | 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:55 | gmaxwell: | 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:17 | gmaxwell: | (not that it shouldn't be done; but it doesn't especially help) |
| 09:22:53 | jrayhawk: | what failures have you observed in the PGP strong set |
| 09:23:19 | gmaxwell: | jrayhawk: the total lack of anyone verifying signatures. |
| 09:24:20 | jrayhawk: | elaborate |
| 09:24:31 | jrayhawk: | because i do one heck of a lot of verification of mailing list traffic |
| 09:24:40 | gmaxwell: | 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:04 | gmaxwell: | Thats worse security theater than the TSA. |
| 09:25:11 | jrayhawk: | but most people aren't using direct downloads, they're using distributions |
| 09:26:56 | gmaxwell: | 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:02 | gmaxwell: | ... some url that no one will find, etc. |
| 09:27:21 | jrayhawk: | wait, seriously signed by nothing else? |
| 09:27:38 | gmaxwell: | 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:22 | jrayhawk: | 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:38 | jrayhawk: | at least we agree it would be an improvement. |
| 09:29:55 | gmaxwell: | jrayhawk: ... Uh. I very very explicitly did not say that. |
| 09:29:57 | jrayhawk: | I come from the debian community, where we use the PGP WOT extensively and quite well. |
| 09:30:03 | Pan0ram1x: | Pan0ram1x is now known as Guest78642 |
| 09:31:40 | gmaxwell: | 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:46 | gmaxwell: | ... notices. |
| 09:32:35 | gmaxwell: | 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:37 | jrayhawk: | Can you point me at the signatures? |
| 09:32:49 | gmaxwell: | jrayhawk: No because I don't want to get specific people in trouble. :) |
| 09:33:05 | jrayhawk: | Yeah, and lots of infrastucture like the WOT toolchains are still using short keyids, which is also embarassing |
| 09:33:15 | jrayhawk: | http://pgp.cs.uu.nl/stats/FEEDBEEF.html because those are pretty easy to make |
| 09:33:39 | gmaxwell: | 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:09 | jrayhawk: | So, there's various classes of trust in a signature based on confidence, I could see doing that, at least. |
| 09:35:16 | jrayhawk: | I mean, using a lower class of trust. |
| 09:35:25 | jrayhawk: | Without in-person verification. |
| 09:36:20 | gmaxwell: | 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:08 | gmaxwell: | 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:02 | gmaxwell: | 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:55 | gmaxwell: | 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:34 | gmaxwell: | (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:05 | moa: | yep |
| 09:41:24 | jrayhawk: | Huh, the installation manual is no longer pushing jigdo. |
| 09:42:10 | jrayhawk: | I usually use debootstrap directly, myself, but, yeah, that lack of sigs on installation media images is pretty bad. |
| 09:42:15 | gmaxwell: | 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:53 | gmaxwell: | 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:57 | jrayhawk: | There's a patchset against GCC for verifiable builds that isn't too big; NixOS is using it IIRC |
| 09:44:01 | jrayhawk: | I have high hopes for them. |
| 09:45:29 | gmaxwell: | 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:26 | gmaxwell: | (and things to prevent the filesystem from influencing file order in archives... or ...) |
| 09:51:26 | jrayhawk: | 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:51 | jrayhawk: | manipulating incentives is complicated :/ |
| 09:55:28 | phantomcircuit: | gmaxwell, you effectively have to set all keys as ultimately trusted in your local keyring to use them |
| 09:55:37 | phantomcircuit: | the gpg wot is horribly broken |
| 09:55:49 | jrayhawk: | GPG is pretty broken in many ways |
| 09:58:30 | jrayhawk: | 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:38 | gmaxwell: | 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:44 | gmaxwell: | ... all over the place. |
| 10:02:21 | jrayhawk: | With sufficiently clumsy automated HTTP object signing, XSS could produce a signed certificate revocation. |
| 10:02:37 | jrayhawk: | An egalitarian outlet for blackhat tendencies! |
| 10:03:12 | gmaxwell: | 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:38 | jrayhawk: | That sounds like a public service. |
| 10:03:49 | gmaxwell: | 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:20 | gmaxwell: | 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:59 | petertodd: | 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:27 | jrayhawk: | holy shit that explains so much |
| 10:22:02 | petertodd: | 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:24 | petertodd: | jrayhawk: unfortunately often indistinguishable from stupidity... |
| 10:22:30 | moa: | lol |
| 10:22:48 | jrayhawk: | And there's been mention of meddling with standardization processes, which would also explain one hell of a lot of OpenPGP. |
| 10:22:56 | moa: | the old "incompetent or corrupt argument?" |
| 10:23:09 | petertodd: | 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:13 | jrayhawk: | Don't have to make it broken, just have to make it unspeakably difficult to implement. |
| 10:23:35 | gmaxwell: | it's all going to be difficult to implement; it's crypto.. and even simple software is widely broken. :) |
| 10:23:45 | petertodd: | 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:38 | gmaxwell: | 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:39 | petertodd: | 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:44 | gmaxwell: | I suspect reality is probably more boring. |
| 10:27:18 | gmaxwell: | 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:35 | petertodd: | I think the "boring" part of the reality is that all it takes is some subtle efforts rather than actual planted holes |
| 10:27:48 | gmaxwell: | Considering how much stuff out there is just broken ... I dunno. |
| 10:30:23 | petertodd: | gmaxwell: btw, mind merging that BIP draft pull-req so I can say the number is official? |
| 10:30:38 | gmaxwell: | oh sure. |
| 10:31:28 | petertodd: | thanks |
| 10:31:29 | gmaxwell: | done. |
| 10:34:02 | petertodd: | 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:58 | gmaxwell: | 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:02 | gmaxwell: | 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:41 | petertodd: | 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:36:47 | petertodd: | ha |
| 10:37:32 | gmaxwell: | 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:33 | petertodd: | 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:29 | petertodd: | 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:50 | SubCreative: | SubCreative is now known as Sub|zzz |
| 11:49:05 | CoinMuncher: | 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:54 | sipa: | iirc for gnupg (part of) the reason was that dealing with locked memory was very hard as a library |
| 11:53:26 | petertodd: | yeah, which is silly, as you don't need locked memory for verification, which would be hugely useful as a library |
| 11:53:51 | petertodd: | gpgme for instance leaves out access to huge amounts of the WoT code and other stuff you need to actually use PGP |
| 12:51:11 | lclc_bnc: | lclc_bnc is now known as lclc |
| 13:00:30 | cbeams_: | cbeams_ is now known as cbeams |
| 13:55:25 | lclc: | lclc is now known as lclc_bnc |
| 14:14:34 | bosma_: | bosma_ is now known as bosma |
| 14:17:25 | kanzure: | DHT stuffhttp://www.freedomlayer.org/articles/dht_intro.html https://news.ycombinator.com/item?id=8591782 |
| 14:17:38 | kanzure: | DHT stuff http://www.freedomlayer.org/articles/dht_intro.html https://news.ycombinator.com/item?id=8591782 (oops) |
| 14:43:45 | lclc_bnc: | lclc_bnc is now known as lclc |
| 16:50:46 | fenn: | .title http://linux-poetry.com/blog/12/ |
| 16:50:46 | yoleaux: | A Note on Deterministic Builds: Morgan (Reece) Phillips @linuxpoetry |
| 16:54:22 | fenn: | 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:46 | hearn: | i've had quite some luck with making java builds reproducible |
| 16:54:53 | hearn: | you don't seem to need a vm |
| 16:58:50 | fenn: | i'm not sure how you verify that builds are deterministic; how do you know you've remove all potential variables? |
| 16:59:16 | kanzure: | at minimum two separate builds should hash the same |
| 17:00:21 | fenn: | but what if the hostname is different, or some path has been changed... |
| 17:00:50 | kanzure: | oops sorry i mean two separate runs of the build process for the same build |
| 17:00:56 | kanzure: | since "build" sometimes means "build artifact" |
| 17:02:45 | fenn: | 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:21 | fenn: | if hash(src1) == hash(src2) then hash(build1) should = hash(build2) |
| 17:05:42 | kanzure: | at the moment bitcoind is using gitian |
| 17:06:22 | kanzure: | https://gist.github.com/devrandom/806265 |
| 17:06:43 | fenn: | 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:36 | fenn: | of course then you have to verify the automatic bug notification |
| 17:07:48 | fenn: | building on shifting sand :) |
| 17:27:28 | coutts: | 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:42 | coutts: | Woops wrong channel again ha |
| 17:30:50 | Guest34189: | Guest34189 is now known as maaku |
| 17:31:38 | devrandom: | fenn: the gitian process is specifically designed for repeatable builds |
| 19:47:24 | tromp: | what's the best place to find criticism of Eyal&Sirer's proposed Two Phase POW for disincentivizing large mining pools? |
| 19:54:44 | mappum: | has this proposal made any headway? https://gist.github.com/gavinandresen/88be40c141bc67acb247 |
| 19:55:02 | mappum: | i don't think i've heard anything about it since that document |
| 19:56:47 | mappum: | (sorry, maybe #bitcoin-dev was a better channel for this question) |
| 20:11:33 | petertodd: | mappum: it's merged |
| 20:11:50 | Starduster_: | Starduster_ is now known as Starduster |
| 20:12:30 | mappum: | petertodd: really? can you point me to a commit? i can't seem to find it |
| 20:12:33 | petertodd: | 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:13 | petertodd: | mappum: 7f3b4e95695d50a4970e6eb91faa956ab276f161 in git HEAD |
| 20:14:24 | mappum: | oh snap, i didn't realize that happened. thanks! :) |
| 20:15:59 | petertodd: | mappum: do me a favor and comment at the bottom of that page saying it got merged... |
| 20:16:11 | mappum: | good idea |
| 20:17:02 | amiller: | tromp, good question, i don't know if anyone has talked about it |
| 20:17:32 | petertodd: | amiller: I had some criticisms, though I forget if I wrote them down or just told the authors in person |
| 20:17:54 | amiller: | you should write them down, start a bitcointalk post or something and i'll add to it too |
| 20:18:22 | petertodd: | amiller: you writing up something on mining centralization? |
| 20:19:04 | amiller: | 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:31 | amiller: | a couple of times it got really unfair review IMO. |
| 20:20:00 | petertodd: | heh, sometimes I'm glad my peer reviewers are in the form of angry reddit trolls :P |
| 20:20:23 | tromp: | i'm amending my cuckoo cycle paper and wondering what form their proposal could take with my pow |
| 20:20:45 | tromp: | so i want to be up-to-date about its possible failings |
| 20:21:34 | tromp: | amiller: did yo submit to bitcoin 2015 workshop? |
| 20:22:51 | amiller: | tromp, no, bitcoin'14, ccs, ndss... hopefully oakland |
| 20:23:30 | amiller: | 2ppow is compatible with cuckoo cycle, sure |
| 20:28:15 | gmaxwell: | 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:51 | amiller: | gmaxwell, well that applies to all weak/strong nonoutsourceable puzzles and doesn have anything to do with the 2ppow specifically |
| 20:30:01 | gmaxwell: | Also their specific proposal is broken because of DSA randomization (which makes it not progress free) |
| 20:30:07 | gmaxwell: | amiller: yes sure. |
| 20:30:29 | gmaxwell: | (but it's 'easily' fixed by precommiting to a nonce.) |
| 20:38:43 | tacotime: | 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:10 | instagibbs: | and it indeed appears they are claiming with out a doubt they're using their 12 second block time scheme |
| 20:47:26 | instagibbs: | ethereum* |
| 20:48:42 | tacotime: | yeah, i don't know how much i trust the assumptions that are in that blog post. |
| 21:16:50 | tromp: | 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:25 | helo: | just make the algorithm emit radiation by necessity, so they have to be widely dispersed to avoid poisoning without costly shielding |
| 21:19:16 | tromp: | 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:47 | tromp: | which means it won't work well with cuckoo cycle |
| 21:20:19 | tromp: | which does billions of steps before needing a signature |
| 21:21:05 | gmaxwell: | tromp: I thought you were able to pick parameters where you were effectively progress free? |
| 21:21:24 | tromp: | progress-free is a continuous scale, not a binary thing |
| 21:21:55 | tromp: | i aim for a single cuckoo attempt to take a few percent of block interval time |
| 21:22:14 | gmaxwell: | oy, okay. Then indeed you may have issues. |
| 21:24:03 | phantomcircuit: | helo, lol |
| 21:24:27 | tromp: | my latest version of the cuckoo paper describes a way to do dynamic sizing |
| 21:24:50 | tromp: | where the graph size will go up over time |
| 21:25:29 | tromp: | keeping it from being completely progress free |
| 21:26:00 | tromp: | but more importantly preserving the (presumed) memory-hardness |
| 21:31:44 | coinheavy: | 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:34 | kanzure: | all of these papers are on different servers? |
| 21:40:59 | kanzure: | you have a typo "Sythetic Commodity Money" |
| 21:51:39 | coinheavy: | kanzure: thanks for the heads up. I'll clean up that record. |
| 21:52:12 | coinheavy: | kanzure: yes, we are linking to their original hosting locations. |
| 21:52:34 | kanzure: | do you have copies of those pdfs? |
| 21:52:37 | kanzure: | and can you send them to me |
| 21:54:05 | coinheavy: | 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:03 | maaku: | maaku is now known as Guest99985 |
| 22:25:35 | phantomcircuit: | er |
| 22:37:39 | Sub|zzz: | Sub|zzz is now known as SubCreative |
| 23:03:26 | zooko`: | zooko` is now known as zooko |
| 23:53:11 | samson2: | samson2 is now known as samson_ |