1 2017-11-21 06:43:48 <geezas> what are the rules on block timestamps?
  2 2017-11-21 06:44:24 <geezas> other than timestamps need to be increasing in value
  3 2017-11-21 06:45:06 <eck> https://en.bitcoin.it/wiki/Block_timestamp
  4 2017-11-21 06:45:31 <geezas> is there anything to prevent timestamps of each block to be incremented by lets say a minute only even though real time between block averages 10 minutes
  5 2017-11-21 06:45:51 <geezas> basically, what keeps reported block timestamps in sync with real time?
  6 2017-11-21 06:45:56 <eck> and numerous other notes at https://en.bitcoin.it/wiki/Protocol_documentation
  7 2017-11-21 06:45:58 <geezas> thanks for the link, reading now
  8 2017-11-21 06:47:03 <eck> consider a node that is being bootstrapped, it is receiving block from the (distant) path
  9 2017-11-21 06:47:05 <eck> *past
 10 2017-11-21 06:47:34 <eck> in this case the freshness check on the timestamp only really applies to up-to-date nodes
 11 2017-11-21 06:48:22 <eck> the consensus rules require that the check be determines purely in terms of what is defined in preceding blocks, not on any external references
 12 2017-11-21 06:48:53 <geezas> ok, so from the first link, valid timestamp range is essentially loosely enforced by the network
 13 2017-11-21 06:49:47 <eck> the protocol is designed so that a node with an incorrect timestamp will still converge to the correct chainstate, therefore the times are defined purely in terms of what is actually in blocks, not on a reference clock
 14 2017-11-21 06:49:52 <geezas> is that really so? no external references
 15 2017-11-21 06:50:18 <geezas> network time + 2 hours rule seems like an external reference
 16 2017-11-21 06:50:46 <eck> yeah I am not an expert, this is what someone else (a core dev) told me
 17 2017-11-21 06:50:53 <geezas> i mean, it says it's a median of all connected nodes
 18 2017-11-21 06:51:01 <geezas> ok got it
 19 2017-11-21 06:51:04 <eck> you could imagine though how you'd validate "new" blocks different from old blocks though
 20 2017-11-21 06:51:26 <eck> i would love to be corrected by someone who knows better though
 21 2017-11-21 06:51:50 <geezas> so it looks like the rule that does not depend on external references is that each block timestamp must be greater than median timestamp of last 11 blocks
 22 2017-11-21 06:52:08 <eck> i think that's accurate
 23 2017-11-21 06:52:26 <geezas> but the rule that prevents invalid timestamps way into the future relies on the network reported time
 24 2017-11-21 06:52:41 <geezas> a decentralized external reference if you will
 25 2017-11-21 06:53:21 <eck> have you read the original whitepaper?
 26 2017-11-21 06:53:33 <geezas> yes
 27 2017-11-21 06:53:35 <eck> it refers to the blockchain itself as a "timestamp server"
 28 2017-11-21 06:53:39 <geezas> why?
 29 2017-11-21 06:53:57 <eck> as i understand it, for precisely this reason
 30 2017-11-21 06:54:03 <eck> to avoid the need to depend on external clocks
 31 2017-11-21 06:54:34 <geezas> well...
 32 2017-11-21 06:54:43 <eck> you provide a PoW problem, and use that to enforce time constraints
 33 2017-11-21 06:55:32 <geezas> it's more like the network is assumed, on average, to report valid time (within some range)
 34 2017-11-21 06:55:42 <eck> I think that's accurate
 35 2017-11-21 06:55:59 <geezas> and because of that, once the block is found, it confirms the timestamp, just like the transactions
 36 2017-11-21 06:56:00 <eck> if enough miners lied about the current time, they could get valid blocks in that wouldn't be valid according to (true time)
 37 2017-11-21 06:56:21 <geezas> so it serves as an immutable ledger as well as immutable timestamp chain
 38 2017-11-21 06:56:28 <eck> to abuse this though, you would need a lot of mining nodes to lie
 39 2017-11-21 06:56:41 <geezas> but the timestamps are only accurate to within a few hours
 40 2017-11-21 06:57:08 <eck> again, as i understand it: the reason there are timestamps at all is for the difficulty adjustment
 41 2017-11-21 06:57:18 <eck> the difficulty adjustment has a 10m target
 42 2017-11-21 06:57:30 <geezas> I think you're right, it's definitely needed for DA
 43 2017-11-21 06:57:34 <eck> therefore it needs to know the difference between the first block and the last block
 44 2017-11-21 06:57:51 <geezas> the reason I'm looking into this now
 45 2017-11-21 06:57:52 <eck> other than that, there is no need (AFAIK) for human-understandable time epochs
 46 2017-11-21 06:58:14 <geezas> is because I was wondering if it would be possible to do ellapsed-time-scaled block size limits
 47 2017-11-21 06:58:36 <eck> where you would rely on an external timestamp server?
 48 2017-11-21 06:58:50 <geezas> this would allow for a lot more steady TX throughput without messing with difficulty adjustment algo
 49 2017-11-21 06:59:19 <eck> who would you trust?
 50 2017-11-21 06:59:55 <geezas> I'm not suggesting to trust some external timestamp server
 51 2017-11-21 07:00:31 <geezas> but I'm interested to see if it's doable with the existing timekeeping methods
 52 2017-11-21 07:00:44 <geezas> to preserve the same trust model
 53 2017-11-21 07:01:00 <geezas> or consensus model I guess
 54 2017-11-21 07:02:51 <geezas> eli5 of what I'm thinking of:
 55 2017-11-21 07:03:43 <geezas> if block is found 5 minutes after last block, its size limit is half of the nominal 10 min rated block size limit
 56 2017-11-21 07:04:10 <eck> how would you know the tlsb (time since last block)?
 57 2017-11-21 07:04:14 <geezas> if block is found 20 minutes after last block, its size limit is double of the nominal 10 min rated block size
 58 2017-11-21 07:05:08 <geezas> right, that's my question as well, but for that I needed to know how time is handled currently
 59 2017-11-21 07:05:52 <geezas> I don't see why nodes couldn't keep track of current time accurately
 60 2017-11-21 07:06:13 <eck> suppose you're a new node
 61 2017-11-21 07:06:15 <geezas> assuming they could, they just calculate elapsed time as current time - time of last block
 62 2017-11-21 07:06:20 <eck> and you're syncing from scratch
 63 2017-11-21 07:06:29 <eck> how would it work then?
 64 2017-11-21 07:07:06 <geezas> for syncing you'd just look at timestamp deltas between blocks
 65 2017-11-21 07:07:16 <eck> right, that's what the current algo does
 66 2017-11-21 07:07:22 <geezas> to determine if each block is within the size limit and therefore valid
 67 2017-11-21 07:07:55 <eck> so if i'm an "up to date" node operating in the new geezas model, how do i know if i'm actually up to date with the new ts server
 68 2017-11-21 07:08:10 <geezas> ts server?
 69 2017-11-21 07:08:15 <eck> timestamp servedr
 70 2017-11-21 07:08:40 <eck> seems like someone could trick me
 71 2017-11-21 07:09:27 <geezas> isn't the same applies to the current system?
 72 2017-11-21 07:09:49 <geezas> I mean, somebody would need to trick majority of the nodes, no?
 73 2017-11-21 07:09:59 <eck> yes, for 11 blocks
 74 2017-11-21 07:10:21 <eck> not impossible, but mining 11 blocks on your own would be quite a feat
 75 2017-11-21 07:11:34 <geezas> how's mining blocks related to that, I though the tricking part was about somehow making a node get a wrong system time
 76 2017-11-21 07:12:21 <eck> you could trick me at <current time>, and i could follow your chain for a short time
 77 2017-11-21 07:12:31 <geezas> I'm probably less in touch with this subject than you, so forgive me if we might not be on the same page
 78 2017-11-21 07:12:37 <eck> if i'm a Real Merchant though, i require X confirmations
 79 2017-11-21 07:12:58 <eck> so you'd have to trick me for X blocks to double-spend
 80 2017-11-21 07:13:28 <Sentineo> interesting reading!
 81 2017-11-21 07:13:55 <Sentineo> are all miners connected to fibre?
 82 2017-11-21 07:14:02 <geezas> I think I need visualize better what we're talking about with concrete examples
 83 2017-11-21 07:14:21 <eck> i think (hope) i can explain
 84 2017-11-21 07:14:29 <Sentineo> eck: was reading your point about malicious miners with wrong time, if theh ate interconnected directly they can do it
 85 2017-11-21 07:14:40 <Sentineo> but would the other part of tje network follow?
 86 2017-11-21 07:14:53 <eck> the way i can trick bitcoin, is if i convince you i paid you X BTC, but in reality i did not (for whatever reason)
 87 2017-11-21 07:15:02 <Sentineo> I think not ... - but might be wrong
 88 2017-11-21 07:15:22 <geezas> right, my impression that correct timekeeping security model is that invalid times would not propagate through honest nodes
 89 2017-11-21 07:15:28 <eck> the way this would happen is if i creat a chain whered i pay you X, but later that chain is determined to be invalid
 90 2017-11-21 07:16:10 <Sentineo> geezas: that assumption is correct (block propagation)
 91 2017-11-21 07:19:51 <geezas> eck, I still don't see how timestamp manipulation can allow for a possible double spend attack
 92 2017-11-21 07:20:24 <geezas> that's somehow different from the one not involving timestamps
 93 2017-11-21 07:20:37 <eck> geezas: i'd have to both manipulate the timestamp + build a long enough valid chain for you to follow it
 94 2017-11-21 07:21:05 <geezas> right, so it seems it's still a pow-based attack
 95 2017-11-21 07:21:10 <eck> which is different of course than just building the wrong chain in the first place (in terms of timestamp)
 96 2017-11-21 07:21:15 <eck> yes
 97 2017-11-21 07:21:30 <eck> the whole timestamp concept is built aroudn pow
 98 2017-11-21 07:21:50 <geezas> I don't think so
 99 2017-11-21 07:22:03 <eck> i might be wrong
