| 00:01:06 | gmaxwell: | If your limit is bandwidth vs CPU depends on how much bandwidth you can tolerate the node using. OpenSSL can process signatures at about IIRC 11MBit-of-transaction-data/sec. libsecp256k1, once we can deploy it, increases that about 5-6x-- assuming you have a 3.2GHz quad core cpu dedicated to verifying transactions; and that you never go offline or fall behind (because if the offered load is actua |
| 00:01:12 | gmaxwell: | lly that great you can never catch up if you fall behind). |
| 00:01:45 | gmaxwell: | Also assuming that we never deploy new features that shift the cost per byte processed up at all. E.g. no cryptographic confidentiality for transactions. If we do then that twizzles those numbers around. |
| 00:07:10 | HostFat: | by this way it seems that the problem are the tx that can be too many ... and the blocks are used to limit them on the network, to limit the CPU works on nodes ... |
| 00:07:21 | HostFat: | work* |
| 00:09:37 | HostFat: | it's late here, I'll think about it more tomorrow |
| 00:11:01 | akrmn: | andytoshi: I read most of the sidechains paper (I was talking to you on Saturday). Is a waiting period really necessary? If you force all miners mining on a subchain to also mine on the parent chain, and always take priority of what the parent chain says (in case of conflicts), then I don't see what the problem is. The miners on the parent chain can decide themselves whether to accept a transaction from a child chain, and then the |
| 00:12:47 | gmaxwell: | "if you force"; yes no waiting is required if you eliminate the isolation between the networks (and the system becomes one security domain). Loss of isolation is explicitly called out as a risk in the sidechains whitepaper; because the motivation for the design is to allow a seperation of concerns. |
| 00:13:18 | akrmn: | gmaxwell: But what is the risk to the top chain? |
| 00:13:33 | gmaxwell: | Otherwise it's isomorphic to just softforking in the sidechain into the main chain. Which is what it is. (e.g. brings up the problem that bad software or resource usage causes harm) |
| 00:14:22 | gmaxwell: | akrmn: in that model you cannot mine it (know that it is valid) without validing the data below it, exposing you to the costs and risks asscoiated with doing so. |
| 00:14:55 | akrmn: | gmaxwell: The top chain miners don't have to mine the subchains |
| 00:15:00 | akrmn: | Just the other way around |
| 00:16:06 | akrmn: | Well ya, you can validate the bottom transactions, but it's your choice, and you will get fees if you do, so there's an incentive |
| 00:17:00 | akrmn: | o ok, ya I guess you have to validate |
| 00:17:40 | akrmn: | but if someone pays for a transaction, I don't see any problem with validating it, or any risk, but maybe I'm missing something. |
| 00:18:41 | gmaxwell: | akrmn: "if someone pays" -- they emphatically do not pay, and cannot pay. Every verifier in the network takes the cost of verifying data. Only the miner choosing to admit a transaction can get paid. |
| 00:19:17 | gmaxwell: | So e.g. one party accepts the transaction, gets paid, and 100,000 nodes take a cost. (plus all the future nodes who haven't even joined yet) |
| 00:19:56 | GGuyZ: | gmaxwell: Thanks. I'm actually doing just that, but I also wanted to allow some amount of public verification without sending the entire transcript of commitments and operations (should have been more clear about succinctness). |
| 00:20:22 | akrmn: | well I'll think about it |
| 00:20:53 | GGuyZ: | Anyway, I basically solved it by creating a commitment to the final output (blinding it) and have those shares publicly verifiable (everyone can reconstruct). Then, the entire transcript can also be inspected but only if something seems suspicious. |
| 00:22:43 | nsh: | \o/ |
| 00:22:52 | GGuyZ: | And it is additively homomorphic (simple Shamir's scheme) with multiplication solved using beaver triplets, so it should work. |
| 00:23:33 | GGuyZ: | andytoshi: Thanks as well! Will look into it out of curiosity, though I don't think it's the best fit for my use case. |
| 00:23:38 | nsh: | .wik Beaver triplets cryptography |
| 00:23:39 | yoleaux: | "" — http://en.wikipedia.org/wiki/User:Tompw/Books/Mathematics |
| 00:24:59 | nsh: | (not on wikipedia at all, sadly) |
| 00:25:37 | GGuyZ: | Yeah, it's hard to come by but pretty a pretty common optimization |
| 00:25:42 | GGuyZ: | http://link.springer.com/chapter/10.1007%2F3-540-46766-1_34#page-1 |
| 00:25:55 | GGuyZ: | ^. Unfortunately, it's not open access. |
| 00:26:33 | nsh: | [Beaver and Feigenbaum '00]? |
| 00:26:53 | nsh: | oh, no, more recent |
| 00:27:30 | GGuyZ: | The link I posted |
| 00:27:33 | GGuyZ: | Actually it's older |
| 00:27:56 | GGuyZ: | But became more commonly used in recent years AFAIK. |
| 00:28:42 | GGuyZ: | It's a variation of BGW multiplication protocol |
| 00:30:04 | nsh: | * nsh nods |
| 00:30:29 | nsh: | ah, i recall the BWG honesty bounds |
| 00:30:37 | nsh: | *BGW |
| 00:31:08 | nsh: | ( proved here: https://eprint.iacr.org/2011/136.pdf ) |
| 00:32:06 | gmaxwell: | * gmaxwell hits the words "semi-honest" and closes the window |
| 00:32:22 | gmaxwell: | :P |
| 00:33:07 | gmaxwell: | (not really, just so frustrated by the focus on the useless semi-honest moderl; I do see that that paper (atypically) goes beyond that toy model) |
| 00:35:23 | GGuyZ: | :D |
| 00:35:40 | GGuyZ: | Semi-honest is a great starting point. It just can't be the finish line. |
| 00:36:19 | petertodd: | GGuyZ: semi-honest is a great starting point, in the same way that kindergarden is a solid foundation for a phd |
| 00:36:23 | GGuyZ: | nsh: Yeah, the full proof is surprisingly recent. I even remember reading somewhere that they've been working on it for years. |
| 00:36:49 | GGuyZ: | petertodd: can't argue with that :) |
| 00:37:18 | GGuyZ: | I might actually steal that ;) |
| 00:37:29 | petertodd: | GGuyZ: hehe, go it; I want credit :) |
| 00:38:09 | GGuyZ: | Will be rightfully attributed |
| 00:41:18 | gmaxwell: | GGuyZ: depends on what you're doing, but I usually encounter things where semi-honest is very nearly worthless and where the protocols to boost semi-honest to malicious security dwarf the complexity/assumptions. I think this is actually a serious problem for cryptosystem research which has contributed to the near total lack of industrial deployment. |
| 00:42:05 | gmaxwell: | ... because the research keeps coping up with constructs that engineers respond to "wait, I have to assume they'll follow the protocol? Why don't I just assume they don't keep logs too", and the like. |
| 00:42:19 | GGuyZ: | http://i.imgur.com/q8XPe4s.png?1 <-- petertodd |
| 00:43:10 | jcorgan: | Spherical Cow Syndrome |
| 00:43:52 | GGuyZ: | gmaxwell: I'm inclined to agree. I'd argue that there's a positive change in attitude in recent years (Bitcoin is some sort of a catalyst). |
| 00:44:52 | gmaxwell: | Well at least with Bitcoin I can tell people with complete confidence "I _will_ use this, if it's secure in the malicious model, and won't consider it otherwise." wherease pre-bitcoin it was more like "Maybe I'll use it someday." |
| 00:44:56 | petertodd: | GGuyZ: haha, amazing |
| 00:45:04 | GGuyZ: | I was in SP15 last week and you can see a more realistic attitude in general |
| 00:45:09 | petertodd: | GGuyZ: maybe make my name a shade lighter :P |
| 00:45:38 | gmaxwell: | There are a lot of ZK protocols where the semi-honest is so complex that its complexity alone is a serious impediment to any deployment. |
| 00:45:59 | GGuyZ: | petertodd: Blame those cheap online generators :). Don't worry, if it's ever in my presentation it will be in shining gold :D |
| 00:46:09 | petertodd: | GGuyZ: heh |
| 00:46:59 | GGuyZ: | gmaxwell: Got an example? Anyway, I think part of the problem is the modeling of the assumptions. |
| 00:48:04 | GGuyZ: | They are either too strict for proving correctness or too light like semi-honest. In any case, they tend to become so detached from real-world assumptions that they stay within the community |
| 00:48:21 | GGuyZ: | research community that is, but are never deployed. |
| 00:49:55 | gmaxwell: | GGuyZ: well people also like showing properties that are needlessly strong. Like, there is a huge emphasis on standard model assumptions, because you can break some random oracle secure protocols in a completely contrived setup. Or some domains focus on information theoretic privacy, which is basically never pratical (any implementation will use a CSPRNG).. and sometimes those decisions force th |
| 00:50:01 | gmaxwell: | ings into a weaker (e.g. semi-honest model). |
| 00:51:32 | GGuyZ: | Exactly, but this is obviously a spectrum. For example, it doesn't make sense to focus on the standard model and I.T security, and then assume semi-honesty. |
| 00:52:13 | gmaxwell: | GGuyZ: I think, in general, that anything more complex than a schnorr signature is complex enough that it risks no one being willing to implement it. You can see this in the wild-- there are basically no implementations for more complex protocols. It's not a bright line, but the space of people willing to implement drops of spectacularly; at about that complexity. (There are exceptions, e.g. pe |
| 00:52:19 | gmaxwell: | rcy++ implements a bunch of non-trivial PIR: But I know of _no_ publically available usable implementations of, say even a simple polynomial private set intersection) |
| 00:52:37 | GGuyZ: | Better to make some realistic model assumptions (random oracle, computational security, CRS, etc ...) and not assume that everyone's following the rules |
| 00:53:18 | nsh: | * nsh is mentally trying to compare gmaxwell's progress-pace frustrations with how people (or himself, at least) felt about the semantic web that never happened |
| 00:53:34 | nsh: | i'd say you're making stellar progress, comparatively |
| 00:54:00 | gmaxwell: | GGuyZ: except people go and do that. They prove in the standard model, and then the lack of a RO ends up needing a trusted setup or a n honest verifier or whatever; which implies semi-honest of some kind. If they instead took an RO assumption, then perhaps the semi-honest falls away. Schnorr ID protocol is an example of this. It's HVZK, but if you repliace the verifier challenge with a random o |
| 00:54:06 | gmaxwell: | racle, you get a schnorr signature and it's secure against a malicious challenger. |
| 00:54:10 | bosma: | bosma is now known as pennies |
| 00:54:17 | pennies: | pennies is now known as bosma |
| 00:54:51 | GGuyZ: | You're preaching to the choir :). |
| 00:55:19 | GGuyZ: | I'm a bit optimistic because there are some (not the majority) that are trying to change that. |
| 00:55:47 | GGuyZ: | Which is something that started less than a decade ago |
| 00:56:32 | GGuyZ: | (and it will probably take some more time before we see things really change in practice) |
| 01:50:42 | c0rw1n: | c0rw1n is now known as c0rw|zZz |
| 02:01:05 | lnovy: | lnovy is now known as zz_lnovy |
| 02:12:43 | nsh: | * nsh rewatches: https://www.youtube.com/watch?v=Y1TxCiOuoYY |
| 02:12:45 | nsh: | .t |
| 02:12:45 | yoleaux: | Wed, 27 May 2015 02:12:45 UTC |
| 02:12:50 | nsh: | .title |
| 02:12:50 | yoleaux: | nsh: Sorry, that command (.title) crashed. |
| 02:13:01 | nsh: | (Winter School on Cryptography: Fully Homomorphic Encryption - Craig Gentry) |
| 02:13:08 | nsh: | inspired by GGuyZ :) |
| 02:13:25 | nsh: | (and other things) |
| 02:15:14 | GGuyZ: | :D |
| 02:18:02 | nsh: | maybe homomorphic encryption and langsec complexity-reduced programming languages will meet in the middle |
| 02:18:04 | nsh: | and we'll have nice things |
| 02:19:10 | nsh: | ( Crema: A Sub-Turing Programming Language -- https://github.com/ainfosec/crema -- http://spw15.langsec.org/slides/torrey-crema-slides.pdf -- http://spw15.langsec.org/papers/torrey-crema.pdf |
| 02:19:11 | nsh: | ) |
| 02:19:37 | nsh: | well, this isn't even a maybe |
| 02:19:44 | GGuyZ: | Hmm |
| 02:19:51 | GGuyZ: | Too bad I missed it |
| 02:20:09 | GGuyZ: | Was presented last week |
| 02:20:32 | nsh: | yeah, i'd have loved to go to that conf. but USA still off-limits for me indefinitely for silly reasons |
| 02:21:25 | nsh: | i'll try and coerce them into having one in europe soon |
| 02:21:35 | zooko: | Hm. |
| 02:21:52 | zooko: | * zooko looks at crema. |
| 02:22:04 | GGuyZ: | I think they mentioned something about having EURO S&P next year |
| 02:22:10 | GGuyZ: | It may have been just a proposal though |
| 02:22:15 | zooko: | * zooko casts Summon Daira. |
| 02:23:03 | zooko: | Hiya tromp! |
| 02:23:49 | daira2: | hello |
| 02:23:58 | gmaxwell: | nsh: interesting link, will read. My frustration is that it appears that to subset far enough to make program _equivilence_ decidable, you have to be very limited. And man, decidablity of equivilence would be really nice. |
| 02:24:07 | tromp__: | hi, Zooko |
| 02:24:08 | zooko: | Hello daira! Sub-Turing proglang for langsec! |
| 02:24:11 | zooko: | /msg daira ( Crema: A Sub-Turing Programming Language -- |
| 02:24:11 | zooko: | https://github.com/ainfosec/crema -- |
| 02:24:11 | zooko: | http://spw15.langsec.org/slides/torrey-crema-slides.pdf -- |
| 02:24:11 | zooko: | http://spw15.langsec.org/papers/torrey-crema.pdf |
| 02:24:17 | zooko: | ha. |
| 02:24:18 | zooko: | * zooko fails at IRC. |
| 02:24:21 | daira2: | thanks! |
| 02:24:34 | GGuyZ: | lol |
| 02:26:08 | gmaxwell: | roconnor ^ the crema links above may be to your interest. |
| 02:27:47 | daira2: | "Whereas traditional verification problems implicitly assume that the underlying computational model of the code they target cannot be substantially simplified, LangSec posits that such simplification can and should be considered for input-parsing routines—as an important step toward security assurance." |
| 02:28:39 | daira2: | btw I think that conventional wisdom about needing Turing-complete languages for most tasks, is entirely wrong... |
| 02:29:00 | daira2: | not just for parsing or input validation, but in general |
| 02:29:28 | zooko: | +1 |
| 02:29:40 | daira2: | * daira2 continues reading |
| 02:29:47 | bsm117532: | Can anyone provide a one-sentence description of how they break turing completeness? I'm at the end of their talk and don't see a concise statement. |
| 02:30:43 | gmaxwell: | daira2: it's trivially probably wrong in the context of Bitcoin Script. The task of bitcoin script is to decide that certian (arbritarily complex) conditions are met for permitting a transaction. _Verification_ of the truth of an NP statement which the prover has a witness to is a task in _P_ itself, not NP. Q.E.D. |
| 02:31:05 | daira2: | actually you need more than a Turing a-machine in many cases (for interaction with an environment and nondeterminism), and less in other cases |
| 02:31:05 | tromp__: | bsm117532: i think they forbid revisiting TM machine states already visited |
| 02:31:23 | gmaxwell: | But that kind of argument isn't constructive, so it doesn't guide e.g. what shape a language should have for optimal expression of the kinds of tests which are useful for transactions. |
| 02:31:33 | GGuyZ: | daira2: +2 |
| 02:33:17 | daira2: | gmaxwell: are you aware of total functional programming? it seems like a good fit here |
| 02:33:38 | gmaxwell: | daira2: I am! this was also maaku's suggestion. |
| 02:33:38 | GGuyZ: | gmaxwell: Could still do a lot more then verifying NP statements. Plenty other problems in P that don't require TC :) |
| 02:33:57 | bsm117532: | tromp__: Is that enough to solve the halting problem? |
| 02:34:45 | gmaxwell: | GGuyZ: I know, I just mean that there is litterally nothing that anyone could ever _require_ of bitcoin script that requires NP; because what bitcoin script is doing is fundimentally verification not computation. |
| 02:34:56 | tromp__: | it would seem to limit runtime to the number of finite control states |
| 02:35:00 | bsm117532: | Revisiting a previously visited state is an indication of an infinite loop. But I can also just write integers to the tape, increasing its length...also doesn't halt. But perhaps it enables provable termination? |
| 02:35:18 | midnightmagic: | hi daira2 I believe this is the first time I've seen you talk in here except for a 'nod' back in december 2013. :) yay welcome. |
| 02:35:55 | daira2: | hi midnightmagic :-) |
| 02:36:04 | zooko: | :-) |
| 02:36:20 | GGuyZ: | Yes yes, I understand. I'm just pointing out the irony of people claiming you need TC for computation. |
| 02:36:25 | bsm117532: | Is daira2 Satoshi!??!! |
| 02:36:40 | daira2: | that would be telling |
| 02:37:10 | GGuyZ: | (for all serious computation that is. For some, that's true) |
| 02:37:35 | gmaxwell: | (I'm mostly making noise because it's a peeve of mine that people talk about turing complete script as if it added capability; ... or as if it were even possible in a pedantic sense (the nodes are time and storage bounded); or as if Bitcoin script were not already equivilent powerful as a particular-time-space-bounded universal turing machine (it has controlled swap, after all)). |
| 02:38:07 | GGuyZ: | Agreed, |
| 02:38:30 | daira2: | so, you probably don't need (and don't want, for security reasons) a very complicated termination prover for Bitcoin scripts |
| 02:38:42 | GGuyZ: | and on another note total functional programming looks cool. |
| 02:39:02 | daira2: | you probably don't even need recursion |
| 02:39:40 | gmaxwell: | And mostly that irritation is because it makes people ignore the really interesting questions that lead to real advancement, like how can we make script more succinct in verification? Or how can a Bitcoin Script be constructed so as to make it most expressive while almost easy to rigorously statically analyize. "Can this contract be executed in a way I don't expect?" |
| 02:39:42 | bsm117532: | gmaxwell: I've long been bothered that the Halting Problem halted serious research into provably-correct code. |
| 02:40:30 | bsm117532: | See also the Godel Incompleteness theorem and all of mathematics throwing their hands up. |
| 02:40:35 | GGuyZ: | If you pay per instruction or some other discrete measure, TC in any case is irrelevant, since that limits the computations anyway |
| 02:40:37 | gmaxwell: | bsm117532: yea, for many things-- esp things like analyizing a smart contract just returning "I cannot tell" is a fine and highly useful result (do not use contracts your tools can't reason about!). |
| 02:40:46 | daira2: | right, static analyzability is really important here |
| 02:41:16 | daira2: | bsm117532: +1! |
| 02:41:36 | gmaxwell: | bsm117532: the interesting thing is how much language design results in sanely constructed ordinary programs returning "I cannot tell"... and I believe that there is a huge potential for impact there. |
| 02:42:01 | gmaxwell: | (er, results in analysis on sanely constructed...) |
| 02:42:44 | daira2: | termination proving is not hard if you require programmers to give loop variants |
| 02:42:48 | GGuyZ: | Isn't there research on bounded provably correct code? |
| 02:43:29 | bsm117532: | Provable complexity tied to a calculated tx fee by static analysis would be way better than Ethereum's "gas" (and having it run out on non-halting TC code) |
| 02:43:31 | gmaxwell: | plus human factors considerations, IMO Bitcoin script is actually really readable with a bit of practice (e.g. if you're already comfortable with HP calculators and RPL); but type ambiguity makes it harder to reason about formally. |
| 02:43:57 | tromp__: | the simply typed lambda calculus is strongly normalizing (i.e. total) but still has no reasonable bound on reduction length |
| 02:44:03 | daira2: | anyway, you don't just want termination for this application, you want bounded runtime |
| 02:44:03 | gmaxwell: | bsm117532: I dunno about that, I mean, network consensus normative static analysis sounds like "box of dragons" |
| 02:44:24 | bsm117532: | Indeed. Just a thought. |
| 02:46:35 | daira2: | let's see, I seem to remember reading some research on that topic (bounding runtime) |
| 02:46:52 | daira2: | * daira2 googles |
| 02:47:30 | bsm117532: | I've got a plan brewing to build sidechains with different consensus rules implemented by a virtual machine. |
| 02:48:01 | bsm117532: | It would be very cool if that virtual machine was not turing complete. You don't want to accidentally discover that your consensus rules do not halt. |
| 02:48:34 | daira2: | oh, Lustre and QDDC |
| 02:50:44 | daira2: | but they're more expressive than needed here |
| 02:50:51 | daira2: | we don't need concurrency |
| 02:51:28 | daira2: | * daira2 looks for something simpler |
| 02:53:46 | daira2: | actually I'm too tired right now, will look tomorrow |
| 02:53:57 | daira2: | 'night all |
| 02:54:59 | daira2: | oh, while I remember... |
| 02:56:16 | daira2: | I think it doors make sense to use something similar to Ethereum's gas for dynamic enforcement of a bound on runtime... |
| 02:56:57 | daira2: | s/doors/does/ |
| 02:57:43 | GGuyZ: | The problem is fire and forget. |
| 02:58:03 | GGuyZ: | You need to gamble on how many steps your computation will take |
| 02:58:33 | daira2: | but *also* to statically prove that the runtime check will not fail... |
| 02:59:03 | daira2: | because that way, the consensus rules don't have to be dependent on the static prover |
| 02:59:51 | daira2: | the parties to a contract can agree on a prover independently of anyone else |
| 03:00:11 | GGuyZ: | You mean having a prover that's not the signer of the tx? |
| 03:03:06 | daira2: | probably there would be some library of available provers, and the parties to a smart contract would just pick one that was powerful enough to prove that that particular contract will not run out of gas |
| 03:04:13 | zooko: | gotta run you awesome folks. |
| 03:04:28 | daira2: | but a bug in one of those provers wouldn't be disastrous, it would only affect contracts that has relied on it (and most contracts would use a simple one) |
| 03:04:45 | daira2: | s/has/had/ |
| 03:05:00 | daira2: | OK, I need to sleep |
| 03:05:33 | GGuyZ: | That's actually a very interesting idea |
| 03:05:46 | GGuyZ: | g'night |
| 03:05:55 | GGuyZ: | I'm off too. |
| 03:08:43 | daira2: | (that idea doesn't just apply to runtime, it could be used for any similar property) |
| 03:35:15 | gmaxwell: | GGuyZ: what you want, when speficying a contract, is a proof that the witness size/complexity will unconditionally be below some cost tolerance bound. |
| 03:36:01 | gmaxwell: | In Bitcoin Script, as it is today, it's trivial to completely sure of that. |
| 03:38:57 | gmaxwell: | I think total functional languages would also, generally, make it fairly straight forward to reason about the maximum witness size. |
| 03:41:05 | gmaxwell: | As far as resource counters go, there isn't anything fundimentally ugly about them; other than if there is a limit and you don't have the above mentioned analysis, some trickster could get you to agree to a contract where some satisfaction you were counting on (e.g. refund if the counterparty cheats) has an infeasably huge size. |
| 03:41:55 | gmaxwell: | There are pratical challenges with cost metrics in that the correct costing is implementation specific, but the cost behavior is network normative. |
| 03:42:55 | gmaxwell: | (this applies no less to what bitcoin does-- bitcoin already costs out script: just by charging for size; but as the OP_CHECKSIG attacks show, getting the cost weights wrong can have consequences!) |
| 03:44:45 | gmaxwell: | E.g. an example of this is we will eventually deploy improvements to OP_CHECKSIG that make it 6x+ faster. Had it been costed out assuming that it cost 3000x more than a OP_SHA256 after that improvement the costs would be wildly out of whack. |
| 03:45:51 | jae: | jae is now known as Guest42529 |
| 05:13:41 | genecyber: | genecyber is now known as ShannonCode |
| 05:52:29 | frankenmint: | frankenmint has left #bitcoin-wizards |
| 08:05:15 | sinisalo.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:15 | sinisalo.freenode.net: | Users on #bitcoin-wizards: andy-logbot lclc_ ThomasV Mably daira1 mkarrer hktud0 paveljanik arubi_ zooko`` gill3s waxwing spinza b_lumenkraft dc17523be3 ebfull prosodyContext ggreer ShannonCode tromp rht_ [7] PRab moa Dr-G wonk_unit antgreen Guest95228 d1ggy SubCreative melvster rustyn jmcn Hunger- PaulCapestany Adlai sparetire_ akrmn Luke-Jr maraoz ttttemp_ LeMiner c0rw|zZz Iriez thrasher` Relos Pan0ram1x go1111111 jcorgan zmachine isis dgenr8 nickler Cory cryptowest_ |
| 08:05:15 | sinisalo.freenode.net: | Users on #bitcoin-wizards: gielbier hashtag mengine EasyAt lmatteis Emcy sneak mkarrer_ HM prodatalab__ grandmaster copumpkin cdecker Starduster bsm117532 Apocalyptic zz_lnovy p15 harrigan andytoshi scoria stonecoldpat gavinandresen brand0 larraboj bedeho2 OneFixt luny` superobserver kyletorpey hulkhogan_ gmaxwell vonzipper mappum MoALTz Jouke weex harrow gnusha alferz tromp__ nsh triazo jonasschnelli mountaingoat CryptoGoon wizkid057 berndj leakypat pollux-bts bosma |
| 08:05:15 | sinisalo.freenode.net: | Users on #bitcoin-wizards: platinuum Oizopower jbenet dasource btcdrak tucenaber kyuupichan helo Taek Madars iddo GreenIsMyPepper amiller epscy adams__ wiz michagogo mikolalysenko artifexd dansmith_btc lmacken yrashk cfields Krellan coryfields Meeh catlasshrugged Alanius null_radix kanzure bliljerk_ azariah warptangent sparetire davout comboy TD-Linux yorick crescend1 veox mm_1 Zouppen huseby _whitelogger wumpus binaryatrocity heath BananaLotus maaku face_ [d__d] |
| 08:05:15 | sinisalo.freenode.net: | Users on #bitcoin-wizards: optimator Eliel narwh4l koshii mr_burdell throughnothing_ elastoma fluffypony Fistful_of_Coins yoleaux Jaamg xabbix mariorz catcow a5m0_ smooth dignork runeks Sqt poggy livegnik K1773R petertodd richardus nephyrin phedny so phantomcircuit afdudley pigeons SwedFTP guruvan ajweiss nanotube forrestv Muis warren Xzibit17 sdaftuar eric roasbeef s1w CryptOprah morcos merlincorey [ace] sturles jaromil Graet indolering Keefe ryan-c jessepollak |
| 08:05:15 | sinisalo.freenode.net: | Users on #bitcoin-wizards: gribble d9b4bef9 starsoccer kumavis otoburb midnightmagic BlueMatt Anduck AdrianG BrainOverfl0w @ChanServ gwillen kinlo sl01 STRML espes |
| 08:23:44 | zz_lnovy: | zz_lnovy is now known as lnovy |
| 08:40:17 | nsh: | gmaxwell, zooko``, daira1: passed on your interest in CREMA to Jacob Torrey, perhaps he'll come to discuss it here; else there is [an underpopoulated] #langsec |
| 11:02:16 | c0rw|zZz: | c0rw|zZz is now known as c0rw1n |
| 11:03:45 | LeMiner2: | LeMiner2 is now known as LeMiner |
| 11:36:27 | Apocalyptic_: | Apocalyptic_ is now known as Apocalyptic |
| 12:35:18 | frankenm_: | frankenm_ is now known as frankenmint_ |
| 13:28:41 | frankenmint_: | frankenmint_ has left #bitcoin-wizards |
| 14:31:35 | lnovy: | lnovy is now known as zz_lnovy |
| 14:40:50 | hearn_: | hearn_ is now known as hearn |
| 15:35:40 | jae: | jae is now known as Guest3654 |
| 15:37:02 | c0rw1n: | c0rw1n is now known as c0rw|away |
| 15:39:21 | StephenM347: | If a transaction spends from two outputs with same P2PKH address, then will the SignatureHash (SIGHASH) when signing each of the inputs individually be the same? |
| 15:39:27 | StephenM347: | I assume not |
| 15:39:47 | StephenM347: | Asking because someone found this interesting transaction: https://blockchain.info/tx/9ec4bc49e828d924af1d1029cacf709431abbde46d59554b62bc270e3b29c4b1 |
| 15:40:32 | StephenM347: | It has signatures with the same R values |
| 15:41:20 | StephenM347: | Wondering if it has anything to do with RFC 6979 (deterministic signatures), or if the signer was using bad software that used the same k value in signing |
| 15:46:55 | wumpus: | deterministic signing will indeed generate the same signature twice for the same input data and key. But if it concerns different inputs, different data should be being signed. |
| 15:47:19 | frankenmint: | frankenmint has left #bitcoin-wizards |
| 16:01:11 | StephenM347: | wumpus: makes sense, that transaction must have signed using the same k value |
| 16:01:22 | StephenM347: | to get the same R |
| 16:43:25 | jae: | jae is now known as Guest14004 |
| 17:09:42 | luny``: | luny`` is now known as luny |
| 18:36:38 | maaku: | StephenM347: the input data would not be the same |
| 18:36:53 | maaku: | *the message being signed |
| 18:38:16 | StephenM347: | maaku: Thanks, that's what I though |
| 18:38:21 | StephenM347: | thought |
| 18:38:43 | maaku: | StephenM347: specifically the outpoint of the inputs would be different |
| 18:38:50 | maaku: | different txid:n |
| 19:07:50 | NewLiberty_: | NewLiberty_ is now known as NewLiberty |
| 19:13:21 | akrmn: | As far as I understand, the lightning network is a way of enforcing bitcoin contracts where each transaction in the contract can happen instantaneously. Now, how flexible are these contracts? Can the contract be to put the bitcoin on a sidechain and bring it back when some condition is met? |
| 19:33:20 | ajweiss: | does anyone in here know of any fully open source (no binary drivers) mobile phones that are available in the us? |
| 19:41:28 | gmaxwell: | ajweiss: I think no such beast exists; even the FirefoxOS stuff repackages binary drivers from android because thats the only way to get hardware compatiblity at the moment. |
| 19:41:51 | gmaxwell: | (it wasn't something that could just be fixed until Mozilla has more leverage with hardware makers) |
| 19:42:55 | helo: | * helo rehashes baseband discussion |
| 19:47:16 | ajweiss: | is that still true even if you say "forget the baseband"? |
| 19:48:26 | akrmn1: | I would like to buy a tablet that has the same size and ear speaker as a phone, and just use VoIP. I wonder if there's any good options now. |
| 19:49:10 | ajweiss: | well i'd just like a phone sized device with a working camera and display that is foss. it would make an excellent platform for a secure wallet. |
| 19:49:52 | akrmn1: | ya true |
| 19:50:29 | ajweiss: | all the android devices have silly binary blobs. although there are foss drivers for the display for some.. |
| 19:50:39 | ajweiss: | but really what you need is the camera |
| 19:50:53 | ajweiss: | or... even the audio |
| 20:13:33 | zz_lnovy: | zz_lnovy is now known as lnovy |
| 20:15:57 | lnovy: | lnovy is now known as zz_lnovy |
| 20:49:29 | ggreer: | did you guys see the papers about building time-lock encryption using the blockchain + witness encryption? |
| 20:49:47 | ggreer: | http://eprint.iacr.org/2015/482 |
| 20:49:55 | ggreer: | http://eprint.iacr.org/2015/478 |
| 20:55:08 | zooko: | ggreer: https://twitter.com/socrates1024/status/603027090942767104 |
| 20:57:18 | gmaxwell: | It's come up in here before... but trusted setup makes it much less interesting! |
| 20:57:34 | gmaxwell: | (well the papers haven't but that application of witness encryption has) |
| 20:58:05 | maaku: | i got very excited until i saw the trusted setup :( |
| 21:00:38 | gmaxwell: | maaku: andytoshi has an informal general argument posted someplace that seems pretty convincing that any kind of obfscuation will need trusted setup. |
| 21:02:46 | gmaxwell: | Doesn't make it useless, but the gap over e.g. N of M IBM cryptocards that remote attest to their config and release keys on time; is smaller but substantial: in particular even with trusted _setup_ it removes an availablity attack. |
| 21:04:04 | maaku: | right |
| 21:04:35 | maaku: | but it's not the holy grail of awesomeness it looked like at first ;) |
| 21:05:47 | gmaxwell: | At a protocol level doing a timelock with the bitcoin blockchain is at best non-interactive-SPV secure, with no fraud proof. |
| 21:05:53 | gmaxwell: | so that would be the other limit. |
| 21:07:22 | Luke-Jr: | is a fraud proof needed for this? |
| 21:11:22 | gmaxwell: | It's just a limitation. There is SPV security (trusts the longest chain that you can go out and fined, which is the longest one given a non-parititioning assumption), and non-interactive-SPV-with-fraud-proofs (trusts a sufficiently long chain you've been given, but have an oppturnity to learn about a longer one before its too late (which is the same as the longest given an even stronger non-censo |
| 21:11:28 | gmaxwell: | rship/non-partitioning assumption), vs trust any sufficiently long chain you've been given, regardless of if its the longest or not. If this matters depends on if you're trying to just 'merge-mine' a computational timelock or if you're counting on bitcoin's adaptive difficulty control to make a very long term timelock viable. |
| 21:11:45 | gmaxwell: | In the latter case, the fact that someone could feed the blackbox a fork is a significant limitation. |
| 21:58:36 | antanst: | antanst has left #bitcoin-wizards |
| 22:13:51 | c0rw|away: | c0rw|away is now known as c0rw1n |
| 22:34:54 | jae: | jae is now known as Guest52128 |
| 23:16:13 | bosma: | bosma is now known as Bosnia |
| 23:29:28 | jae: | jae is now known as Guest46054 |