--- Log opened Sun Dec 08 00:00:40 2013
13:44 < MoALTz> http://blockexplorer.com/block/00000000000000189ad9b20ed103ac14ca5c08ecfb0f5a0f538e4678f4535c46
13:53 < MoALTz> the smallest block. the next (same-sized) smallest are 181 bytes
18:04 < crispy> fdadf
18:05 < phantomcircuit> gmaxwell, lol mike
18:05 < phantomcircuit> there is no such thing as a secure registrar
18:05 < phantomcircuit> DNE
18:10 < nsh> i hear melbourne IT is pretty good
18:10  * nsh sniggers
19:11 < Emcy> did petertodds pooled-solo mining thing from May go anywhere?
19:16 < Luke-Jr> Emcy: petertodd's? :P
19:16 < Luke-Jr> BIP 22 is from Feb 2012 ;)
19:22 < Emcy> sorry, he did say it was more you and greg
19:23 < Emcy> im going over the dev list again
19:23 < Emcy> you guys send a lot of mail to that list now
19:26 < Emcy> i think when people take discussions private then start ccing list again it breaks threads in my program :(
20:51 < Mike_B> has anyone assessed this new paper about blockchain confirm security?
20:51 < Mike_B> counting orphaned blocks as a confirmation
20:54 < Baz> there's a pretty good thread on it https://bitcointalk.org/index.php?topic=359582.0;topicseen
20:55 < Baz> are there disadvantages for when a wallet client uses a server to read through the blockchain, rather than load it all locally, as armory does
21:39 < maaku> Mike_B: I'm not sure that's an accurate explanation. it doesn't count orphaned blocks as confirmation, but uses work spent on orphans is determining the most-work chain
21:42 < midnightmagic> It seems strange somehow that you can force the network to switch to another sibling by mining multiple side-by-side siblings, and potentially roll back a retarget.
21:44 < maaku> midnightmagic: that requires a 51% attack ... nothing strange about that
21:49 < midnightmagic> as far as I know, a 51% attack can't *roll back* a retarget though can it? the 51% must linearly reach a longer sibling fork which itself is beyond the retarget.
21:50 < midnightmagic> this provides an additional consideration for a 51% direction that an attacker can take the chain.
21:50  * midnightmagic finishes reading
21:51 < maaku> midnightmagic: it most certainly can
21:52 < maaku> there is no limitation on how far back a rollback can go, except for checkpoints
21:53 < midnightmagic> maaku: What I mean is, it must extend it using post-retarget mined blocks. but if you reveal a GHOST-based subtree which is heavier but hasn't yet reached retarget, the network as a whole rewinds to that.
21:53 < midnightmagic> in essence, the retarget can be rewound as though no retarget has happened yet because a heavier subtree exists that hasn't reached retarget.
21:54 < maaku> midnightmagic: the reorg code doesn't care squat about retargetting, as far as I am aware
21:54 < gmaxwell> any limit creates a potential for an unresolvable fatal partition in the network if there is a reorg right at the boundary. So you argue "boundary X is safe because making a reorg that deep is infeasable" I respond "boundary X is pointless because it defends against an attack you just told me can never happen" :)
21:54 < midnightmagic> i don't know if it matters, was just thinking of possibilities.
21:54 < gmaxwell> midnightmagic: yea, I dunno if thats especially concerning subtle things to think through for sure.
21:56 < midnightmagic> maaku: I guess the retarget boundary may not be relevant, but it looks like a heavy subtree can make the main chain length *shorter*..
21:56 < phantomcircuit> gmaxwell, "checkpoints are a performance feature not a security feature"
21:57 < gmaxwell> phantomcircuit: hm? yes.
21:57 < maaku> midnightmagic: it extends the length of the sub-tree, i don't see how it reduces the length of the main chain
21:58 < gmaxwell> maaku: well for security you actually care about the relative distance to the next best tree that doesn't include your txn.
21:58 < gmaxwell> since thats the amount of work required to change the decision.
21:58 < midnightmagic> maaku: It is possible that mining could indefinitely create a reorg which switches back and forth between two trees without actually extending the main chain length.
21:59 < midnightmagic> I don't think a 51% attack right now could do that. I think it must *extend* some tree in order to increase main chain length.
21:59 < gmaxwell> midnightmagic: I dunno that that matters though. I worry more about details like how the heck do you make sure that everyone actually agrees on longest.
22:00 < andytoshi> gmaxwell: well, if boundary X is there to try and keep nodes from getting DOS'd, even if it is infeasible to split the network that far back it is a useful boundary
22:00 < maaku> yes, a problem here is that you no longer have global knowledge about how much weaker a distant subtree (which you're ignoring due to DoS considerations) is, until it overtakes you
22:01 < maaku> but it would take the nuclear 51% for the subtree to have any effect, which is why it's not a very weighty concern from where I'm sitting...
22:01 < gmaxwell> andytoshi: header flooding alone isn't really an interesting dos though, esp as you don't forward them
22:02 < andytoshi> well, it could be interesting if you've gotta keep them all in memory at once
22:03 < Mike_B> hey btw gmaxwell - did you ever find that hashcash paper?
22:03 < Mike_B> i'd really love to read it if you did.
22:03 < andytoshi> i thought that was the crux of this "diff-1 flood" attack we are discussing
22:03 < gmaxwell> Mike_B: haven't had a chance.
22:03 < Mike_B> gmaxwell: do you remember the title? i was searching stuff like "hashcash progress-free" on google but without much luck.
22:06 < gmaxwell> Mike_B: if I did I would have just given you the result.
22:06 < midnightmagic> ah, footnote #10 was what I was looking for
22:07 < gmaxwell> andytoshi: I haven't been following the discussion here, and don't have time to.
22:09 < gmaxwell> andytoshi: but with a 'sutiable' headers first implementation diff-1 flooding basically reduces to a boring "peer can send me unwanted packets" problem... though I don't know if anyone would ever bother with the really dos hardened version since incrementing the minimum difficulty (and then fixating the old chain as a one time thing) is a simpler thing to do.
22:10 < gmaxwell> (if you don't mind potentially fetching fork headers multiple times you can basically bound the space uning a hierarchy of bloom filters to accept headers for inspection)
22:13 < andytoshi> hmm, i'd have to think about what a 'suitable' headers first implemetation would look like, since if you are weighing entire trees you can have a situation where two peers each have half the tree
22:13 < andytoshi> but neither is aware of the other half
22:15 < gmaxwell> oh if you're talking about that fast blocks paper, I think it destroys every anti-dos mechenism for block flooding I'm aware of (other thain incremeinting the minimum diff)
22:15 < andytoshi> oh, i am :P i think we have been talking past each other
22:15 < gmaxwell> well okay other than that, and other than SNARKs for membership in a chain of some total diff.
22:16 < maaku> andytoshi: which is totally fine...
22:16 < gmaxwell> e.g. you could build a snark for summing the diff of a chain which commits to a hashtree of headers. And then you can prove each header incrementally is a member of a chain with some sum diff.
22:17 < gmaxwell> maaku: it's fine? really? if you end up with half the hashrate on one subtree and half on another subtree..  thats not good. what triggers resyncing the missing blocks to make them ever converge?
22:17 < maaku> gmaxwell: reverting to IBD mode when one tree is longer, which it will be eventually
22:17 < andytoshi> right, my concern is that no node can make a snark because nobody individually has a heavy enough subtree
22:17 < andytoshi> but together, their subtrees could add up to a lot, so you have to listen to them all
22:18 < gmaxwell> maaku: I don't follow but I think I'm too worn out to think now.
22:19 < maaku> gmaxwell: the point is the question amounts to "assume a situation only possible as the result of a 51% attack, here's a problem" - and my response is "that problem will sort itself out, and beyond that is not worth thinking about because you're assuming a devistating attack"
22:20 < gmaxwell> maaku: I don't see that.  assume the network ends up in a state where half the nodes know fork blocks ABC and half know DEF and as a result you have half hashpower on each subtree and they stay tied. What makes them eventually converge?
22:21 < maaku> gmaxwell: block generation being a stochastic process. they will diverge from each other randomly
22:21 < phantomcircuit> maaku, they *might* but you have no guaratee
22:21 < phantomcircuit> we like those
22:21 < gmaxwell> maaku: sure, but there are three extra blocks on each side. how long until one gets three ahead when they have an even split of hashpower?
22:22 < gmaxwell> and how much hashpower does it take to maintain that state?
22:22 < gmaxwell> (by adding extra orphans)
22:22 < maaku> i'm not sure i follow - why the magic number 3?
22:22 < gmaxwell> I just picked a number.
22:22 < Luke-Jr> obviously the Holy Trinity
22:23 < gmaxwell> 1, 2, many.  Three is the smallest many.
22:23 < maaku> gmaxwell: well you just need a single block more on either chain
22:23 < andytoshi> once one half of the split gets one block ahead, that should be enough to draw hashpower toward it
22:24 < andytoshi> which is the way that their "eventually you always reconverge" theorem works
22:24 < gmaxwell> anyways, point I'm trying to make is I think you can put this system into a state where it will probably never converge, even without an (active) attacker.
22:24 < maaku> and chances are you'll get that ... unless the attacker is >51% of the network and censoring his own blocks, in which case :shrug:
22:24 < andytoshi> i think maaku is right, but only when everybody is sharing all the available blocks -- and then i think we have DoS potential
22:24 < gmaxwell> maaku: hm? no the nodes with the A B C orphans need the D E F orphan chain to be 4 blocks longer before they think its longer.
22:25 < gmaxwell> andytoshi: but _how_ do you share all blocks? how do you actually know if you have them all? how do you know if you don't to go get them? and how doesn't any anti-dos not mess that up?
22:26 < maaku> gmaxwell: ah ok i misunderstood your description of the initial state
22:26 < andytoshi> well, you have a master chain, and if you say, ignore any blocks more than 10000 behind the head of the chain, that would be an anti-DOS which doesn't affect this business of reconvergence
22:26 < andytoshi> unless you get a 10000-deep split, and then you're totally screwed
22:27 < andytoshi> but 10000 blocks ago the diff should be high enough that spamming blocks is impossible
22:27 < gmaxwell> you know for sure you have all the blocks normally, because of the linked list structure of the chain, but this stuff creates relationships which are not unidirectional. E.g. newer orphans make older blocks (which are later in the chain) better.
22:27 < maaku> gmaxwell: getting ahead (or behind) 3 blocks would take a while, but it will happen - and i should point out the chance of it happening is the same as getting into that state in the first place
22:27 < maaku> since you're presuming the forks have equal hash power, but somehow one has 3 more proof of works than the other
22:28 < gmaxwell> right 3 will happen buy may take a long time. .. a semi-active attacker with fairly modest hashpower who keeps mining more orphans only on the shortest subtree could prolong that.
22:29 < maaku> but "in reality" there will be some miners which only have one orphan stored - and they will jump ship first
22:30 < maaku> i think you're still balancing on a pin to set this up
22:32 < gmaxwell> maaku: but its a balance that could even happen without an attacker— which I agree is unlikely, and attacker could make it happen for sure. wait for a natural split, buy a burst of hashing power to build two blocks and give them in a censored manner... repeat as needed to keep it imbalanced. I don't know that its fatal, but its a whole class of attack that doesn't exist in the current system because we have jamming resistant ...
22:32 < gmaxwell> ... communication of blocks
22:32 < midnightmagic> I guess building additional orphans is less of a good idea than building ones that are likely to become canonical due to coinbase payments.
22:32 < gmaxwell> midnightmagic: someone breaking the system is short coins and doesn't care about the coinbase payments.
22:32 < midnightmagic> hrm
22:33 < midnightmagic> joker effect.
22:33 < gmaxwell> "byzantine failure"
22:34 < gmaxwell> though perhaps its sufficient if miners commit to all the blocks they're using to contribute to the difficulty they're using ... maybe that gets it back to the same communications model.
22:34 < gmaxwell> e.g. if blocks get censored you'll know it if you hear the tip.. and then you can go looking for the contributors.
22:34 < midnightmagic> well it's pretty neat they did this paper, it's a cool idea. i wonder if it can work in a p2pool-like sharechain where orphans themselves could count towards the whole.
22:34 < maaku> gmaxwell: if the attacker is in a position to buy more than the entire hashpower of the network, there's a lot more they can do than just that
22:34 < maaku> are you saying they can do it without maintaining that hash advantage?
22:34 < gmaxwell> maaku: only for a brief window? no way. I'm saying they don't have to maintain a hashing advantage.
22:35 < gmaxwell> as you note, once its on-the-head-of-a-pin its unlikely to converge by chance... so they just have to keep proding it to equlibrium if its gets out.
22:35 < gmaxwell> they could have an average hashpower a small fraction of the networks and make the split continue to diverge.
22:36 < gmaxwell> e.g. 10% of the network hashpower they're adding 1 block to the smallest subtree per 10 blocks added to the network.
22:37 < maaku> gmaxwell: i'm not certain of that ... it's not explained how they're able to maintain this partition of knowledge about the orphans
22:37 < andytoshi> maaku: i think the idea is, the nodes don't think to ask for the missing orphans, because they don't see any new blocks referencing them
22:37 < gmaxwell> it's not knoweldge, they're making them and handing them out
22:38 < maaku> gmaxwell: i mean the orphans which resulted in the split in the first place
22:38 < maaku> andytoshi: a GHOST client would benefit from gossiping about orphans
22:40 < maaku> midnightmagic: i'd edit your post. it is perfectly possible to rewind past a difficulty retarget. we don't want to be spreading misinformation to the people who read that
22:41 < midnightmagic> maaku: It's a sub-point of stripping blocks off head..?
22:41 < maaku> midnightmagic: you can have a two-block reorg when the difficulty retarget was 1 block ago
22:42 < maaku> (and have a different retarget as the result, due to different timestamps)
22:42 < midnightmagic> maaku: Yes but after that reorg the head work count is not shorter, correct?
22:42 < maaku> correct
22:43 < maaku> but you post states "This includes rewinding back past a difficulty retarget, which is currently impossible"
22:43 < maaku> that *sounds* like diff retarget == checkpoint
22:43 < maaku> whether that is what you meant or not
22:43 < midnightmagic> I am editing the post, but that is a semantic difference of the meaning of the term "rewind" which I'd hoped was made clear by the fact I'd put it as a subpoint of *stripping off blocks from head without replacing them.*
22:45 < midnightmagic> That is, you have to replace it with a *greater* amount of work, and thus substitute one reorg for another. I'm assuming by now you know what I mean and just don't think the vocabulary I'm using is appropriate.
22:47 < maaku> midnightmagic: correct
23:59 < gmaxwell> yo dawg, i heard you liked vanity https://people.xiph.org/~greg/qr.png
--- Log closed Mon Dec 09 00:00:42 2013