100 2017-11-21 07:22:05 <geezas> timestamps are locked in with pow, but that's not what makes them valid
101 2017-11-21 07:22:19 <eck> go on
102 2017-11-21 07:22:47 <geezas> network consensus rules are used to enforce valid timestamps, otherwise, propagation is blocked
103 2017-11-21 07:23:01 <geezas> that's the mechanism that keeps timestamps valid
104 2017-11-21 07:23:10 <eck> maybe, or maybe the nodes are lyring
105 2017-11-21 07:23:14 <eck> *lying
106 2017-11-21 07:23:36 <geezas> that the timestamps get locked into the blockchain with pow after that is is another part of this
107 2017-11-21 07:24:55 <geezas> the lower limit on the timestamp is enforced by simple rule of being higher than median of last 11 blocks, so there isn't much wiggle room there
108 2017-11-21 07:25:04 <Sentineo> nodes check the validity of a block
109 2017-11-21 07:25:11 <geezas> but what enforces upper limits on timestamps?
110 2017-11-21 07:25:22 <Sentineo> median time being in the correct range is one of them
111 2017-11-21 07:25:51 <eck> what upper limit?
112 2017-11-21 07:25:52 <geezas> it seems to me that's enforced by nodes keeping track of their own time
113 2017-11-21 07:25:53 <Sentineo> 20 mins in future is allowed max iirc
114 2017-11-21 07:26:20 <Sentineo> geezas: yes
115 2017-11-21 07:26:21 <geezas> so if a block is not mined for an hour, the timestamp still goes up by no more than 20 mins?
116 2017-11-21 07:26:44 <eck> so i might be wrong, but if the timestamp is determined purely by last N blocks (in this case N=11), that seems plausible to me
117 2017-11-21 07:27:17 <geezas> let's say ~94% of hash rate goes away for a day, we mine 1 block every 3h, 8 blocks in total
118 2017-11-21 07:27:20 <eck> ok
119 2017-11-21 07:27:24 <eck> with you so far
120 2017-11-21 07:27:27 <Sentineo> it can not be less than median time, no more than now + 20mins
121 2017-11-21 07:27:51 <geezas> would timestamps of each block increment by 10-20 mins or so?
122 2017-11-21 07:27:57 <Sentineo> where now is nodes curret time
123 2017-11-21 07:28:01 <eck> geezas: no
124 2017-11-21 07:28:50 <geezas> so in this scenario, what are valid ranges for the 8 blocks?
125 2017-11-21 07:29:08 <geezas> assume blocks were 10 mins apart before then and that timestamps were exact for those
126 2017-11-21 07:29:13 <eck> based on the median time of the last 11 blocks, same as any other node
127 2017-11-21 07:30:08 <eck> the attack is not "what i mine 100 blocks in 1 minute", the attack is "what if 1 block is mined in 1000 minutes"
128 2017-11-21 07:30:15 <geezas> so median time of last 11 blocks would be, assuming hash rate slowed down at midnight today, would be 6 blocks back, so 11pm yesterday
129 2017-11-21 07:30:46 <eck> it could be arbitrarily long
130 2017-11-21 07:30:46 <geezas> now a new block is mined at 3am
131 2017-11-21 07:30:58 <geezas> what's the valid range for the timestamp of this block?
132 2017-11-21 07:31:10 <geezas> it must be greater than 11pm yesterday
133 2017-11-21 07:31:13 <eck> sure
134 2017-11-21 07:31:15 <geezas> what's the upper limit?
135 2017-11-21 07:31:26 <eck> so worst case, assume zombie apocalypse
136 2017-11-21 07:31:37 <geezas> a miner picks the timestamp, so what's the upper limit?
137 2017-11-21 07:31:46 <eck> in the zombie apocalypse case, i would lie
138 2017-11-21 07:32:01 <eck> upper limit is given by the median of the last 11 blocks
139 2017-11-21 07:32:10 <geezas> that's lower limit
140 2017-11-21 07:32:17 <eck> nah
141 2017-11-21 07:32:28 <geezas> in my mind time increases
142 2017-11-21 07:32:30 <eck> that's the lower acceptable limit
143 2017-11-21 07:32:34 <eck> not the lower limit
144 2017-11-21 07:33:03 <geezas> how about we use more specific terms, min and max instead of lower upper
145 2017-11-21 07:33:23 <geezas> my assumption that min timestamp value = median of last 11 blocks
146 2017-11-21 07:33:44 <geezas> you're saying it's not correct, right?
147 2017-11-21 07:33:49 <eck> one second
148 2017-11-21 07:33:53 <eck> let me rtfs
149 2017-11-21 07:35:10 <geezas> ha, ok, I will summarize how I understood that link about block timestamp
150 2017-11-21 07:35:37 <eck> as i understand the code, if you controlled many nodes to me, you could lie and i would be tricked
151 2017-11-21 07:35:44 <geezas> next block timestamp minimum allowed value = median of previous 11 blocks
152 2017-11-21 07:35:47 <eck> *connected to me
153 2017-11-21 07:36:03 <geezas> so minimum limit can't be tricked
154 2017-11-21 07:36:16 <eck> but i would detct if i waited long enough
155 2017-11-21 07:36:19 <geezas> as the source of that limit is pow-confirmed blocks
156 2017-11-21 07:36:35 <Sentineo> eck: it does not sound right
157 2017-11-21 07:36:39 <eck> how manmy pow-confirmed blocks you accept is up to you
158 2017-11-21 07:36:41 <geezas> but the maximum limit comes from peer nodes
159 2017-11-21 07:36:53 <Sentineo> if a ts is not ok, my full node rejects your block
160 2017-11-21 07:37:11 <geezas> eck, for timestamp, it's not up to you, it's median of 11 previous block timestamps
161 2017-11-21 07:37:18 <eck> right
162 2017-11-21 07:37:53 <geezas> so if next block has timestamp violating this rule, other nodes will not consider it a valid block, no matter how you interpret it
163 2017-11-21 07:38:04 <eck> i think that's right
164 2017-11-21 07:38:07 <geezas> but
165 2017-11-21 07:38:10 <geezas> for upper limit
166 2017-11-21 07:38:20 <geezas> it's what they call "Network-adjusted time"
167 2017-11-21 07:38:35 <eck> from first principles, every node should get to the same final state
168 2017-11-21 07:38:47 <eck> even if their individual clocks are different
169 2017-11-21 07:38:59 <geezas> if I understand it correctly, for the purpose of validating historical blocks, there is no limit
170 2017-11-21 07:39:26 <geezas> but for propagating new blocks, it's NAT (network-adjusted time) + 2 hours
171 2017-11-21 07:40:10 <eck> well
172 2017-11-21 07:40:23 <eck> old blocks should be treated same as new blocks
173 2017-11-21 07:40:36 <eck> how do you know if you're in old mode vs new mode?
174 2017-11-21 07:40:44 <geezas> right, that's where I'm interesting in understanding this better
175 2017-11-21 07:41:23 <eck> bingo
176 2017-11-21 07:42:28 <geezas> I think the network relies on the majority of nodes reporting correct current time, give or take
177 2017-11-21 07:42:40 <Sentineo> nodes syncing have a special state
178 2017-11-21 07:42:50 <Sentineo> forgot the name ibd I think
179 2017-11-21 07:42:59 <Sentineo> look for it in the debug.log
180 2017-11-21 07:43:10 <geezas> but for syncing, I wonder if there's an upper limit on valid timestamp, I don't think there is
181 2017-11-21 07:43:16 <eck> most nodes are connected to only 8 other nodes
182 2017-11-21 07:43:24 <eck> so it is pretty easy to trick them
183 2017-11-21 07:43:26 <Sentineo> and its activation deoends from the time
184 2017-11-21 07:44:05 <Sentineo> eck: they will accept the longest most proof of work chain and trust the tkmestamp
185 2017-11-21 07:44:43 <geezas> so... image I'm a new node and I'm syncing. Let's say my current block is #10000 with timestamp 2017-01-01, someone sends me a block #10001  with timestamp 2017-11-21 (today)
186 2017-11-21 07:44:44 <Sentineo> the timestamp is really enforced by up to date nodes
187 2017-11-21 07:44:54 <Sentineo> not ibd ones
188 2017-11-21 07:44:59 <geezas> that would be a valid block, right?
189 2017-11-21 07:45:09 <Sentineo> geezas: yes
190 2017-11-21 07:45:44 <geezas> ok, makes sense, so there's no upper limit on timestamp delta between blocks
191 2017-11-21 07:45:59 <Sentineo> ah that is what you mean
192 2017-11-21 07:46:00 <geezas> other than current time + 2 hours
193 2017-11-21 07:46:02 <Sentineo> no there is not
194 2017-11-21 07:46:15 <Sentineo> right
195 2017-11-21 07:46:17 <geezas> which is enforced by majority nodes reporting correct current time
196 2017-11-21 07:46:18 <Sentineo> considerr
197 2017-11-21 07:46:28 <geezas> but for syncing it does not matter
198 2017-11-21 07:46:28 <Sentineo> 80% of hashpower disapears
199 2017-11-21 07:46:48 <Sentineo> 2016 blocks would take a loong time
200 2017-11-21 07:47:11 <Sentineo> you do not know how much in advance, so such rule would be problematic and not solve anything
201 2017-11-21 07:47:49 <geezas> Sentineo, I agree, I'm not considering such a rule, but somehow conversation with eck lead to that
202 2017-11-21 07:48:09 <geezas> initially he said that timestamps do not rely on any external clocks or time servers
203 2017-11-21 07:48:09 <Sentineo> yeas, agree
204 2017-11-21 07:48:26 <Sentineo> the external is important there
205 2017-11-21 07:48:43 <Sentineo> you can drop blocks just cause you have a bad clock
206 2017-11-21 07:49:04 <Sentineo> e.g. you stay in 2015
207 2017-11-21 07:49:07 <geezas> and from what I understand, the upper valid limit does indeed exist, but not on time difference between blocks, but on timestamp value itself (current time (via NAT) + 2 hours)
208 2017-11-21 07:49:20 <Sentineo> you would not get new blocks added to your chain
209 2017-11-21 07:49:22 <geezas> which is actually enforced by so called external system(s)
210 2017-11-21 07:49:43 <geezas> right
211 2017-11-21 07:50:10 <Sentineo> but it is external to the system (btc)
212 2017-11-21 07:50:13 <geezas> and you'd think you're up to date, but that's only if you're connected to more than 50% of malicious nodes
213 2017-11-21 07:50:26 <Sentineo> not how eck ment it , and how I understand what he wrote
214 2017-11-21 07:50:30 <geezas> plus, that's assuming you don't have your own clock for sanity checking
215 2017-11-21 07:51:25 <geezas> so, now that I'm pretty clear on current workings of this
216 2017-11-21 07:51:35 <geezas> (thanks eck and Sentineo)
217 2017-11-21 07:52:19 <Sentineo> I will set my own clock to 2015
218 2017-11-21 07:52:27 <Sentineo> want to see the log messages ;)
219 2017-11-21 07:52:31 <Sentineo> never tried it
220 2017-11-21 07:52:41 <geezas> I was wondering if there would be foreseeable issues if block size limit would be a function of timestamp delta between its timestamp and prev block timestamp
221 2017-11-21 07:53:06 <Sentineo> well you would see no increase in the way you described it
222 2017-11-21 07:53:09 <geezas> Sentineo, I think your node might be using NAT (network adjusted time)
223 2017-11-21 07:53:13 <Sentineo> but even it could decrease
224 2017-11-21 07:53:15 <geezas> not your system clock
225 2017-11-21 07:53:25 <geezas> from link, eck posted earlier: https://en.bitcoin.it/wiki/Block_timestamp
226 2017-11-21 07:53:28 <Sentineo> geezas: of course I would turn it off
227 2017-11-21 07:53:52 <geezas> oh, sorry, never ran a node, so I don't know how configurable it is
228 2017-11-21 07:54:08 <geezas> so you can turn off NAT, is what you're saying, right?
229 2017-11-21 07:54:25 <Sentineo> if u mean ntp, yes
230 2017-11-21 07:54:55 <geezas> what's ntp?
231 2017-11-21 07:55:32 <geezas> the link I just posted, it says: "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.
232 2017-11-21 07:56:05 <geezas> A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours.
233 2017-11-21 07:56:59 <Sentineo> well i am not sure if bitcoind will consider system time at all then
234 2017-11-21 07:57:08 <geezas> anyway, back to my inquiry about block size as a function of timestamp delta
235 2017-11-21 07:57:08 <Sentineo> we will see
236 2017-11-21 07:57:40 <Sentineo> cause if it does not, eck is right that miners can fool nodes (not how I thought it works)
237 2017-11-21 07:58:22 <geezas> pause on my inquiry... how can miners fool nodes?
238 2017-11-21 07:58:43 <geezas> nodes report time to other nodes
239 2017-11-21 07:59:02 <Sentineo> they should not report, it requires trust
240 2017-11-21 07:59:32 <Sentineo> but do not know
241 2017-11-21 07:59:48 <Sentineo> never tried ;)
242 2017-11-21 08:00:08 <geezas> right, but then it's not specifically miners than can fool nodes, but just nodes in general
243 2017-11-21 08:01:19 <geezas> but there are hundreds of other valid attacks on nodes when surrounded by malicious nodes, so reporting bad time is probably the least of the worries in such a scenario
244 2017-11-21 08:02:34 <geezas> although from what I know, many attacks require that all or almost all peer nodes are malicious for the attack to work
245 2017-11-21 08:03:03 <Sentineo> reporting time means sending a block
246 2017-11-21 08:03:14 <Sentineo> blocks need PoW
247 2017-11-21 08:03:19 <Sentineo> so you need miners
248 2017-11-21 08:03:40 <geezas> whereas with NAT, only 50% + 1 malicious nodes is enough to trick a node into getting a wrong time
249 2017-11-21 08:03:54 <geezas> you don't need miners for NAT
250 2017-11-21 08:04:02 <geezas> which is then used to validate blocks
251 2017-11-21 08:04:06 <geezas> so here is an attack scenario
252 2017-11-21 08:04:28 <Sentineo> how do I get NAT?
253 2017-11-21 08:04:39 <Sentineo> you think it is a protocol of some sort?
254 2017-11-21 08:04:45 <geezas> what do you mean by get?
255 2017-11-21 08:05:02 <geezas> sorry, I am going solely off of that definition from the link
256 2017-11-21 08:05:19 <geezas> I assume it's in the protocol
257 2017-11-21 08:05:47 <geezas> whether it's something the node software tells you I don't know
258 2017-11-21 08:05:49 <eck> geezas: how do you pick your peers in the NAT?
259 2017-11-21 08:05:53 <geezas> since I never ran a node
260 2017-11-21 08:06:37 <geezas> eck: it says it's the "median of the timestamps returned by all nodes connected to you"
261 2017-11-21 08:06:46 <eck> alright
262 2017-11-21 08:06:54 <Sentineo> no
263 2017-11-21 08:06:58 <eck> maybe i'm a student a university X
264 2017-11-21 08:07:02 <Sentineo> for sure not
265 2017-11-21 08:07:06 <eck> and my peers in my dorm lie to me
266 2017-11-21 08:07:27 <eck> ideally, there is some way to get back onto the main chain
267 2017-11-21 08:07:30 <eck> even if they lie to me
268 2017-11-21 08:07:33 <Sentineo> you should count stuff from blocks, not from messages from peers
269 2017-11-21 08:07:51 <eck> right
270 2017-11-21 08:08:12 <geezas> Sentineo, yes and no
271 2017-11-21 08:08:42 <geezas> if you're syncing, and you're currently at last year block
272 2017-11-21 08:09:00 <eck> the whole idea is that if my peers in my dorm wanted to lie to me, to actually do that they'd have to have more has power than the rest of the network combined
273 2017-11-21 08:09:04 <geezas> if peers report to you that current time is 2017 January
274 2017-11-21 08:09:36 <geezas> how do you know that 2017 January is invalid reported time? blocks wont help you here
275 2017-11-21 08:09:38 <Sentineo> geezas: we afe not syncing
276 2017-11-21 08:09:41 <eck> the timestamp is in the block
277 2017-11-21 08:09:46 <eck> not in what peers tell you
278 2017-11-21 08:09:54 <Sentineo> exactlt
279 2017-11-21 08:09:58 <eck> it's part of the block header
280 2017-11-21 08:09:58 <Sentineo> eck has the point
281 2017-11-21 08:10:11 <Sentineo> you trust the BLOCK, as it is backed by PoW
282 2017-11-21 08:10:34 <Sentineo> not a peer and some time message from it (there is no such message type iirc)
283 2017-11-21 08:10:43 <geezas> yes but your lets say the latest block you synced is from last year
284 2017-11-21 08:10:49 <geezas> because you're not done syncing
285 2017-11-21 08:10:50 <eck> ok
286 2017-11-21 08:11:27 <geezas> the timestamp on the latest block you synced says lets say 2016 December something
287 2017-11-21 08:11:36 <eck> so I see that there is chain A (the real, main chain) that has 1000s of txs built on it, or i see this crappy side chain that has 7 tx built on it
288 2017-11-21 08:11:50 <eck> which am i going to follow?
289 2017-11-21 08:12:12 <geezas> eck, not sure what you're talking about, there are no sidechains or alternative chains
290 2017-11-21 08:12:13 <Sentineo> you care about the work in the chain
291 2017-11-21 08:12:17 <geezas> just the main chain for now
292 2017-11-21 08:12:36 <Sentineo> geezas: there are, you implicitly have 2 if you are talking about an attack
293 2017-11-21 08:12:50 <eck> geezas: we're discussing how a node would trick the network, which implies the node double-spends
294 2017-11-21 08:13:00 <eck> if not a double spending attack, what are you worrried about?
295 2017-11-21 08:13:00 <Sentineo> right
296 2017-11-21 08:13:04 <geezas> I'm not talking about an attack where false blocks are given to you
297 2017-11-21 08:13:14 <geezas> at least not at this point
298 2017-11-21 08:13:25 <Sentineo> ok, try again ;)
299 2017-11-21 08:13:40 <geezas> ok, so I'm a new node
300 2017-11-21 08:13:46 <geezas> I start syncing to the main chain
301 2017-11-21 08:13:51 <eck> alright
302 2017-11-21 08:14:19 <geezas> I'm being given blocks that follow whatever my latest block I've synced is
303 2017-11-21 08:14:24 <eck> ok
304 2017-11-21 08:14:32 <geezas> so I start and get block 1 then 2 then 3 etc
305 2017-11-21 08:14:50 <geezas> so I reach block whatever, let's say 100000
306 2017-11-21 08:15:14 <geezas> and lets say timestamp on that block is 2016 December whatever
307 2017-11-21 08:15:19 <eck> ok
308 2017-11-21 08:16:07 <geezas> I'm connected to 21 nodes, 11 are malicious and are reporting current time as 2017 January 5
309 2017-11-21 08:16:36 <geezas> so I will keep syncing until I reach a block  with timestamp 2017 January 5 + 2 hours
310 2017-11-21 08:16:48 <geezas> after which, I will thing I'm getting blocks which are in the future and thus invalid
311 2017-11-21 08:16:57 <geezas> so I will start rejecting those
312 2017-11-21 08:17:07 <geezas> and think I'm done syncing
313 2017-11-21 08:17:13 <eck> i haved not rtfs, but i believe what happens is  you see two chains
314 2017-11-21 08:17:13 <geezas> since I'm not getting any more valid blocks
315 2017-11-21 08:17:24 <geezas> there are no two chains
316 2017-11-21 08:17:27 <geezas> it's still one chain
317 2017-11-21 08:17:29 <eck> why not
318 2017-11-21 08:17:40 <geezas> where is the 2nd chain you're speaking of?
319 2017-11-21 08:17:42 <eck> syncing != 1 chain
320 2017-11-21 08:17:58 <geezas> all blocks are referencing each other in one chain
321 2017-11-21 08:18:01 <Sentineo> geezas: you are not correct if you assume nodes are reporgint time, they are not
322 2017-11-21 08:18:03 <eck> sure
323 2017-11-21 08:18:17 <eck> each block references the hash of the previous block
324 2017-11-21 08:18:23 <geezas> Sentineo, maybe that's true, but that's not what bitcoin wiki says about it
325 2017-11-21 08:18:29 <Sentineo> geezas: nodes send you blocks, and those have timestamps ... so sending different time means you send an alternative chain (different blocks)
326 2017-11-21 08:18:36 <eck> or more accurately, its merkle root
327 2017-11-21 08:18:51 <Sentineo> geezas: bitcoin wiki has like 7 sentences, you want to analyse a protocol based on that?
328 2017-11-21 08:18:56 <eck> so as a new syncing node, i see we all agree up to block X
329 2017-11-21 08:19:06 <eck> after block X, i see two new possible merkle roots
330 2017-11-21 08:19:13 <Sentineo> no no
331 2017-11-21 08:19:15 <eck> i follow the one with the most pow behind it
332 2017-11-21 08:19:16 <Sentineo> merkle root is for txes
333 2017-11-21 08:19:27 <geezas> eck, merkle roots are not related to this
334 2017-11-21 08:19:28 <eck> the merkle root is in the block header
335 2017-11-21 08:19:34 <Sentineo> block header's hash is used in the blocks
336 2017-11-21 08:19:39 <eck> it references the previous block
337 2017-11-21 08:19:52 <Sentineo> eck: not merkle root references the txes in the current block
338 2017-11-21 08:19:58 <Sentineo> and you are right they are in the block header
339 2017-11-21 08:20:05 <geezas> right, so here's the simplified block chain: A -> B -> C -> D -> E (current)
340 2017-11-21 08:20:06 <eck> if i mine block X, how do i know which block is X-1?
341 2017-11-21 08:20:06 <Sentineo> there is a previous block header field in the header
342 2017-11-21 08:20:22 <geezas> eck: each block references previous block
343 2017-11-21 08:20:25 <eck> right
344 2017-11-21 08:20:37 <geezas> so let me redo me diagram: A <- B <- C <- D <- E (current)
345 2017-11-21 08:20:39 <Sentineo> eck: you build on top of it, you must .. otherwise how would others tell you are on the correct chain? you are prooving it to them by referencing its block hash in the header
346 2017-11-21 08:21:05 <eck> more accurately, the block header has merkle root (this block) + merkel root (prev block) + other stuff (e.g. version bits)
347 2017-11-21 08:21:32 <Sentineo> eck: no :)
348 2017-11-21 08:21:45 <eck> alright
349 2017-11-21 08:21:48 <eck> enlighten me
350 2017-11-21 08:21:57 <geezas> if I'm being given wrong NAT by malicious peer nodes, let's say time is such that blocks D and E are invalid according to such time, what happens then when I'm syncing? I will sync A <- B <-C and presumably reject D and E
351 2017-11-21 08:22:19 <Sentineo> eck: look at https://bitcoin.org/en/developer-reference#block-headers
352 2017-11-21 08:22:39 <eck> Sentineo: which part did i get wrong?
353 2017-11-21 08:22:49 <Sentineo> eck: you have two 256 bit fields in the header, one for merkle root, the other for previous block hash
354 2017-11-21 08:22:58 <Sentineo> eck: you sounded like you say they are the same
355 2017-11-21 08:23:03 <geezas> eck, merkle root in each block is independant from any other block, it's just a summary hash (fingerprint) of all transactions in that block
356 2017-11-21 08:23:17 <Sentineo> geezas: you are not given NAT man ...
357 2017-11-21 08:24:14 <geezas> Sentineo, either documentation is correct or it's not, which is it?
358 2017-11-21 08:24:34 <Sentineo> it is the user who is interpreting words incorectly
359 2017-11-21 08:24:38 <Sentineo> you write as
360 2017-11-21 08:24:44 <Sentineo> if NAT was a protocol or something
361 2017-11-21 08:24:48 <Sentineo> it is just a concept
362 2017-11-21 08:25:43 <Sentineo> it sounds like we are talking that the manual says this 10kg ball is 8kg. So it is 8kg. Well it is whatever you measure it is ... :)
363 2017-11-21 08:26:51 <geezas> well, it sure sounds like protocol is being described
364 2017-11-21 08:27:08 <geezas> it explicitly says what is considered a valid timestamp (of a block)
365 2017-11-21 08:27:46 <geezas> it says it must be greater than median of last 11 timestamps and less than n.a.t.
366 2017-11-21 08:28:00 <Sentineo> you can spin up a node, use tcpdump or wireshark to capture the messages between them
367 2017-11-21 08:28:07 <geezas> I presume if timestamp is invalid, the block is considered invalid
368 2017-11-21 08:28:07 <Sentineo> and tell me there you see a NAT message
369 2017-11-21 08:28:31 <geezas> there does not need to be a nat message
370 2017-11-21 08:28:31 <Sentineo> nat is calculated from a block, not from a message from a peer
371 2017-11-21 08:28:37 <Sentineo> and that makes the whole difference
372 2017-11-21 08:28:46 <geezas> is there ever a timestamp when communicating with nodes?
373 2017-11-21 08:28:56 <geezas> that's enough to get a timestamp from a node
374 2017-11-21 08:29:02 <Sentineo> from your assumptions it sounds like you think there is a separate message and you get time from peers
375 2017-11-21 08:29:10 <Sentineo> geezas: no there is not
376 2017-11-21 08:29:18 <geezas> then "NAT" is calculated internally, by taking a median of all timestamps, one from each node
377 2017-11-21 08:29:58 <geezas> so what does "timestamps returned by all nodes connected to you" phrase mean?
378 2017-11-21 08:32:45 <Sentineo> internaly from blocks you have
379 2017-11-21 08:32:59 <Sentineo> from the blocks they send
380 2017-11-21 08:33:16 <Sentineo> you have no way of knowing you are on the valid chain
381 2017-11-21 08:33:27 <Sentineo> e.g. if your node goes off
382 2017-11-21 08:33:38 <Sentineo> and comes back 2 hours later and there is no new block since
383 2017-11-21 08:33:48 <Sentineo> you see the progress indicator as 0.9999 something, not 1
384 2017-11-21 08:34:00 <Sentineo> as it does not know if it is out of sync, or just there was no new block
385 2017-11-21 08:34:07 <Sentineo> it will know once a new blocks gets to it
386 2017-11-21 08:54:54 <geezas> Sentineo
387 2017-11-21 08:55:47 <geezas> so what happens if a miner mines a block with a timestamp that's dated 30 days into the future?
388 2017-11-21 08:56:16 <geezas> by your explanation, it would be a perfectly valid block and all nodes would accept it as the next block
389 2017-11-21 09:02:09 <Sentineo> no they would not
390 2017-11-21 09:02:18 <Sentineo> as they check the blocks timestamp to their time
391 2017-11-21 09:02:31 <Sentineo> in case they are synced of course
392 2017-11-21 11:18:20 <cluelessperson> Would someone who's been around be able to help me with some media and opinions?
393 2017-11-21 16:00:05 <hkjn0> hey, I have my node running with txindex=1 and restarted with -reindex, but I still get "no such transaction" from getrawtransaction calls..
394 2017-11-21 16:00:21 <hkjn0> I guess the reindexing is still going? can I check the status of reindexing with some RPC?
395 2017-11-21 16:04:44 <hkjn0> ah, I just noticed "Reindexing block file blk00165.dat..." messages in logs.. so I guess I can estimate progress by comparing how many blk*.dat files there are
396 2017-11-21 16:43:11 <hidden> 2017-11-21 11:14:34 [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE].
397 2017-11-21 16:43:12 <hidden> 2017-11-21 12:20:28  block index         4051611ms
398 2017-11-21 16:43:12 <hidden> 2017-11-21 12:20:28 init message: Loading wallet...
399 2017-11-21 16:43:12 <hidden> 2017-11-21 12:20:28 Keys: 102 plaintext, 0 encrypted, 0 w/ metadata, 102 total
400 2017-11-21 16:43:12 <hidden> 2017-11-21 12:20:28 nFileVersion = 32400
401 2017-11-21 16:43:12 <hidden> 2017-11-21 12:20:28 No coin database inconsistencies in last 7 blocks (13599 transactions)
402 2017-11-21 16:43:14 <hidden> 2017-11-21 12:20:28  wallet                   65ms
403 2017-11-21 16:43:16 <hidden> 2017-11-21 12:20:28
404 2017-11-21 16:43:18 <hidden> ************************
405 2017-11-21 16:43:20 <hidden> EXCEPTION: St13runtime_error
406 2017-11-21 16:43:22 <hidden> GenerateNewKey: AddKey failed
407 2017-11-21 16:43:24 <hidden> C:\Program Files\Bitcoin\bitcoin-qt.exe in Runaway exception
408 2017-11-21 16:43:28 <hidden> 2017-11-21 16:34:08 CDBEnv::EnvShutdown: Error -30974 shutting down database environment: DB_RUNRECOVERY: Fatal error, run database recovery
409 2017-11-21 20:33:37 <fullstep> Hi All. I'm looking over the version message structure (https://bitcoin.org/en/developer-reference#version) and I am wondering why the timestamp is a signed int instead of unsigned. Same for start_height. Any reason for that?
410 2017-11-21 21:29:04 <eck> it's unsigned
411 2017-11-21 21:29:41 <eck> https://en.bitcoin.it/wiki/Block_timestamp