00:44:45bramc:My list of stuff to research is now officially empty. Maybe I should start building something.
00:46:10justanotheruser:bramc: https://docs.google.com/viewer?url=https%3A%2F%2Fresearch.microsoft.com%2Fpubs%2F180286%2Fpinocchio.pdf
00:50:18Guest89043:Guest89043 is now known as maaku
01:44:37bramc:justanotheruser, ZK stuff is interesting but I'm not going to use it for now
04:22:47BlueMatt:;;later tell bramc "ZK stuff is interesting but I'm not going to use it for now"......then you havent sufficiently gotten into bitcoin yet!
04:22:47gribble:The operation succeeded.
04:31:50rusty:BlueMatt: I'd say he successfully avoided the rabbit hole, myself :)
04:52:27contrapumpkin:contrapumpkin is now known as copumpkin
05:07:40Pan0ram1x:Pan0ram1x is now known as Guest84128
05:11:54BlueMatt:rusty: I consider that failure :p
06:43:17Guest59384:Guest59384 is now known as amiller
09:05:18holmes.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
09:05:18holmes.freenode.net:Users on #bitcoin-wizards: andy-logbot paveljanik cbeams Burrito benten damethos jaekwon moa c0rw1n MoALTz__ Emcy_ hktud0 orik aburan28 hashtag_ coiner kyletorpey amiller Guest84128 TheSeven catcow nick1234abcd__ btc___ PFate thrasher` d1ggy Dr-G2 copumpkin spinza gsdgdfs shesek justanotheruser devrandom Cory sipa Graftec wallet42 PaulCapestany imposter bepo Meeh HaltingState samson_ gmaxwell EasyAt nuke1989 nubbins` xabbix weex_ platinuum Aesthetic jgarzik smooth
09:05:18holmes.freenode.net:Users on #bitcoin-wizards: fanquake starsoccer hashtag [\\\] huseby cfields maaku Luke-Jr nsh iddo grubles @ChanServ BananaLotus Xzibit17 Alanius artifexd_ kumavis jbenet luny epscy grandmaster mkarrer qwopqwop null_radix dgenr8 ebfull mappum Oizopower PRab waxwing ryan-c ajweiss DoctorBTC gavinandresen wizkid057 stonecoldpat davout hollandais warren bosma forrestv otoburb ahmed_ phantomcircuit gribble [d__d] lechuga_ nanotube so Apocalyptic michagogo Muis CryptOprah HM2
09:05:18holmes.freenode.net:Users on #bitcoin-wizards: bbrittain Hunger- phedny Iriez comboy_ MRL-Relay optimator_ earlz cryptowest wiz coryfields_ harrow` brad___ Graet helo throughnothing nickler_ Adrian_G fenn yrashk sl01 mr_burdell JonTitor roasbeef Keefe espes__ petertodd dansmith_btc lclc_bnc poggy heath kanzure fluffypony catlasshrugged pigeons Krellan dasource Eliel_ Guest74833 morcos K1773R _v3Rve Dyaheon tromp brand0 LarsLarsen asoltys_ isis livegnik go1111111 tacotime BlueMatt eric
09:05:18holmes.freenode.net:Users on #bitcoin-wizards: azariah Taek crescend1 berndj Starduster_ jaromil d9b4bef9 NikolaiToryzin TD-Linux warptangent deego SubCreative tromp_ sdaftuar lnovy midnightmagic delll BigBitz yoleaux hguux_ BrainOverfl0w wumpus sneak btcdrak Anduck jcorgan s1w Fistful_of_Coins kinlo andytoshi gwillen gnusha burcin Nightwolf a5m0
11:32:12s1w:s1w is now known as Guest48898
12:01:42s1w-:s1w- is now known as s1w
13:11:20Guyver2:Guyver2 has left #bitcoin-wizards
14:11:36andytoshi:i have a problem in alts.pdf ... i describe the bitcoin network as "synchronous" then cite an impossibility result for distributed consensus asynchronous networks and claim it's applicable
14:12:57andytoshi:the reason this is ok is because we aren't synchronous but "weakly synchronous" i.e. data only reaches all parties "eventually"
14:13:03andytoshi:can i make "eventually" more precise? amiller ?
15:22:33amiller:andytoshi, no it's not enough for data to reach all participants only eventually
15:22:35amiller:because if it takes 30 minutes for each honest miner who mines a block to deliver it to the next guy, then the amount of work wasted would be too high
15:38:13andytoshi:amiller: it has to reach each participant in less the blocktime, right? does it need to be significantly smaller than the blocktime?
15:38:25andytoshi:and i'm not too worried about wasted work at this point, just "will it converge?"
15:39:45amiller:there are some equations for how much loss there is precisely
15:39:58amiller:but look at it this way, even without an attacker with hashpower,
15:41:05amiller:if the time to propagate is significantly more than the blocktime, then the chance might be really good that there is a fork at every block, in which case it might takea really long time to converge
16:03:33artifexd_:artifexd_ is now known as artifexd
16:36:57lclc_bnc:lclc_bnc is now known as lclc
18:11:00gmaxwell:Hi all, new straight forward soft-fork proposed for Bitcoin for strictder enforcement: please comment on the list (even if your comment is just a "I read this and it's boring")
18:11:38gmaxwell:If posting to the list is too burdensome for you, you can tell me and I'll relay your comments; but I'd really prefer you post.
20:05:02wallet42:wallet42 is now known as Guest83064
20:05:02wallet421:wallet421 is now known as wallet42
20:29:22mountainlake:mountainlake has left #bitcoin-wizards
20:42:10jcorgan:jcorgan is now known as perkypat
20:42:13perkypat:perkypat is now known as jcorgan
21:00:32andytoshi:amiller: if you have two minutes can you glance at https://download.wpsoftware.net/bitcoin/alts.pdf page 8, first para of section 6? (just the one paragraph has changed)
21:02:33kyletorpey:kyletorpey has left #bitcoin-wizards
21:03:53amiller:andytoshi, i get that you're trying to say that bitcoin relies on something weaker than 'synchronous' but stronger than 'asynchronous'
21:04:35amiller:but you haven't really met the burden of evidence that there's a gap between the 'weakly synchronous' thing needed and the ordinary 'synchronous' model
21:05:46amiller:the main thing is that there's a time parameter in bitcoin, and it needs to be set so that communications propagate fast enough
21:06:07kanzure:unrelated to the exact requirements for making strong and correct statements there, a section about "if you disagree with these requirements regarding mutually distrusting parties, that's nice and all but not bitcoin-compatible because: "
21:06:09amiller:that's kind of characteristically synchronous
21:06:37gavinandresen:If any of y’all wizards have an opinion on “What Satoshi Didn’t Know” that you think I should talk about in San Juan… send me email. I’m working on my keynote
21:06:43andytoshi:amiller: well i'm just trying to give an idea that the impossibility result for asynchronous networks actually implies that bitcoin needs some sort of "economic patch" to be workable
21:06:59andytoshi:maybe this implication is not there and i should remove it. but it's been folklore in -wizards for a while
21:07:09kanzure:is the impossibility result cited/reproduced in this doc somewhere?
21:07:19kanzure:actually, reproduced is preferable, and not cited
21:07:23kanzure:*and not just cited
21:08:19andytoshi:kanzure: it is cited, it is this one http://diyhpl.us/~bryan/papers2/bitcoin/Impossibility%20of%20distributed%20consensus%20with%20one%20faulty%20process.pdf ... i'd rather not reproduce it in this document since it's only used as a motivation
21:08:21amiller:that seems like the wrong implication andytoshi, there's a need for an economic patch even given a *synchronous* network, because of the lack of strong identities.... and on the other side, even with bitcoin's economic patch, it requires what's effectively a 'synchronous' network model, although it's tricky because it's not exactly the standardr point-to-point t hing
21:09:03andytoshi:amiller: are you aware of a rigorous result along the lines of what you just said?
21:09:21andytoshi:it really weakens the document if i make a claim like that with no citation
21:09:54andytoshi:(tho given that until today the document totally miscited the asynchronous paper as being about synchronous networks, maybe people aren't reading it as closely as i want :()
21:10:23kanzure:that's useful evidence that nobody is reading it
21:10:54amiller:lol review canary
21:10:55andytoshi:well, one person did, it was https://github.com/TheBlueMatt/bitcoinninja/issues/11 that caused me to notice this
21:11:42amiller:andytoshi, i try to cover this in like all my related work sections, i say borrow from http://eprint.iacr.org/2014/857.pdf and http://tr.eecs.ucf.edu/78/ and i'll send you the in-review draft of the systemization-of-knowledge paper
21:12:11andytoshi:oh, fwiw pos.pdf cited the result properly, and needed only a one-character fix to be correct; while alts.pdf said literally "[cite impossibility result]", so unless somebody read my mind they would not have seen my mistake
21:12:27andytoshi:thx amiller
21:17:03andytoshi:actually i think i want to cite you directly here, this is much better written than what i would come up with. plus i did not know this stuff
21:29:49andytoshi:hmm :/ i had a quite serious misunderstanding here, i thought the FLT impossibility result was directly applicable to bitcoin. amiller do you think we can chat about this at FC15? i will read up on this in the meantime
21:33:59gmaxwell:andytoshi: funny I didn't think I'd read what you'd written that way.
21:34:18gmaxwell:I thought you were bringing it up to point out that the synchrnous thinking people often show up with just does not work at all.
21:39:11andytoshi:gmaxwell: i did say roughly that «We do not (and cannot, in an untrusted and physically dispersed network) assume that nodes agree on the precise timing or even time-ordering of messages on the network.» but i thought the FLT result made this intuitive truth solid
21:43:39amiller:flp is extremely limited
21:43:43amiller:first of all it applies to deterministic only
21:44:01amiller:even in the same setting it's stated in, it can be overcome with randomized algoirthms
21:45:19amiller:flp applies only to asynchronous networks, which is the weakest network model, so there are even deterministic consensus algorithms if you assume there's some known network delay bound
21:45:51kanzure:well there's definitely a known minimum network delay heh
21:46:28amiller:maximum bound :p
21:46:59amiller:so yeah basically FLP doesn't apply at all.
21:50:15amiller:so imo the real reason the positive results for distrbuted consensus like paxos etc don't apply is the lack of preestablished set of parties with authentic channels between them.
21:51:12amiller:so bitcoin's setting is like, everything else is "easy" ... assume there's a network bound, use randomness, etc., but one really hard aspect - no preestablished set of parties - which is harder than anyone else had really worked in
21:51:28amiller:that's almost analogous to how ecash never took off.
21:52:12amiller:all the ecash research assumed there was a semi-trusted bank, and batted down all these other features with crypto designs, like the untraceability, like deanonymize-on-double-spend so you don't have to have a stable connection
21:53:29amiller:then bitcoin takes off... it doesn't provide untraceability, you can't confirm transactions unless you have a connection to a bunch of peers, etc... but it does away with the bank which everything else had taken for granted
21:53:40phantomcircuit:amiller, not sure if you were around for this but i improved the description of that i was trying to do f(m, k) = s such that you can produce a compact proof that there is no valid k value
21:53:59phantomcircuit:from just s
21:54:15phantomcircuit:actually i guess that's still poorly defined
21:54:30amiller:sorry about that tangent, the point is - the right way to view bitcoin's model is that it's really "strong assumptions" (sycnhronous, randomized) in every aspect except one, which is the fixed party set
21:54:32phantomcircuit:no that is actually what im looking for i think
21:55:27phantomcircuit:actually that's still not even particularly interesting
22:03:50amiller:phantomcircuit, https://www.youtube.com/watch?v=8FHpOLiobmA#t=2m36s
22:12:53lclc:lclc is now known as lclc_bnc
22:30:17phantomcircuit:amiller, lulz
23:01:36andytoshi:amiller: thanks, i will update my document to reflect that, that is definitely not how i was looking at things
23:23:39NewLiberty:NewLiberty is now known as NewLiberty-afk
23:35:20gwillen:gmaxwell: the fact that strictder enforcement requires the non-VERIFY opcodes to still fail the entire script if !isDER is gross, not that you don't know that
23:35:41gwillen:gmaxwell: am I understanding correctly that this is to prevent this from being a hardforking change due to the possibility of inverting the check?
23:35:48sipa:gwillen: correct
23:35:51gwillen:* gwillen nods
23:36:10sipa:a softfork basically can only add conditions that immediately fail the script
23:36:40gwillen:because you can't add anything that could appear under a negation, since it could make failing scripts now succeed which would be a hardforking change
23:36:48gmaxwell:Its maybe a little less gross when you just consider it as an additional constraint like the push_data opcode that is used to push in the signature must be valid, e.g. it's not a question of signature validity, it's a question of transaction wellforedness.
23:37:07gwillen:gmaxwell: *nod*
23:37:27gmaxwell:(maybe imaginging that there are types attached to pushes, and this adds a type requirement on checksig that the input be a ValidDER type)
23:37:43gwillen:I was just thinking about it in terms of types
23:37:52sipa:except the constraint only applies to arguments that actually get evaluated
23:38:07gwillen:which makes it sort of weird again
23:38:26gmaxwell:the analogy wears thin, I mean you could imagine checkmultisig is a composition of a dispatch and a checksig (which is actually how it's implemented...)
23:38:46gwillen:I guess you can't really make it check all encoded signatures including ones that are never evaluated
23:38:55gwillen:since they don't have to be literals
23:39:00gwillen:so if it's not evaluated you might not have it o
23:44:26gwillen:is a single-byte R with a value of 0x00 legitimate?
23:45:41sipa:well, it's DER compliant
23:45:48sipa:afaik there is no valid signature with R = 0
23:46:13phantomcircuit:gwillen, yes but lolol
23:46:18gwillen:* gwillen nods
23:47:37sipa:well, some curves could have a valid R = signature, if they have a point with x=0 on the curve
23:47:46sipa:s can't ever be 0 in ecda
23:47:47gmaxwell:sipa: incorrect.
23:47:59sipa:actually, r can't be 0 in ecdsa ever
23:48:05gmaxwell:sipa: r can actually be zero. except for right.
23:48:40gmaxwell:The point on the curve test is insufficient though; because R.x % order congruent to 0 is on the curve.
23:49:14sipa:you seem to have experience with testing ecdsa edge cases
23:49:25gmaxwell:r being zero is explicitly rejected by the verification equation though because its trivial to forge a signature with r=0. :P