| 00:41:53 | gmaxwell: | 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:23 | gmaxwell: | only if (1) the rules were all identical (yuck) and even then not really because the proof can be arbritarily large. |
| 00:48:01 | justanotheruser: | 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:07 | justanotheruser: | ... be the size of a branch of a merkle tree plus the size of a tx. |
| 01:15:56 | justanotheruser: | 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:28 | gmaxwell: | 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:52 | justanotheruser: | gmaxwell: how is a full node fraud proof more censorable than an SPV fraud proof? |
| 01:20:38 | gmaxwell: | SPV security implies an assumption about the hashrate, a minority of the hashrate cannot persistantly censor. |
| 01:20:38 | kyletorpey: | kyletorpey has left #bitcoin-wizards |
| 01:21:18 | justanotheruser: | Oh, I thought you were talking about propogation censorship |
| 01:23:09 | justanotheruser: | 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:26 | justanotheruser: | 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:45 | bitjedi: | any coin devs want to take on a side alt-coin dev project (paid)? let me know. I have too many projects. |
| 01:25:55 | bitjedi: | it's not a pegged-sidechain alt |
| 01:26:02 | bitjedi: | because the economics for that are retarded |
| 01:26:12 | justanotheruser: | bitjedi: #bitcoin-otc |
| 01:26:17 | bitjedi: | ok |
| 01:26:43 | bitjedi: | * bitjedi slithers back into the shadows |
| 01:28:17 | amiller: | here's a thing that's bothering me about the usual presentation of sidechains, this is inspired from a conversation with zooko |
| 01:28:40 | amiller: | 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:12 | amiller: | even though there's no real difference, i think the former is perceived as more tolerable than the latter. |
| 01:29:39 | amiller: | however, in sidechains, it's basically recommended to flip that around. |
| 01:29:40 | gmaxwell: | I think both are non-starters and are uninteresting. |
| 01:30:37 | amiller: | 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:49 | maaku: | amiller: there is a difference, but it's OT here |
| 01:32:15 | amiller: | 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:16 | amiller: | fees |
| 01:32:25 | gmaxwell: | amiller: it comes from the same place Bitcoin miners fees come from long term; transaction fees. |
| 01:42:14 | BlueMatt: | * 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:43 | BlueMatt: | 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:25 | Taek: | 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:49 | Taek: | it's more of a luxury if fees alone are sufficient |
| 03:47:51 | justanotheruser: | Taek: the funny thing is miners can implement demmurage as a softfork whenever they want |
| 03:48:30 | justanotheruser: | Taek: also, at least two of the names on the sidechains paper would agree with you |
| 03:52:13 | Dizzle_: | Dizzle_ is now known as Dizzle |
| 04:20:32 | BlueMatt: | justanotheruser: huh? no they cant! |
| 04:20:57 | BlueMatt: | justanotheruser: only if the sidechain is set up to auto-demmurage on stolen coins |
| 04:21:52 | Luke-Jr: | BlueMatt: they could freeze all outputs that don't honour their demurrage rules |
| 04:22:34 | Luke-Jr: | so technically, miners could enforce demurrage on bitcoin today |
| 04:22:39 | BlueMatt: | Luke-Jr: that would be a soft-fork to require miner fees, essentially |
| 04:22:43 | BlueMatt: | not the same thing |
| 04:22:58 | Luke-Jr: | pretty much the same thing IMO *shrug* |
| 04:23:02 | BlueMatt: | to make it equivalent they'd need to keep 51% forever |
| 04:23:08 | BlueMatt: | so not at all the same thing |
| 04:23:16 | justanotheruser: | 00:22 < BlueMatt> to make it equivalent they'd need to keep 51% forever |
| 04:23:23 | justanotheruser: | that is what a softfork requires after all |
| 04:23:26 | Luke-Jr: | BlueMatt: that's true of any softfork |
| 04:23:47 | BlueMatt: | softfork requires more than miners, remember... |
| 04:23:57 | BlueMatt: | for a softfork to be a softfork people have to enforce it as well |
| 04:24:02 | BlueMatt: | otherwise its just a 51% attack |
| 04:24:13 | justanotheruser: | BlueMatt: if you define a 51% attack that way, yeah |
| 04:24:21 | Luke-Jr: | it's soft because it only requires miners |
| 04:24:25 | BlueMatt: | no, they are two very different concepts |
| 04:24:47 | Luke-Jr: | BlueMatt: only miners have ever been considered in proposals for softforks |
| 04:24:57 | BlueMatt: | HUH? |
| 04:24:58 | gwillen: | welllll, it doesn't practically speaking require the cooperation of nonminers |
| 04:25:09 | gwillen: | the outcome will be the same whether they cooperate or not |
| 04:25:11 | BlueMatt: | yes, and then its a 51% attack |
| 04:25:21 | gwillen: | so, maybe at some moral or theoretical level, fine |
| 04:25:27 | BlueMatt: | the difference is without the cooperation of non-miners, people who are pissed can go buy hashpower |
| 04:25:30 | gwillen: | but that doesn't really matter in practice |
| 04:25:35 | gwillen: | hmm |
| 04:25:37 | BlueMatt: | but in a softfork that doesnt help |
| 04:26:02 | gwillen: | yeah, that's true; if all the merchants switch to your softfork then the hashpower that doesn't switch doesn't matter |
| 04:26:15 | Luke-Jr: | a softfork isn't a softfork if it doesn't maintain 51% of miners |
| 04:26:17 | BlueMatt: | yes, then it actually is a softfork via economic majority :) |
| 04:26:24 | BlueMatt: | Luke-Jr: yes it is! |
| 04:26:32 | Luke-Jr: | no, the behaviour is essentially equivalent to a hardfork if it drops below 51% |
| 04:26:39 | BlueMatt: | if you do a softfork and then 99% of miners decide they dont want it anymore, the rules still apply |
| 04:26:46 | Luke-Jr: | BlueMatt: not to old nodes |
| 04:26:52 | BlueMatt: | you just lose 99% of mininer power to any new nodes |
| 04:26:58 | justanotheruser: | 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:59 | Luke-Jr: | softfork isn't a hardfork because old nodes follow it |
| 04:27:13 | BlueMatt: | 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:25 | BlueMatt: | justanotheruser: nope, actually... |
| 04:27:33 | Luke-Jr: | if old nodes follow the more-work non-softforked chain, then the softfork is essentially a hardfork |
| 04:27:49 | BlueMatt: | 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:01 | BlueMatt: | Luke-Jr: depends on your definition |
| 04:28:15 | justanotheruser: | BlueMatt: new clients can't fork at will. They require a miner majority to softfork |
| 04:28:18 | BlueMatt: | softfork definition is usually that its a stricly smaller set of valid transactions |
| 04:28:22 | BlueMatt: | justanotheruser: what??? |
| 04:28:35 | justanotheruser: | BlueMatt: I should ask the same of you. |
| 04:28:50 | BlueMatt: | justanotheruser: any set of users can fork at will based on some softfork rules |
| 04:29:04 | BlueMatt: | justanotheruser: if they're not the economic majority it doesnt matter much |
| 04:29:10 | Luke-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:12 | justanotheruser: | BlueMatt: new clients that fork without miner support are hardforking |
| 04:29:23 | BlueMatt: | 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:47 | BlueMatt: | 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:05 | Luke-Jr: | BlueMatt: to exclude that case, negates the meaningfulness of the distinction |
| 04:30:32 | Luke-Jr: | the only purpose to having two separate terms "softfork" vs "hardfork" is because of the distinctive difference |
| 04:30:34 | BlueMatt: | well it does still have one distinction: old clients can switch to the forked chain |
| 04:30:41 | Luke-Jr: | can, but won't. |
| 04:30:45 | Luke-Jr: | no practical difference |
| 04:30:46 | BlueMatt: | whether its smaller or not is important, but not all |
| 04:30:55 | BlueMatt: | well, maybe the new fork gets more mining power slower? |
| 04:31:09 | BlueMatt: | possible is actually important here in the longer run, depends on how long you dont have 51% mining power |
| 04:31:19 | Luke-Jr: | maybe |
| 04:32:24 | Luke-Jr: | * Luke-Jr debates trusting 0.9.x, or waiting out for 0.10.x |
| 04:33:13 | justanotheruser: | Luke-Jr: can you elaborate on why 0.10.x may be a hardfork? |
| 04:33:17 | BlueMatt: | ->#bitcoin-dev, but I would be hesitant to trust 0.10...maybe till 0.10.X |
| 04:33:21 | Luke-Jr: | justanotheruser: huh? why would it be? |
| 04:33:22 | BlueMatt: | too big a release |
| 04:33:31 | BlueMatt: | justanotheruser: I believe it was not related to the previous conversation |
| 04:33:39 | justanotheruser: | Luke-Jr: you were discussing that a bug may cause it to be with wumpus in -dev iirc |
| 04:33:59 | Luke-Jr: | BlueMatt: yeah, but is it worth upgrading to 0.9.x for just a few months? :p |
| 04:42:11 | justanotheruser: | Luke-Jr: http://hastebin.com/yedelezazo.xml |
| 04:51:55 | Luke-Jr: | justanotheruser: oh, that. just pure risk |
| 04:52:18 | Luke-Jr: | more code churn = more risk of hardforking accidentally |
| 08:05:16 | wolfe.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:16 | wolfe.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:16 | wolfe.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:16 | wolfe.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:16 | wolfe.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:40 | wumpus: | 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:43 | Luke-Jr: | wumpus: yep |
| 09:35:11 | penny: | penny is now known as Guest91682 |
| 11:52:26 | Rynomster: | Rynomster is now known as SDCDev |
| 12:58:57 | Aquent1: | Aquent1 is now known as Aquent |
| 16:00:29 | Taek: | I've been trying to find discussion of this somewhere |
| 16:01:09 | Taek: | 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:41 | Taek: | if you timestamp a block 10 hours in the future, 100% will reject the block and not mine on it |
| 16:02:09 | Taek: | and if you timestamp a block that is current time, 100% will accept the block |
| 16:02:43 | Taek: | 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:19 | Taek: | 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:29 | MRL-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:03 | sipa: | Taek: too high timestamp doesn't make the block invalid |
| 16:04:07 | sipa: | it's just ignored |
| 16:04:14 | sipa: | it can later be resubmitted and accepted |
| 16:04:15 | MRL-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:36 | sipa: | there's no consensus risk from a too-high timestamp, just reduced propagation |
| 16:05:06 | sipa: | MRL-Relay: network time is not computed from block timestamps |
| 16:05:07 | MRL-Relay: | I am a relay bot linking this channel to the Monero Research Lab |
| 16:05:13 | sipa: | i know |
| 16:05:19 | Taek: | 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:57 | sipa: | 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:57 | MRL-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:35 | sipa: | MRL-Relay: yes, sure, but that has nothing to do with the network time rule, or acceptance of blocks |
| 16:06:35 | MRL-Relay: | I am a relay bot linking this channel to the Monero Research Lab |
| 16:06:38 | sipa: | I KNOW |
| 16:06:48 | MRL-Relay: | [surae] lol i have no idea why it's doing that |
| 16:07:25 | tacotime: | Sorry, relay has been a bit buggy sometimes. fluffypony your relay is doing weird stuffs. |
| 16:07:31 | MRL-Relay: | [surae] no, but if you are talking about attempting to manipulate difficulty with a disproportionately small amount of hashing power... |
| 16:07:52 | MRL-Relay: | [surae] rather than trying to cause a fork or something funky |
| 16:07:57 | sipa: | that's not what we're talking about |
| 16:08:03 | Taek: | 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:03 | sipa: | you're talking about a validity rule for chains |
| 16:08:22 | sipa: | Taek: sure, you're just silly if you set your blocks' timestamps dangerously high |
| 16:08:37 | sipa: | it means your blocks have a lower chance of being built upon, that's all |
| 16:08:39 | MRL-Relay: | [fluffypony] tacotime: it self-defines if you mention it by name I think - I'll nuke that functionality later |
| 16:10:01 | Taek: | Is the attack not functionally similar to a block discarding attack? |
| 16:10:25 | MRL-Relay: | [surae] yeah now i'm confused (my typical state of being, I guess) |
| 16:10:28 | sipa: | yes, except performed by the sender |
| 16:10:39 | sipa: | it's making your own blocks be discarded... |
| 16:11:15 | Taek: | 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:26 | Taek: | because the 40% chain needs to make 2 blocks to catch up |
| 16:12:14 | MRL-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:09 | Taek: | consistently performing this attack increases the amount of stale mining, which will drive down the difficulty |
| 16:14:14 | MRL-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:35 | sipa: | there's a limit on how far in the future you can go |
| 16:14:39 | sipa: | max 2 hours |
| 16:14:46 | MRL-Relay: | [surae] ok, so push the envelope to +2 hours |
| 16:14:49 | sipa: | so whatever someone can game, it 's bounded |
| 16:15:38 | Taek: | if there are more stale blocks, the apparent number of blocks created in the same amount of time will be lower |
| 16:15:45 | sipa: | so you can get a 0.6% reduced difficulty from gaming, at the cost of making your blocks less likely to win |
| 16:15:57 | MRL-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:01 | sipa: | and if they don't win, it doesn't matter |
| 16:16:24 | MRL-Relay: | [surae] why 0.6%? |
| 16:16:37 | MRL-Relay: | [surae] just chose a tiny number or is that an estimate? |
| 16:16:53 | sipa: | 2 hours in 2 weeks |
| 16:16:57 | sipa: | is 0.6% |
| 16:16:59 | MRL-Relay: | [surae] ah |
| 16:17:49 | MRL-Relay: | [surae] that is one benefit of having a large difficulty adjustment period |
| 16:18:03 | sipa: | one of the many benefits :) |
| 16:18:09 | Taek: | you can have a greater impact than 0.6% if the network is consistently mining on 2 chains. |
| 16:18:26 | sipa: | how so? |
| 16:18:49 | sipa: | difficulty is computed per chain |
| 16:18:54 | Taek: | 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:58 | tromp: | 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:17 | sipa: | sure |
| 16:19:24 | sipa: | that's a collusion attack |
| 16:19:28 | tromp: | to drop replay of just that block |
| 16:19:35 | tromp: | relay |
| 16:19:47 | sipa: | 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:58 | MRL-Relay: | [surae] is the +2h cutoff based on the client time or the top block on the blockchain? |
| 16:22:12 | sipa: | network time |
| 16:22:15 | MRL-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:15 | Taek: | 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:17 | MRL-Relay: | [surae] oh network time. |
| 16:22:43 | sipa: | which you can game with a sybil attack, but not by mining |
| 16:23:27 | MRL-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:53 | MRL-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:17 | sipa: | Taek: i don't understand |
| 16:24:53 | sipa: | and when someone extends the +2h child block, everyone switches to it |
| 16:25:23 | Taek: | right but until the child block gets extended, only 60% of the network is mining on the chain |
| 16:25:24 | sipa: | so all you accomplish with your +2h time is that half of your blocks don't end up in the main chain |
| 16:25:27 | sipa: | waste of money |
| 16:25:39 | Taek: | much more than 50% of your blocks will make it |
| 16:25:53 | Taek: | because the 40% side needs to make 2 blocks to catch up |
| 16:26:09 | sipa: | right |
| 16:26:44 | Taek: | the result though is that because 40% of the hash power is wasted 10% of the time |
| 16:26:58 | Taek: | the apparent amount of hashing power in the winning chain is 4% lower |
| 16:27:08 | tromp: | Taek: you're also implying that tweaking the 2hour cutoff to, say, 2h+5mi, would be beneficial for miners |
| 16:27:16 | MRL-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:33 | MRL-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:45 | Taek: | right this attack is a longer term attack |
| 16:28:01 | MRL-Relay: | [surae] a difficulty-drift? |
| 16:28:16 | sipa: | MRL-Relay: network time is UTC; no DST here |
| 16:28:17 | MRL-Relay: | I am a relay bot linking this channel to the Monero Research Lab |
| 16:28:32 | MRL-Relay: | [surae] <--- surae, not the relay. |
| 16:28:49 | MRL-Relay: | [surae] then why even have a +2 hour cutoff? why not make it 45 minutes? or 30 minutes? |
| 16:28:53 | Taek: | surae can I highlight you through the relay? |
| 16:29:34 | MRL-Relay: | [surae] what do you mean? when you mention "surae" the chat line is highlighted |
| 16:29:35 | sipa: | i think 1 minute would be plenty |
| 16:29:52 | sipa: | can't you just use IRC directly...? |
| 16:30:58 | MRL-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:18 | MRL-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:24 | Taek: | 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:01 | tromp: | Taek: by tweaking i mean subversively deviating from the official cutoff |
| 16:33:30 | Taek: | ah |
| 16:33:34 | tromp: | in order to avoid being in the 40% parent-mining group of your example |
| 16:43:32 | tromp: | in any case it will be interesting to see the reaction to a major pool setting +2h timestamps |
| 17:07:42 | stonecoldpat: | 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:55 | Pan0ram1x: | Pan0ram1x is now known as Guest3670 |
| 17:48:49 | stonecoldpat: | 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:32 | stonecoldpat: | of course cant check that with time i seen them appear sadly |
| 17:50:56 | justanotheruser: | stonecoldpat: so there was a 118 minute gap between blocks you're saying? |
| 17:51:41 | sipa: | there has been a 1 week gap between blocks... |
| 17:52:12 | sipa: | you need to look at clocktime vs blocktime if you want to know how much the boundary matters |
| 17:56:45 | justanotheruser: | sipa: when was there a 1 week gap? 2009? |
| 17:56:54 | sipa: | between block 0 and 1 |
| 17:57:24 | justanotheruser: | lol |
| 18:02:45 | tacotime: | on the seventh day, satoshi rested. |
| 18:13:39 | ryan-c: | phantomcircuit: Is cloudhashing your pool? |
| 18:21:50 | gmaxwell: | surae: yea, so? it's a 0.5% difficulty hit, one time. |
| 18:21:59 | gmaxwell: | (a two hour advance) |
| 18:46:18 | Taek: | gmaxwell: with 1/3 hash power you can lower the difficulty 6.6% while increasing your profits: http://pastebin.com/aqMptxW4 |
| 18:59:59 | gmaxwell: | 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:33 | Taek: | 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:12 | Taek: | you have some hidden nodes around the network that pay attention to which nodes are forwarding the high-timestamp blocks you release |
| 19:13:36 | Taek: | you slowly raise the timestamp until ~1/5 of the mining power isn't forwarding your blocks |
| 19:14:09 | Taek: | 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:12 | Taek: | 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:01 | Taek: | 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:28 | gmaxwell: | Taek: your figuring doesn't account for only 1-2 minutes of rejection, however. |
| 19:32:37 | gmaxwell: | It assumes they reject forever, even an hour later. |
| 19:51:49 | skyraider7: | skyraider7 has left #bitcoin-wizards |
| 19:58:03 | dgenr8: | Taek: now + 2h + avg-block-propagation-time is where you'd start |
| 19:58:05 | dgenr8: | 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:05 | fluffypony: | MRL-Relay: |
| 20:13:10 | fluffypony: | ok good, all fixed |
| 20:13:13 | fluffypony: | MRL-Relay: now behave. |
| 20:14:12 | Taek: | MRL-Relay is relay bot linking this channel to the Monero Research Lab |
| 20:16:17 | fluffypony: | Taek: yes - I was just disabling that thing where it explained itself when someone mentioned it by name |
| 20:16:21 | fluffypony: | except now I appear to have broken the relay |
| 20:16:22 | fluffypony: | lol |
| 20:16:45 | Taek: | just poking fun lol |
| 20:17:51 | Taek: | gmaxwell: tried to adjust the figuring: http://pastebin.com/Zy0YknPR |
| 20:18:00 | MRL-Relay: | [fluffypony] testing 1 2 3 |
| 20:18:05 | fluffypony: | there we go, all fixed |
| 20:18:11 | fluffypony: | sorry about it misbehaving earlier, sipa |
| 20:18:17 | Taek: | appears that ~5 minutes of network skew is needed, assuming a linear distribution |
| 20:18:32 | Taek: | as skew reduces, the amount of wasted mining that high-timestamps can introduce goes down substantially |
| 20:19:37 | Dizzle__: | Dizzle__ is now known as Dizzle |
| 20:21:11 | Dizzle__: | Dizzle__ is now known as Dizzle |
| 20:22:34 | nsh: | Taek, do you have a write-up of the attack class you're discussing yet? |
| 20:22:54 | nsh: | or discussion on the mailing list, or what have you |
| 20:23:10 | gmaxwell: | please don't just take half baked things to the mailing list. |
| 20:24:12 | gmaxwell: | 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:31 | kanzure: | raft stuff http://raftconsensus.github.io/ (slightly off-topic) |
| 20:29:28 | Taek: | 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:39 | Taek: | plus the total effects of the attack are a pretty minor difficulty reduction + wasted mining for the miners with slow clocks. |
| 20:31:22 | Taek: | *wasted mining for the miners with fast clocks |
| 20:31:42 | Taek: | no wait slow nvm |
| 20:39:17 | Eliel: | 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:12 | Taek: | It would cause short term loss of income for everyone, but that'd fix as soon as the difficulty adjusted |
| 20:42:16 | Eliel: | I'd expect the orphan rate to stay high as long as the attack continues. That in itself would motivate fixing. |
| 20:43:13 | gmaxwell: | I'm simulating this any only seeing tiny amounts of orphaning. |
| 20:43:33 | gmaxwell: | the minority gets ahead a pretty large chunk of the time too. |
| 20:44:45 | nsh: | hmmm |
| 20:44:47 | Eliel: | how big is this tiny if calculated in terms of income lost to orphans? |
| 20:45:02 | Eliel: | in percentage |
| 21:22:36 | Dizzle___: | Dizzle___ is now known as Dizzle |
| 21:37:35 | dgenr8: | 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:47 | dgenr8: | though it would be more than that due to the split |
| 21:41:55 | amiller: | https://konradsgraf.squarespace.com/storage/Monetary%20analsyis%20of%20sidecoins%20KG%2024Oct2014.pdf Sidechained Bitcoin Substitutes: a Monetary Commentary |
| 21:44:40 | amiller: | (haven't seen this posted here or discussed directly but it's 5 days old i guess) |
| 22:39:47 | nsh_: | amiller, do they make any valid points? |
| 22:40:53 | go1111111: | 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:58 | gmaxwell: | nsh: the point of it is not invalid, but also I think not very interesting. |
| 22:41:14 | gmaxwell: | what go1111111 said. |
| 22:41:36 | Eliel: | go1111111: surprisingly, it reads the exact same way to me. |
| 22:42:00 | Eliel: | 7 pages to state what you could easily state in a couple of sentences :P |
| 22:42:40 | nsh_: | right, that was my confusion too |
| 22:43:17 | Eliel: | reading it felt like reading the same argument over and over again |
| 22:43:26 | Eliel: | each time worded a bit differently |
| 22:45:52 | Eliel: | 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:59 | BlueMatt: | Eliel: because it makes it seem more important and thought-out |
| 22:47:18 | BlueMatt: | and in bitcoin-land, it makes you look special and like an academic who should be treated with respect |
| 22:47:40 | gmaxwell: | I'm glad people are thinking about things, ... thats just the way some people think. |
| 22:49:56 | nsh: | it's all grist for the mill :) |
| 22:50:22 | nsh: | except when it's sand in your eyes |