00:41:53gmaxwell:17:39 < justanotheruser> Wouldn't sidechains have full node security given that you could have fraud proofs that prove A) A block is the incorrect size using a merkle sum tree, B) A transaction script doesn't evaluate to true, C) A transaction has a previous tx that wasn't in the utxo at the time (proof that it was already spent)
00:42:23gmaxwell:only if (1) the rules were all identical (yuck) and even then not really because the proof can be arbritarily large.
00:48:01justanotheruser:gmaxwell: Even if all rules aren't identical, couldn't you just have full node security between identical child-chains? It appears to me that in case A the proof size would be either the size of a tx plus a branch of the merkle tree OR the entire merkle trees size. For B it would just be the size of a tx script (assuming the script isn't dependent on other tx in the utxo or something). For C, it appears the proof would ...
00:48:07justanotheruser:... be the size of a branch of a merkle tree plus the size of a tx.
01:15:56justanotheruser:I do agree that it would be difficult for chains with different rulesets to be full node security, but I think it may be possible if you standardize how an opcode is defined (among a set of sidechains that allow this feature).
01:16:28gmaxwell:justanotheruser: No, not quite full node. If its identical and if all the requirements are met for fraud proof being compact (your list is not sufficient), and if you're not considering the censorship of the proof.. then you get something which is in-between because of the censorship risk.
01:18:52justanotheruser:gmaxwell: how is a full node fraud proof more censorable than an SPV fraud proof?
01:20:38gmaxwell:SPV security implies an assumption about the hashrate, a minority of the hashrate cannot persistantly censor.
01:20:38kyletorpey:kyletorpey has left #bitcoin-wizards
01:21:18justanotheruser:Oh, I thought you were talking about propogation censorship
01:23:09justanotheruser:I agree. Censorship means that there can only be spv security until full block proofs are a requirement assuming the same hashing power between chains.
01:24:26justanotheruser:Or the same set of miners having the same hashing power I should say. If it is a different set of miners, two chains could have the same hashing power with one chain having a 51% miner.
01:25:45bitjedi:any coin devs want to take on a side alt-coin dev project (paid)? let me know. I have too many projects.
01:25:55bitjedi:it's not a pegged-sidechain alt
01:26:02bitjedi:because the economics for that are retarded
01:26:12justanotheruser:bitjedi: #bitcoin-otc
01:26:43bitjedi:* bitjedi slithers back into the shadows
01:28:17amiller:here's a thing that's bothering me about the usual presentation of sidechains, this is inspired from a conversation with zooko
01:28:40amiller:there's no difference generally between "inflating" a coin by printing more money to give to miners, and imposing a "tax" where a portion of everyone's money is taken to give to miners
01:29:12amiller:even though there's no real difference, i think the former is perceived as more tolerable than the latter.
01:29:39amiller:however, in sidechains, it's basically recommended to flip that around.
01:29:40gmaxwell:I think both are non-starters and are uninteresting.
01:30:37amiller:if miners on a sidechain are going to receive mining fees, then it either has to come from inflating the sidechain coin relative to its bitcoin peg, or it has to come from reducing sidechain user's holdings
01:31:49maaku:amiller: there is a difference, but it's OT here
01:32:15amiller:if both of those are non-starters (and based on the sidechains paper) i guess you're recommending having sidechain mining rewards only come from transaction fes
01:32:25gmaxwell:amiller: it comes from the same place Bitcoin miners fees come from long term; transaction fees.
01:42:14BlueMatt:* BlueMatt likes namecoin as a sidechain - the fees people expect to pay for namespace/updates make for a less negative feeling when paying fees which go to miner security
01:42:43BlueMatt:ie people are already used to 10$/yr for a domain, not so much transaction fees (mostly they just dont see them, but still)
03:45:25Taek:demurrage/inflation makes sense to me for miner fees. The people with coins sitting in the sidechain/altcoin have a vested interest in it staying secure
03:45:49Taek:it's more of a luxury if fees alone are sufficient
03:47:51justanotheruser:Taek: the funny thing is miners can implement demmurage as a softfork whenever they want
03:48:30justanotheruser:Taek: also, at least two of the names on the sidechains paper would agree with you
03:52:13Dizzle_:Dizzle_ is now known as Dizzle
04:20:32BlueMatt:justanotheruser: huh? no they cant!
04:20:57BlueMatt:justanotheruser: only if the sidechain is set up to auto-demmurage on stolen coins
04:21:52Luke-Jr:BlueMatt: they could freeze all outputs that don't honour their demurrage rules
04:22:34Luke-Jr:so technically, miners could enforce demurrage on bitcoin today
04:22:39BlueMatt:Luke-Jr: that would be a soft-fork to require miner fees, essentially
04:22:43BlueMatt:not the same thing
04:22:58Luke-Jr:pretty much the same thing IMO *shrug*
04:23:02BlueMatt:to make it equivalent they'd need to keep 51% forever
04:23:08BlueMatt:so not at all the same thing
04:23:16justanotheruser:00:22 < BlueMatt> to make it equivalent they'd need to keep 51% forever
04:23:23justanotheruser:that is what a softfork requires after all
04:23:26Luke-Jr:BlueMatt: that's true of any softfork
04:23:47BlueMatt:softfork requires more than miners, remember...
04:23:57BlueMatt:for a softfork to be a softfork people have to enforce it as well
04:24:02BlueMatt:otherwise its just a 51% attack
04:24:13justanotheruser:BlueMatt: if you define a 51% attack that way, yeah
04:24:21Luke-Jr:it's soft because it only requires miners
04:24:25BlueMatt:no, they are two very different concepts
04:24:47Luke-Jr:BlueMatt: only miners have ever been considered in proposals for softforks
04:24:58gwillen:welllll, it doesn't practically speaking require the cooperation of nonminers
04:25:09gwillen:the outcome will be the same whether they cooperate or not
04:25:11BlueMatt:yes, and then its a 51% attack
04:25:21gwillen:so, maybe at some moral or theoretical level, fine
04:25:27BlueMatt:the difference is without the cooperation of non-miners, people who are pissed can go buy hashpower
04:25:30gwillen:but that doesn't really matter in practice
04:25:37BlueMatt:but in a softfork that doesnt help
04:26:02gwillen:yeah, that's true; if all the merchants switch to your softfork then the hashpower that doesn't switch doesn't matter
04:26:15Luke-Jr:a softfork isn't a softfork if it doesn't maintain 51% of miners
04:26:17BlueMatt:yes, then it actually is a softfork via economic majority :)
04:26:24BlueMatt:Luke-Jr: yes it is!
04:26:32Luke-Jr:no, the behaviour is essentially equivalent to a hardfork if it drops below 51%
04:26:39BlueMatt:if you do a softfork and then 99% of miners decide they dont want it anymore, the rules still apply
04:26:46Luke-Jr:BlueMatt: not to old nodes
04:26:52BlueMatt:you just lose 99% of mininer power to any new nodes
04:26:58justanotheruser:BlueMatt: all softforks require a mining majority anyways. The only difference is the majority of full nodes may not use the softfork (which has probably been true for previous softforks)
04:26:59Luke-Jr:softfork isn't a hardfork because old nodes follow it
04:27:13BlueMatt:yes, but this is why softforks require buy-in from lots of the community....otherwise its only a softfork to a few people
04:27:25BlueMatt:justanotheruser: nope, actually...
04:27:33Luke-Jr:if old nodes follow the more-work non-softforked chain, then the softfork is essentially a hardfork
04:27:49BlueMatt:softforks do to be enforced for old clients, but new clients can fork at will (ofc it gets fuzze depending on your definition of softfork)
04:28:01BlueMatt:Luke-Jr: depends on your definition
04:28:15justanotheruser:BlueMatt: new clients can't fork at will. They require a miner majority to softfork
04:28:18BlueMatt:softfork definition is usually that its a stricly smaller set of valid transactions
04:28:22BlueMatt:justanotheruser: what???
04:28:35justanotheruser:BlueMatt: I should ask the same of you.
04:28:50BlueMatt:justanotheruser: any set of users can fork at will based on some softfork rules
04:29:04BlueMatt:justanotheruser: if they're not the economic majority it doesnt matter much
04:29:10Luke-Jr:BlueMatt: a softfork without miner support is a hardfork because it makes what was previously "not the best chain" and makes it "the best chain" - same as making an invalid transaction valid
04:29:12justanotheruser:BlueMatt: new clients that fork without miner support are hardforking
04:29:23BlueMatt:but if bitpay+coinbase+all exchanges+all merchants decided they wanted fees to be paid to them in all transactions...they can go fork and do so
04:29:47BlueMatt:Luke-Jr: ok, yes, this is where it just matters on what your definition of soft vs hardfork is, frankly I dont know what the consensus is here
04:30:05Luke-Jr:BlueMatt: to exclude that case, negates the meaningfulness of the distinction
04:30:32Luke-Jr:the only purpose to having two separate terms "softfork" vs "hardfork" is because of the distinctive difference
04:30:34BlueMatt:well it does still have one distinction: old clients can switch to the forked chain
04:30:41Luke-Jr:can, but won't.
04:30:45Luke-Jr:no practical difference
04:30:46BlueMatt:whether its smaller or not is important, but not all
04:30:55BlueMatt:well, maybe the new fork gets more mining power slower?
04:31:09BlueMatt:possible is actually important here in the longer run, depends on how long you dont have 51% mining power
04:32:24Luke-Jr:* Luke-Jr debates trusting 0.9.x, or waiting out for 0.10.x
04:33:13justanotheruser:Luke-Jr: can you elaborate on why 0.10.x may be a hardfork?
04:33:17BlueMatt:->#bitcoin-dev, but I would be hesitant to trust 0.10...maybe till 0.10.X
04:33:21Luke-Jr:justanotheruser: huh? why would it be?
04:33:22BlueMatt:too big a release
04:33:31BlueMatt:justanotheruser: I believe it was not related to the previous conversation
04:33:39justanotheruser:Luke-Jr: you were discussing that a bug may cause it to be with wumpus in -dev iirc
04:33:59Luke-Jr:BlueMatt: yeah, but is it worth upgrading to 0.9.x for just a few months? :p
04:42:11justanotheruser:Luke-Jr: http://hastebin.com/yedelezazo.xml
04:51:55Luke-Jr:justanotheruser: oh, that. just pure risk
04:52:18Luke-Jr:more code churn = more risk of hardforking accidentally
08:05:16wolfe.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
08:05:16wolfe.freenode.net:Users on #bitcoin-wizards: andy-logbot cbeams HaltingState kjj21__000 damethos aburan28 todaystomorrow jaekwon_ ericp4 pen RoboTeddy TheSeven DoctorBTC chinjai Aquent1 bosma devrandom Dr-G3 bitjedi tacotime fanquake justanotheruser Taek zenojis wiretapped Cory sneak digitalmagus atgreen Rynomster Sangheili adlai EasyAt iddo nsh_ Anduck devsaturn rfreeman_w torsthaldo Baz___ warptangent vdo zwischenzug jokosh Greed maaku Hunger- Transisto LarsLarsen optimator_ Starduster
08:05:16wolfe.freenode.net:Users on #bitcoin-wizards: wizkid057 altoz kumavis heath andytoshi dgenr8 shesek Kretchfoop ebfull comboy arowser1 BrainOverfl0w copumpkin c0rw1n nuke1989 spinza waxwing fds4345 dansmith_btc samson_ gazab Graftec mappum jbenet sl01 Iriez artilectinc go1111111 bbrittain BigBitz Apocalyptic emsid Starsoccer throughnothing warren tromp_ null_radix gavinandresen iambernie dansmith- Meeh pi07r d4de GnarSith irc88 forrestv kyuupichan stonecoldpat Nightwolf AdrianG Logicwax
08:05:16wolfe.freenode.net:Users on #bitcoin-wizards: jgarzik mmozeiko fluffypony mr_burdell Eliel zibbo_ tromp berndj SomeoneWeird kgk firepacket Dyaheon hollandais myeagleflies wumpus @ChanServ lechuga_ abc56889 harrow so ahmed_ Gnosis Keefe pajarillo roasbeef ryan-c otoburb helo [Tristan] TD-Linux catcow danneu coryfields btc_ crescendo amiller yoleaux jrayhawk_ Muis michagogo @gwillen BlueMatt smooth petertodd bobke hguux _2539 gmaxwell sipa [\\\] coryfields_ livegnik burcin MRL-Relay Graet
08:05:16wolfe.freenode.net:Users on #bitcoin-wizards: CryptOprah epscy espes__ midnightmagic Guest89609 HM_ gnusha LaptopZZ [d__d] NikolaiToryzin fenn artifexd phedny PaulCapestany phantomcircuit paperbot superobserver Luke-Jr poggy a5m0 Alanius kinlo btcdrak Krellan nsh gribble CodeShark super3 kanzure Fistful_of_coins weex_ asoltys lnovy Grishnakh nanotube pigeons K1773R
08:40:40wumpus:Luke-Jr: another reason why the consensus library is important, when we can move the consensus critical parts to their own repository it's much easier to keep track of which code changes have risk of a hardfork
08:41:43Luke-Jr:wumpus: yep
09:35:11penny:penny is now known as Guest91682
11:52:26Rynomster:Rynomster is now known as SDCDev
12:58:57Aquent1:Aquent1 is now known as Aquent
16:00:29Taek:I've been trying to find discussion of this somewhere
16:01:09Taek:but, isn't there an attack possible where a malicious miner releases blocks that are timestamp'd out of bounds for half of the network, which would cause a split?
16:01:41Taek:if you timestamp a block 10 hours in the future, 100% will reject the block and not mine on it
16:02:09Taek:and if you timestamp a block that is current time, 100% will accept the block
16:02:43Taek:since miners don't have perfectly consistent timestamps, there should be a timestamp you can put on a block that will cause ~50% of the network to accept, and 50% of the network to reject
16:03:19Taek:through experimentation, you can find the timestamp that splits the network most evenly, and mine on the larger side, which will increase your expected return per hash
16:03:29MRL-Relay:[surae] Taek yes, Monero is currently working on various "timewarp" attack scenarios, but Monero is different in that there isn't a system time computed from everyone else's time like in Bitcoin
16:04:03sipa:Taek: too high timestamp doesn't make the block invalid
16:04:07sipa:it's just ignored
16:04:14sipa:it can later be resubmitted and accepted
16:04:15MRL-Relay:[surae] I'm not sure if your particular attack route would work, but I know that, for example, by purposely mis-stamping your blocks consistently back-in-time or forward-in-time you could cause drift in folks' perceived time
16:04:36sipa:there's no consensus risk from a too-high timestamp, just reduced propagation
16:05:06sipa:MRL-Relay: network time is not computed from block timestamps
16:05:07MRL-Relay:I am a relay bot linking this channel to the Monero Research Lab
16:05:13sipa:i know
16:05:19Taek:sipa: if the timestamp is ignored by only half of the miners, then half of the miners will mine on your block, and the other half will continue to mine on the parent
16:05:57sipa:yes, and when they announce their next block, everyone will happily switch to the new better chain, including the block they previously didn't accept
16:05:57MRL-Relay:[surae] sipa doesn't that depend on how difficulty is being computed? if the network is expecting blocks to appear every 10 minutes, and someone with a lot of hashing power posts a bunch of blocks a few hours in the future, doesn't it appear as if blocks are taking longer?
16:06:35sipa:MRL-Relay: yes, sure, but that has nothing to do with the network time rule, or acceptance of blocks
16:06:35MRL-Relay:I am a relay bot linking this channel to the Monero Research Lab
16:06:38sipa:I KNOW
16:06:48MRL-Relay:[surae] lol i have no idea why it's doing that
16:07:25tacotime:Sorry, relay has been a bit buggy sometimes. fluffypony your relay is doing weird stuffs.
16:07:31MRL-Relay:[surae] no, but if you are talking about attempting to manipulate difficulty with a disproportionately small amount of hashing power...
16:07:52MRL-Relay:[surae] rather than trying to cause a fork or something funky
16:07:57sipa:that's not what we're talking about
16:08:03Taek:sipa there's no consensus risk, but it does increase the amount of stale mining that happens, which can be abused to increase the expected returns on mining.
16:08:03sipa:you're talking about a validity rule for chains
16:08:22sipa:Taek: sure, you're just silly if you set your blocks' timestamps dangerously high
16:08:37sipa:it means your blocks have a lower chance of being built upon, that's all
16:08:39MRL-Relay:[fluffypony] tacotime: it self-defines if you mention it by name I think - I'll nuke that functionality later
16:10:01Taek:Is the attack not functionally similar to a block discarding attack?
16:10:25MRL-Relay:[surae] yeah now i'm confused (my typical state of being, I guess)
16:10:28sipa:yes, except performed by the sender
16:10:39sipa:it's making your own blocks be discarded...
16:11:15Taek:If you split the network into mining 40% on parent, 60% on high-timestamp child, and you mine on the high-timestamp child, your chain has a very high probability of winning
16:11:26Taek:because the 40% chain needs to make 2 blocks to catch up
16:12:14MRL-Relay:[surae] so, set aside the discarding bit, because there's another danger, and that's someone with less than 50% hashing power manipulating difficulty in a way that is disproportionate to their hashing power, which concerns me more...
16:13:09Taek:consistently performing this attack increases the amount of stale mining, which will drive down the difficulty
16:14:14MRL-Relay:[surae] yeah, that's true, too... my understanding is that hash power is estimated by looking at the number of blocks that have been posted in a period of time. so if somoene is posting a bunch of blocks several hours in the future, the "number of blocks" probably hasn't changed but the "period of time" has been spread out more
16:14:35sipa:there's a limit on how far in the future you can go
16:14:39sipa:max 2 hours
16:14:46MRL-Relay:[surae] ok, so push the envelope to +2 hours
16:14:49sipa:so whatever someone can game, it 's bounded
16:15:38Taek:if there are more stale blocks, the apparent number of blocks created in the same amount of time will be lower
16:15:45sipa:so you can get a 0.6% reduced difficulty from gaming, at the cost of making your blocks less likely to win
16:15:57MRL-Relay:[surae] post all your blocks with +2 hours, if you own 10% of the network, it'll look like rather than getting 1 block every 10 minutes, it looks like you are getting 1 block every 10 minutes across 90% of the network but 1 block every 2 hours across 10% of the network, driving difficulty down
16:16:01sipa:and if they don't win, it doesn't matter
16:16:24MRL-Relay:[surae] why 0.6%?
16:16:37MRL-Relay:[surae] just chose a tiny number or is that an estimate?
16:16:53sipa:2 hours in 2 weeks
16:16:57sipa:is 0.6%
16:16:59MRL-Relay:[surae] ah
16:17:49MRL-Relay:[surae] that is one benefit of having a large difficulty adjustment period
16:18:03sipa:one of the many benefits :)
16:18:09Taek:you can have a greater impact than 0.6% if the network is consistently mining on 2 chains.
16:18:26sipa:how so?
16:18:49sipa:difficulty is computed per chain
16:18:54Taek:let's say that 10% of the blocks are high-timestamp, such that 50% mine on the child, and 50% mine on the parent
16:18:58tromp:I think what Taek is suggesting is that if say, hash power was split 60%-40 % across the equator, then when announcing your solved block, being able to drop all cross-equator relays would be beneficial for the miner
16:19:24sipa:that's a collusion attack
16:19:28tromp:to drop replay of just that block
16:19:47sipa:but it's a valid one: if you know you can reach 50% of the hashing power quickly, there is no need to relay to others
16:21:58MRL-Relay:[surae] is the +2h cutoff based on the client time or the top block on the blockchain?
16:22:12sipa:network time
16:22:15MRL-Relay:[surae] i.e. local wall clock or the timestamp of the latest block? seems like it has to be local wall clock
16:22:15Taek:it's a collusion attack that can be organized by a single person, taking advantage of the fact that not all miners have synchronized understandings of the network time.
16:22:17MRL-Relay:[surae] oh network time.
16:22:43sipa:which you can game with a sybil attack, but not by mining
16:23:27MRL-Relay:[surae] ah, but let's say I have 10% of hashing power, as in Taek's example, and so 1 in every 10 newly minted blocks are mine. And I'm consistently putting my tiemstamps ahead by +2 hours.
16:23:53MRL-Relay:[surae] about half the network will ignore it, continuing to mine on the parent, and half the network will mine on the +2h child block, right?
16:24:17sipa:Taek: i don't understand
16:24:53sipa:and when someone extends the +2h child block, everyone switches to it
16:25:23Taek:right but until the child block gets extended, only 60% of the network is mining on the chain
16:25:24sipa:so all you accomplish with your +2h time is that half of your blocks don't end up in the main chain
16:25:27sipa:waste of money
16:25:39Taek:much more than 50% of your blocks will make it
16:25:53Taek:because the 40% side needs to make 2 blocks to catch up
16:26:44Taek:the result though is that because 40% of the hash power is wasted 10% of the time
16:26:58Taek:the apparent amount of hashing power in the winning chain is 4% lower
16:27:08tromp:Taek: you're also implying that tweaking the 2hour cutoff to, say, 2h+5mi, would be beneficial for miners
16:27:16MRL-Relay:[surae] so i guess the question is: is the attacker trying to make money *right now* by executing some sort of bizarre attack, or are they trying to increase stale-rates, drive down difficulty, to make mining easier next week?
16:27:33MRL-Relay:[surae] tromp actually I think the cutoff time should be shorter if anything, but then you have daylights savings time screwing with everyone
16:27:45Taek:right this attack is a longer term attack
16:28:01MRL-Relay:[surae] a difficulty-drift?
16:28:16sipa:MRL-Relay: network time is UTC; no DST here
16:28:17MRL-Relay:I am a relay bot linking this channel to the Monero Research Lab
16:28:32MRL-Relay:[surae] <--- surae, not the relay.
16:28:49MRL-Relay:[surae] then why even have a +2 hour cutoff? why not make it 45 minutes? or 30 minutes?
16:28:53Taek:surae can I highlight you through the relay?
16:29:34MRL-Relay:[surae] what do you mean? when you mention "surae" the chat line is highlighted
16:29:35sipa:i think 1 minute would be plenty
16:29:52sipa:can't you just use IRC directly...?
16:30:58MRL-Relay:[surae] i suppose... i'm being relayed through MRL so as to maintain a connection with that research group but it's not necessary really...but i have to go right now anyway so it's not like it matters for right now
16:32:18MRL-Relay:[surae] it's all immaterial anyway because the bitcoin network is so big... i'm more interested in smaller altcoins and their difficulty adjustment and timestamp handling
16:32:24Taek:tromp: tweaking the cutoff wouldn't help, regardless of where the cutoff is set, there's some timestamp a subversive miner can pick that will have ~50% of the nodes ignoring the block
16:33:01tromp:Taek: by tweaking i mean subversively deviating from the official cutoff
16:33:34tromp:in order to avoid being in the 40% parent-mining group of your example
16:43:32tromp:in any case it will be interesting to see the reaction to a major pool setting +2h timestamps
17:07:42stonecoldpat:id be surprised to know how many miner's timestamps are really that out of sync (assuming most connect to an ntp server already) and if it were possible to find a reasonable 50% (or 60-40) cut-off point
17:42:55Pan0ram1x:Pan0ram1x is now known as Guest3670
17:48:49stonecoldpat:just did a quick check and it does seem the 2 hour boundary has been hit (118 minutes) by comparing previous block time with the latest in the chain, but with a quick eye check most of them are synched quite well (assuming 0-10 minute gap for a new block to be created)
17:49:32stonecoldpat:of course cant check that with time i seen them appear sadly
17:50:56justanotheruser:stonecoldpat: so there was a 118 minute gap between blocks you're saying?
17:51:41sipa:there has been a 1 week gap between blocks...
17:52:12sipa:you need to look at clocktime vs blocktime if you want to know how much the boundary matters
17:56:45justanotheruser:sipa: when was there a 1 week gap? 2009?
17:56:54sipa:between block 0 and 1
18:02:45tacotime:on the seventh day, satoshi rested.
18:13:39ryan-c:phantomcircuit: Is cloudhashing your pool?
18:21:50gmaxwell:surae: yea, so? it's a 0.5% difficulty hit, one time.
18:21:59gmaxwell:(a two hour advance)
18:46:18Taek:gmaxwell: with 1/3 hash power you can lower the difficulty 6.6% while increasing your profits: http://pastebin.com/aqMptxW4
18:59:59gmaxwell:Taek: uh. you seem to be omitting a procedure for selecting timestamps that 1/5 will ignore (and won't stop ignoring seconds later)
19:12:33Taek:selecting timestamps could potentially be done by trial and error, especially if nodes won't forward a block that they see as invalid
19:13:12Taek:you have some hidden nodes around the network that pay attention to which nodes are forwarding the high-timestamp blocks you release
19:13:36Taek:you slowly raise the timestamp until ~1/5 of the mining power isn't forwarding your blocks
19:14:09Taek:If the whole network is mostly synchronized, and nodes will start mining on a block as soon as it becomes valid, then the attack isn't effective
19:15:12Taek:but that would require miners to remember blocks that were in the future, and to re-validate them once they were no longer too far in the future -> not too hard to program but I don't know if this is the current behavior
19:21:01Taek:you probably only need a network skew of 1-2 minutes to make this work, even if nodes do start mining on blocks as soon as they are valid
19:32:28gmaxwell:Taek: your figuring doesn't account for only 1-2 minutes of rejection, however.
19:32:37gmaxwell:It assumes they reject forever, even an hour later.
19:51:49skyraider7:skyraider7 has left #bitcoin-wizards
19:58:03dgenr8:Taek: now + 2h + avg-block-propagation-time is where you'd start
19:58:05dgenr8:what's interesting about this timestamp split is that it's not happening. PoW is working as a way to reduce these kinds of games, which are like DoS attacks
20:13:10fluffypony:ok good, all fixed
20:13:13fluffypony:MRL-Relay: now behave.
20:14:12Taek:MRL-Relay is relay bot linking this channel to the Monero Research Lab
20:16:17fluffypony:Taek: yes - I was just disabling that thing where it explained itself when someone mentioned it by name
20:16:21fluffypony:except now I appear to have broken the relay
20:16:45Taek:just poking fun lol
20:17:51Taek:gmaxwell: tried to adjust the figuring: http://pastebin.com/Zy0YknPR
20:18:00MRL-Relay:[fluffypony] testing 1 2 3
20:18:05fluffypony:there we go, all fixed
20:18:11fluffypony:sorry about it misbehaving earlier, sipa
20:18:17Taek:appears that ~5 minutes of network skew is needed, assuming a linear distribution
20:18:32Taek:as skew reduces, the amount of wasted mining that high-timestamps can introduce goes down substantially
20:19:37Dizzle__:Dizzle__ is now known as Dizzle
20:21:11Dizzle__:Dizzle__ is now known as Dizzle
20:22:34nsh:Taek, do you have a write-up of the attack class you're discussing yet?
20:22:54nsh:or discussion on the mailing list, or what have you
20:23:10gmaxwell:please don't just take half baked things to the mailing list.
20:24:12gmaxwell:nsh: he's suggesting that if some miners clocks are slow relative to a supermajority of the network, you could intentionally produce blocks right at the limit where the supermajority would accept, making the slow miners reject, and in those cases where you are successful, leaving them a block behind the supermajority.
20:28:31kanzure:raft stuff http://raftconsensus.github.io/ (slightly off-topic)
20:29:28Taek:nsh: All I've got is what I've typed here today. Idk what the clock skew of the network looks like, but it'd need to be pretty large for this attack to make sense, assuming that the attack even works in the first place.
20:30:39Taek:plus the total effects of the attack are a pretty minor difficulty reduction + wasted mining for the miners with slow clocks.
20:31:22Taek:*wasted mining for the miners with fast clocks
20:31:42Taek:no wait slow nvm
20:39:17Eliel:Taek: wouldn't that attack cause loss of income for the rest of the network? I'd expect it'd end up fixed rather fast if anyone actually started doing it.
20:40:12Taek:It would cause short term loss of income for everyone, but that'd fix as soon as the difficulty adjusted
20:42:16Eliel:I'd expect the orphan rate to stay high as long as the attack continues. That in itself would motivate fixing.
20:43:13gmaxwell:I'm simulating this any only seeing tiny amounts of orphaning.
20:43:33gmaxwell:the minority gets ahead a pretty large chunk of the time too.
20:44:47Eliel:how big is this tiny if calculated in terms of income lost to orphans?
20:45:02Eliel:in percentage
21:22:36Dizzle___:Dizzle___ is now known as Dizzle
21:37:35dgenr8:10 minutes of rejection would be a good figure, since that's when minority would probably get an orphan and request the far-out block again
21:39:47dgenr8:though it would be more than that due to the split
21:41:55amiller:https://konradsgraf.squarespace.com/storage/Monetary%20analsyis%20of%20sidecoins%20KG%2024Oct2014.pdf Sidechained Bitcoin Substitutes: a Monetary Commentary
21:44:40amiller:(haven't seen this posted here or discussed directly but it's 5 days old i guess)
22:39:47nsh_:amiller, do they make any valid points?
22:40:53go1111111:amiller: maybe I missed something, but I found that paper to say something very trivial in a very verbose way: the price of sidecoins will likely be discounted to the extent of the risks of having coins on a sidechain, and the movement delay
22:40:58gmaxwell:nsh: the point of it is not invalid, but also I think not very interesting.
22:41:14gmaxwell:what go1111111 said.
22:41:36Eliel:go1111111: surprisingly, it reads the exact same way to me.
22:42:00Eliel:7 pages to state what you could easily state in a couple of sentences :P
22:42:40nsh_:right, that was my confusion too
22:43:17Eliel:reading it felt like reading the same argument over and over again
22:43:26Eliel:each time worded a bit differently
22:45:52Eliel:I'm baffled as to why someone feels the need to write a 7 page paper to state an obvious fact that can be expressed neatly and concisely in a few sentences.
22:46:59BlueMatt:Eliel: because it makes it seem more important and thought-out
22:47:18BlueMatt:and in bitcoin-land, it makes you look special and like an academic who should be treated with respect
22:47:40gmaxwell:I'm glad people are thinking about things, ... thats just the way some people think.
22:49:56nsh:it's all grist for the mill :)
22:50:22nsh:except when it's sand in your eyes