--- Day changed Wed Jun 19 2019 00:02 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 244 seconds] 00:16 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 00:24 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 245 seconds] 00:37 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 00:43 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-pr-reviews 00:51 -!- ccdle12 [~ccdle12@182.52.241.31] has quit [Remote host closed the connection] 00:51 -!- ccdle12 [~ccdle12@182.52.241.31] has joined #bitcoin-core-pr-reviews 00:56 -!- ccdle12 [~ccdle12@182.52.241.31] has quit [Ping timeout: 268 seconds] 01:38 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews 02:37 -!- ironbutt [~LiberLive@144.49.211.130.bc.googleusercontent.com] has joined #bitcoin-core-pr-reviews 02:53 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:ceb:6ebe:b1a2:30ca] has joined #bitcoin-core-pr-reviews 03:06 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 258 seconds] 03:11 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:ceb:6ebe:b1a2:30ca] has quit [Quit: Sleep mode] 03:18 -!- ccdle12 [~ccdle12@182.52.241.31] has joined #bitcoin-core-pr-reviews 03:18 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:ceb:6ebe:b1a2:30ca] has joined #bitcoin-core-pr-reviews 03:24 -!- shesek [~shesek@37.26.149.195] has joined #bitcoin-core-pr-reviews 03:24 -!- shesek [~shesek@37.26.149.195] has quit [Changing host] 03:24 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 03:30 -!- ccdle12 [~ccdle12@182.52.241.31] has quit [Ping timeout: 268 seconds] 03:42 -!- ccdle12 [~ccdle12@182.52.241.31] has joined #bitcoin-core-pr-reviews 03:43 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 248 seconds] 03:46 -!- ccdle12 [~ccdle12@182.52.241.31] has quit [Ping timeout: 245 seconds] 04:00 < jnewbery> Next review club meeting is at 17:00 UTC (6 hours from now). Please make sure you've read the notes and questions before the meeing so we can get straight into it. Thanks! 04:06 -!- ccdle12 [~ccdle12@182.52.241.31] has joined #bitcoin-core-pr-reviews 04:11 -!- ccdle12 [~ccdle12@182.52.241.31] has quit [Ping timeout: 272 seconds] 04:36 -!- shesek [~shesek@2.55.22.101] has joined #bitcoin-core-pr-reviews 04:36 -!- shesek [~shesek@2.55.22.101] has quit [Changing host] 04:36 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 04:38 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:ceb:6ebe:b1a2:30ca] has quit [Quit: Sleep mode] 05:03 -!- ccdle12 [~ccdle12@182.52.241.31] has joined #bitcoin-core-pr-reviews 05:06 -!- ccdle12 [~ccdle12@182.52.241.31] has quit [Remote host closed the connection] 05:06 -!- ccdle12 [~ccdle12@182.52.241.31] has joined #bitcoin-core-pr-reviews 06:46 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 246 seconds] 06:54 -!- shesek [~shesek@2.55.22.101] has joined #bitcoin-core-pr-reviews 06:54 -!- shesek [~shesek@2.55.22.101] has quit [Changing host] 06:54 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 06:57 -!- ccdle12_ [~ccdle12@182.52.241.31] has joined #bitcoin-core-pr-reviews 06:57 -!- ccdle12 [~ccdle12@182.52.241.31] has quit [Read error: Connection reset by peer] 07:04 -!- ccdle12 [~ccdle12@182.52.241.31] has joined #bitcoin-core-pr-reviews 07:04 -!- ccdle12_ [~ccdle12@182.52.241.31] has quit [Read error: Connection reset by peer] 07:41 -!- michaelfolkson [~textual@82-132-230-234.dab.02.net] has joined #bitcoin-core-pr-reviews 07:42 -!- lightlike [~lightlike@2001:16b8:57b8:5600:f84c:1f75:1b7e:f425] has joined #bitcoin-core-pr-reviews 07:58 -!- michaelfolkson [~textual@82-132-230-234.dab.02.net] has quit [Quit: Sleep mode] 08:01 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-bzcrdxgjoctdrtyr] has joined #bitcoin-core-pr-reviews 08:03 -!- michaelfolkson [~textual@84.252.214.166] has joined #bitcoin-core-pr-reviews 08:05 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 08:14 -!- michaelfolkson [~textual@84.252.214.166] has quit [Quit: Sleep mode] 08:15 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 248 seconds] 08:20 -!- sdupre [~androirc@107.242.116.85] has joined #bitcoin-core-pr-reviews 08:35 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-pr-reviews 08:38 -!- ccdle12 [~ccdle12@182.52.241.31] has quit [Read error: Connection reset by peer] 08:38 -!- michaelfolkson [~textual@194.74.154.62] has joined #bitcoin-core-pr-reviews 08:40 -!- ccdle12 [~ccdle12@182.52.241.31] has joined #bitcoin-core-pr-reviews 08:43 -!- davterra [~tralfaz@178.128.106.205] has quit [Quit: Leaving] 08:55 -!- ccdle12 [~ccdle12@182.52.241.31] has quit [] 08:55 -!- ccdle12 [~ccdle12@182.52.241.31] has joined #bitcoin-core-pr-reviews 09:01 -!- pinheadmz [~matthewzi@208.69.41.101] has joined #bitcoin-core-pr-reviews 09:01 < michaelfolkson> I think the link re. "The proposal was discussed at the recent Bitcoin Core devtech meetup" is the wrong link 09:01 < michaelfolkson> Links to the mailing list post rather than meeting minutes from the Bitcoin Core devtech meetup 09:04 < lightlike> yes, http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-great-consensus-cleanup/ is probably the link. 09:05 < michaelfolkson> Great, thanks 09:18 -!- michaelfolkson [~textual@194.74.154.62] has quit [Quit: Sleep mode] 09:19 -!- jonatack [b84af09c@gateway/web/freenode/ip.184.74.240.156] has joined #bitcoin-core-pr-reviews 09:46 -!- fjahr [~FJ@185.153.177.13] has joined #bitcoin-core-pr-reviews 09:48 -!- rockstardev [49d0ad0b@gateway/web/freenode/ip.73.208.173.11] has joined #bitcoin-core-pr-reviews 09:48 -!- rockstardev [49d0ad0b@gateway/web/freenode/ip.73.208.173.11] has quit [Client Quit] 09:49 < jnewbery> Hi folks. We'll get started in about 10 minutes. If you haven't already read the notes and questions, now would be a good time! 09:51 -!- helloanything [c7a789f1@gateway/web/freenode/ip.199.167.137.241] has joined #bitcoin-core-pr-reviews 09:52 -!- helloanything is now known as rockstardev 09:52 < jnewbery> michaelfolkson: thanks for reporting. I've just pushed a fix 09:52 < jnewbery> PRs welcome at https://github.com/bitcoin-core-review-club/bitcoin-core-review-club.github.io :) 09:53 < rockstardev> I really need to figure out whitelisted/blacklisted IPs... 09:54 -!- pinheadmz [~matthewzi@208.69.41.101] has quit [Quit: pinheadmz] 09:54 < rockstardev> @jnewbery I would maybe add link to https://bitcoin-core-review-club.github.io in the header - makes it easier to navigate 09:55 -!- pinheadmz [~matthewzi@208.69.41.101] has joined #bitcoin-core-pr-reviews 09:56 -!- digi_james [~jamesc@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews 09:57 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 09:58 < jnewbery> you mean to the main index.html page? The 'Bitcoin Core PR Review Club' text is a link 10:00 < jnewbery> hi 10:00 < kanzure> hi 10:00 < pinheadmz> hi 10:00 < sosthene> hi 10:00 < ccdle12> hi 10:00 -!- fjahr [~FJ@185.153.177.13] has quit [Ping timeout: 245 seconds] 10:00 < jonatack> hi ! 10:00 < rockstardev> hi... @jnewbery I'll follow up with details after PR review 10:01 < amiti> hi 10:01 -!- fjahr [uid374480@gateway/web/irccloud.com/x-wbzyczhsyyayfsfl] has joined #bitcoin-core-pr-reviews 10:01 < ariard> hi 10:01 < jnewbery> Before we start, can you raise your hand o/ if you managed to clone/build the PR and read the notes/questions? 10:01 -!- fl [~fl@185.212.170.140] has joined #bitcoin-core-pr-reviews 10:02 < nehan> hi 10:02 < pinheadmz> read everything, did not test locally 10:02 < ccdle12> same as above 10:03 < jnewbery> ok, let's give everyone a couple of minutes to catch up. Notes are at https://bitcoin-core-review-club.github.io/15481.html 10:03 < ariard> read notes/BIP and skim over commits 10:03 < jnewbery> I'd encourage everyone to spend at least a few minutes preparing before the meeting by reading the notes. It'll really increase the benefit you get from the meeting if you come with questions prepared. 10:03 < ariard> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016316.html 10:03 < ariard> Getting around to fixing the timewarp attack 10:04 -!- PaulTroon [~paultroon@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews 10:04 < jonatack> * yup built, tested, read 10:04 < PaulTroon> I looked over Jon's shoulder :-) 10:04 < jnewbery> ok, so let's hit some of those questions 10:05 < jnewbery> pinheadmz: What could a miner do by abusing the timestamp field in a difficulty adjustment block prior to the Great Consensus Cleanup change? 10:05 -!- PaulTroon is now known as remyers 10:05 < pinheadmz> force a downward difficultly adjustment 10:06 -!- JulioBarros [~juliobarr@97-115-0-127.ptld.qwest.net] has joined #bitcoin-core-pr-reviews 10:06 < ariard> and so increase the block production rate? 10:06 < jnewbery> exactly right 10:06 < pinheadmz> making mining easier 10:06 < jnewbery> either push difficulty down or keep it low 10:06 < jnewbery> the idea is that the retarget algorithm only looks at 2015 out of 2016 blocks, so the retargeting periods don't overlap 10:07 < jnewbery> the timewarp exploits this by pushing the difficulty adjustment block way into the future, and then the next block back into the present 10:07 < jnewbery> that makes it appear to the retarget algorithm that it took a long time for the prior retarget period, so difficulty stays low or is adjusted down 10:08 < sosthene> Is it the same vulnerability that was exploited against Verge was attacked last year? 10:08 < pinheadmz> can we clarify which blocks by # ? Like, block 2015 (the ACTUAL last block for retarget algo) is the one thats post-dated 2 hours into the future? 10:09 < jnewbery> sosthene: I think similar. As far as I'm aware verge had some system that used multiple POW algorithms 10:09 < lightlike> jnewbery: "way in the future": is it possible, i read somewhere that you cannot go more than 2 hours into the future with the current rules? 10:09 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews 10:09 < pinheadmz> lightlike: correct, 2 hours 10:09 < jnewbery> lightlike: correct, so you couldn't use this attack at the tip, but you could redo a blockchain from genesis that does this because you have 10 years to play with 10:09 < rockstardev> @lightlike: https://bitcoin.stackexchange.com/a/20490/13744 10:10 -!- hugohn2 [b84af09c@gateway/web/freenode/ip.184.74.240.156] has joined #bitcoin-core-pr-reviews 10:10 < jnewbery> (in fact there are stome checkpoints, so you could only do it from block 295,000 if you wanted your blockchain to be accepted by Bitcoin Core) 10:10 < pinheadmz> and that 2 hours is measured against netwoek-adjusted wall-clock time? not MTP 10:10 < nehan> jnewbery: in matt's bip, it's called "timewarp inflation vulnerability". How does inflation come into it? 10:10 < jnewbery> pinheadmz: yes, your local time 10:10 < ariard> you could redo a blockchain but with less work, so you can't override current chain right? 10:11 < kanzure> inflation because subsidy goes out quicker than scheduled 10:11 < jnewbery> nehan: because if you can increase the rate of block production, you can increase the rate of new coin emission 10:11 < nehan> ok, so it refers to schedule and not # of coins 10:11 < jnewbery> nehan: exactly 10:11 < jnewbery> it doesn't affect the 21m cap 10:12 < pinheadmz> since retarget algo is based on median, how much effect can post-dating block #2015 by 2 hours really have? 10:12 < jnewbery> ariard: yes, you'd still need to do more work than the current blockchain if you wanted others to reorg to your chain 10:12 < nehan> i'd appreciate more explanation about the bug, like what pinheadmz asked for (which blocks) 10:12 < pinheadmz> or does the attack have to involve more than just the last block 10:13 < jnewbery> so if I wanted to create a blockchain with many blocks, I'd do the following: 10:13 < jnewbery> create block 1 with a timestamp 1 second after the genesis block 10:13 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-pr-reviews 10:13 < jnewbery> create block 2 with timestamp one second after that 10:13 < jnewbery> ... 10:14 < jnewbery> create block 2015 with timestamp genesis+2015 10:14 -!- satoshi [c7a789f1@gateway/web/freenode/ip.199.167.137.241] has joined #bitcoin-core-pr-reviews 10:14 < jnewbery> create block 2016 with timestamp 2 weeks in the future 10:14 -!- rockstardev [c7a789f1@gateway/web/freenode/ip.199.167.137.241] has quit [Ping timeout: 256 seconds] 10:14 < jnewbery> sorry, timestamp genesis+2 weeks 10:14 -!- hugohn2 [b84af09c@gateway/web/freenode/ip.184.74.240.156] has quit [Client Quit] 10:14 -!- satoshi is now known as rockstardev 10:14 < jnewbery> create block 2017 with timestmp genesis+2017 10:14 < jnewbery> ... 10:15 < nehan> jnewbery: is that within the 2 hour time bound? 10:15 < jnewbery> nehan: correction, not 2 weeks in the future from clock time, 2 weeks in the future from genesis 10:15 < nehan> it seems like two weeks + genesis - 2016s + geneses > 2 hours 10:15 < jnewbery> so the retarget algorithm compares the timestamp of block 2016 with block 1 and thinks "hmmm, it took 2 weeks to mine these blocks, keep difficulty at 1" 10:16 < jnewbery> but because 2017 is back to genesis+2017 seconds, the time hasn't advanced two weeks 10:16 < ariard> the hard limit of 2 hours is based on which clock ? Median-Time-Past of X blocks ? 10:16 < jnewbery> nehan: the 2 hours check is against clock time on the node 10:16 < nehan> hasn't it for block 2016 though? why would nodes accept 2016's with such a far off timestamp? 10:16 < jnewbery> the two hour rule is really weird 10:16 < nehan> or is it averaged over blocks? 10:17 < jnewbery> it's the only 'consensus' rule that isn't based on blockchain data but on local data 10:17 < ariard> okay if you're a malicious miner just tune your clock time like you want? 10:17 < jnewbery> it's almost better to not think of it as a consensus rule 10:17 < jnewbery> ariard: sure, but other people wouldn't accept your block 10:18 < jnewbery> because they're all comparing to their (presumably correct) clocks 10:18 < ccdle12> so what is the significance of updating previous block nTime to -600 seconds? (why -600 as an arbitrary number) 10:19 < ariard> the 600 seconds is to avoid messing with miner software using timestamp field for pow 10:19 < jnewbery> so in summary: it allows someone to create arbitrarily long blockchains without the difficulty increasing. The Median Time Passed of the blockchain creeps forward slowly, but one block out of every 2016 is sent forward in time to artificially keep the difficulty down 10:19 < pinheadmz> jnewbery: in your example, why not just create blocks 1-2016 at ten minute intervals? the diff will still stay unchanged? 10:20 < fl> ariard: using the node's local clock, it increases the attack surface from inaccurate time attestations in blocks to requiring the persistent manipulation of timeserver/nodes' local time 10:20 < jnewbery> ariard: exactly right. Some miners apparently use the timestamp field as extra nonce and roll it forward up to 10 minutes 10:20 < rockstardev> that's a good one... interesting to learn that miners do that with timestamp 10:20 < jnewbery> pinheadmz: because at blocks every 10 minutes the timestamp will advance to current time after ~580000 blocks 10:20 < fl> there's a bit of a dearth of nonce space IIRC 10:21 < jnewbery> the attack is to make a longer blockchain, but without increasing the difficulty 10:21 * pinheadmz thumbs up 10:21 < jnewbery> so more coinbase subsidy is realeased 10:21 < lightlike> jnewbery: why would other nodes accept the longer blockchain? I thought the one with the most cumulated work is accepted, not with the largest block count. 10:22 < fl> jnewbery wouldn't a timewarped fork chain require an eclipse attack to prevent nodes from learning about a non attacking chain? or is the desire just to make controlled supply more metered? 10:22 < jnewbery> lightlike: correct, so the full attack would be: I control 51% of the mining power, so I can create a chain with more work than anyone else. I do that, but also use timeward to make that most-work chain really long 10:23 < pinheadmz> does this attack have to start from genesis? 10:23 < fl> pinheadmz no 10:23 < lightlike> jnewbery: ok, thanks, I think I got it now :-) 10:23 < jnewbery> it means that a 51% attack can now increase the rate at which new coins are minted 10:23 < fl> timewarping can start at any block 10:23 < jnewbery> fl: yes, exactly correct 10:24 < fl> jnewbery to which comment? 10:24 < jnewbery> fl: correct that a timewarp can start at any block 10:24 < fl> ty 10:24 < hugohn> q: why is the 600sec limit in miner.cpp? don't miners run their own sw? 10:24 < jnewbery> I used genesis as an example because I thought it might simplify the concept, but you could start anywhere 10:25 < jnewbery> obviously if you start a more recent block, it'll be more work 10:25 < jnewbery> I created a 500,000 long mainnet blockchain by starting at genesis with an S7 a few years ago. At the time I believe it was the longest mainnet Bitcoin blockchain (but not most work, obviously) 10:26 < pinheadmz> jnewbery: thats awesome! ha 10:26 < nehan> jnewbery: i still don't understand why, in your example, other nodes would accept block 2016 (its timestamp is far in the future) but i am happy to take it offline 10:26 < ariard> fl: yes on increasing the attack surface to require the persistent manipulation of timeserver but I wonder if eclipse attacks can destroy this assumption and instead relying on public data wouldn't be better... 10:27 < fl> What would be the effect of sending a timewarped-spoofed chain to a node, would chainstate get erased? 10:27 < jnewbery> block 2016 is in the future from the prior block, but it's in the past when your node is validating 10:27 < wallet42> jnewbery: awesome! wen polo? 10:27 < nehan> jnewbery: aha, because you're starting at genesis, which was a long time ago. got it, thanks! 10:27 < jnewbery> yes, my use of the word future was probably confusing 10:28 < jnewbery> hugohn: I believe most miners use the Bitcoin Core software to get block templates, which they then do work on 10:28 < jnewbery> the `getblocktemplate` RPC will give a block template with the timestamp filled in 10:29 < jnewbery> Here's the code: https://github.com/bitcoin/bitcoin/blob/0221420d1a0550cd849e0f3a5ada3738d5931bdd/src/rpc/mining.cpp#L292 10:29 < jnewbery> You can see that it also returns `curtime` and `mintime` 10:29 < jnewbery> this PR means the value returned for those fields may change. Why? 10:30 < ariard> fl: headers-sync first would happen first and your spoffed chain not queried as new chainstate ? 10:31 < jnewbery> ariard fl: assuming your peer is on the most work tip, and your spoofed chain is below block 295,000, it wouldn't accept the headers because of the checkpoint 10:31 < fl> ah yeah 10:32 < fl> forgot 10:32 < jnewbery> you could create a timewarped chain after block 295,000 but even back at that height, it's quite a lot of work 10:32 -!- michaelfolkson [~textual@193.117.169.106] has joined #bitcoin-core-pr-reviews 10:33 < ariard> jnewbery: yes and after 295,000 headers are the counter-measures against resource consumption to track spoofed-chain? 10:33 < jnewbery> anyone want to take a shot at why `curtime` and `mintime` might be changed? 10:33 < fl> i.e. unless timewarped chain had more chainwork after 295e3 nodes wouldn't switch tips, correct? 10:33 < jnewbery> fl: right, we wouldn't reorg unless the new chain contained more work 10:34 < jonatack> to cap the mintime at not less than nTime - 600 ? 10:34 < fl> jnewbery but a timewarp spoof chain target node would have some some resource consumption based on header-sync assesment I think 10:34 < hugohn> so this is not a consensus change right? as the 600-limit is only in miner.cpp 10:35 < jnewbery> ok, so mintime might change because of the code change here: https://github.com/bitcoin/bitcoin/pull/15481/files#diff-9651347c8e00bed3ddc7631de569406dR656 10:35 < pinheadmz> Is there any way timewarp can benefit one single attacker? Seems like it lowers difficulty for EVERYONE, doesn't give one party a specific advantage 10:35 -!- jamal [b84af09c@gateway/web/freenode/ip.184.74.240.156] has joined #bitcoin-core-pr-reviews 10:35 < jnewbery> if the last block of the retarget period was more than 10 minute in the future, then `mintime` would be that timestamp-600 10:36 < fl> pinheadmz it would benefit miners with low block propogation latency 10:36 < jnewbery> hugohn: correct, not a consensus change. This is just miner behaviour change 10:36 < jnewbery> pinheadmz: potentially you could combine it with selfish mining if you're not sharing your chain 10:37 < jnewbery> but really, the dangerous attack is from a miner (or group of miners) that control 51% 10:37 < jnewbery> why might `curtime` change? 10:37 < ariard> fl: starting from checkpoints that's only 2,3 GB of headers with current height of 581487 10:38 < jonatack> to close the vuln without potentially breaking miner machines 10:38 < wallet42> 23 MB 10:38 < jnewbery> fl: I believe we won't download the full block if it's not the most work chain - just the header 10:38 < wallet42> (581487−295000)×80 10:38 < nehan> jnewbery: block->nTime is set on line 41 in UpdateTime(), and it might have been changed at line 37 10:39 < ariard> wallet42: oh sorry right 10:39 < jnewbery> so if you're trying to use this to DOS nodes, you need to do a ton of work just to waste 80 bytes 10:39 < fl> jnewbery I agree just header data would get computed on, thought I would mention that there is some marginal increase in resource consumption 10:39 < jnewbery> if you want to use timewarp to ratchet down the difficulty, you still need to get to the next difficulty retarget block after 295000, and then you can only lower it by 75% 10:40 < jnewbery> fl: yes, but it's asymetric. The attacker needs to do a *lot* of work for a minimal amount of bandwidth/CPU/memory wastage on the civtim 10:40 < jnewbery> *victim 10:40 < fl> issuance rate and preserving DMMS are the more important network properties anti-timewarping attack measures benefit 10:41 < fl> IMO 10:41 < wallet42> hm but once you lowered it enough, you can generate 80 bytes very easily no? 10:41 < jnewbery> nehan: yes exactly right. The update time change here: https://github.com/bitcoin/bitcoin/pull/15481/files#diff-4a59b408ad3778278c3aeffa7da33c3cR36 is used when constructing the block template 10:41 < jnewbery> and `curtime` is taken from that block: https://github.com/bitcoin/bitcoin/blob/0221420d1a0550cd849e0f3a5ada3738d5931bdd/src/rpc/mining.cpp#L667 10:42 < jnewbery> ok, last question: Which function would need to be changed to enforce this timestamp restriction as a consensus rule? 10:42 < fl> jnewbery the resource consumption on a spoof timewarp chain is negligible but in your case where 51% miner stretches out the chain, they could start stuffing more and more data into blocks increasing node operation costs more 10:42 < nehan> jnewbery: but *why* was that change made? 10:43 < jnewbery> nehan: because the aim of this PR is to make miners not mine a difficulty retarget block more than 600 seconds before the prior block. When the miner callers GBT we want the block template returned to them to have a timestamp that is constrained by that rule 10:43 < fl> well not more data into blocks but more data per time 10:44 < jnewbery> and `curtime` is just taken from the block 10:44 < jnewbery> the help text would be technically wrong after this PR: https://github.com/bitcoin/bitcoin/blob/0221420d1a0550cd849e0f3a5ada3738d5931bdd/src/rpc/mining.cpp#L361 10:45 < jnewbery> by the way, GBT is defined in a BIP here: https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki 10:45 < jnewbery> Anyone brave enough to try to answer "Which function would need to be changed to enforce this timestamp restriction as a consensus rule?" :) 10:45 -!- michaelfolkson [~textual@193.117.169.106] has quit [Quit: Sleep mode] 10:46 < jnewbery> hint: it's a consensus rule, so it's probably in validation.cpp 10:46 < lightlike> jnewbery: Change CheckBlock() in validation to not accepts new block that break it? 10:47 < jnewbery> lightlike: almost! 10:47 < jnewbery> the change would actually be in ContextualCheckBlockHeader() 10:47 < jnewbery> Header, because this is a field in the block header 10:48 < jnewbery> Contextual, because it's a context-dependant check (ie it depends on where the block is in the blockchain) 10:48 < jnewbery> Matt has a reference implementation for the Consensus Cleanup softfork: https://github.com/bitcoin/bitcoin/pull/15482 10:49 < jnewbery> the relevant change is here: https://github.com/bitcoin/bitcoin/pull/15482/files#diff-24efdb00bfbe56b140fb006b562cc70bR3251 10:49 < hugohn> q: what happens if there is a large hashrate drop between the second-to-last block and the last block in a period (so the gap between those 2 blocks is truly more than 2 minutes)? Won't this change make it so that we won't account for this hash rate drop in retargeting? then that means the next period's difficulty will be a lot longer than it has to be? 10:49 < hugohn> *more than 10 minutes 10:49 < jnewbery> so the code changes this week were very minor, but I hope you agree that there's a lot of interesting discussion behind them 10:50 < hugohn> *harder than it has to be 10:50 < jnewbery> hugohn: the change imposes a new minimum on the block timestamp, not a new maximum 10:51 < jnewbery> if the hashrate is dropping, then we'd expect the timestamps to become more spread out 10:51 < jnewbery> last 10 minutes. Any questions? 10:51 < pinheadmz> actually we have 2 hours still :-) 10:52 < fl> I dunno my local clock says... 10:53 < jnewbery> ok, thanks everyone! 10:53 -!- ccdle12 [~ccdle12@182.52.241.31] has quit [Read error: Connection reset by peer] 10:53 < wallet42> thanks @jnewbery! 10:53 < lightlike> thanks! 10:53 < jonatack> V interesting discussion. No Concept ACK from you on the PR? 10:53 < pinheadmz> thanks 10:53 < fl> jnewbery thanks great pr review 10:53 < ariard> thanks jnewbery, was really interesting! 10:53 < rockstardev> pinheadmz: good one 10:53 -!- ccdle12 [~ccdle12@182.52.241.31] has joined #bitcoin-core-pr-reviews 10:54 -!- JulioBarros [~juliobarr@97-115-0-127.ptld.qwest.net] has quit [] 10:54 < jnewbery> I'm out of office and won't make the next couple of review clubs. I'm going to try to find someone else to host, so keep an eye out on the website for details. 10:55 -!- remyers [~paultroon@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [] 10:56 < jnewbery> jonatack: I believe Matt has some updates to make to his consensus cleanup proposal. I'm going to hold off on concept reviewing until after that 10:57 -!- ccdle12 [~ccdle12@182.52.241.31] has quit [Remote host closed the connection] 10:57 < jonatack> jnewbery: thanks 10:57 < rockstardev> jnewbery: sad to hear that... you are leaving exactly when I'm joining the club to learn more 10:57 -!- jamal [b84af09c@gateway/web/freenode/ip.184.74.240.156] has quit [Quit: Page closed] 10:57 < digi_james> exit 10:58 -!- digi_james [~jamesc@rrcs-184-74-240-156.nyc.biz.rr.com] has left #bitcoin-core-pr-reviews ["WeeChat 2.0.1"] 11:00 -!- fl [~fl@185.212.170.140] has quit [Quit: fl] 11:00 < rockstardev> but I guess there is enough work on BTCPayServer to keep me going 11:05 -!- michaelfolkson [~textual@193.117.169.106] has joined #bitcoin-core-pr-reviews 11:29 -!- rockstardev [c7a789f1@gateway/web/freenode/ip.199.167.137.241] has quit [Quit: Page closed] 11:31 -!- michaelfolkson [~textual@193.117.169.106] has quit [Quit: Sleep mode] 11:35 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection] 12:51 -!- sdupre [~androirc@107.242.116.85] has quit [Read error: Connection reset by peer] 12:51 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Read error: Connection reset by peer] 12:53 -!- jonatack [b84af09c@gateway/web/freenode/ip.184.74.240.156] has quit [Ping timeout: 256 seconds] 12:58 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews 13:18 -!- amiti [uid373138@gateway/web/irccloud.com/x-hikcesiorfplmuag] has quit [Quit: Connection closed for inactivity] 13:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds] 13:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 13:46 -!- lightlike [~lightlike@2001:16b8:57b8:5600:f84c:1f75:1b7e:f425] has quit [Quit: Leaving] 14:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 14:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 14:42 -!- pinheadmz [~matthewzi@208.69.41.101] has quit [Quit: pinheadmz] 14:44 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 14:49 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews 14:52 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Client Quit] 14:52 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews 14:53 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Client Quit] 14:54 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews 14:55 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Client Quit] 14:56 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews 14:58 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Client Quit] 15:01 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer] 15:02 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-pr-reviews 15:10 -!- seven__ [~seven@2a00:ee2:410c:1300:1564:7748:3d7c:ce7e] has quit [Ping timeout: 258 seconds] 15:13 < jnewbery> There's a good write-up of the timewarp attack here: https://bitcoin.stackexchange.com/questions/75831/what-is-time-warp-attack-and-how-does-it-work-in-general 15:17 -!- seven [~seven@BSN-77-101-62.static.siol.net] has joined #bitcoin-core-pr-reviews 15:24 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews 15:34 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 15:41 -!- shesek [~shesek@5.22.134.185] has joined #bitcoin-core-pr-reviews 15:41 -!- shesek [~shesek@5.22.134.185] has quit [Changing host] 15:41 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 16:16 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 16:27 -!- la99 [~e99@172-239-114-200.fibertel.com.ar] has joined #bitcoin-core-pr-reviews 17:00 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-bzcrdxgjoctdrtyr] has quit [Quit: Connection closed for inactivity] 17:32 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 264 seconds] 18:01 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 246 seconds] 18:18 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 18:37 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews 18:38 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has quit [Client Quit] 18:39 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews 18:51 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 18:55 -!- booyah [~bb@193.25.1.157] has quit [Ping timeout: 258 seconds] 18:56 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-pr-reviews 19:13 -!- ccdle12 [~ccdle12@182.52.241.164] has joined #bitcoin-core-pr-reviews 19:28 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 19:47 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews 20:44 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 20:45 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-pr-reviews 21:42 -!- jnewbery [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Ping timeout: 248 seconds] 21:43 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 256 seconds] 22:00 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 22:01 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has quit [Client Quit] 22:02 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 22:15 -!- ccdle12 [~ccdle12@182.52.241.164] has quit [Remote host closed the connection] 22:21 -!- ccdle12 [~ccdle12@182.52.241.164] has joined #bitcoin-core-pr-reviews 22:24 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 22:26 -!- ccdle12 [~ccdle12@182.52.241.164] has quit [Ping timeout: 248 seconds] 22:29 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews 22:38 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 22:48 -!- jnewbery [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews 22:55 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews 23:41 -!- ccdle12 [~ccdle12@182.52.241.164] has joined #bitcoin-core-pr-reviews 23:45 -!- ccdle12 [~ccdle12@182.52.241.164] has quit [Ping timeout: 244 seconds]