| 00:44:45 | bramc: | My list of stuff to research is now officially empty. Maybe I should start building something. |
| 00:46:10 | justanotheruser: | bramc: https://docs.google.com/viewer?url=https%3A%2F%2Fresearch.microsoft.com%2Fpubs%2F180286%2Fpinocchio.pdf |
| 00:50:18 | Guest89043: | Guest89043 is now known as maaku |
| 01:44:37 | bramc: | justanotheruser, ZK stuff is interesting but I'm not going to use it for now |
| 04:22:47 | BlueMatt: | ;;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:47 | gribble: | The operation succeeded. |
| 04:31:50 | rusty: | BlueMatt: I'd say he successfully avoided the rabbit hole, myself :) |
| 04:52:27 | contrapumpkin: | contrapumpkin is now known as copumpkin |
| 05:07:40 | Pan0ram1x: | Pan0ram1x is now known as Guest84128 |
| 05:11:54 | BlueMatt: | rusty: I consider that failure :p |
| 06:43:17 | Guest59384: | Guest59384 is now known as amiller |
| 09:05:18 | holmes.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:18 | holmes.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:18 | holmes.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:18 | holmes.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:18 | holmes.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:12 | s1w: | s1w is now known as Guest48898 |
| 12:01:42 | s1w-: | s1w- is now known as s1w |
| 13:11:20 | Guyver2: | Guyver2 has left #bitcoin-wizards |
| 14:11:36 | andytoshi: | 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:57 | andytoshi: | the reason this is ok is because we aren't synchronous but "weakly synchronous" i.e. data only reaches all parties "eventually" |
| 14:13:03 | andytoshi: | can i make "eventually" more precise? amiller ? |
| 15:22:33 | amiller: | andytoshi, no it's not enough for data to reach all participants only eventually |
| 15:22:35 | amiller: | 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:13 | andytoshi: | amiller: it has to reach each participant in less the blocktime, right? does it need to be significantly smaller than the blocktime? |
| 15:38:25 | andytoshi: | and i'm not too worried about wasted work at this point, just "will it converge?" |
| 15:39:45 | amiller: | there are some equations for how much loss there is precisely |
| 15:39:58 | amiller: | but look at it this way, even without an attacker with hashpower, |
| 15:41:05 | amiller: | 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:33 | artifexd_: | artifexd_ is now known as artifexd |
| 16:36:57 | lclc_bnc: | lclc_bnc is now known as lclc |
| 18:11:00 | gmaxwell: | 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:08 | gmaxwell: | http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06744.html |
| 18:11:38 | gmaxwell: | 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:02 | wallet42: | wallet42 is now known as Guest83064 |
| 20:05:02 | wallet421: | wallet421 is now known as wallet42 |
| 20:29:22 | mountainlake: | mountainlake has left #bitcoin-wizards |
| 20:42:10 | jcorgan: | jcorgan is now known as perkypat |
| 20:42:13 | perkypat: | perkypat is now known as jcorgan |
| 21:00:32 | andytoshi: | 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:33 | kyletorpey: | kyletorpey has left #bitcoin-wizards |
| 21:03:53 | amiller: | andytoshi, i get that you're trying to say that bitcoin relies on something weaker than 'synchronous' but stronger than 'asynchronous' |
| 21:04:35 | amiller: | 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:46 | amiller: | 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:07 | kanzure: | 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:09 | amiller: | that's kind of characteristically synchronous |
| 21:06:37 | gavinandresen: | 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:43 | andytoshi: | 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:59 | andytoshi: | maybe this implication is not there and i should remove it. but it's been folklore in -wizards for a while |
| 21:07:09 | kanzure: | is the impossibility result cited/reproduced in this doc somewhere? |
| 21:07:19 | kanzure: | actually, reproduced is preferable, and not cited |
| 21:07:23 | kanzure: | *and not just cited |
| 21:08:19 | andytoshi: | 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:21 | amiller: | 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:03 | andytoshi: | amiller: are you aware of a rigorous result along the lines of what you just said? |
| 21:09:21 | andytoshi: | it really weakens the document if i make a claim like that with no citation |
| 21:09:54 | andytoshi: | (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:23 | kanzure: | that's useful evidence that nobody is reading it |
| 21:10:54 | amiller: | lol review canary |
| 21:10:55 | andytoshi: | well, one person did, it was https://github.com/TheBlueMatt/bitcoinninja/issues/11 that caused me to notice this |
| 21:11:42 | amiller: | 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:11 | andytoshi: | 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:27 | andytoshi: | thx amiller |
| 21:17:03 | andytoshi: | 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:49 | andytoshi: | 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:59 | gmaxwell: | andytoshi: funny I didn't think I'd read what you'd written that way. |
| 21:34:18 | gmaxwell: | 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:11 | andytoshi: | 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:41:09 | andytoshi: | %s/FLT/FLP/ |
| 21:43:39 | amiller: | flp is extremely limited |
| 21:43:43 | amiller: | first of all it applies to deterministic only |
| 21:44:01 | amiller: | even in the same setting it's stated in, it can be overcome with randomized algoirthms |
| 21:45:19 | amiller: | 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:51 | kanzure: | well there's definitely a known minimum network delay heh |
| 21:46:28 | amiller: | maximum bound :p |
| 21:46:59 | amiller: | so yeah basically FLP doesn't apply at all. |
| 21:50:15 | amiller: | 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:12 | amiller: | 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:28 | amiller: | that's almost analogous to how ecash never took off. |
| 21:52:12 | amiller: | 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:29 | amiller: | 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:40 | phantomcircuit: | 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:59 | phantomcircuit: | from just s |
| 21:54:15 | phantomcircuit: | actually i guess that's still poorly defined |
| 21:54:30 | amiller: | 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:32 | phantomcircuit: | no that is actually what im looking for i think |
| 21:55:27 | phantomcircuit: | actually that's still not even particularly interesting |
| 21:55:27 | phantomcircuit: | nvm |
| 22:03:50 | amiller: | phantomcircuit, https://www.youtube.com/watch?v=8FHpOLiobmA#t=2m36s |
| 22:12:53 | lclc: | lclc is now known as lclc_bnc |
| 22:30:17 | phantomcircuit: | amiller, lulz |
| 23:01:36 | andytoshi: | amiller: thanks, i will update my document to reflect that, that is definitely not how i was looking at things |
| 23:23:39 | NewLiberty: | NewLiberty is now known as NewLiberty-afk |
| 23:35:20 | gwillen: | 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:41 | gwillen: | 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:48 | sipa: | gwillen: correct |
| 23:35:51 | gwillen: | * gwillen nods |
| 23:36:10 | sipa: | a softfork basically can only add conditions that immediately fail the script |
| 23:36:13 | gwillen: | right |
| 23:36:40 | gwillen: | 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:48 | gmaxwell: | 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:36:49 | sipa: | exactly |
| 23:37:07 | gwillen: | gmaxwell: *nod* |
| 23:37:27 | gmaxwell: | (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:37 | gwillen: | right |
| 23:37:43 | gwillen: | I was just thinking about it in terms of types |
| 23:37:52 | sipa: | except the constraint only applies to arguments that actually get evaluated |
| 23:38:07 | gwillen: | which makes it sort of weird again |
| 23:38:26 | gmaxwell: | 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:46 | gwillen: | I guess you can't really make it check all encoded signatures including ones that are never evaluated |
| 23:38:55 | gwillen: | since they don't have to be literals |
| 23:39:00 | gwillen: | so if it's not evaluated you might not have it o |
| 23:44:26 | gwillen: | is a single-byte R with a value of 0x00 legitimate? |
| 23:45:27 | sipa: | yes |
| 23:45:41 | sipa: | well, it's DER compliant |
| 23:45:48 | sipa: | afaik there is no valid signature with R = 0 |
| 23:46:13 | phantomcircuit: | gwillen, yes but lolol |
| 23:46:18 | gwillen: | * gwillen nods |
| 23:47:37 | sipa: | well, some curves could have a valid R = signature, if they have a point with x=0 on the curve |
| 23:47:46 | sipa: | s can't ever be 0 in ecda |
| 23:47:47 | gmaxwell: | sipa: incorrect. |
| 23:47:59 | sipa: | actually, r can't be 0 in ecdsa ever |
| 23:48:05 | gmaxwell: | sipa: r can actually be zero. except for right. |
| 23:48:40 | gmaxwell: | The point on the curve test is insufficient though; because R.x % order congruent to 0 is on the curve. |
| 23:49:14 | sipa: | you seem to have experience with testing ecdsa edge cases |
| 23:49:25 | gmaxwell: | r being zero is explicitly rejected by the verification equation though because its trivial to forge a signature with r=0. :P |