--- Log opened Fri Nov 08 00:00:41 2013
06:31 < adam3us> anyone tried to figure out if ed felten is right?
06:32 < adam3us> i posed the question similarly in my comments to the selfish-miner paper authors (on bitcoin-dev): https://bitcointalk.org/index.php?topic=327064
06:33 < adam3us> wrong link http://sourceforge.net/mailarchive/message.php?msg_id=31612133
06:33 < adam3us> "It is also not clear what will happen if multiple selfish miners compete with each other.  A selfish miner cooperating as a peer to increase percentage runs risk of mutual sabotage - he has to announce his private block to his co-conspirator, and the co-conspirator may publish, or collude with another non-selfish miner."
06:34 < adam3us> felten claims the answer to that q. is selfish mining is unstable so wont persist
06:35 < adam3us> (well a selfish pool composed of multiple smaller pools or powerful miners, is unstable is his claim)
10:39 < amiller> adam3us, ian michael miers sent ed an email about this
10:40 < amiller> it would be pretty straightforward for the pool operator to enforce/discourage fairweather-mining
10:40 < amiller> for example if you don't keep up the pace, you get kickedo ut
10:41 < adam3us> amiller: yes i thought it was an interesting question, and posed it also, but i am not sure ed's gut reaction is necessarily right or properly checked
10:41 < adam3us> is that public email? on a list?
10:42 < amiller> it was a private email, instigated by a public twitter conversation
11:44 < adam3us> amiller: i guess the fair-weather guy could also sell information or be in collusion with or be a larger unselfish miner; then he can switch to the previous block at random, and the selfish miner wont know which block to mine (do this reactively when the selfish miner gets ahead)
11:45 < adam3us> amiller: as soon as the selfish miner is > 1 block ahead (which happens 1/9 of the time with 33% power), the unselfish miner has already lost so he loses nothing new by this strategy
11:47 < amiller> did you switch from fairweather miner to unselfish miner?
11:48 < adam3us> amiller: no
11:48 < adam3us> amiller: fairweather is someone who attacks the selfish mining pool from within, unselfish is someone who is running the normal protocol
11:49 < adam3us> amiller: my point is the unselfish miner can sabotage the selfish mining game, and to the selfish miner he'll just look ridiculously unlucky which he will notice soon enough
11:50 < adam3us> amiller: but if he cant find anyone who wont do that to him, he cant do the attack unless he amasses 33% himself
11:50 < amiller> i have no idea what you're saying actually ;/
11:51 < amiller> you're saying fairweather miners can undetectably leak information to some other unselfsih miner?
11:52 < adam3us> amiller: correct, they can participate in the selfish mining in hashrate, but sabotage it, but it will be noticed statistically that the selfish pool is not doing as well as expected
13:30 < adam3us> seems like it could be useful to extend timelock to be a scrit function rather than a tx property so you can do before, after, ranges, and do in one tx rather than multiple interlocked tx
14:08 < gmaxwell> adam3us: the creates freaky problems where a transaction which falls out of the chain in a reorg can't be put back in.
14:10 < adam3us> gmaxwell: yes you'd have to have it confirmed (timestamped) within it validity period or you're out of luck
14:11 < gmaxwell> adam3us: not just that, it can be confirmed.. and then the chain gets reorged.. and it can never be put back.
14:11 < gmaxwell> The security of all coins decended from that one arguably reduced forever.
14:23 < adam3us> gmaxwell: well a coin reorg that excludes it is not much different to putting zero fees and not getting in the first time
14:25 < gmaxwell> adam3us: it is— because you know when its never been in. This is the same kind of fungibility problem that coins derrived from coinbase txn have, which is why they have a 100 block settling time.
14:26 < gmaxwell> I'm not saying no-never... but it has tradeoffs which make me uneasy.
14:45 < adam3us> gmaxwell: yes.  maybe an addendum could be to authorize belated adding if previously confirmed in an orphan within th required block/time
14:49 < amiller> i don't get how it's different
14:49 < amiller> if the chain gets reorged, one conflicting transaction can replace the other
14:50 < amiller> everything descending from the tree is affected, if the fork goes back that far
14:50 < adam3us> amiller: he means that if its < timelock, nd the time has passed you're out of luck
14:50 < amiller> yeah
14:50 < adam3us> amiller: whereas now timelock is only > timelock so you just resend it
14:50 < amiller> it's still caveat emptor, i don't see how that should matter
14:50 < amiller> or to put it another way, if you receive a bitcoin from someone, who just received it from someone else, it's still not fungible
14:51 < adam3us> amiller: yes that is somewhat true; if a big enough reorg occured to undo 6 blocks, never mind 100 you've got other problem, you're vulnerable to full-on 51% attacks
14:52 < adam3us> amiller: but gmaxwell is right that mined blocks are treated with more suspicion in terms of confirmations at least in the qt client
14:52 < amiller> perhaps they shouldn't be?
14:53 < amiller> anyway i think coinbase maturity is a bad rule because of economic blah blah incentive-compatible but that's a dead horse
14:53 < adam3us> amiller: well there could be an argument that honest reorgs would preserve the transaction order
14:53 < amiller> honest reorgs is a weird model but sure
14:54 < adam3us> amiller: yeah; only justification i can see really
14:56 < amiller> i think incentive-compati-bullshit should trump honest-reorg friendliness, but who's to say :p
14:57 < gmaxwell> amiller: because even without dishonesty on the part of the transacting parties locking in the other direction can screw people.
14:57 < gmaxwell> amiller: they should be, they're not the same as non-fresh coins.
14:58 < adam3us> amiller: well someone (satoshi, someone else) must've put 100 confirms on coinbase tx for some rationale, maybe its even mentioned in the code
14:58 < gmaxwell> They have an additional risk. If the chain reorgs to far they are forever gone no matter how much people wish it were otherwise.
14:59 < gmaxwell> vs if the chain reorgs that far they merely _could_ be forever gone, in the presence of an attack involving a grandparent transaction.
15:01 < adam3us> gmaxwell: this is true, but if chain reorgs much > 6 occurred with any frequency someone may try repeatedly double spending (simultaneously to about 50% of hash rate) sooner or later he'll get lucky
15:01 < amiller> past a small distance, the difference of freshness is a negligible matter
15:01 < amiller> if you're really concerned about forks that far back, then you shouldn't consider fungibility anyway
15:01 < gmaxwell> adam3us: Right, but the criteria of "there must be an attack at all" is a major one.
15:02 < gmaxwell> adam3us: I agree, debate can be had what the small difference was.
15:02 < amiller> i guess you're saying that a major fork is more likely to occur due to honest things that will largely preserve transactions rather than a fork that introduces some magnificent double spend in the past
15:02 < adam3us> gmaxwell: say once per month average this happened (i imagine its never happened ignoring the db bug) people would do it as it would pay off
15:04 < adam3us> gmaxwell: (because double spending to something fungible can have nearly zero cost either you pay yourself (and say oops and pay again) or you pay the seller; sell it back and repeat)
15:05 < gmaxwell> Satoshi picked 100 blocks. I like that figure, you may not. it's hard to argue for any specific value.
15:07 < adam3us> gmaxwell: yes, anyway its nice and conservative and not causing a problem; i do find the script language limitations require extra interlocked transactions, to avoid abort/extort attacks etc but i also appreciate that changing script is very what-if and would have to be very carefully validated for implications
15:08 < gmaxwell> 100 blocks fits well in the timescale of large scale (national level) internet partitionings we've had in the past 15 years.
15:08 < adam3us> gmaxwell: eg opentransactions allows eg javascript or other script langs, ripple draft script lang is not very constrained (to the point of probably security risk)
15:09 < adam3us> gmaxwell: eg imagine halting problem in jscript, or vm escape - all hell could break loose
15:09 < gmaxwell> yea, plus its at the center of a consensus protocol... all implementaitons must agree.
15:09 < gmaxwell> (in bitcoin)
15:09 < gmaxwell> Javascript!@#!
15:09 < gmaxwell> :P
15:10 < adam3us> gmaxwell: (even apart from the cryptographic security of the script language - its hard to prove that the script language changes do not introduce crypto attacks)
15:10 < gmaxwell> OP_RETURN
15:10 < gmaxwell> (facepalm)
15:11 < adam3us> gmaxwell: didnt get the return ref
15:11 < adam3us> gmaxwell: like anyone can cash? sure you can write dumb scripts, but more the worry is the script lang itself introduces a risk for other peoples payents
15:11 < gmaxwell> adam3us: in the original bitcoin source code you could push 1 then OP_RETURN in a _ScriptSig_ and spend any coin you wanted without it ever executing the ScriptPubkey.
15:11 < adam3us> gmaxwell: oh ha ha ha :)
15:12 < adam3us> gmaxwell: thats like being able to write your own script, and then satisfying it tautalogically
15:12 < gmaxwell> this was fixed by turning OP_RETURN into a RETURN(FALSE) effectively. :)
15:13 < adam3us> gmaxwell: well wait shouldnt the satisfying inputs be constants not script keywords generically?
15:13 < gmaxwell> (which was a safe but somewhat kludgey fix... ideally it would have just been prohibited in scriptsigs or.. that)
15:14 < gmaxwell> adam3us: there are slightly useful things you can do with scripts in scriptsigs to make txn slightly smaller, but not worth the problems it creates.
15:15 < gmaxwell> e.g. instead of PUSH_Hash(1) you could PUSH_1 OP_HASH...
15:15 < adam3us> gmaxwell: that seems like a robust fix now i need to go see if i can confuse someone else's script with more script code in front of it (excluding return) is that generically safe even?
15:15 < amiller> it doesn't matter whether 100 blocks is a good value, any number of blocks is bad if you buy my argument about incentive compatibiltiy and stray transactions
15:15 < amiller> i think the question should be whether or not incentive compatibility is a first-class design goal and if so how to cope with it and what to trade off for it
15:16 < maaku> amiller: is that even a question? why would you not want incentive compatability?
15:16 < adam3us> amiller: well i reckon in an ideal world you should be incentive immune - you participate all day long with the devil himself
15:17 < adam3us> amiller: you only fall back to incentive when you cant cryptographically enforce
15:17 < amiller> maaku, i wrote an argument why the coinbase maturity  actually leads to an incentive compatibility glitch
15:17 < gmaxwell> amiller: Transaction independance from the consensus mechnism is a first order design goal of bitcoin.
15:18 < gmaxwell> (in one direction)
15:18 < midnightmagic> incentives are the reason why when people see bitcoin's floodfill and declare it useless because it's O(mn) they're missing the point
15:18 < amiller> maaku, https://gist.github.com/amiller/cf9af3fbc23a629d3084
15:19 < adam3us> amiller: eg re enforcement up to 99%  hostile network with committed transactions thats fun, that the best the attacker can do is random DoS that costs him money, its like a DoS counter measure where the victim can cost the culprit a massive multiplier
15:20 < amiller> i don't understand
15:20 < maaku> amiller: but we can't really change that rule, except by adding it to the someday, maybe hard-fork wishlist...
15:20 < gmaxwell> amiller: I think any argument for incentive-compatible at least for short-term-self-interested is pretty insanely hard to achieve.
15:20 < adam3us> amiller: about commited tx? or ther thread
15:21 < gmaxwell> amiller: e.g. incentive arguments fail to things like miners can just perform a double spend attack of far greater value for the subsidty, enough to pay off a bunch of miners.
15:23 < midnightmagic> amiller: hah, great gist. :) i love it
15:24 < amiller> i think that's fine for my model of attacker
15:25 < amiller> which is a) it's an individual's decision how long to wait, which depends in part on how long *other* individuals wait
15:25 < amiller> b) any attacker that makes a profit has to target some maximum length of attack, so it doesn't harm eventual consensus
15:25 < amiller> thanks midnightmagic :)
16:11 < BlueMatt> gmaxwell: though I agree it is unlikely that analysis is correct and any miners are delaying blocks, does anyone actually have monitoring in place that would tell them if they were?
16:11 < gmaxwell> BlueMatt: I watch for orphans.
16:12 < gmaxwell> I assume other people do to.
16:12 < gmaxwell> (I also get a phone call for reorgs >2 blocks, though that hasn't fired for a while, I ought to set up some test so I know if it stops working)
16:13 < BlueMatt> hmm, fair enough
16:13 < sipa> how often does >2 happen?
16:15 < gmaxwell> sipa: basically never (but not never)
16:16 < gmaxwell> looking at my logs, I see a reorg of 2 once in the last three months.
16:16 < gmaxwell> I don't have logs going back to the last time I saw 3.
16:16 < gmaxwell> but that was the point. At 3 I can reasonably drop whatever I'm doing and go worry about bitcoin... it should be rare enough that its not a terrible disruption.
16:18 < phantomcircuit> gmaxwell, that file is the blocks folder
16:20 < ielo> oh hi there
16:24 < phantomcircuit> nope actually it's an entire .bitcoin folder
16:24 < phantomcircuit> that's bad
16:29 < gmaxwell> phantomcircuit: with wallet too? :P
16:33 < phantomcircuit> sadly no
16:42 < amiller> justaskingplz is the only person working on a bitcoin p2p and mining simulator
16:42 < justaskingplz> hi
16:44 < sipa> cool
16:48 < ebfull> so this is where the cool kids hang out
16:48 < amiller> http://ebfull.github.io/ this is a selfish mining simulation
16:48 < ebfull> a very naive one
16:49 < ebfull> it does appear to work though, shows a sybil+selfish attack together will significantly increase revenue under this topology
16:49 < ebfull> for certain percentages
16:49 < ebfull> of network hashrate
16:53 < adam3us> ebfull: does it take into account that the non-selfish winner will not be convinced by the raced announce?  (and that 80% of the network is pooled, in pool sizes of 30%, 20%, 15%, 7% etc stats from blockchain.info)?
16:54 < adam3us> ebfull: i hacked up a simultator  few dys ago but was unsatisfied with its in ability to model latency (i did start coding the above though)
16:55 < ebfull> it doesn't take into account pools and other large miners, but it can if i change the way nodes are created
16:55 < adam3us> ebfull: also do you have correct parameters to create the approximate correct ratio of accidental orphans
16:55 < ebfull> originally it did
16:55 < ebfull> i adjusted the natural orphan rate to mimic bitcoin's
16:55 < ebfull> everything else is completely different, latency between nodes etc.
16:56 < ebfull> arbitrary that is
16:56 < ebfull> i can adjust the orphan rate, if i make it higher the attacker will get a better lead and earn more revenue
16:56 < ebfull> (as you'd expect)
16:57 < ebfull> i'll try changing it to simulate larger miners
16:57 < adam3us> ebfull: sounds good might be interesting to know what gamma is achievable (ratio of race wins) with realistic latency as cribbed from pool operators
16:57 < adam3us> ebfull: i predicted worse than 50%
16:58 < ebfull> what did you write your simulator in?
16:58 < adam3us> ebfull: which makes profitable alpha (hashrate percent) of between 25% and 33%
16:58 < adam3us> ebfull: C
16:58 < adam3us> ebfull: but it sucks so i abandoned it - you really need to consider triple collisions and such things so my structure was bad
16:59 < ebfull> i considered writing one in c, but i wanted other people to be able to rapidly prototype ideas and changes to the simulation
16:59 < ebfull> i can make this javascript one fast enough for smaller simulations but i probably should write a better one
17:00 < ebfull> i also liked being able to throw in d3 (for graph rendering)
17:00 < ebfull> should i continue with this javascript one or work on a new one
17:00 < amiller> i like the javascript one tbh
17:00 < amiller> it's presentable, that's the main advantage and that's huge
17:01 < amiller> i haven't looked at your code to comment on whether it's flexible/maintainable/presentable so i have no idea what the effort is required to add new little features
17:01 < adam3us> ebfull: wow graphics, wasnt expecting that, mine being written by me was unix console app :)
17:01 < ebfull> it's definitely a mess but i can clean it up well
17:01 < ebfull> ya haha
17:02 < ebfull> you can turn them off if you don't care about them though
17:02 < ebfull> they can use up browser memory
--- Log closed Sat Nov 09 00:00:49 2013