| 00:12:30 | ahmed_: | ahmed_ is now known as ahmed_ZzZz |
| 00:13:46 | moa: | just wondering what blockhain-verifying optimised hardware might look like? |
| 00:16:04 | Emcy: | libsecp made out of logic gates |
| 00:17:13 | moa: | something a fpga could do |
| 00:18:07 | Emcy: | an asic could do better |
| 00:18:23 | Emcy: | doesnt seem like a good investment though |
| 00:18:27 | woah: | moa what do you mean by that? |
| 00:18:28 | moa: | right |
| 00:18:55 | Emcy: | perhaps 100 years heance when munging your blockchain makes grown men cry |
| 00:19:13 | phantomcircuit: | i'd like to see an fpga implementation |
| 00:19:15 | phantomcircuit: | that would be neat |
| 00:19:24 | moa: | phantomcircuit: me too |
| 00:19:29 | Emcy: | yes |
| 00:19:37 | moa: | full chain verification shoot-out race |
| 00:19:47 | Emcy: | but how do you give FPGA fast access to enough storage |
| 00:20:00 | phantomcircuit: | Emcy, storage? what |
| 00:20:09 | phantomcircuit: | you can pipeline the signature verification step |
| 00:20:19 | phantomcircuit: | transaction verification is already pipelined |
| 00:20:24 | Emcy: | do what now |
| 00:20:27 | moa: | 25Gb is not that much ... |
| 00:22:36 | moa: | maybe start with an OpenCL gpu implementation of libsecp .... ;) |
| 00:27:39 | lnovy: | lnovy is now known as lnovy`afk |
| 00:29:10 | Emcy: | i think someone said once its not as much faster as youd expect |
| 00:32:53 | wallet421: | wallet421 is now known as wallet42 |
| 00:33:49 | moa: | should be mostly integer ops? |
| 00:34:29 | moa: | probably better on AMD cypress or similar |
| 00:34:48 | Emcy: | i dont know |
| 00:34:52 | Emcy: | it might not be necessary |
| 00:35:13 | Emcy: | intel for once are just about moving to 8 cores in mainstream |
| 01:01:11 | petertodd: | gmaxwell: re: cryptocard, my discussions with someone in the HSM business indicate that there is very strong political pressure to keep remote-attestation tech out of the hands of normal users; IBM only has it because their devices are expensive as hell, and because of grandfathering |
| 01:01:24 | kanzure: | interesting |
| 01:02:32 | gmaxwell: | petertodd: surprising to me; just because it's hard to believe someone noticed the potential of doing something that anyone disliked... |
| 01:02:40 | petertodd: | gmaxwell: e.g. Intel has 99.9% of what it takes to do good remote attestation, but the last 0.1% is quite delibrately turned off and replaced with a model where individual applications are officially vetted by Intel first, and it appears to be unofficially by the US govt |
| 01:03:35 | petertodd: | gmaxwell: I was surprised too, but I guess the authorities are smarter than we think |
| 01:03:53 | gmaxwell: | or just read a couple particular mailing lists in the 90s. :( |
| 01:04:17 | petertodd: | gmaxwell: it tooks me literally hours of frustrating phone conversations to get the guy to admit that it was political pressure that was keeping him from offering a half-decent product (he was talking to be re: bitcoin applications) |
| 01:04:53 | kanzure: | petertodd: i am doing some hsm things at the moment, shopping around a bit for a vendor |
| 01:05:04 | lnovy`afk: | lnovy`afk is now known as lnovy |
| 01:05:23 | kanzure: | (well really it's a client) |
| 01:05:48 | petertodd: | gmaxwell: for instance, Intels implementation on their trustzone(?) technology requires you to have Intel sign the binaries for your particular app, and they currently *will not* sign binaries that allow for any type of trusted code execution, e.g. end-user-provided business logic to determine if a Bitcoin transaction should or should not be allowed |
| 01:06:29 | petertodd: | *talking to me re: bitcoin applications |
| 01:09:03 | kanzure: | was this because they wanted to review those binaries themselves? e.g. does signing mean they have to had "certified" the code in some capacity? |
| 01:09:27 | kanzure: | *had to have |
| 01:09:41 | petertodd: | kanzure: yeah, the tech will not run binaries on non-dev-kit hardware unless it's been codesigned by intel |
| 01:10:37 | petertodd: | kanzure: to get certified it sounds like you have to provide intel sourcecode; if the sourcecode allows for any type of remote attest execution, regardless of whether it's in a safe script sandbox or not, not only do they reject your application, but they'll cut off your access to the dev kit |
| 01:11:17 | kanzure: | hm, so, how much surface area were you suggesting to them to put in-- like how much software? a full bitcoind node? |
| 01:11:51 | petertodd: | kanzure: simply the ability to run small scripts for business logic, e.g. a Forth interpreter inside a small sandbox |
| 01:11:51 | kanzure: | just the secp256k1 signing? |
| 01:12:41 | petertodd: | what Intel will allow is things that do signing, and things that implement *fixed* business logic - e.g. don't allow more than xBTC to be spent in y hours. But allowing the end-user to specify those rules is forbidden. |
| 01:14:41 | gmaxwell: | I wonder if this technology made it onto some munitions list. |
| 01:14:59 | petertodd: | gmaxwell: I strongly suspect that's what happened |
| 01:15:02 | kanzure: | http://www.bis.doc.gov/index.php/regulations/commerce-control-list-ccl |
| 01:15:26 | kanzure: | aka "the greatest list of toys and goodies you've always wanted" |
| 01:15:41 | gmaxwell: | yea, seen before... some of them are quite interesting. |
| 01:15:53 | kanzure: | "no floating point math over 128 bits rawr" |
| 01:15:59 | gmaxwell: | like "things which I don't think are physically possible. 'hmm'" |
| 01:17:01 | gmaxwell: | (there is some threshold on transistor energy efficiency, IIRC) |
| 01:17:08 | petertodd: | keep in mind some of the items on those lists will be placed there as decoys to obscure what is most important |
| 01:17:29 | kanzure: | http://www.bis.doc.gov/index.php/forms-documents/doc_download/951-ccl5-pt2 |
| 01:17:32 | gmaxwell: | petertodd: but everyone knows it's all about the speech codecs below 2400 bps. :) |
| 01:17:35 | kanzure: | there's the infosec subsection |
| 01:18:02 | petertodd: | "The cryptographic functionality cannot be |
| 01:18:06 | petertodd: | easily changed by the user;" <- interesting clause |
| 01:18:46 | kanzure: | reading this might be a bad idea if you care about clearances or something, who knows |
| 01:18:49 | gmaxwell: | might be less smart, and more over cooked interpertation of a rule. |
| 01:19:51 | petertodd: | could be - though I think experience shows that while these agencies don't tend to have abilities much beyond what we publicly know is possible, it's also foolish to assume they're dumb |
| 01:21:06 | gmaxwell: | sure sure; but I've certantly had a hard time convincing random-tech-people that remote attest is useful at all. |
| 01:21:41 | petertodd: | yes, but that's random-tech-people - not necessarily the people working at the likes of the NSA |
| 01:22:00 | gmaxwell: | I don't think $authority is dumb, but surprising to see them looking far ahead of even the techy public, at least in niche areas. |
| 01:22:17 | gmaxwell: | But fair enough; one doesn't get an impression of how many petertodds there are at the NSA since the NSA doesn't tend to talk. |
| 01:22:26 | petertodd: | if you're in that environment, it should be pretty obvious to you that remote-attest can lead to more secure systems that are harder to break into, and we know for a fact that keeping things easy to break into is something the US govt spends huge amounts of money on |
| 01:22:48 | petertodd: | gmaxwell: well, the Canadian NSA equivilent CSIS did try to recruit me just after the snowden leaks |
| 01:23:47 | gmaxwell: | yea, that might be really the end of it: keeping things insecure. Not zomg oracles. |
| 01:24:50 | jgarzik: | At a higher level, the US has always tried to maintain Technological Dominance, i.e. make sure CIA/NSA have & know about tech well before any other country |
| 01:25:13 | jgarzik: | "keeping things insecure" is just part of maintaining distance between US & "adversaries" |
| 01:25:25 | petertodd: | I'm sure blockchain tech scares the shit out of them - just look at assange saying publicly how it can be used for truth |
| 01:25:27 | jgarzik: | as the world moves to become more secure, they will raise the bar |
| 01:25:56 | ericp4: | ericp4 has left #bitcoin-wizards |
| 01:26:00 | jgarzik: | "scares the shit out of them" is a little much |
| 01:26:07 | kanzure: | petertodd: how many vendors were you talking with when you were trying to find a solution? did they all shut you down when you said bitcoin, or..? |
| 01:26:41 | petertodd: | kanzure: this wasn't me talking to vendors, this was a startup who was talking to vendors talking to me |
| 01:27:09 | kanzure: | similar situation in my case heh |
| 01:28:55 | petertodd: | jgarzik: if something as simple as secure code execution invites heavy handed bans... |
| 01:29:20 | kanzure: | i'm also curious how much bitcoin-specific software they were looking to put on the device |
| 01:29:54 | kanzure: | oh, "small scripts" |
| 01:30:13 | kanzure: | unfixed, user-defined and possibly changing regularly. hm. |
| 01:30:27 | petertodd: | kanzure: their plan was for it to be extremely specific, basically a wallet with pre-defined logic for how to authenticate transactions - my advice to them was that businesses would need to be able to put some amount of business logic on there if they were actually going to use it securely... which lead to hours of evasive conversations |
| 01:30:38 | tacotime: | petertodd: i'm not sure how much they dislike it really, the US Navy, Air Force, and DARPA have sponsored ZeroCash |
| 01:30:46 | tacotime: | re: blockchain tech |
| 01:31:08 | petertodd: | tacotime: keep in mind that govt is not a monolith, and academic research tends to be free passes that production tech doesn't |
| 01:31:15 | tacotime: | right |
| 01:31:23 | kanzure: | petertodd: could you elaborate on your argument about that, then. why would it be less secure to do signing on the device? |
| 01:31:30 | kanzure: | *to do a limited set of operations |
| 01:31:42 | petertodd: | tacotime: for govt the Intel situation with remote attestation is ideal, because they can still make use of the tech in its full capacity |
| 01:32:34 | petertodd: | kanzure: for example in the case of an exchange, just signing a transaction on demand isn't very useful compared to having some business logic to keep track of what customer balances should be and only sign when balance > 0 (for example) |
| 01:33:08 | petertodd: | kanzure: it's not less secure compared to not using the device at all, but it's much less secure than putting business logic on the device |
| 01:37:10 | gmaxwell: | well I think a HSM without business logic has realtively little value for most bitcoin things. |
| 01:37:22 | gmaxwell: | "I hack your system and now your magic box signs for me, hurrah" |
| 01:37:41 | kanzure: | for real-time transaction signing it is of limited use i think |
| 01:37:45 | gmaxwell: | almost as good as "I hack your box and take your private key"— when you only need a couple signatures to take all the monies. |
| 01:37:48 | petertodd: | yup, kinda like how HSM's in general tend to be security snake oil because they don't have any business logic |
| 01:38:25 | kanzure: | but it seems to provide defense against a different threat model in the case of offline less-real-time transaction signing |
| 01:38:38 | kanzure: | *less-than-real-time |
| 01:39:10 | gmaxwell: | sure but so does a regular PC unplugged from the network. Most of the security there is provided by the offlineness not the hardened hardware |
| 01:39:50 | gmaxwell: | not worthless, perhaps, but of reduced value. Esp since there are additional risks (e.g. systems you can't effectively backup) |
| 01:41:25 | gmaxwell: | hsm plus even minimal business logic is much more powerful... not even really compariable to without. Even dumb business logic, like coding in withdraw limits would severely frustrate attackers. |
| 01:43:07 | petertodd: | gmaxwell: yeah, also this company was looking into client-side HSM tech, e.g. on mobile and desktops, where being able to securely run code on the client with GUI interaction is a huge UX win |
| 01:44:03 | petertodd: | gmaxwell: yet rather than having even just a dumb sandboxed forth that could pop up some GUI elements and ask users questions, they were going to have a complex scheme of hardcoded UI flows that you'd have to pick between, just to avoid any remote-attest code capability |
| 01:45:29 | petertodd: | gmaxwell: (part of why they were talking to me was to figure out what categories of these UI flows they'd implement - my immediate suggestion was to have a generic scripting layer) |
| 01:46:13 | kanzure: | this all sounds overly complex |
| 01:46:17 | kanzure: | you should have told them to reduce their scope heh |
| 01:46:32 | gmaxwell: | this all might also explain why IBM seems to fail to market the cryptocard. |
| 01:46:56 | petertodd: | kanzure: I know, I'm 100% sure they knew too, but it sounds like their options were either "Market a trezor" or "Intel/ARM/etc. will pull your license" |
| 01:47:36 | petertodd: | gmaxwell: I'll bet you the cryptocard is so old that it's grandfathered in as an exception |
| 01:47:55 | kanzure: | trezor works because it is simple, not because it runs sandboxes etc |
| 01:47:56 | petertodd: | gmaxwell: also, as you know getting dev kits for it isn't easy |
| 01:48:00 | gmaxwell: | they have refreshed it several times though, latest version is pcie and only a couple years old. |
| 01:48:17 | petertodd: | kanzure: we don't know yet that the trezor works... |
| 01:48:25 | kanzure: | good point, i haven't poked at one |
| 01:48:32 | petertodd: | kanzure: putting all the gui code into a sandbox would likely result in a more secure trezor |
| 01:49:14 | kanzure: | yeah but with everyone's track record they will just want to drop in webkit or something /s |
| 01:49:31 | kanzure: | maybe that's too cynical |
| 01:49:36 | petertodd: | kanzure: lol |
| 01:50:51 | skyraider7: | HSMs seem most useful when building a system where you want to assume the entry point (like a server) is compromised. if you have bespoke business logic on the HSM, an attacker could still issue unauthorized commands, just more limited ones. |
| 01:51:43 | skyraider7: | form that perspective, having something like a physical button press (ala trezor) or smartcard auth (the bigger HSM boxes) makes sense except for high-volume needs, even if there is no biz logic on the box |
| 01:52:38 | phantomcircuit: | skyraider7, an interactive only hsm is useless for high value applications |
| 01:54:11 | phantomcircuit: | an hsm could be used as an accounting system which at least guaranteed that accounts remained in balance |
| 01:59:25 | kanzure: | what would non-interactive be |
| 02:04:35 | skyraider7: | that works for a bank, but if you're an exchange doing margin trading or something, you then need to verify your margin model on the device.. or maybe more importantly, let your customers verify it |
| 02:31:34 | skyraider7: | skyraider7 has left #bitcoin-wizards |
| 07:52:16 | maaku: | maaku is now known as Guest14889 |
| 08:05:16 | cameron.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
| 08:05:16 | cameron.freenode.net: | Users on #bitcoin-wizards: andy-logbot koshii gloriusAgain vfor Guest14889 AaronvanW brisque mkarrer rfreeman_w x48_ hollandais TheSeven Adlai so zibbo roconnor ericp4 cym cbeams Transisto todaystomorrow jbenet drawingthesun SDCDev p15 emsid Dr-G2 jrayhawk nuke1989 kmels Hunger- fanquake irc88_ devrandom samson_ jchp nsh lnovy pi07r Emcy atgreen wiretapped ahmed_ZzZz napedia dansmith_btc epscy tacotime hguux comboy Starduster skinnkavaj mortale Graftec grandmaster2 |
| 08:05:16 | cameron.freenode.net: | Users on #bitcoin-wizards: LarsLarsen arowser OneFixt _2539 Meeh spinza br4n jgarzik Fistful_of_coins BlueMatt Sangheili dgenr8 go1111111 Logicwax NikolaiToryzin tromp__ nanotube tromp ebfull wizkid057 a5m0 artifexd digitalmagus8 HaltingState prepost mappum Grishnakh altoz iddo starsoccer midnightmagic Adohgg jaekwon Muis berndj-blackout gribble Graet melvster kinlo zenojis [Derek] Dyaheon CryptOprah_ promoJo michagogo btc_ copumpkin pigeons BrainOverfl0w lianj_ |
| 08:05:16 | cameron.freenode.net: | Users on #bitcoin-wizards: UukGoblin optimator wumpus Apocalyptic poggy rs0 jcorgan_ Iriez mr_burdell fluffypony K1773R bbrittain SomeoneWeird forrestv livegnik Anduck amiller Nightwolf Keefe Krellan BigBitz [\\\] Taek42 warren asoltys waxwing EasyAt sl01 Luke-Jr @ChanServ phedny petertodd burcin LaptopZZ danneu catcow TD-Linux lechuga_ abc56889 Guest50253 helo smooth otoburb gwillen kanzure ryan-c nickler_ Alanius Guest47516 throughnothing CodeShark Eliel mmozeiko |
| 08:05:16 | cameron.freenode.net: | Users on #bitcoin-wizards: andytoshi roasbeef harrow DoctorBTC gmaxwell phantomcircuit HM crescendo pajarillo nsh- bobke [d__d] coryfields sipa espes__ |
| 08:18:07 | fanquake_: | fanquake_ is now known as fanquake |
| 09:13:24 | jrayhawk: | /window 8 |
| 09:13:26 | jrayhawk: | whoops |
| 11:25:20 | lnovy: | lnovy is now known as zz_lnovy |
| 11:32:15 | zz_lnovy: | zz_lnovy is now known as lnovy |
| 12:34:09 | jgarzik: | jgarzik is now known as home_jg |
| 15:03:40 | maaku: | maaku is now known as Guest72851 |
| 15:14:02 | ahmed_ZzZz: | ahmed_ZzZz is now known as ahmed_ |
| 16:52:42 | Taek42: | Are there secure protocols that make use of orphan blocks? |
| 16:53:48 | Taek42: | IE, when determining the state of the network, you somehow also need to consider all orphan blocks |
| 16:54:04 | Taek42: | or even just some orphan blocks |
| 16:54:28 | sipa: | if it requires you being able to see all orphan blocks, no, because that would require another consensus mechanism |
| 16:55:38 | sipa: | determining the state of the network based on information that not everyone has seems like a really bad idea if your aim is consensus |
| 16:55:57 | Taek42: | so orphan blocks would need to be recognized by the main chain if they were to be secure |
| 16:56:34 | sipa: | if you have blicks that somehow can commit to non-active side branches of itself, yes |
| 16:56:47 | sipa: | sort of resulting in a block DAG |
| 16:56:54 | Taek42: | right |
| 16:57:07 | sipa: | amiller once proposed something like this |
| 16:57:20 | Taek42: | got a link? |
| 16:57:39 | sipa: | where the rate of committed side branches was used to determine the inter block time, optimizing itself for a given % of orphans |
| 16:58:08 | sipa: | which seems like a bad idea for other reasons, as it very strongly encourages miner centralization |
| 16:58:47 | tromp: | Some people, when confronted with a problem, think “I know, I'll use orphans” Now they have two problems. |
| 16:59:18 | tromp: | (my re-take on http://regex.info/blog/2006-09-15/247) |
| 17:00:28 | sipa: | some programmers, when cobfronted with a problem think "i know, i'll use floating point!"; now they have 1.9999997 problems |
| 17:02:11 | llinus: | llinus is now known as Aquent |
| 17:17:18 | Aquent: | Aquent is now known as itsnotlupus |
| 17:30:19 | itsnotlupus: | itsnotlupus is now known as Aquent |
| 18:20:26 | fanatic: | so ripple is taking the edge again |
| 18:20:43 | fanatic: | http://www.coindesk.com/us-banks-embraced-ripple/ |
| 18:53:26 | helo: | like one takes a punch |
| 19:16:23 | Dizzle__: | Dizzle__ is now known as Dizzle |
| 20:32:05 | Aquent: | Aquent is now known as ress |
| 20:32:18 | ress: | ress is now known as Ress |
| 20:54:36 | home_jg: | home_jg is now known as jgarzik |
| 23:29:21 | ahmed_: | ahmed_ is now known as ahmed_ZzZz |