00:11:48Pan0ram1x:Pan0ram1x is now known as Guest29578
03:12:34fanquake:kanzure nice collections
03:12:49kanzure:thank you.
03:13:15fanquake:I know what I’m going to be doing this weekend.
03:13:58kanzure:decisions about what to put in bitcoin/ are very hard to make
03:14:10kanzure:because some of the "cryptocurrency whitepapers" are worthless junk
03:14:24kanzure:but there's some sort of hilarity benefit to archival? and historical-hilarity benefit? i dunno.
03:17:07fanquake:I started collecting papers myself at one point, the best ones are kinda just cluttering up my desktop.
03:20:06Luke-Jr:kanzure: considered adding select papers to bitcoin.ninja?
03:21:19gmaxwell:yea. even a lot of good things are bad.
03:21:44gmaxwell: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:07gmaxwell:and the altcoin whitepapers are mostly just halarious.
03:22:43gmaxwell:you know it'll be a riot if it uses the word "emission".
03:22:45kanzure:well here's one, https://github.com/TheBlueMatt/bitcoinninja/pull/6
03:23:57fanquake:kazure I’ll try figure out which ones, if any, aren’t on your list and let you know.
03:24:09fanquake:Can’t spot this one though http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full.pdf
03:24:26kanzure:fanquake: you may be interested in removing watermarks that identify you as an scholarly traitor by using https://github.com/kanzure/pdfparanoia
03:25:46kanzure: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:47fanquake:I’m guessing you’ve already gone though this thread as well. https://bitcointalk.org/index.php?topic=441611.0
03:26:54fanquake:So papers somewhat like this one http://bojinov.org/professional/usenixsec2012-rubberhose.pdf ?
03:27:14kanzure:yes. exactly.
03:28:51phantomcircuit: you know it'll be a riot if it uses the word "emission".
03:29:21phantomcircuit:I start by zooming out and scrolling through, if there's zero code, then i dont even read the introduction
03:29:26kanzure: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:44gmaxwell:kanzure: Indeed.
03:30:54gmaxwell: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:03gmaxwell:bitcoin whitepaper should have been 6 documents.
03:31:18kanzure: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:24sipa:each one giving an extra confirmation on the previous?
03:31:38gmaxwell:* gmaxwell groans
03:31:39kanzure: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:56sipa:* sipa confirms the groan
03:32:08kanzure:(and society hasn't really negotiated any particular way to signal to others that "there is almost literally nobody that understands this")
03:32:45Luke-Jr:gmaxwell: of course, Satoshi couldn't have known how big a success it would be (at least with development)
03:33:04gmaxwell: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:20phantomcircuit:gmaxwell, sure, but it does a great job of explaining high level details and jumping to low level details when necessary
03:34:17gmaxwell:usually adoption and understanding keep pace, but seems bitcoin can be really easily adopted without much understanding.
03:34:32sipa:how many people understand dollars? :p
03:34:37Luke-Jr:gmaxwell: well, there *are* casualties to that :p
03:34:40kanzure:what's there to understand about dollars?
03:34:41sipa:(i don't)
03:35:03sipa:when new money is printed, who gets it?
03:35:46gmaxwell: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:52kanzure:depends on what you mean by printed
03:36:17sipa:i just gave a question i can't answer - no matter how you interpret it
03:36:25gmaxwell: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:57kanzure:amusing to note that there are at least four central banks running on top of drupal
03:37:08kanzure:i went looking yesterday because of the latest drupal vulnerability
03:37:34gmaxwell: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:53kanzure:these ones: http://www.eestipank.ee/ http://www.bcb.gob.bo/ http://www.bnm.md/ http://www.cbos.gov.sd/
03:38:48Luke-Jr:I thought new USD went to miners!
03:38:50phantomcircuit:gmaxwell, what'd you mean about "emission"
03:39:22gmaxwell:phantomcircuit: it's a word a lot of the sketchier altcoins uses for the initial currency distribution.
03:39:37kanzure:technically i think it may be safe to say that there is nobody that understands bitcoin completely, right?
03:39:50kanzure:i don't mean ecdsa stuff either
03:40:14Luke-Jr:kanzure: no one person, at least
03:40:14kanzure: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:37Luke-Jr:at the very least, there are unknown unknowns :p
03:40:42amiller:i recommend you not wait for me :p
03:40:49kanzure:oh, i guess i need to put up bounds around "understands"
03:41:05kanzure:too broad etc
03:44:54kanzure: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:57amiller:kanzure, are you talking about ripple
03:46:31amiller:or for bitocin
03:46:39kanzure:no. just referring back to a recent petertodd amiller bitcoin conversation.
03:47:14amiller:https://eprint.iacr.org/2014/765 <-- this is probably the new best distributed consensus theory for bitcoin
03:48:24amiller: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:51kanzure:"the input validation predicate, the input contribution function, and the chain reading function" that's all? what's going on here.
03:54:54amiller:also the chain quality property
03:57:00kanzure: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:03amiller:there's a notion of input to participants
03:58:12amiller:it's a stream of inputs
03:58:24amiller:"beliefs" of valid transactions doesn't really show up
03:58:36amiller:but there's an input validation function sure
04:01:01kanzure:i have been thinking about a slumbering bitcoin user lately, and i don't know why
04:01:14kanzure: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:31kanzure:where he finds that the network has diverged from the rules that his ideal client implements
04:01:40amiller:kanzure, i really like that idea
04:01:54kanzure:there are certain implications for consensus as for whether he starts mining at some point or what
04:02:22kanzure: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:38kanzure:and i don't know if it's good or bad, in terms of his ideal consensus
04:03:09kanzure:one answer might be "well, his bitcoin is still accessible anyway, even if he might disagree with various hardfork transaction rule stuff"
04:03:19kanzure:"and that should be enough, *grump*"
04:07:00amiller:it's hard to model consensus in the presence of things like changes to the protocol iself
04:07:06amiller:deifnitely no one has modeled that
04:07:37kanzure:protocol changes are almost indistinguishable from noise or attacks or something
04:07:47kanzure:or maybe there is a way to tell that i just don't know yet
04:08:45amiller:you can just redefine the protocol so that it has a range of possible changes
04:09:03amiller:that's what's done in Tezos
04:09:14kanzure: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:27gmaxwell: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:02phantomcircuit:i do i do throw money at me
04:13:05gwillen: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:10phantomcircuit:* phantomcircuit flees the scene
04:13:28gmaxwell: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:42kanzure:phantomcircuit: you are not so good at fleeing, so far
04:13:56phantomcircuit:kanzure, i haven't much tried
04:14:01gmaxwell:but if you mean the actual implemented bitcoin too, no surprising stuff remains.
04:14:06phantomcircuit:try to find me
04:14:25kanzure:i have informants at that company
04:14:33kanzure:wait, i shouldn't claim that
04:14:39gmaxwell: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:58gmaxwell:(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:12amiller: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:14phantomcircuit:gmaxwell, hash or ecdsa?
04:16:46kanzure: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:00amiller:yeah that's a great goal that's exactly what formalism should help with
04:17:06phantomcircuit:kanzure, you're a dreamer
04:17:09kanzure:yeah but what's the boundary conditions of that
04:17:16kanzure:you can't expect it to defeat all possible bad ideas, for example
04:17:49kanzure:(uh, not that anyone was claiming it would, of course)
04:18:30gwillen:kanzure: it seems like you could arrange for hardforking changes not to create difficult-to-analyze scenarios with old clients
04:18:51gmaxwell:phantomcircuit: not in ecdsa.
04:18:57gwillen: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:25gwillen: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:26gmaxwell: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:37amiller:oh yeah. that's a pretty good point
04:20:24gmaxwell: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:01gwillen:gmaxwell: is there a doc somewhere I could read with 'security games' analysis
04:22:21kanzure:"participants are in nash equilibrium!!!!!" done
04:22:31kanzure:i can has phd?
04:22:51amiller:i think the selfish mining paper is pretty useful for defining a security game
04:23:00amiller:sort of
04:23:21amiller:it's not really defining nor security game so i mean something other than what i just said.
04:24:19gwillen:I took 'security game' to mean a game-theoretic security analysis
04:24:34gmaxwell: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:47gwillen:i.e. the miner has these plays available at this time
04:30:17kanzure: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:15kanzure:heh i shall dub this "satoshi's nightmare scenario"
04:31:27gmaxwell:continue on in his little sopilistic bubble?
04:31:59kanzure:but his new fork would be attacked pretty quickly if he has any adoption?
04:32:07gmaxwell: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:38gmaxwell: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:17kanzure:it's interesting that when you connect to a peer node you don't really know what they think "bitcoin" "is"
04:37:59kanzure:(and they could even be lying to you anyway if they were able to tell you somehow)
04:38:19kanzure:(i don't mean the blockchain specifically)
04:38:47gmaxwell: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:02amiller:gmaxwell, so you know tezos?
04:39:14Luke-Jr:it doesn't really make sense to talk about "lying" in this context..
04:39:20Luke-Jr:it's inherently an opinion
04:39:31gmaxwell:amiller: never heard of it.
04:39:32kanzure:that almost sounds dumb?
04:39:43gmaxwell:it's nomic?
04:39:47amiller:yes its nomic
04:40:07gmaxwell:yea, that doesn't actually work unless they've done something remarkable.
04:40:16gmaxwell:that class of ideas runs into problems like POS.
04:40:32gmaxwell:E.g. you simulate the original network changing its rules to BOB RULES EVERYTHING.
04:40:46gmaxwell:and a new party joining can't distinguish the simulation from the real thing.
04:40:53amiller:it's definitely in the same class as everything PoS
04:41:09amiller:which is again why it's so sad we haven't really sorted out a good answer to proof of stake
04:41:13gmaxwell:oh they even describe it like nomic in the abstract.
04:41:22amiller:maybe security games and formalisms will end up being useful to understand proof of stake
04:41:40amiller: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:06gmaxwell: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:52kanzure:were those serious proposals
04:43:10gmaxwell: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:38gmaxwell: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:56sipa:(i of course pick the worst example)
04:44:14gmaxwell:sipa: yea, lol.
04:44:36gmaxwell:I like that loading that page gives me a wall of ignored users.
04:44:41kanzure:"It seems to me that some dialect of LISP would be suitable choice."
04:45:11kanzure:man i am going to get a kick out of future markov bots
04:45:13amiller:no ones ever been murdered by time traveling an AI for choosing lisp
04:45:43gmaxwell:hah. maaku's comment.. man, our understanding of the challenges here have come a long way.
04:45:57gmaxwell:At the time of that post I would have probably thought it 10x more reasonable that I would today.
04:47:04kanzure:"That's how we're handling it, combined with a PKI infrastructure."
04:47:12gmaxwell:amiller: thats because in universes where people use lisp succesful AIs are never developed. :)
04:47:49gmaxwell:kanzure: indeed, well that solves the nothing at stake problem. :)
04:49:42gmaxwell: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:01amiller:oh, got it
04:50:28gmaxwell: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:54kanzure: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:55amiller:hens coqcoin
04:51:17amiller:hence* nvm
04:51:36gmaxwell: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:08kanzure:also depends on what security "guarantees" or statements you're looking to make...
04:52:42kanzure:"eternally correct operation" was and will never be on the table heh
04:53:07kanzure:oh wait. what?
04:53:14kanzure:ah, for testing
04:53:30amiller:there are all sorts of practical appraoches to program analysis
04:53:41amiller:someone should static analyze the bitcoin c++ code even and generate a protocol spec from it
04:53:53kanzure:that's an llvm module, i think.
04:55:00sipa:amiller: if you believe a static analyzer can do that, you haven't seen the bitcoin source code :)
04:56:13amiller: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:54gmaxwell:amiller: we use static analysis all the time... but it's not very strong (esp against C++ code)
04:57:20sipa:amiller: the bug was in 0.7 code, and relied on configuration settings of the BDB library
04:58:44gmaxwell: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:25gmaxwell: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:22gmaxwell:(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:32gmaxwell: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:51gwillen: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:40gwillen: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:40sipa: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:04gmaxwell:gwillen: means any future blocks too, past the inputs.
05:25:20gmaxwell:you don't have to clarify if all inputs are infinitely long... :)
05:25:22sipa: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:30gwillen:yes, what sipa said
05:25:41gwillen:you don't need infinite inputs
05:25:49gwillen:just induction over infinitely-many possible finite inputs
05:27:19gmaxwell: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:48gwillen:well, if you're talking about theorems, you're hopefully proving theorems that are good for any number of blocks
05:27:59gwillen:if you're trying to actually check things mechanically, then I agree you want to check state
05:28:00sipa:which is why it has to be identical for _every_ finite sequence
05:28:07gwillen:rather than waiting for 2^31 blocks to go by :-)
05:38:57gmaxwell:yea, I misunderstood 'infinitely many possible finite' to mean specific a particular finite bound.
05:39:17gwillen:* gwillen nods
08:05:17wilhelm.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:17wilhelm.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:17wilhelm.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:17wilhelm.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:17wilhelm.freenode.net:Users on #bitcoin-wizards: Apocalyptic mr_burdell fluffypony @ChanServ phedny lechuga_ abc56889 throughnothing harrow
08:06:20phantomcircuit:gmaxwell, with static analysis software, can you "help" them by adding conditional restrains on the ranges for values?
08:06:51phantomcircuit:iirc ADA and COBOL both offer that as a way to improve compile time failures
08:08:21gmaxwell:stuff like frama C can.
08:10:35gmaxwell:(also even things like clang-static-analasis are helped by asserts, assuming your assert function is annotated with NORETURN)
08:18:45phantomcircuit:gmaxwell, i guess the problem with using something like that is that the potential space for a hash value is huge
08:21:18phantomcircuit:network/user inputs which could be any value value for the type and stuff
08:52:20amtri:amtri is now known as amdroid
09:49:09grandmaster2:grandmaster2 is now known as dansmith_btc2
11:01:58davidlatapie:davidlatapie has left #bitcoin-wizards
13:56:57fanquake:fanquake has left #bitcoin-wizards
17:39:54Guyver2:Guyver2 has left #bitcoin-wizards
17:58:26Aquent_:Aquent_ is now known as Aquent
18:38:51kumavis: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:26kumavis:my guess is that bitcoin wisdom's backend lost connection with bitstamp, so its just missing data for that time
18:39:53BlueMatt:kumavis: verrrryyyy off-topic
18:40:14kumavis:what is the topic?
18:40:58kumavis:the topic is defined in the negative, so its unclear
18:41:31BlueMatt:read those, then come back
18:41:47kumavis:its also using relative language ("short") without context
18:42:19kumavis:so more theory than practice, more longtail than current
18:42:25gmaxwell:kumavis: sorry, bought some bitcoin.
18:42:43kumavis:makes sense, sorry for the noise
21:37:32abbursn:abbursn has left #bitcoin-wizards