--- Log opened Mon Nov 04 00:00:16 2013 17:11 < amiller> uh.. does anyone have a rough figure for the gate count of an asci/fpga mining unit 17:11 < amiller> i'm trying to come up with a way of projecting what the relative cost per operation would be using rsa operations rather than sha2 19:10 < gmaxwell> wow, unethical headlines say what? "bitcoin-protocol-vulnerability-could-lead-to-a-collaps" 19:58 < petertodd> gmaxwell: meh, don't fall in love with your babies. It's a deeply ugly issue, just like all the other centralizing forces are, and we're naive to assume it won't be a problem. 19:59 < gmaxwell> petertodd: I'm not saying its a non-issue, I'm saying it's being heavily exagerated, and I think it's _less_ of a centralizing forces than many other ones that people don't care about at all. 19:59 < petertodd> The deeper problem is it's easy to see how Bitcoin could still be useful to some people, and hence valuable, even if it was mostly centralized... like right now in the short term. Add some more centralizing forces and that can become a long-term, permanent thing, where mining is a weird cartel. 20:00 < petertodd> gmaxwell: Sure, but given that those other issues *are* plenty real, I'm going to call the headline reasonable, even if it's more than just one issue that makes it reasonable. 20:01 < gmaxwell> I suppose it's fine to see people pointing out the centeralizing forces are a risk. I suppose thats news to people who are not me. :) 20:01 < petertodd> Well, yeah, lots of people don't understand that stuff at all. 20:02 < petertodd> Anything that gives people the accurate impression that Bitcoin's decentralization is mostly a function of the community at best is probably a good thing, and I'd say it's ethical reporting. 20:02 < gmaxwell> This is kind of a lame context for it though. 20:02 < petertodd> (IE the technology is broken, and absent community pressure we'd see 51% pools) 20:05 < petertodd> Anyway, tech question: has anyone ever seriously analyzed the effects of a chain-selection algorithm that counted total work, that is one where work could be worth more if it was especially under the target? 20:09 < gmaxwell> petertodd: yea, I ran a simulation on that (counting target instead of work) in 2011, uh, I should look for logs. What I concluded was that it created huge incentives to delay announcing solutions. 20:10 < petertodd> gmaxwell: Right, that's what I concluded. On the other hand, if you add a cutoff, where work is never more valuable than a certain amount, that seems to reduce the incentives, while maybe preventing the selfish miner attack. 20:11 < gmaxwell> I'm doubtful but haven't tried that. I haven't really had time to think about it much though. 20:12 < gmaxwell> through the day I've warmed a little to their "solution" 20:12 < petertodd> Well, basically the decision to not announce is based on the strength of your solution, given that there's a certain chance the other hashing power would come up with a better solution than you do. 20:12 < petertodd> ha, for me it's the exact opposite: their solution asks miners to do what's against their short-term economic incentives. 20:13 < gmaxwell> oh to actually be random? interesting point. 20:13 < petertodd> Yeah. Even with someone trying to carry out that attack, you're better building on the block the majority is regardless. 20:15 < petertodd> I gave it a go at working out the actual equations for expected return for a given amount of hashing power, and first try popped out the answere that if solution value is random, it always makes sense to reveal your blocks. Though I suspect I screwed that up somewhere... 20:17 < gmaxwell> petertodd: if the solution is random and you have a lot of hashpower, then you should delay. I thought the threshold was like 40% but uuk was saying 33% earlier. 20:17 < petertodd> uuk? 20:20 < sipa> UukGoblin 20:21 < petertodd> ah. Anyway, that's why I suspect I screwed up. :) 20:23 < sipa> i seem to remember a number closer to 40-45% ish 20:23 < sipa> but i never thought hard about it, or looked up where the number came from 20:24 < petertodd> Yeah, anyway, IMO something like that wouldn't be too bad, so long as the incentives to hide blocks were under control - the paper's solution worries me given that it's not economically rational. Good to have an alternative. 22:07 < midnightmagic> how does withholding a block not penalize the selfish miners and wouldn't their activity be discernible without an accompanyingly-expensive sybil network? 22:08 < midnightmagic> Also, if centralization is a risk to the value of the currency, then why would "rational" miners mine to increase centralization and thus decrease trust in the currency? 22:09 < gmaxwell> it would be trivally discernible. 22:09 < gmaxwell> midnightmagic: why do we have mining pools with 30% hashpower or whatever? 22:09 < midnightmagic> because everyone thinks the magic number is 51% 22:10 < gmaxwell> midnightmagic: delaying the block only peanlizes them if they lose the race against a competing block as a result, the paper argues that with the right network stunts they can avoid that. 22:10 < gmaxwell> well perhaps this paper will help then. 22:10 < gmaxwell> or make it worse. 22:10 < gmaxwell> if people think a 30% pool is doing bad thing perhaps they'll join it. 22:10 < midnightmagic> it seems to me all this is already well-known. 22:11 < midnightmagic> (at least among people who care anyway) 22:11 < gmaxwell> well I don't think I had considered the ability to network-attack to shift the balance. 22:33 < petertodd> midnightmagic: my ELI5 explanation: https://bitcointalk.org/index.php?topic=324413.msg3484951#msg3484951 22:35 < petertodd> Basically the attack leverages an investment in low-latency nodes and networks - if all miners do it the miner that wins is the one with the least-latency per dollar, very roughly speaking. 22:36 < petertodd> Unfortunately least-latency per dollar is very likely to mean "huge up-front costs", a strong-centralization force. 22:58 < midnightmagic> hrm.. 23:14 < midnightmagic> p2pool blocks seem a tad innoculated against it. 23:18 < petertodd> why? 23:18 < midnightmagic> p2pool simultaneously releases blocks to all member bitcoind when a successful p2pool share exceeds bitcoin target 23:19 < midnightmagic> .. or so I thought 23:19 < petertodd> p2pool doesn't do anything "simultaneously" any more than the bitcoin network itself does 23:19 < midnightmagic> the p2pool share is smaller than a bitcoind block. its propagation is faster. 23:20 < midnightmagic> in a minor sense, we're already using the nature of p2pool to get our blocks broadcast faster than normal pools with monolithic network infrastructure can 23:22 < midnightmagic> this is probably why this new paper doesn't feel novel. 23:24 < midnightmagic> of course, gmaxwell can correct this in the event it's a misapprehension of p2pool operation 23:24 < midnightmagic> or forrestv 23:24 * midnightmagic waves. 23:27 < midnightmagic> of course, I guess they could just listen to the p2pool network for solutions and short-circuit us that way.. 23:31 < midnightmagic> but we're still short-circuiting actual block propagation.. so.. 23:31 < petertodd> exactly. I suspect this stuff will turn out to be latency driven, so a succesful selfish miner will be one with access to low-latency optimized networking 23:32 < midnightmagic> if we presume our txn list is similar across the network, could we use a p2pool-like short-msg to propagate blocks more rapidly over the pre-existing network? 23:33 < midnightmagic> and thus make the attack more expensive, without convincing everyone to use p2pool subgroupd 23:33 < petertodd> of course we could, but we'll still lose out to the guy with access to dedicated fiber arranged along min-distance great circles... 23:35 < amiller> you can use my bitcoin mapping technique to find the best number of people to connect to to be one hope away from everyone 23:36 < petertodd> amiller: email them! I spoke briefly in private with them, and they sounded interested in writing more papers 23:37 < midnightmagic> it would amuse me if the long-run fiber being contemplated in canada to avoid US traversal became a superior bitcoin-propagation network due to a decreased number of router fabric traversal 23:37 < midnightmagic> poor-man's geographic bisection 23:40 < petertodd> that would frighten me... I pointed out on the email list how in general orphans will encourage bitcoin mining pools, and even the hardware itself, to be centrally located geographically 23:58 < midnightmagic> petertodd: What would frighten you? Everyone moving to a bunch of p2pool subgroups or amiller's suggestion to map bitcoin and accelerate the coming of a new Mining Age? :) 23:58 < midnightmagic> not to mention possibility of network segmentation 23:59 < midnightmagic> also: amiller is this the mechanism you were discussing with me a while back? 23:59 < petertodd> heh, nah, just how it'd give strong incentives for everyone's pools to move to the same country/town/datacenter 23:59 < midnightmagic> ah, yeah for sure --- Log closed Tue Nov 05 00:00:20 2013