| 00:11:48 | Pan0ram1x: | Pan0ram1x is now known as Guest29578 |
| 03:12:34 | fanquake: | kanzure nice collections |
| 03:12:49 | kanzure: | thank you. |
| 03:13:15 | fanquake: | I know what I’m going to be doing this weekend. |
| 03:13:58 | kanzure: | decisions about what to put in bitcoin/ are very hard to make |
| 03:14:10 | kanzure: | because some of the "cryptocurrency whitepapers" are worthless junk |
| 03:14:24 | kanzure: | but there's some sort of hilarity benefit to archival? and historical-hilarity benefit? i dunno. |
| 03:17:07 | fanquake: | I started collecting papers myself at one point, the best ones are kinda just cluttering up my desktop. |
| 03:19:11 | kanzure: | gimme? |
| 03:20:06 | Luke-Jr: | kanzure: considered adding select papers to bitcoin.ninja? |
| 03:21:19 | gmaxwell: | yea. even a lot of good things are bad. |
| 03:21:44 | gmaxwell: | There are a bunch of papers which present one interesting idea, but also give a very poor, confusing, or incorrect explination of bitcoin. |
| 03:22:07 | gmaxwell: | and the altcoin whitepapers are mostly just halarious. |
| 03:22:43 | gmaxwell: | you know it'll be a riot if it uses the word "emission". |
| 03:22:45 | kanzure: | well here's one, https://github.com/TheBlueMatt/bitcoinninja/pull/6 |
| 03:23:57 | fanquake: | kazure I’ll try figure out which ones, if any, aren’t on your list and let you know. |
| 03:24:09 | fanquake: | Can’t spot this one though http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full.pdf |
| 03:24:26 | kanzure: | fanquake: you may be interested in removing watermarks that identify you as an scholarly traitor by using https://github.com/kanzure/pdfparanoia |
| 03:25:46 | kanzure: | thank you, i will stare at that one for a bit. i am also interested in things that peripherally seem unrelated to bitcoin, because there are more people that have been thinking about cryptography problems for longer than there have been people wondering about bitcoin so far.. |
| 03:25:47 | fanquake: | I’m guessing you’ve already gone though this thread as well. https://bitcointalk.org/index.php?topic=441611.0 |
| 03:26:54 | fanquake: | So papers somewhat like this one http://bojinov.org/professional/usenixsec2012-rubberhose.pdf ? |
| 03:27:14 | kanzure: | yes. exactly. |
| 03:28:51 | phantomcircuit: | you know it'll be a riot if it uses the word "emission". |
| 03:28:53 | phantomcircuit: | huh? |
| 03:29:21 | phantomcircuit: | I start by zooming out and scrolling through, if there's zero code, then i dont even read the introduction |
| 03:29:26 | kanzure: | gmaxwell: i think that "very poor, confusing, or incorrect explanation of bitcoin" might even include the original bitcoin.pdf (i mean, it's not bad, but it leaves a lot of open questions unoutlined) |
| 03:29:44 | gmaxwell: | kanzure: Indeed. |
| 03:30:54 | gmaxwell: | Well I think we have a better-- more general at least-- understanding of the ideas now, so some might be an unfair standard. But the paper is also very high level. I have sympathy, it's too hard for me to write something that both expresses broad highlevel ideas and covers implementations in fine details. |
| 03:31:03 | gmaxwell: | bitcoin whitepaper should have been 6 documents. |
| 03:31:18 | kanzure: | on a non-technical note, it's really interesting to see people reacting to a technology that an extremely small number of people "might possibly" understand. |
| 03:31:24 | sipa: | each one giving an extra confirmation on the previous? |
| 03:31:38 | gmaxwell: | * gmaxwell groans |
| 03:31:39 | kanzure: | there has been cases in the past where only a few people knew about, say, unix, or kernels or something, but that was tens of thousands of people |
| 03:31:56 | sipa: | * sipa confirms the groan |
| 03:32:08 | kanzure: | (and society hasn't really negotiated any particular way to signal to others that "there is almost literally nobody that understands this") |
| 03:32:45 | Luke-Jr: | gmaxwell: of course, Satoshi couldn't have known how big a success it would be (at least with development) |
| 03:33:04 | gmaxwell: | kanzure: I'm glad you reconize this. I've wondered if I've been a bit crazy before when some people are saying bitcoin isn't being adopted fast enough (there is an old argument between hearn and I on bitcoin-development on these lines), and I'm thinking they're nuts, its being adopted far far faster than any technology this new. |
| 03:33:20 | phantomcircuit: | gmaxwell, sure, but it does a great job of explaining high level details and jumping to low level details when necessary |
| 03:34:17 | gmaxwell: | usually adoption and understanding keep pace, but seems bitcoin can be really easily adopted without much understanding. |
| 03:34:32 | sipa: | how many people understand dollars? :p |
| 03:34:37 | Luke-Jr: | gmaxwell: well, there *are* casualties to that :p |
| 03:34:40 | kanzure: | what's there to understand about dollars? |
| 03:34:41 | sipa: | (i don't) |
| 03:35:03 | sipa: | when new money is printed, who gets it? |
| 03:35:46 | gmaxwell: | ssipa: many thousands of people at very deep levels, many tens of thousands at moderate ly deep levels (better than I for sure) |
| 03:35:52 | kanzure: | depends on what you mean by printed |
| 03:36:17 | sipa: | i just gave a question i can't answer - no matter how you interpret it |
| 03:36:25 | gmaxwell: | yea yea sure most of the public has no clue about how the monetary system works in general, but in absolute numbers there are still a lot. |
| 03:36:35 | sipa: | agree |
| 03:36:57 | kanzure: | amusing to note that there are at least four central banks running on top of drupal |
| 03:37:08 | kanzure: | i went looking yesterday because of the latest drupal vulnerability |
| 03:37:34 | gmaxwell: | there is also this element of new systems vs old systems... say there are an equal number of unknowns in something new and something old.. in the old thing the unknowns are less likely to be really important. |
| 03:37:53 | kanzure: | these ones: http://www.eestipank.ee/ http://www.bcb.gob.bo/ http://www.bnm.md/ http://www.cbos.gov.sd/ |
| 03:38:48 | Luke-Jr: | I thought new USD went to miners! |
| 03:38:50 | phantomcircuit: | gmaxwell, what'd you mean about "emission" |
| 03:38:50 | phantomcircuit: | ? |
| 03:39:22 | gmaxwell: | phantomcircuit: it's a word a lot of the sketchier altcoins uses for the initial currency distribution. |
| 03:39:36 | phantomcircuit: | ah |
| 03:39:37 | kanzure: | technically i think it may be safe to say that there is nobody that understands bitcoin completely, right? |
| 03:39:50 | kanzure: | i don't mean ecdsa stuff either |
| 03:40:14 | Luke-Jr: | kanzure: no one person, at least |
| 03:40:14 | kanzure: | like, as long as amiller is still poking around for his security model or whatever, that seems like a fair statement to me |
| 03:40:37 | Luke-Jr: | at the very least, there are unknown unknowns :p |
| 03:40:42 | amiller: | i recommend you not wait for me :p |
| 03:40:49 | kanzure: | oh, i guess i need to put up bounds around "understands" |
| 03:41:05 | kanzure: | too broad etc |
| 03:44:54 | kanzure: | amiller: btw, did you adequately assimilate the consensus set stuff, or the rules around when a consensus is said to exist or not exist between a number of participants? |
| 03:45:57 | amiller: | kanzure, are you talking about ripple |
| 03:46:31 | amiller: | or for bitocin |
| 03:46:39 | kanzure: | no. just referring back to a recent petertodd amiller bitcoin conversation. |
| 03:47:14 | amiller: | https://eprint.iacr.org/2014/765 <-- this is probably the new best distributed consensus theory for bitcoin |
| 03:48:24 | amiller: | it's a lot more thorough than the one from my tech report (but it doesn't really disagree with it or tell anything surprising) |
| 03:51:51 | kanzure: | "the input validation predicate, the input contribution function, and the chain reading function" that's all? what's going on here. |
| 03:54:48 | amiller: | yeah |
| 03:54:54 | amiller: | also the chain quality property |
| 03:57:00 | kanzure: | i would expect it to be a function that has, at minimum, an input of participants or participants beliefs on valid transactions/blocks/etc |
| 03:58:03 | amiller: | there's a notion of input to participants |
| 03:58:12 | amiller: | it's a stream of inputs |
| 03:58:24 | amiller: | "beliefs" of valid transactions doesn't really show up |
| 03:58:36 | amiller: | but there's an input validation function sure |
| 04:01:01 | kanzure: | i have been thinking about a slumbering bitcoin user lately, and i don't know why |
| 04:01:14 | kanzure: | but basically, imagine that a bitcoin user at block height 100k decides to sleep for a bit and reconnect at block height 800k |
| 04:01:31 | kanzure: | where he finds that the network has diverged from the rules that his ideal client implements |
| 04:01:40 | amiller: | kanzure, i really like that idea |
| 04:01:54 | kanzure: | there are certain implications for consensus as for whether he starts mining at some point or what |
| 04:02:22 | kanzure: | because as a small little node, he can't mine anything relevant on his own fork because if he convinces people to join his fork, they will just outcompete/overwrite him but this may or may not be bad |
| 04:02:30 | kanzure: | *block-overwrite |
| 04:02:38 | kanzure: | and i don't know if it's good or bad, in terms of his ideal consensus |
| 04:03:09 | kanzure: | one answer might be "well, his bitcoin is still accessible anyway, even if he might disagree with various hardfork transaction rule stuff" |
| 04:03:19 | kanzure: | "and that should be enough, *grump*" |
| 04:07:00 | amiller: | it's hard to model consensus in the presence of things like changes to the protocol iself |
| 04:07:06 | amiller: | deifnitely no one has modeled that |
| 04:07:37 | kanzure: | protocol changes are almost indistinguishable from noise or attacks or something |
| 04:07:47 | kanzure: | or maybe there is a way to tell that i just don't know yet |
| 04:08:13 | kanzure: | s/protocol/consensus |
| 04:08:45 | amiller: | you can just redefine the protocol so that it has a range of possible changes |
| 04:09:03 | amiller: | that's what's done in Tezos |
| 04:09:14 | kanzure: | gmaxwell: this one is a little "out there" but i'm curious whether it may one day be useful to you, http://diyhpl.us/~bryan/papers2/futurism/Who%20steers%20who%20steers%3f%20A%20note%20on%20identifying%20vulnerable%20moral%20propensities.pdf |
| 04:12:27 | gmaxwell: | kanzure: understanding is a fuzzy thing. But absolutely no one understands it completely, even under a narrow definition of understands like "is not likely to be surprised by the behavior of the system in practice, even absent interactions with other complex systems" |
| 04:13:02 | phantomcircuit: | i do i do throw money at me |
| 04:13:05 | gwillen: | kanzure: the abstract of that paper is very exciting to me, but the lack of listed institutions, the 'futurism' in the url, and the fact that it's only 5 pages long, are not as hopeful |
| 04:13:10 | phantomcircuit: | * phantomcircuit flees the scene |
| 04:13:28 | gmaxwell: | Maybe we have a pretty good highlevel understanding now that absent incentive issues (which import all of humanity into the system) we understand a spherical frictionless bitcoin which can never be authored by a human mind. |
| 04:13:42 | kanzure: | phantomcircuit: you are not so good at fleeing, so far |
| 04:13:56 | phantomcircuit: | kanzure, i haven't much tried |
| 04:14:01 | gmaxwell: | but if you mean the actual implemented bitcoin too, no surprising stuff remains. |
| 04:14:04 | phantomcircuit: | otoh |
| 04:14:06 | phantomcircuit: | try to find me |
| 04:14:25 | kanzure: | i have informants at that company |
| 04:14:30 | phantomcircuit: | lol |
| 04:14:33 | kanzure: | wait, i shouldn't claim that |
| 04:14:39 | gmaxwell: | For example I recently discovered a new cryptographic attack on bitcoin that I'm pretty sure has not been published anywhere before. (fortunately it has complexity ~2^96 or so, so I don't mind mentioning it here) |
| 04:14:58 | gmaxwell: | (I'm planning on writing a tech note on it, but have been so saturated with other writing that I haven't had a chance) |
| 04:16:12 | amiller: | i think a safe thing to admit is that the various efforts of bitcoin formalism have not had any useful payoff yet. which doesn't mean that it's not useful and building up to something better |
| 04:16:14 | phantomcircuit: | gmaxwell, hash or ecdsa? |
| 04:16:46 | kanzure: | amiller: mm, yeah i keep hoping for some equation i can point people to and say "plug your terrible idea into this, and now i wont have to tell you why it's terrible" but.... that's an unreasonable goal. |
| 04:17:00 | amiller: | yeah that's a great goal that's exactly what formalism should help with |
| 04:17:06 | phantomcircuit: | kanzure, you're a dreamer |
| 04:17:09 | kanzure: | yeah but what's the boundary conditions of that |
| 04:17:16 | kanzure: | you can't expect it to defeat all possible bad ideas, for example |
| 04:17:49 | kanzure: | (uh, not that anyone was claiming it would, of course) |
| 04:18:30 | gwillen: | kanzure: it seems like you could arrange for hardforking changes not to create difficult-to-analyze scenarios with old clients |
| 04:18:51 | gmaxwell: | phantomcircuit: not in ecdsa. |
| 04:18:57 | gwillen: | e.g. if you _ever_ emit blocks that a given old client will refuse, you should just mark _all_ your blocks with a version number that will make those clients refuse it |
| 04:19:25 | gwillen: | I think with things like that you could ensure that if a change might break old clients in weird ways, it will instead break them in obvious ways |
| 04:19:26 | gmaxwell: | amiller: thats not quite correct depending on what you mean by "formalizm", roconnor did a bunch of work towards making a COQ implementation and found several important vulnerabilties. |
| 04:19:37 | amiller: | oh yeah. that's a pretty good point |
| 04:20:24 | gmaxwell: | Vs the security games sort of formalism has yielded little concrete, but I think it's still improved understanding. Or at least I can now make much more crisp arguments about issues that were more handwavy in the past. |
| 04:22:01 | gwillen: | gmaxwell: is there a doc somewhere I could read with 'security games' analysis |
| 04:22:21 | kanzure: | "participants are in nash equilibrium!!!!!" done |
| 04:22:31 | kanzure: | i can has phd? |
| 04:22:51 | amiller: | i think the selfish mining paper is pretty useful for defining a security game |
| 04:23:00 | amiller: | sort of |
| 04:23:21 | amiller: | it's not really defining nor security game so i mean something other than what i just said. |
| 04:23:51 | gwillen: | heh. |
| 04:24:19 | gwillen: | I took 'security game' to mean a game-theoretic security analysis |
| 04:24:34 | gmaxwell: | well it's a kind of approach to formalism which I'm perhaps using loosely, I would have included the selfish mining paper or amiller's old consensus document in that bucket. |
| 04:24:47 | gwillen: | i.e. the miner has these plays available at this time |
| 04:24:56 | gwillen: | *nods* |
| 04:30:17 | kanzure: | so what is an old slumbering bitcoiner to do when he wakes up to see that everyone else has been attacked and frauded into joining some silly fork? |
| 04:31:15 | kanzure: | heh i shall dub this "satoshi's nightmare scenario" |
| 04:31:27 | gmaxwell: | continue on in his little sopilistic bubble? |
| 04:31:59 | kanzure: | but his new fork would be attacked pretty quickly if he has any adoption? |
| 04:32:07 | gmaxwell: | ultimately bitcoin depends on peoples willingness to use it and not something else... no one can directly make you use the bogus version, but thats little comfort... |
| 04:32:38 | gmaxwell: | kanzure: even ignoring that, a currency with just you and a couple other hermits using it is basically worthless (and probably not worth attacking either) |
| 04:37:17 | kanzure: | it's interesting that when you connect to a peer node you don't really know what they think "bitcoin" "is" |
| 04:37:59 | kanzure: | (and they could even be lying to you anyway if they were able to tell you somehow) |
| 04:38:19 | kanzure: | (i don't mean the blockchain specifically) |
| 04:38:47 | gmaxwell: | I've commented before that I'd like to have a design where all the rules of the system were bytecoded for a very simple VM, and nodes could just share their bytecode hash. ... obviously someone could like, but the design is robust to malicious parties. |
| 04:39:02 | amiller: | gmaxwell, so you know tezos? |
| 04:39:11 | amiller: | http://tezos.com/ |
| 04:39:14 | Luke-Jr: | it doesn't really make sense to talk about "lying" in this context.. |
| 04:39:20 | Luke-Jr: | it's inherently an opinion |
| 04:39:27 | kanzure: | hm. |
| 04:39:31 | gmaxwell: | amiller: never heard of it. |
| 04:39:32 | kanzure: | that almost sounds dumb? |
| 04:39:43 | gmaxwell: | it's nomic? |
| 04:39:47 | amiller: | yes its nomic |
| 04:40:07 | gmaxwell: | yea, that doesn't actually work unless they've done something remarkable. |
| 04:40:16 | gmaxwell: | that class of ideas runs into problems like POS. |
| 04:40:32 | gmaxwell: | E.g. you simulate the original network changing its rules to BOB RULES EVERYTHING. |
| 04:40:46 | gmaxwell: | and a new party joining can't distinguish the simulation from the real thing. |
| 04:40:53 | amiller: | it's definitely in the same class as everything PoS |
| 04:41:09 | amiller: | which is again why it's so sad we haven't really sorted out a good answer to proof of stake |
| 04:41:13 | gmaxwell: | oh they even describe it like nomic in the abstract. |
| 04:41:22 | amiller: | maybe security games and formalisms will end up being useful to understand proof of stake |
| 04:41:40 | amiller: | unlike bitcoin where we're just barely catching up to what's already shouldering the load of billions of market cap dollars or whatever |
| 04:42:06 | gmaxwell: | the basic stuff about "sign to vote to change the rules" or "miners vote to change the rules" were perrenial proposals on bitcointalk in 2011. though most werenot thought out completely at all. |
| 04:42:52 | kanzure: | were those serious proposals |
| 04:43:10 | gmaxwell: | amiller: seems really clear that POS will need a very different security assumption than bitcoin; so far none of the proposals I've seen have appeared useful at all. I'm sure you're aware of the non-formalized aguments in andytoshis writeup. |
| 04:43:18 | amiller: | yes |
| 04:43:34 | sipa: | https://bitcointalk.org/index.php?topic=54382.0;wap2 |
| 04:43:38 | gmaxwell: | kanzure: by some of their proposers very much so, but often made by not very techincal people who didn't forsee many of the challenges.. so they were obvious non-starers. |
| 04:43:56 | sipa: | (i of course pick the worst example) |
| 04:44:14 | gmaxwell: | sipa: yea, lol. |
| 04:44:36 | gmaxwell: | I like that loading that page gives me a wall of ignored users. |
| 04:44:41 | kanzure: | "It seems to me that some dialect of LISP would be suitable choice." |
| 04:45:11 | kanzure: | man i am going to get a kick out of future markov bots |
| 04:45:13 | amiller: | no ones ever been murdered by time traveling an AI for choosing lisp |
| 04:45:43 | gmaxwell: | hah. maaku's comment.. man, our understanding of the challenges here have come a long way. |
| 04:45:57 | gmaxwell: | At the time of that post I would have probably thought it 10x more reasonable that I would today. |
| 04:47:04 | kanzure: | "That's how we're handling it, combined with a PKI infrastructure." |
| 04:47:12 | gmaxwell: | amiller: thats because in universes where people use lisp succesful AIs are never developed. :) |
| 04:47:49 | gmaxwell: | kanzure: indeed, well that solves the nothing at stake problem. :) |
| 04:49:42 | gmaxwell: | amiller: so what I was referring to wasn't at all as grandiose... it's an implementation idea, basically to try to reduce some the the extreme risk we have today around consensus where people reimplement things and getting multiple consistent implementations of the rules is basically impossible. |
| 04:50:01 | amiller: | oh, got it |
| 04:50:28 | gmaxwell: | so if the kernel which someone reimplements is made as small and simple and testable as possible, and the rest is just an identical bytecode, then maybe we have a fighting chance. :) |
| 04:50:49 | amiller: | yeah |
| 04:50:54 | kanzure: | i keep thinking that the "push a boulder up a hill" route to solving nearly-impossible multiple implementations is to just throw them all in VMs and distribute a giant test environment with a few thousand different implementations, all instrumented |
| 04:50:55 | amiller: | hens coqcoin |
| 04:51:17 | amiller: | hence* nvm |
| 04:51:36 | gmaxwell: | kanzure: doesn't work. input space is too large to test and get reasonable coverage. You can be secure against random errors that way, but not an intelligent attacker. Obviously its better to randomly test than not. |
| 04:52:08 | kanzure: | also depends on what security "guarantees" or statements you're looking to make... |
| 04:52:42 | kanzure: | "eternally correct operation" was and will never be on the table heh |
| 04:53:07 | kanzure: | oh wait. what? |
| 04:53:14 | kanzure: | ah, for testing |
| 04:53:30 | amiller: | there are all sorts of practical appraoches to program analysis |
| 04:53:41 | amiller: | someone should static analyze the bitcoin c++ code even and generate a protocol spec from it |
| 04:53:53 | kanzure: | that's an llvm module, i think. |
| 04:55:00 | sipa: | amiller: if you believe a static analyzer can do that, you haven't seen the bitcoin source code :) |
| 04:56:13 | amiller: | yeah, doing any subset like just the script language one wouldn't have caught the 0.8.4 fork or whichever that one was |
| 04:56:54 | gmaxwell: | amiller: we use static analysis all the time... but it's not very strong (esp against C++ code) |
| 04:57:20 | sipa: | amiller: the bug was in 0.7 code, and relied on configuration settings of the BDB library |
| 04:58:44 | gmaxwell: | The kind of static analysis used for industrial software quality stuff is super weak and hardly goes far beyond "oh see, you wrote (void *)0[0] here and I'm pretty sure thats not right" :) (well somewhat better but not much) |
| 04:59:25 | gmaxwell: | some tools like frama-c let you make stronger assertions about what the code should be doing, but it's C only and is mostly unusable for even slightly complex code. |
| 05:00:22 | gmaxwell: | (basically for anything moderately complex it can't even prove your integers don't overflow, and just drops you into COQ in a sea of automatically generated theorms and asks you to help it complete the proof; at which point the game manual says you must take a shot of vodka, and it all goes down hill from there) |
| 05:03:32 | gmaxwell: | What we want to do when talking about multiple implementations is even worse: We want to prove that two pieces of code, with different architectures, written in different languages (usually), reach the same state (state has a weird definition because its normally implementation defined itself) when given any possible sequence of block inputs... or something like that. |
| 05:20:51 | gwillen: | gmaxwell: you can get around 'state' if you just require that for any sequence of block inputs they both either validate or don't, I think (assuming you're only checking consensus-correctness) |
| 05:21:40 | gwillen: | any 'state' at some time t should be fully captured by some possible block that will validate or fail at some future time t' |
| 05:24:40 | sipa: | if you assume the system correctly deals with reorganizations and timing, the only thing it matters is that it accepts the same sequences of blocks |
| 05:25:04 | gmaxwell: | gwillen: means any future blocks too, past the inputs. |
| 05:25:20 | gmaxwell: | you don't have to clarify if all inputs are infinitely long... :) |
| 05:25:22 | sipa: | future acceptance is captured by the fact that it should be identical to rerunning the validation at that future time with the current blocks + the blocks that have occurred since |
| 05:25:30 | gwillen: | yes, what sipa said |
| 05:25:41 | gwillen: | you don't need infinite inputs |
| 05:25:49 | gwillen: | just induction over infinitely-many possible finite inputs |
| 05:27:19 | gmaxwell: | but what if the difference now has say, an output which is locked to be only spendable 2^31 blocks from now. ... and it forgets that output.. it's undetectable by any block sequence less than that number of blocks long. :) |
| 05:27:48 | gwillen: | well, if you're talking about theorems, you're hopefully proving theorems that are good for any number of blocks |
| 05:27:59 | gwillen: | if you're trying to actually check things mechanically, then I agree you want to check state |
| 05:28:00 | sipa: | which is why it has to be identical for _every_ finite sequence |
| 05:28:07 | gwillen: | rather than waiting for 2^31 blocks to go by :-) |
| 05:38:57 | gmaxwell: | yea, I misunderstood 'infinitely many possible finite' to mean specific a particular finite bound. |
| 05:39:17 | gwillen: | * gwillen nods |
| 08:05:17 | wilhelm.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:17 | wilhelm.freenode.net: | Users on #bitcoin-wizards: andy-logbot tromp_ vmatekole amtri AaronvanW grandmaster2 RoboTeddy profreid super3 NewLiberty jtimon TheSeven davidlatapie coinheavy koshii Dr-G2 d4de^^ Adlai Graftec wiretapped Guest29578 nanotube Starduster go1111111 burcin SDCDev Meeh nuke1989 spinza LarsLarsen samson_ pi07r c0rw1n optimator_ stonecoldpat wumpus Grishnakh alferz mmozeiko epscy jgarzik todaystomorrow wizkid057 Nightwolf grubles berndj forrestv asoltys [d__d] livegnik reick |
| 08:05:17 | wilhelm.freenode.net: | Users on #bitcoin-wizards: tacotime artilectinc nsh Dyaheon DoctorBTC Sangheili lianj Fistful_of_coins myeagleflies SomeoneWeird Krellan shesek CryptOprah altoz Max_H3adr00m Emcy emsid Iriez [Derek] comboy gsdgdfs NikolaiToryzin Anduck HM arowser warren Logicwax coryfields_ [\\\] pigeons xenogis Luke-Jr sipa gmaxwell Taek kanzure iddo_ _2539 LaptopZZ_ lnovy dgenr8 hguux zwischenzug Alanius K1773R phantomcircuit kumavis heath a5m0 andytoshi bobke petertodd BigBitz |
| 08:05:17 | wilhelm.freenode.net: | Users on #bitcoin-wizards: waxwing fanquake espes__ BrainOverfl0w ebfull digitalmagus CodeShark smooth BlueMatt Graet @gwillen sl01 copumpkin artifexd michagogo tromp bbrittain weex gribble Kretchfoop Muis Hunger-- jrayhawk_ firepacket yoleaux hollandais MRL-Relay mappum jbenet zibbo_ Eliel amiller crescendo btc_ kgk coryfields poggy UukGoblin danneu catcow TD-Linux [Tristan] helo otoburb ryan-c roasbeef pajarillo Keefe Gnosis ahmed_ so starsoccer midnightmagic kinlo |
| 08:05:17 | wilhelm.freenode.net: | Users on #bitcoin-wizards: Apocalyptic mr_burdell fluffypony @ChanServ phedny lechuga_ abc56889 throughnothing harrow |
| 08:06:20 | phantomcircuit: | gmaxwell, with static analysis software, can you "help" them by adding conditional restrains on the ranges for values? |
| 08:06:51 | phantomcircuit: | iirc ADA and COBOL both offer that as a way to improve compile time failures |
| 08:08:21 | gmaxwell: | stuff like frama C can. |
| 08:10:35 | gmaxwell: | (also even things like clang-static-analasis are helped by asserts, assuming your assert function is annotated with NORETURN) |
| 08:18:45 | phantomcircuit: | gmaxwell, i guess the problem with using something like that is that the potential space for a hash value is huge |
| 08:21:18 | phantomcircuit: | network/user inputs which could be any value value for the type and stuff |
| 08:52:20 | amtri: | amtri is now known as amdroid |
| 09:49:09 | grandmaster2: | grandmaster2 is now known as dansmith_btc2 |
| 11:01:58 | davidlatapie: | davidlatapie has left #bitcoin-wizards |
| 13:56:57 | fanquake: | fanquake has left #bitcoin-wizards |
| 17:39:54 | Guyver2: | Guyver2 has left #bitcoin-wizards |
| 17:58:26 | Aquent_: | Aquent_ is now known as Aquent |
| 18:38:51 | kumavis: | haay wizards - looking at this chart and trying to understand what happened at 9:45-10:15 this morning https://bitcoinwisdom.com/markets/bitstamp/btcusd |
| 18:39:26 | kumavis: | my guess is that bitcoin wisdom's backend lost connection with bitstamp, so its just missing data for that time |
| 18:39:53 | BlueMatt: | kumavis: verrrryyyy off-topic |
| 18:40:14 | kumavis: | what is the topic? |
| 18:40:32 | BlueMatt: | /topic |
| 18:40:58 | kumavis: | the topic is defined in the negative, so its unclear |
| 18:41:25 | BlueMatt: | http://bitcoin.ninja/ |
| 18:41:31 | BlueMatt: | read those, then come back |
| 18:41:47 | kumavis: | its also using relative language ("short") without context |
| 18:42:19 | kumavis: | so more theory than practice, more longtail than current |
| 18:42:25 | gmaxwell: | kumavis: sorry, bought some bitcoin. |
| 18:42:43 | kumavis: | makes sense, sorry for the noise |
| 21:37:32 | abbursn: | abbursn has left #bitcoin-wizards |