--- Log opened Wed Jan 03 00:00:18 2024
00:01 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
00:02 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
00:07 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Ping timeout: 245 seconds]
00:14 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
00:19 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
00:31 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
00:36 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
00:55 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
00:59 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
01:01 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Ping timeout: 260 seconds]
01:03 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
01:04 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 260 seconds]
01:08 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Ping timeout: 246 seconds]
01:09 -!- puchka [~puchka@185.203.122.11] has quit [Ping timeout: 276 seconds]
01:10 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
01:11 -!- puchka [~puchka@185.203.122.10] has joined #bitcoin-core-pr-reviews
01:15 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 245 seconds]
01:20 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
01:22 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
01:27 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
01:32 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
01:39 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
01:45 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Ping timeout: 256 seconds]
01:52 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
02:15 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
02:20 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
02:20 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
02:21 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Ping timeout: 260 seconds]
02:25 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 245 seconds]
02:28 -!- jon_atack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
02:29 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
02:31 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
02:31 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
02:34 -!- jon_atack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
02:34 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
02:37 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
02:41 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
02:57 -!- kevkevin [~kevkevin@98.226.43.69] has joined #bitcoin-core-pr-reviews
02:59 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
03:02 -!- kevkevin [~kevkevin@98.226.43.69] has quit [Ping timeout: 245 seconds]
03:04 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 246 seconds]
03:17 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
03:21 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Ping timeout: 260 seconds]
03:21 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
03:27 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
03:27 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
03:32 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
03:33 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
03:35 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
03:37 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
03:40 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Ping timeout: 268 seconds]
03:49 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
03:52 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
03:54 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 260 seconds]
04:04 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Ping timeout: 260 seconds]
04:07 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
04:37 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
04:43 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Ping timeout: 245 seconds]
04:56 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
05:00 -!- abubakarsadiq_ [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
05:01 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Ping timeout: 268 seconds]
05:13 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
05:20 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Ping timeout: 260 seconds]
05:35 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
05:39 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Ping timeout: 245 seconds]
05:55 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
05:57 -!- puchka [~puchka@185.203.122.10] has quit [Ping timeout: 240 seconds]
06:02 -!- puchka [~puchka@185.203.122.10] has joined #bitcoin-core-pr-reviews
06:03 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Ping timeout: 256 seconds]
06:05 -!- mutex [~mutex@static-198-54-134-180.cust.tzulo.com] has quit [Ping timeout: 268 seconds]
06:11 -!- mutex [~mutex@static-198-54-134-180.cust.tzulo.com] has joined #bitcoin-core-pr-reviews
06:18 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
06:23 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Ping timeout: 260 seconds]
06:36 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
06:42 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Ping timeout: 276 seconds]
06:55 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
07:30 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Remote host closed the connection]
07:31 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
07:43 -!- abubakarsadiq_ [uid602234@id-602234.hampstead.irccloud.com] has left #bitcoin-core-pr-reviews []
07:43 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
07:56 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 264 seconds]
08:30 -!- vmammal [~vmammal@107.181.222.132] has joined #bitcoin-core-pr-reviews
08:54 -!- hernanmarino [~hernanmar@181.98.56.2] has joined #bitcoin-core-pr-reviews
08:56 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
08:57 -!- guest-127 [~guest-127@212.129.76.43] has joined #bitcoin-core-pr-reviews
08:59 -!- Ayelen [~ayelen@181.29.127.131] has joined #bitcoin-core-pr-reviews
09:00 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
09:00 < stickies-v> #startmeeting
09:00 < dergoegge> hi
09:00 -!- alfonsoromanz [~alfonsoro@181.29.127.131] has joined #bitcoin-core-pr-reviews
09:00 < stickies-v> hi everyone, welcome to the first review club of 2024!
09:00 < effexzi> Hey every1
09:00 < vmammal> hi
09:00 < monlovesmango> hey
09:00 -!- pablomartin [~pablomart@181.30.100.202] has joined #bitcoin-core-pr-reviews
09:00 < hernanmarino> hi everyone 
09:00 < alfonsoromanz> hey everyone
09:00 < Ayelen> Hi
09:01 < michaelfolkson> hi
09:01 < kevkevin> hi
09:01 < stickies-v> Today we're looking at #28956, authored by dergoegge. The notes and questions are available on https://bitcoincore.reviews/28956
09:01 < pablomartin> hello
09:01 < glozow> hi
09:01 < lightlike> Hi
09:01 < stickies-v> anyone joining us for the first time today? even if you're just lurking, feel free to say hi!
09:01 -!- henmeh [~henning@2a02:8070:4686:d820:1d62:c45:c291:76e2] has joined #bitcoin-core-pr-reviews
09:02 < alfonsoromanz> this is my first time today :) 
09:02 < Ayelen> first time today
09:02 < stickies-v> nice, welcome alfonsoromanz !
09:02 < stickies-v> and Ayelen. Feel free to just lurk or chime in whenever you want to
09:03 < Ayelen> thanks!
09:03 < alfonsoromanz> sounds good
09:03 < stickies-v> who got the chance to review the PR or read the notes? (y/n)
09:03 < hernanmarino> y
09:03 < alfonsoromanz> y
09:03 < dergoegge> y
09:03 < TheCharlatan> y
09:04 < Ayelen> y
09:04 < henmeh> y
09:04 < TheCharlatan> hi
09:04 < stickies-v> for those of you who were able to review, would you give it a Concept ACK, Approach ACK, Tested ACK, or NACK? what was your review approach?
09:04 < TheCharlatan> Concept ACK
09:04 < hernanmarino> Concept ACK
09:05 < pablomartin> havent reviewed it yet, but read notes
09:05 < stickies-v> nice!
09:06 < stickies-v> so today, we'll be focusing on the conceptual questions, and tomorrow we'll dive more into the code
09:06 < stickies-v> given that consensus is touched, the conceptual understanding is pretty critical for this PR, probably more so than the actual code
09:07 < stickies-v> let's get started with the questions:
09:07 -!- Justin [~Justin@host-87-8-3-150.retail.telecomitalia.it] has joined #bitcoin-core-pr-reviews
09:07 < stickies-v> 2. Is it necessary for block headers to have a timestamp? If so, why?
09:07 < michaelfolkson> Not convinced on the Concept ACK personally but hope to be convinced :)
09:07 < alfonsoromanz> Yes so your node can make sure it’s in sync with the network 
09:07 < monlovesmango> yes, for difficulty adjustment
09:07 -!- Justin is now known as Guest7427
09:07 < stickies-v> alfonsoromanz: what do you mean with "in sync"?
09:08 < stickies-v> or rather, why is it important?
09:08 < alfonsoromanz> that is on the right chain 
09:08 -!- Guest60 [~Guest60@140.228.88.147] has joined #bitcoin-core-pr-reviews
09:08 < Guest60> hi
09:08 < stickies-v> the right chain is identified by the most cumulated proof of work, we don't really use timestamps for that
09:09 < stickies-v> monlovesmango: yes! that's one of the use cases. but there are more!
09:09 < pablomartin> seq order, difficulty adjustment, consensus mechanism, preventing timestime manipulation, human-readable information
09:09 -!- sr_gi [~sr_gi@4.53.92.114] has joined #bitcoin-core-pr-reviews
09:09 -!- Guest60 [~Guest60@140.228.88.147] has quit [Client Quit]
09:10 < sr_gi> Hi! Sorry I'm late
09:10 < stickies-v> pablomartin: wdym with seq order and preventing timestime manipulation?
09:10 < monlovesmango> block validation too right?
09:10 < vmammal> hi sr_gi
09:10 < monlovesmango> which is what this pr touches
09:10 < stickies-v> no worries sr_gi, we're async anyway so feel free to continue discussing questions anytime - even if we've moved on to something else
09:11 < stickies-v> monlovesmango: well yes this PR affects how a block header's timestamps affects its validity, but if it didn't have the timestamp to begin with we wouldn't have to validate it :D
09:12 < pablomartin> seq order: blocks should be in chronologial order... preventing timestamp manipulation: helps prevent miners from manipulating the block creation process, miners must set the timestamp within certain limits
09:12 < stickies-v> blocks already point to the previous block header so that shouldn't really affect block order i think
09:12 < pablomartin> true
09:13 < vmammal> also the timestamp is needed to evaluate timelocked transactions, no?
09:13 < stickies-v> and re timestamp manipulation: that also doesn't really explain why we need the timestamp, just how it can be manipulated
09:13 < sr_gi> Isn't it necessary to compute the diff adjustment?
09:13 < stickies-v> vmammal: yes exactly! we need consensus on a specific time in order to validate timelocks
09:14 < stickies-v> sr_gi: indeed it is
09:14 < hernanmarino> sr_gi +1
09:14 -!- Guest7427 [~Justin@host-87-8-3-150.retail.telecomitalia.it] has quit [Remote host closed the connection]
09:14 < stickies-v> difficulty adjustment and timelocks are the two reasons I could think of, but maybe there are more?
09:14 < stickies-v> 3. What is the difference between Median Time Past (MTP) and network-adjusted time? Which of these are relevant to the PR?
09:14 < sr_gi> Our only sense of how long blocks take to get mined is based on the block timestamp, so in order to re-adjust we need to know how long it took (sorry if it was pointed out, I'm missing the chat log :'))
09:15 < stickies-v> nw, monlovesmango already mentioned the difficulty adjustment but thanks for that extra context 👍
09:16 < monlovesmango> mtp is calculated with past block timestamps whereas network-adjusted time is calculated based on first 199 outgoing peers' median time
09:16 < alfonsoromanz> MTP is the median time of last 11 blocks and network adjusted time is a time that is calculated by adding the median of the offsets between current node time and a sample of 200 peers, to try to get nodes closer to each other in terms of clock synchronization. For this PR only network adjusted time is relevant.
09:16 < monlovesmango> network adjusted is relevant here
09:17 < stickies-v> correct, monlovesmango and alfonsoromanz (although its based on 199 peers instead of 200, but we'll get to that in a bit)
09:17 < stickies-v> now, conceptually, there's another big distinction between them both
09:17 < monlovesmango> hehe yeah didn't quite follow that :)
09:18 < stickies-v> MTP is uniquely defined for all network participants that are on the same chain (i.e. there's consensus on time), whereas they can (and generally do) have a different network-adjusted time
09:18 < stickies-v> so, why don't we just use MTP for everything and scrap network-adjusted time?
09:19 < sr_gi> MTP is used as the lower bound for the timestamps of the subsequent block, whereas the network-adjusted time is our view of time corrected by the view of our peers (at least before this PR)
09:20 < monlovesmango> bc MTP cant be calculated for future time threshold
09:20 < stickies-v> monlovesmango: exactly! 
09:20 < lightlike> a rule like "prevent a block >2 hours in the future" would not be possible with MTP
09:21 < stickies-v> 4. Why are limits enforced on how far "off" a block header's timestamp is allowed to be from a node's internal clock? And since we don't require exact agreement on time, can these limits be made more strict?
09:22 < sr_gi> The restrictions are in place to prevent tampering with the difficulty adjustments. If timestamps are to far off the future, when computing the next difficulty it would look like blocks took longer to be mined, wrongly correcting the difficulty down, the same applies, in the opposite way, if timestamps are too far into the past. These limits could
09:22 < sr_gi> be made more strict, given we are giving some room for discrepancies (maxtimeadjustment) but it we made them too strict valid blocks could be rejected, creating a consensus issue.
09:22 < monlovesmango> if timestamp is too far off it could be used to manipulate difficulty adjustment or time locks?
09:24 < stickies-v> sr_gi: monlovesmango both correct! this class of attacks is called timewarping attacks, if anyone wants to research more
09:24 < hernanmarino> exactly, to prevent miners to manipulate difficulty adjustments 
09:25 < stickies-v> we don't need the time to be exactly correct, it's mostly important that it keeps moving in the right direction and that it keeps moving at the same pace as the wall clock on average
09:25 < stickies-v> 5. Prior to this PR, why would an attacker try to manipulate a node's network-adjusted time?
09:26 < michaelfolkson> If it is a node run by a miner to get its mined blocks rejected?
09:26 < monlovesmango> the only thing I could think of was to convince a node that a valid block is invalid and then broadcast a fake block to the node (that would be valid to the node)
09:27 < stickies-v> michaelfolkson: yep that's one reason!
09:27 < lightlike> or a mining node might not accept a valid new block and keep wasting hash power an old tip.
09:28 < monlovesmango> oh interesting lightlike
09:28 < sr_gi> Even to make a timely transaction with a time-lock to be rejected from a block in where it could potentially have been included
09:28 < michaelfolkson> And then there's the time dilation attacks on Lightning Antoine was discussing in a comment https://github.com/bitcoin/bitcoin/pull/25908#pullrequestreview-1127411015
09:29 < stickies-v> monlovesmango: yes! broadcasting a fake block would require a lot of hashpower of course, but forking nodes off the valid chain is possible like that
09:29 < stickies-v> lightlike: hadn't thought of that, you're right!
09:32 < stickies-v> sr_gi ooh and for timelocks with short windows that could actually be pulled off quite stealthily perhaps
09:32 < stickies-v> 6. Prior to this PR, how could an attacker try to manipulate a node's network-adjusted time? Which network message(s) would they use? *Hint: network messages are processed in `net_processing.cpp`*
09:32 < lightlike> if I rejected a block because it's too much in the future (>2h), and then some time passes and it's now valid, will my node accept it  a bit later?  Or will it be remembered as being invalid indefinitely?
09:33 < michaelfolkson> I find it very difficult to assess the Concept ACK on this. As I think you say in a comment stickies-v it is making some esoteric attacks harder to pull off whilst potentially making some other esoteric attacks easier to pull off
09:33 < stickies-v> lightlike: i think invalid blocks are never re-validated?
09:34 < michaelfolkson> So you have to essentially assess whether you're more worried about an attacker controlling your local time or an attacker controlling all your peers
09:34 < hernanmarino> lightlike: i think the problem is with eventual forks in the chain in that situation 
09:35 < stickies-v> michaelfolkson: yes, that is the main question to be answered for this PR imo
09:35 < monlovesmango> michaelfolkson: i agree. in my gut it feels much easier to attack an individual with malware (to change system time) and little recourse for correction than to orchestrate being one of the first outgoing peers
09:36 < dergoegge> adjusted time does not fully protect against NTP based attacks
09:36 < lightlike> stickies-v: then how do I recover if my time is really wrong (>2h) for some reason, and I rejected a valid block, and now I fixed my time and wanna get back to the right chain?
09:37 < monlovesmango> lightlike: i would imagine just like you sync a node, request the new blocks from peers
09:37 -!- jess [meow@libera/staff/cat/jess] has quit [Quit: Lost terminal]
09:38 < dergoegge> it's just extra complexity that doesn't really achieve anything imo
09:38 < michaelfolkson> And then there's also the weighing up of dangers of forking yourself off the network versus contagion with forking peers off the network? (for admittedly esoteric attacks)
09:38 -!- jess [meow@libera/staff/cat/jess] has joined #bitcoin-core-pr-reviews
09:38 < monlovesmango> dergoegge: correct, adjusted time doesn't protect against NTP based attacks. just think this attack is much harder to pull off than a targeted malware attack. but really don't know.
09:38 < hernanmarino> Also NTP is not so difficult to attack, assuming you are using NTP
09:39 < stickies-v> lightlike: that is a good point, and i see now that we have a `BlockValidationResult::BLOCK_TIME_FUTURE` so probably those blocks can be re-evaluated?
09:39 < stickies-v> i can't immediately find it in the code tho
09:40 < monlovesmango> but then I also think malware attack is already possible so are we really increasing the attack vector? myabe not
09:40 < michaelfolkson> It is hard. I don't feel I understand the trade-offs well enough to assess the Concept ACK. I get the fact it is cleaner from a consensus code perspective post this PR but also not sure how much of a "big win" that really is
09:41 < dergoegge> deleting 100s of lines of code that don't achieve what they claim seems like a good win to me
09:42 < stickies-v> if a user knows how to safely manage their system clock, they are now vulnerable to one less attack
09:42 < monlovesmango> but how many users really know how to do this?
09:42 < monlovesmango> realistically i say less than 1%
09:43 < monlovesmango> if we want non technical folks to run a node, this probably would be a hindrance, but only in cases where system time is off which is very rare)
09:44 < michaelfolkson> dergoegge: With no trade-offs to consider and it not being consensus agreed that would be a good win. I just don't know personally
09:44 < lightlike> re: question 6: An attacker would need to send us multiple version messages with manipulated timestamps. They would need us to make >50% of outbound connections to nodes controlled to them, which is hopefullly hard (but much easier than completely eclipsing the node).
09:45 < stickies-v> lightlike yes, beautiful answer!
09:45 < stickies-v> and the last bit is really important - does anyone know why that is much easier than eclipsing a node?
09:47 < vmammal> if we have one honest peer, we're ok
09:47 < vmammal> in theory
09:47 < lightlike> also, an attacker would need to do this in the first couple hours after the victim's node has started, because after 199 sample cutoff.
09:48 < stickies-v> yeah indeed vmammal, we always assume that we just need one honest peer to be fine - this doesn't hold for network-adjusted time
09:50 < monlovesmango> so eclipsing attack is harder simply bc it only needs one honest peer to fail?
09:50 < hernanmarino> in network-adjusted-time , one honest node is not enough because all nodes contribute to your computation of time
09:51 < vmammal> hernanmarino ah, ok
09:51 < stickies-v> hernanmarino: not really all of them, but because we're looking at the median you just need >50% malicious peers
09:51 < hernanmarino> an even one dishonest node can alter your computation 
09:51 < hernanmarino> yes
09:51 < stickies-v> so, no, one dishonest node cannot alter your computation
09:52 < hernanmarino> but 51% is easier than 100% :)
09:52 < hernanmarino> stickies-v: ok, agree
09:52 < stickies-v> 8. Does this PR change consensus behaviour? If so, is this a soft fork, a hard fork, or neither? Why?
09:53 < sr_gi> I think one relevant detail is that we only take one sample per peer, given that happens during the handshake (i.e. exchange of version messages), hence why a single peer cannot affect your computation
09:54 < monlovesmango> yes I think it does change consensus..? soft fork?
09:54 < michaelfolkson> It is one of those where technically it is a hard fork right? But in reality we're dealing with highly unlikely esoteric attacks and code cleanup
09:55 < michaelfolkson> Relaxing a check?
09:55 < sr_gi> I think it does not change consensus behavior but it can lead to consensus discrepancies, e.g a chain split due to what blocks are valid wrt time
09:56 < monlovesmango> sr_gi: I think the nature of a median calculation means having <50% malicious peers should not affect your calculation
09:56 < michaelfolkson> You expect it to not change consensus behavior and you're extremely confident it won't. But theoretically it could
09:56 < TheCharlatan> +1 sr_gi
09:56 < hernanmarino> michaelfolkson: totally agree with you 
09:57 < dergoegge> michaelfolkson: how could it?
09:57 < sr_gi> monlovesmango you're right, but it only applies back to the amount of distinct peers because we sample on handshake. If you happen to do so on any other message that can be sent without disconnecting a single peer may affect multiple samples
09:58 < michaelfolkson> dergoegge: Theoretically it is possible that you reject a block after this PR that you would have accepted before this PR? Emphasize "theoretically"
09:59 < stickies-v> would adding better eclipse protection to Bitcoi Core constitute a hard fork?
09:59 < stickies-v> mm no that's a bad example
09:59 < monlovesmango> wouldn't this change also make bitcoin consensus more reliant on time servers? 
10:00 < monlovesmango> which could open up regional level attacks? this assumes that ppl are willing to manipulate time to mess with bitcoin
10:01 < sr_gi> michaelfolkson I think that's a bit unfair. The root of why would you reject a block (both after and before this PR) is because your view of time deviates from "the network's", that can be achieved either by peers messing with your corrected time, or by your NTP server messing with you
10:01 < sr_gi> So in both cases you would reject a somewhat valid block
10:02 < dergoegge> sr_gi: +1
10:02 < monlovesmango> "peers messing with your corrected time, or by your NTP server messing with you" agree, but imo NTP server messing with you seems easier to orchestrate
10:02 < hernanmarino> sr_gi: that's interesting, chain splits could be occurring right now, without this PR
10:03 < sipa> i happen to have just written an answer to a somewhat related question on bitcoin SE: https://bitcoin.stackexchange.com/questions/121247/how-exactly-is-the-timestamp-calculated-for-the-2h-acceptance-rule-and-do-i-hav/121251
10:03 < sr_gi> I think the matter really boils down to how likely is is that after the change non-adjusted and adjusted clients may conflict, and that's a fair concern
10:04 < hernanmarino> yes
10:04 < sipa> i think it's important to realize that adjusted time rejection of a block isn't a permanent rejection
10:04 < sr_gi> monlovesmango but that's something that can still happen currently
10:04 < lightlike> I think it's important to note that adjusted time can only change time by a max of 70 minutes, which is smaller than the 120 minutes block rule. So I think that any meaningful attack would require the attacker to be a miner, that would date its own block almost 2 hours into the future, and then adjust the victim's time into the past. 
10:04 < sipa> which is why it's not really a consensus rule, just a network acceptance rule
10:05 < monlovesmango> sr_gi:  yes, but currently ntp server messing with you will not throw you out of consensus right?
10:06 < michaelfolkson> The chain split risk is really the important question versus whether this is theoretically a hard fork or not. If the chain split risk reduces or is unimpacted then we're happy. And we're in the realm of edge cases anyway
10:07 < stickies-v> i didn't want to interrupt the ongoing conversation but as we've gone quite a bit over time already i'll wrap up the meeting here
10:07 < monlovesmango> thanks for hosting stickies-v!!
10:07 < stickies-v> the lines between consensus, network and policy aren't always as clear!
10:07 < sr_gi> I will I think, if you're far off, you'll adjust the time up to a certain extend, but not beyond `maxtimeadjustment`, but blocks times will still be off for you, so you won't accept them. That's my intuition at least, but take it with a grain of salt
10:07 < lightlike> thank you stickies-v!
10:07 < stickies-v> we'll have the second part of this meeting tomorrow at 5PM UTC
10:07 < michaelfolkson> Thanks stickies-v! Struggled with this one
10:07 < stickies-v> so i hope to see you all again there!
10:07 < stickies-v> #endmeeting
10:08 < pablomartin> thanks stickies-v and all!!!
10:08 < hernanmarino> thanks 
10:08 -!- guest-127 [~guest-127@212.129.76.43] has quit [Quit: Client closed]
10:09 < alfonsoromanz> thanks everyone!
10:09 < michaelfolkson> "i think it's important to realize that adjusted time rejection of a block isn't a permanent rejection" <- This too
10:09 < dergoegge> thanks stickies-v, and everyone for the review!
10:09 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:10 < monlovesmango> sr_gi: wouldn't block times only be off if more than 50% of outgoing peers were affected by NTP attack as well?
10:11 -!- guest1231342 [~guest1231@190.150.197.120] has joined #bitcoin-core-pr-reviews
10:11 -!- alfonsoromanz [~alfonsoro@181.29.127.131] has quit []
10:11 -!- Ayelen [~ayelen@181.29.127.131] has quit []
10:12 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit []
10:12 -!- guest1231342 [~guest1231@190.150.197.120] has quit [Remote host closed the connection]
10:13 -!- BUSY [~BUSY@user/busy] has quit [Ping timeout: 252 seconds]
10:14 -!- pablomartin [~pablomart@181.30.100.202] has quit [Ping timeout: 245 seconds]
10:14 < sr_gi> I think not, but I'm not super familiar with that part of the codebase. My understanding is that the based of your adjusted time is your own time, but that can be corrected up to a certain extend (maxtimeadjustment) based on the median time of your 199 first samples
10:14 < sr_gi> So if you are way off you would still be way off
10:15 < sr_gi> I may be wrong though, so happy to be corrected
10:28 -!- grettke [~grettke@065-026-198-174.biz.spectrum.com] has joined #bitcoin-core-pr-reviews
10:28 -!- hernanmarino [~hernanmar@181.98.56.2] has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
10:43 -!- vmammal [~vmammal@107.181.222.132] has quit [Quit: Client closed]
10:59 -!- hernanmarino [~hernanmar@181.98.56.2] has joined #bitcoin-core-pr-reviews
11:18 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
11:24 -!- sr_gi [~sr_gi@4.53.92.114] has quit [Quit: Client closed]
11:41 -!- sr_gi[m] [~srgimatri@2620:6e:a000:ce11::2a] has joined #bitcoin-core-pr-reviews
11:50 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Remote host closed the connection]
11:51 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has joined #bitcoin-core-pr-reviews
12:05 -!- henmeh [~henning@2a02:8070:4686:d820:1d62:c45:c291:76e2] has quit [Quit: Leaving]
12:11 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:36 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
12:43 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
12:44 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
12:49 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
12:55 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
12:59 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 245 seconds]
13:03 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
13:12 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
13:36 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
13:41 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
13:46 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
13:57 -!- Guest7 [~Guest7@2804:14d:4c85:8f05:8443:84f7:931a:6231] has joined #bitcoin-core-pr-reviews
13:58 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
14:03 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 246 seconds]
14:05 -!- Guest7 [~Guest7@2804:14d:4c85:8f05:8443:84f7:931a:6231] has left #bitcoin-core-pr-reviews []
14:32 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
14:37 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 260 seconds]
14:39 -!- kevkevin [~kevkevin@2601:241:8703:7b30:a84b:24a9:3120:c69e] has quit [Remote host closed the connection]
14:45 -!- mutex [~mutex@static-198-54-134-180.cust.tzulo.com] has quit [Ping timeout: 260 seconds]
14:59 -!- mutex [~mutex@static-198-54-134-180.cust.tzulo.com] has joined #bitcoin-core-pr-reviews
15:05 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
15:39 -!- kevkevin [~kevkevin@2607:fb90:9bac:41eb:9c09:da1b:6e12:a33e] has joined #bitcoin-core-pr-reviews
15:53 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
15:54 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
16:01 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
16:30 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
16:33 -!- kevkevin [~kevkevin@2607:fb90:9bac:41eb:9c09:da1b:6e12:a33e] has quit [Remote host closed the connection]
16:33 -!- kevkevin [~kevkevin@2607:fb90:9bac:41eb:9c09:da1b:6e12:a33e] has joined #bitcoin-core-pr-reviews
16:34 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 260 seconds]
16:42 -!- kevkevin [~kevkevin@2607:fb90:9bac:41eb:9c09:da1b:6e12:a33e] has quit [Remote host closed the connection]
16:52 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
16:57 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
17:32 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
17:36 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
17:51 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
17:55 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
18:13 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
18:18 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
18:26 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
18:30 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
18:32 -!- kevkevin [~kevkevin@2601:243:197e:8f10:bd9a:7914:512d:e030] has joined #bitcoin-core-pr-reviews
18:37 -!- kevkevin [~kevkevin@2601:243:197e:8f10:bd9a:7914:512d:e030] has quit [Ping timeout: 268 seconds]
18:53 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
18:58 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 260 seconds]
18:59 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
19:04 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
19:07 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
19:16 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 240 seconds]
19:19 -!- grettke [~grettke@065-026-198-174.biz.spectrum.com] has quit [Quit: grettke]
19:25 -!- grettke [~grettke@065-026-198-174.biz.spectrum.com] has joined #bitcoin-core-pr-reviews
19:29 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
19:34 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 260 seconds]
19:40 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
19:49 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 245 seconds]
20:02 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
20:06 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
20:19 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
20:24 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 245 seconds]
20:57 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
21:02 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
21:03 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
21:07 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 245 seconds]
21:14 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
21:19 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 260 seconds]
21:20 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
21:25 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 276 seconds]
21:42 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
21:47 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
21:47 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
21:52 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
22:05 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
22:10 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 260 seconds]
22:22 -!- mutex [~mutex@static-198-54-134-180.cust.tzulo.com] has quit [Ping timeout: 240 seconds]
22:23 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
22:28 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
22:33 -!- Adamperry [~Adamperry@95.129.46.60] has joined #bitcoin-core-pr-reviews
22:35 < Adamperry> https://pastebin.com/MCKZj5pw
22:36 -!- Adamperry [~Adamperry@95.129.46.60] has left #bitcoin-core-pr-reviews []
22:36 -!- mutex [~mutex@static-198-54-134-180.cust.tzulo.com] has joined #bitcoin-core-pr-reviews
22:45 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
22:47 -!- kevkevin [~kevkevin@2601:243:197e:8f10:bd9a:7914:512d:e030] has joined #bitcoin-core-pr-reviews
22:49 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 245 seconds]
22:52 -!- kevkevin [~kevkevin@2601:243:197e:8f10:bd9a:7914:512d:e030] has quit [Ping timeout: 245 seconds]
23:30 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
23:34 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 245 seconds]
23:35 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
23:40 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
23:55 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
23:59 -!- Buggytom [~tommy@2601:243:cd80:b040:a4cd:fb37:1c3e:cf02] has joined #bitcoin-core-pr-reviews
23:59 < Buggytom> Bitcoin is dead, you morons
23:59 < Buggytom> Join #freakBall
--- Log closed Thu Jan 04 00:00:21 2024