00:12:30ahmed_:ahmed_ is now known as ahmed_ZzZz
00:13:46moa:just wondering what blockhain-verifying optimised hardware might look like?
00:16:04Emcy:libsecp made out of logic gates
00:17:13moa:something a fpga could do
00:18:07Emcy:an asic could do better
00:18:23Emcy:doesnt seem like a good investment though
00:18:27woah:moa what do you mean by that?
00:18:55Emcy:perhaps 100 years heance when munging your blockchain makes grown men cry
00:19:13phantomcircuit:i'd like to see an fpga implementation
00:19:15phantomcircuit:that would be neat
00:19:24moa:phantomcircuit: me too
00:19:37moa:full chain verification shoot-out race
00:19:47Emcy:but how do you give FPGA fast access to enough storage
00:20:00phantomcircuit:Emcy, storage? what
00:20:09phantomcircuit:you can pipeline the signature verification step
00:20:19phantomcircuit:transaction verification is already pipelined
00:20:24Emcy:do what now
00:20:27moa:25Gb is not that much ...
00:22:36moa:maybe start with an OpenCL gpu implementation of libsecp .... ;)
00:27:39lnovy:lnovy is now known as lnovy`afk
00:29:10Emcy:i think someone said once its not as much faster as youd expect
00:32:53wallet421:wallet421 is now known as wallet42
00:33:49moa:should be mostly integer ops?
00:34:29moa:probably better on AMD cypress or similar
00:34:48Emcy:i dont know
00:34:52Emcy:it might not be necessary
00:35:13Emcy:intel for once are just about moving to 8 cores in mainstream
01:01:11petertodd: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:02:32gmaxwell:petertodd: surprising to me; just because it's hard to believe someone noticed the potential of doing something that anyone disliked...
01:02:40petertodd: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:35petertodd:gmaxwell: I was surprised too, but I guess the authorities are smarter than we think
01:03:53gmaxwell:or just read a couple particular mailing lists in the 90s. :(
01:04:17petertodd: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:53kanzure:petertodd: i am doing some hsm things at the moment, shopping around a bit for a vendor
01:05:04lnovy`afk:lnovy`afk is now known as lnovy
01:05:23kanzure:(well really it's a client)
01:05:48petertodd: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:29petertodd:*talking to me re: bitcoin applications
01:09:03kanzure: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:27kanzure:*had to have
01:09:41petertodd:kanzure: yeah, the tech will not run binaries on non-dev-kit hardware unless it's been codesigned by intel
01:10:37petertodd: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:17kanzure:hm, so, how much surface area were you suggesting to them to put in-- like how much software? a full bitcoind node?
01:11:51petertodd:kanzure: simply the ability to run small scripts for business logic, e.g. a Forth interpreter inside a small sandbox
01:11:51kanzure:just the secp256k1 signing?
01:12:41petertodd: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:41gmaxwell:I wonder if this technology made it onto some munitions list.
01:14:59petertodd:gmaxwell: I strongly suspect that's what happened
01:15:26kanzure:aka "the greatest list of toys and goodies you've always wanted"
01:15:41gmaxwell:yea, seen before... some of them are quite interesting.
01:15:53kanzure:"no floating point math over 128 bits rawr"
01:15:59gmaxwell:like "things which I don't think are physically possible. 'hmm'"
01:17:01gmaxwell:(there is some threshold on transistor energy efficiency, IIRC)
01:17:08petertodd:keep in mind some of the items on those lists will be placed there as decoys to obscure what is most important
01:17:32gmaxwell:petertodd: but everyone knows it's all about the speech codecs below 2400 bps. :)
01:17:35kanzure:there's the infosec subsection
01:18:02petertodd:"The cryptographic functionality cannot be
01:18:06petertodd:easily changed by the user;" <- interesting clause
01:18:46kanzure:reading this might be a bad idea if you care about clearances or something, who knows
01:18:49gmaxwell:might be less smart, and more over cooked interpertation of a rule.
01:19:51petertodd: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:06gmaxwell:sure sure; but I've certantly had a hard time convincing random-tech-people that remote attest is useful at all.
01:21:41petertodd:yes, but that's random-tech-people - not necessarily the people working at the likes of the NSA
01:22:00gmaxwell: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:17gmaxwell: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:26petertodd: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:48petertodd:gmaxwell: well, the Canadian NSA equivilent CSIS did try to recruit me just after the snowden leaks
01:23:47gmaxwell:yea, that might be really the end of it: keeping things insecure. Not zomg oracles.
01:24:50jgarzik: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:13jgarzik:"keeping things insecure" is just part of maintaining distance between US & "adversaries"
01:25:25petertodd: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:27jgarzik:as the world moves to become more secure, they will raise the bar
01:25:56ericp4:ericp4 has left #bitcoin-wizards
01:26:00jgarzik:"scares the shit out of them" is a little much
01:26:07kanzure: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:41petertodd:kanzure: this wasn't me talking to vendors, this was a startup who was talking to vendors talking to me
01:27:09kanzure:similar situation in my case heh
01:28:55petertodd:jgarzik: if something as simple as secure code execution invites heavy handed bans...
01:29:20kanzure:i'm also curious how much bitcoin-specific software they were looking to put on the device
01:29:54kanzure:oh, "small scripts"
01:30:13kanzure:unfixed, user-defined and possibly changing regularly. hm.
01:30:27petertodd: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:38tacotime:petertodd: i'm not sure how much they dislike it really, the US Navy, Air Force, and DARPA have sponsored ZeroCash
01:30:46tacotime:re: blockchain tech
01:31:08petertodd: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:23kanzure:petertodd: could you elaborate on your argument about that, then. why would it be less secure to do signing on the device?
01:31:30kanzure:*to do a limited set of operations
01:31:42petertodd: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:34petertodd: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:08petertodd: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:10gmaxwell:well I think a HSM without business logic has realtively little value for most bitcoin things.
01:37:22gmaxwell:"I hack your system and now your magic box signs for me, hurrah"
01:37:41kanzure:for real-time transaction signing it is of limited use i think
01:37:45gmaxwell: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:48petertodd:yup, kinda like how HSM's in general tend to be security snake oil because they don't have any business logic
01:38:25kanzure:but it seems to provide defense against a different threat model in the case of offline less-real-time transaction signing
01:39:10gmaxwell: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:50gmaxwell:not worthless, perhaps, but of reduced value. Esp since there are additional risks (e.g. systems you can't effectively backup)
01:41:25gmaxwell: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:07petertodd: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:03petertodd: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:29petertodd: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:13kanzure:this all sounds overly complex
01:46:17kanzure:you should have told them to reduce their scope heh
01:46:32gmaxwell:this all might also explain why IBM seems to fail to market the cryptocard.
01:46:56petertodd: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:36petertodd:gmaxwell: I'll bet you the cryptocard is so old that it's grandfathered in as an exception
01:47:55kanzure:trezor works because it is simple, not because it runs sandboxes etc
01:47:56petertodd:gmaxwell: also, as you know getting dev kits for it isn't easy
01:48:00gmaxwell:they have refreshed it several times though, latest version is pcie and only a couple years old.
01:48:17petertodd:kanzure: we don't know yet that the trezor works...
01:48:25kanzure:good point, i haven't poked at one
01:48:32petertodd:kanzure: putting all the gui code into a sandbox would likely result in a more secure trezor
01:49:14kanzure:yeah but with everyone's track record they will just want to drop in webkit or something /s
01:49:31kanzure:maybe that's too cynical
01:49:36petertodd:kanzure: lol
01:50:51skyraider7: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:43skyraider7: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:38phantomcircuit:skyraider7, an interactive only hsm is useless for high value applications
01:54:11phantomcircuit:an hsm could be used as an accounting system which at least guaranteed that accounts remained in balance
01:59:25kanzure:what would non-interactive be
02:04:35skyraider7: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:34skyraider7:skyraider7 has left #bitcoin-wizards
07:52:16maaku:maaku is now known as Guest14889
08:05:16cameron.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:16cameron.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:16cameron.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:16cameron.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:16cameron.freenode.net:Users on #bitcoin-wizards: andytoshi roasbeef harrow DoctorBTC gmaxwell phantomcircuit HM crescendo pajarillo nsh- bobke [d__d] coryfields sipa espes__
08:18:07fanquake_:fanquake_ is now known as fanquake
09:13:24jrayhawk:/window 8
11:25:20lnovy:lnovy is now known as zz_lnovy
11:32:15zz_lnovy:zz_lnovy is now known as lnovy
12:34:09jgarzik:jgarzik is now known as home_jg
15:03:40maaku:maaku is now known as Guest72851
15:14:02ahmed_ZzZz:ahmed_ZzZz is now known as ahmed_
16:52:42Taek42:Are there secure protocols that make use of orphan blocks?
16:53:48Taek42:IE, when determining the state of the network, you somehow also need to consider all orphan blocks
16:54:04Taek42:or even just some orphan blocks
16:54:28sipa:if it requires you being able to see all orphan blocks, no, because that would require another consensus mechanism
16:55:38sipa: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:57Taek42:so orphan blocks would need to be recognized by the main chain if they were to be secure
16:56:34sipa:if you have blicks that somehow can commit to non-active side branches of itself, yes
16:56:47sipa:sort of resulting in a block DAG
16:57:07sipa:amiller once proposed something like this
16:57:20Taek42:got a link?
16:57:39sipa:where the rate of committed side branches was used to determine the inter block time, optimizing itself for a given % of orphans
16:58:08sipa:which seems like a bad idea for other reasons, as it very strongly encourages miner centralization
16:58:47tromp:Some people, when confronted with a problem, think “I know, I'll use orphans” Now they have two problems.
16:59:18tromp:(my re-take on http://regex.info/blog/2006-09-15/247)
17:00:28sipa:some programmers, when cobfronted with a problem think "i know, i'll use floating point!"; now they have 1.9999997 problems
17:02:11llinus:llinus is now known as Aquent
17:17:18Aquent:Aquent is now known as itsnotlupus
17:30:19itsnotlupus:itsnotlupus is now known as Aquent
18:20:26fanatic:so ripple is taking the edge again
18:53:26helo:like one takes a punch
19:16:23Dizzle__:Dizzle__ is now known as Dizzle
20:32:05Aquent:Aquent is now known as ress
20:32:18ress:ress is now known as Ress
20:54:36home_jg:home_jg is now known as jgarzik
23:29:21ahmed_:ahmed_ is now known as ahmed_ZzZz