01:18:58 nsh- is now known as nsh 01:49:12 damn i don't think there's any way for my tournament idea to work with current bitcoin :/ 01:55:41 ok enough of that madhouse. thanks for the info gmaxwell 02:56:42 Good evening, me. 02:56:50 Hi, me. 02:58:26 "Since Bitcoin's security relies primarily on the number of confirmations received instead of on elapsed time, we end up getting irreversibility of transactions with very high probability in far less than 10 minutes. 02:58:33 is that really true 02:59:44 no, it's not— it depends on your threat model. 03:00:06 the part before the comma i mean 03:00:16 no, it's not— it depends on your threat model. 03:01:33 so "longer" blocks are statistically a better confirmation of a txn than shorter ones? 03:03:21 Emcy: in some threat models, e.g. where the attacker is going to lease power to do a short reversal time after the first confirmation is basically all that matters... how much work must the attacker do to undo the confirmation. 03:05:05 right 03:05:10 Figuring out the safty in their revised selection algorithim isn't simple either. e.g. you could have a block with 10 confirms, but its really compeating with another subgroup which is only 1 confirm behind, and maybe its actually ahead but you've just not heard of one of the blocks required to make it win. 03:05:30 Fun attack in that model: "delayed announcement of your own stale blocks" 03:06:20 i want to try and read and understand enough to work out for myself if its viable or not 03:06:39 thought the immediate claim of 1 second blox makes me skeptic 03:06:49 well just ignore the actual numbers. 03:07:10 1 second would give big advantages to consolidations. 03:07:51 consolidations? 03:08:03 hashing datacenters. 03:08:07 (or pools for that matter) 03:09:53 oh yes 03:10:26 its only a couple of times the causal diameter of the earth :/ 03:10:31 delayed announcement attack— you're mining and you find your block stale. but instead of announcing it, you put it aside and hope that later there is less than one block of difference between a fork containing that block and another fork, and if that happens you start mining on it and delay announcing the tiebreaking stale that would let everyone else know that they'd best be mining on that subgroup, until you've found a block. 03:10:38 Emcy: right. 03:10:51 1 second is almost certantly too fast... though it would take simulations to tell for sure. 03:11:18 not to mention that pratically all mining hardware today has multisecond latencies. 03:11:21 tahts why im skeptik...another paper leading with a fantastical claim 03:11:47 p2pool had to increase from 10 second shares to 30 second shares because of slow hardware responses. 03:12:48 did you see p2pool jumped to 3% power this week. hashpower doubled out of nowhere 03:12:50 Hello, wizards. 03:12:53 also, if you wanted to talk about viable: more viable in the context of bitcoin would be basically makine p2pool a protocol requirement with a rule that new shares can't displace transactions in prior ones. 03:12:56 feelsgoodman.png 03:13:10 and doing that would avoid breaking the scalablity of lite clients. 03:13:39 (in fact, it would just be a soft fork) 03:13:49 zooko excuse me sir, im a warlock 03:14:08 ☺ 03:15:06 gmaxwell i dont see that happening either. If p2pool gets too big its just back to square one. Unless theres a way to split them in a decentralised way 03:15:21 Emcy: ... 03:15:28 Emcy: ::sigh:: 03:15:35 Emcy: what I'm suggesting has nothing to do with p2pool. 03:15:42 Emcy: except using the same technique 03:16:04 in all but name then? 03:16:09 Emcy: I'm pointing out that you don't have to hardfork bitcoin to have a fast blockchain. We already have a 30 second blockchain, it's called p2pool. 03:16:43 ah thats true 03:16:51 The only distinctions are that (1) not everyone is forced to use it, (2) it allows later shares to reverse earlier ones— they don't accumulate. 03:17:15 those could be fixed. In such a world you could still have a p2pool mining that network which was a fraction of the size. 03:17:25 but the two level chain would give you fast confirmations. 03:18:09 also because its two level it wouldn't increase work for lite clients unless they were interested in hearing about fast confirms 03:18:52 could it work the other way? 03:19:04 bitcoin could become a subchain for something else 03:19:25 not without changing bitcoin's rules in a hardforking way. 03:20:04 perhaps 10 minuties was actually too fast for base chain then 03:20:43 Emcy: in any case, thanks, if I bring up that point again I'll be sure to not mention p2pool. :) 03:26:13 heh so im your litmus test for being able to properly explain your ideas to the masses :) 03:26:37 if thats how i help bitcoin so be it 03:27:27 hah. well if it confuses you, its going to confuse other people. 03:29:21 doesnt help ive got a foot inside migraine territory right now 03:29:26 in fact yeah i better go 03:29:46 later wizerds 03:34:25 Hello zooko, fancy seeing you here. 03:42:52 sbbodhtimrj is now known as jrmithdobbs 03:52:06 Hello, gwillen. 13:31:11 amiller: gmaxwell: i'm trying to understand regarding DoS by diff-1 orphans at genesis, if we eliminate checkpoints and add to blocks some kind of merkle root committing to the current UTXO (to help lite nodes), how does it mitigate this DoS attack? 13:32:19 there's only a DoS attack possible because of how the current chain-catchup works 13:32:49 hmm 13:33:02 with headers-first synchronization, you can know there is enough PoW on top of a block before actually downloading and processing it 13:34:34 i don't understand, diff-1 PoW blocks are (relatively) easy to generate, what's the rule that will cause you to ignore them instead of bloating your local copy of the blockchain with them? 13:35:05 right, it won't prevent it entirely 13:35:37 but right now, the largest problem is that diff-1 blocks will be downloaded and potentially processed 13:35:54 but with headers-first, you'd only download and process the headers 13:36:05 ahh 13:36:12 until such a chain becomes the actually best total work chain 13:36:55 hmm headers first is an optimization that isn't related to merkle datastruct (like MMR) for lite nodes, i think? 13:37:02 not at all 13:37:16 completely orthogonal 13:38:20 ok, peter todd and amiller said yesterday that the MMR stuff can mitigate DoS that checkpoints currently protects against, i wonder why... 13:39:30 checkpoints don't protect against a DoS, they are just there to make not-checking-all-signatures safe 13:40:14 wait, no, they do protect against a dos by helpig the heuristics determine if an early block in the chain has a chance of beatig the total known PoW 13:40:49 sipa: yes i mean what gmaxwell said: https://bitcointalk.org/index.php?topic=194078.msg2014204#msg2014204 (i.e. you ignore diff-1 at genesis because you already have a checkpoint) 13:41:59 but then peter todd said that MMR can give this anti-DoS without checkpoints, and amiller said that the reason is that blocks have commitments to the UTXO set 13:42:15 but i don't see why it helps, yet 13:43:35 this is in the context of the new paper by Aviv Zohar, it seems that anti-DoS is easier with Bitcoin rules than his new rules, assuming that there are no checkpoints 13:45:54 for example the most naive anti-DoS is for the Bitcoin node to have some quota and not accept more than certain amount of forks for each block, so if in the future it turns out that a competing fork is better then that node will need to ask peers for blocks that it rejected in the past 13:46:17 but with the new paper, this naive anti-DoS doesn't work, i think 13:46:52 (could cause netsplits that don't re-converge) 13:48:55 and even if it can work with the new rules, the communication among nodes will be much greater i think 14:35:22 iddo: emphasis on *sum* tree - the MMR (or just merkle tree) lets you interactively query your peer to be sure the total sum work claimed makes sense. But yeah, even without the sum tree just working backwards from current best block is pretty good too. 14:49:38 petertodd: trying to understand you... isn't that just a method to prove more efficiently that a competing fork has more weight? 14:50:42 petertodd: what i don't understand, diff-1 PoW blocks are (relatively) easy to generate, what's the rule that will cause you to ignore them instead of DoS attack where you'd be bloating your local copy of the blockchain with them? 14:51:16 (checkpoints do prevent this kind of DoS attack) 14:56:30 it still seems to me that with Bitcoin rules to select the best chain we can have anti-DoS mechanisms (without checkpoints) against diff-1 orphans at genesis attack, while with Aviv Zohar's rules I'm not so sure 15:00:00 but i'm still unclear why amiller and you said that such merkle trees remove the need for checkpoints, is it just in the context of bootstrapping new nodes without doing too much work verifying the entire history, or also in the context of anti-DoS ? 15:57:40 iddo, well... you can do something like starting at SPV security and gradually validating the chain 16:05:31 amiller: but not all nodes can do that, i think? the question is still whether full nodes should eliminate orphan branches or keep them, if they always eliminate then the communication can blowup? 16:07:10 eventually eliminate them? 16:09:08 yes i think that with Bitcoin it may be safe to eliminate old orphans (assuming no checkpoints), but with Aviv Zohar's rules, i'm not sure yet 16:09:16 you may even think of it as an incentive thing, there's a tradeoff from an individuals point of view 16:09:28 potentially keeping some orphans around will save on future bandwidth, but at the cost of storage now 16:10:50 it's also not only about eliminating orphans that you already have, but also about rejecting new orphans, like the 1-diff at genesis attack 16:12:20 with Bitcoin i think that it can be safe to reject short orphans (with small risk that you may need to request them later and waste communication), but with Aviv Zohar's rule, not sure.. 17:14:52 ok i summarized what i asked here, in the public thread: https://bitcointalk.org/index.php?topic=359582.msg3867074#msg3867074 17:19:14 gmaxwell: with this new rule, you think that blocks need to point to all their ancestors only because of lite clients? full nodes can calculate the difficulty of a block without it having pointers to ancestors, i think? 17:20:41 one question i've had is how you do efficient merging 17:20:47 to make sure the same work doesn't show up in multiple places in the same tree 17:29:46 amiller: btw if you can dig up #bitcoin-dev or mailing list link where you first proposed this rule, maybe they could reference you in this paper:) might be worthwhile, there's plan for followup paper too 17:38:59 i send an email to the thread with the irc log from bitcoin-dev 17:39:34 i wouldn't mind having an acknowledgement but i didn't develop the idea very far at all :p 17:39:39 i'm really glad that someone is working on it. 17:42:35 i also tried to emphasize that, it's not even that their idea isn't fine as is (we haven't argued super well that there *clearly is* a big dos attack), but that it's difficult to analyze that there are no dos attacks, so being conservative to include thing is understandable 17:43:55 so if they really want to say there thing is practical and ready to implement, they should come up with some really compelling anti-dos analysis 17:44:05 that's just my opinion though :o 17:46:11 yes that's all true, probably difficult to analyse it in theory, trying simulations first is a good idea 19:32:02 gmaxwell: hm.... the previous thoughts about pruning included nodes having a random subset of the blockchain to serve to peers. that seems good, but that may have privacy issues? 19:32:08 gmaxwell: you can use that to identify nodes 19:34:47 You can use many things to distinguish nodes already. So what about it? 19:35:29 You propose instead forcing nodes to use tens of gigabytes of disk space if they want to contribute at all to distributed storage? 19:35:43 no 19:35:56 It doesn't connect transactions to anything. 19:36:03 are there ways to obscure the subset so it is less certainly a unique identifier 19:36:35 I never suggested a random subset that would be stupid, I always suggested contigious quantized ranges. 19:37:12 (stupid because it would take a lot more data to express than just a range or two) 19:38:01 ok 19:43:03 and be a lot harder to make sure that a particular block is available 19:44:59 in particular, you'd need O(n^2) nodes that serve the same n blocks with the same probability to get equal chance a particular block is available 19:45:45 when I connect to random bitcoin peers now, it seems that often many of the peers are useless, too slow or fake 19:45:46 in the future we can have SCIP proofs for UTXO "checkpoints", so less need to serve old blocks 19:46:54 hmm key birthdates would help 19:57:53 iddo: perhaps, we need scip that doesn't need a trusted CRS.. and prover performance that at least makes it possible to run. 19:58:21 I don't know if we'll have that in 2 years, 5 years, or 10 years. 20:01:12 proof size is logarithmic in num of computation steps (computation == verifying the history, maybe optimized by composing with prev SCIP checkpoints), the issue is how big are the constants of this log size proof.... 20:01:48 this is for the variant without CRS 20:08:47 warren, you can already uniquely identify peers fairly reliably 20:08:53 they give everybody the same version nonce iirc 20:49:13 iddo: well for checkpoints it can be rather large, eventually it will be small relative to the blockchain. :) But I worry about computing it just being infeasable. If it costs $1k in compute time thats doable, if it costs $1m in compute time thats right out. 20:56:59 hrm, what should be the parts of a bitcoin gambling tool that plays through games of iddo's protocol? 20:57:12 i am thinking it should be a self contained wallet 20:57:51 because i would want to have some notion of 'sending coins to my gambling wallet' rather than integrating it with my personal bitcoind or something big like that 20:58:41 really i would want this to be SPV something, it's not particularly supposed to provide bandwidth to anyone 21:05:01 i guess i should study bitcoinj 21:12:45 K1773R_ is now known as K1773R 21:33:32 iddo: I really wish people with implementations of snarks for C would release something... there are 'small' applications we could use the stuff for right away. Like proving ownership of a bitcoin without disclosing which bitcoin you own. 21:35:08 i've been out for too long... how does snarks relate to scip? 21:37:07 sipa: scip is snarks 21:37:18 SNARKS is the general term 21:37:33 SCIP is what Eli et al call their implementation of a SNARKS system 21:37:46 gmaxwell: correct me if i'm wrong 21:39:07 sipa: SCIP is just what Eli et all call their SNARKS for C stuff. 21:40:18 ok 21:40:29 are they abbreviations of something? 21:40:35 SNARK = succinct argument of knowledge (sometimes zk-SNARK when its also zero knowledge). succinct ~meaning that its sublinear in the witness size, argument because they are only computationally sound, they're not a proof. 21:41:27 (there is some proof that you cannot produce a proof (perfectly sound) which is succinct, the best you can do is computationally sound) 21:43:25 gmaxwell: is there a 30-second explanation of what 'computationally sound' means in this context? 21:44:11 gwillen: computationally sound basically means a cryptographic assumption, e.g. someone who can search 2^256 spaces can produce a proof which you believe is valid but it's not. 21:44:34 Vs a perfectly sound proof where you can never be fooled even by an unbounded attacker. 21:45:40 (or, if the cryptographic assumption fails— discrete log is easy, etc. depends on how the system is constructed which assumptions are at play. Or of P=NP..— then the system allows fake proofs) 21:46:16 gmaxwell: ahhhh, clever. 21:48:22 There is a similar set of levels of zero knoweldge. Some things have perfect zero knoweldge where an unbounded attacker with unbounded examples of your proof learns nothing, statistical zero knoweldge where the distribution of answers is negligibly different from 'fake' answers so at most they learn very little, and varrious computational assumptions for zero knoweldge. e.g. where they learn nothing unless they can solve some hard ... 21:48:29 ... problem. 21:48:41 * gwillen nods 21:48:54 Interestingly there seems to be some tradeoff, it seems that many of the systems with perfect soundness can only offer computational zero knoweldge, and vice versa. 21:49:14 interesting. 21:49:43 For something like blockchain proofs we don't care about zero knoweldge at all, thought we do care if the proofs are small. 21:51:13 gmaxwell: is this counting or not counting 'I prove that I have a bitcoin without revealing which one' as zk? 21:51:22 it feels zk-flavored to me 21:51:41 for that you'd want zk, indeed— though computationally sound ZK is probably fine for that. 21:51:59 * gwillen nods 21:52:29 'you can break my anonymity if you can do a 256-bit search' is certainly an improvement on what we have now. :-) 21:53:38 likewise, for something like zerocoin you need zk to hide which coins you're spending. So we do have applications for ZK. Things like my contigent payment protocol need fairly strong ZK since the payer can rob the payee if the ZK isn't strong. 21:54:24 interesting. 21:56:45 then you have the whole axis of publically verifyable vs designated verifier. 21:57:10 A bunch of these systems work easiest where there is a single verifier who generates a challenge, and a single prover. Thats desigated verifier. 21:57:40 gmaxwell: from what i know there is no (working) code yet for non-CRS SCIP, but it's being work on... about CRS SCIP, obviously they will release code with their lame zerocoin altcoin:( but i'll continue to inquire and see if i have updates 21:58:14 Publically verifyable is like a digital signature. Then a number of these systems are "publically verifyable in the CRS model" which is basically publically verifyable but only if everyone has a magical trusted string. 21:59:51 gmaxwell: what are the requirements on the CRS? 22:01:15 gwillen: depends on the system, most of the CRS models are effectively structured like public key cryptography where the CRS gives you public keys for a trapdoor permutation constructed so that you can encrypt your proof but still check that its valid. if someone knows the randomness underlying the CRS they can trivially create fake proofs. 22:01:51 the crs generation process in that case just ends up looking like generating a bunch of random public keys, more or less. 22:02:17 gmaxwell: is this the sort of thing where, if we knew that God generated the CRS and threw away the generation parameters, the system would be fine? 22:02:22 Yes. 22:02:24 Huh. 22:03:15 some of the stuff in the CRS model also loses its zero knoweldge to god, so you can't necessarily safely use it in the designated verifier case where the designated verifier produces the CRS. (annoyingly I find the papers often unclear exactly what the threat model(s) they work under) 22:03:40 (though anythin with a succinct proof is probably still ZK to god, simply because there is so little information at the end) 22:04:59 some people talking about this stuff have suggested you could use multiparty computation to compute the CRS in a way that God is distributed. 22:05:26 But it still would leave you that if the majority (or all) of the multiparty computation players cheated they'd know the parameters. 22:06:13 Also, many of the active-secure multiparty computation systems only achieve security via zero knoweldge proofs ... so you can end up with circular security. :) 22:06:58 E.g. you can take a passive-secure multiparty computation system, — one which is only secure if the players follow the protocol— and boost it to active security (secure regardless of the players) by having the player use proofs to prove they did their computation according to the rules. 22:08:09 gmaxwell, is there anything preventing someone from mining a version=3 block? 22:08:14 other than just stupidity 22:08:24 phantomcircuit: nope. 22:08:33 is it at least discouraged? 22:09:11 it shouldn't be done, because we will want to use the version field for future changes, and if people are actively producing blocks with other versions it will make that impossible. 22:17:22 i like this business of referring to an unbounded attacker as god 22:17:29 #bitcoin-wizards could use some wizardly lingo 22:19:31 let's call Him Laplace's Demo 22:19:49 hmm, i actually wanted tot type Demon, but Demo isn't too bad either 22:20:35 he is Laplace's Demon, Laplace's Demo is when he shows you that your system is insecure. 22:20:46 I wonder if in some of the holographic universe theories if knowing the path of a single partical with enough detail actually describes the entire universe. :) 22:21:07 particle* 22:21:24 gmaxwell: certain facts about our actual universe makes me like the theory that this isn't true because it has only limited resolution 22:21:36 (i.e. that you can't in fact get the entire universe from the path of a particle) 22:22:31 gwillen: e.g. what if there is only one universe consistent with our laws of physics and the existance of particle X. 22:22:40 * gwillen nods 22:27:15 http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/ now in slashdot btw 22:30:06 which makes me wonder, is there any book on bitcoin with internal details etc 22:39:20 edulix: yes, it's online at https://github.com/bitcoin/bitcoin 22:39:31 (and at http://bitcoin.it) 22:43:44 nice 22:50:39 hehe the author of that post doesn't understand why double spend is fixed the way is fixed in bitcoin 22:52:14 is it true there were altcoins with fixed difficulty? 22:53:48 Emcy: liquidcoin had that... didn't last long. 22:54:53 what was the rationale of that 22:56:56 gmaxwell, what block shunning is there? 22:57:10 or is that just txs 22:57:27 ;;seen jgarzik 22:57:36 no gribble