1 2017-11-21T00:01:20 *** Kedstar has joined #bitcoin-dev
2 2017-11-21T00:38:55 *** Belxjander has quit IRC
3 2017-11-21T00:40:57 *** oleganza has quit IRC
4 2017-11-21T00:43:57 *** Belxjander has joined #bitcoin-dev
5 2017-11-21T00:48:36 *** dviola has quit IRC
6 2017-11-21T00:54:46 *** dabura667 has joined #bitcoin-dev
7 2017-11-21T01:04:33 *** esotericnonsense has quit IRC
8 2017-11-21T01:06:09 *** jb55 has quit IRC
9 2017-11-21T01:08:47 *** spritian has quit IRC
10 2017-11-21T01:13:05 *** Kedstar has quit IRC
11 2017-11-21T01:15:27 *** spritian has joined #bitcoin-dev
12 2017-11-21T01:24:24 *** gnubeard is now known as damons_is_away
13 2017-11-21T01:24:28 *** damons_is_away is now known as gnubeard
14 2017-11-21T01:33:42 *** Chris_Stewart_5 has joined #bitcoin-dev
15 2017-11-21T02:02:12 *** asdasd_ has quit IRC
16 2017-11-21T02:03:45 *** segy_ has joined #bitcoin-dev
17 2017-11-21T02:05:35 *** segy has quit IRC
18 2017-11-21T02:05:35 *** segy_ is now known as segy
19 2017-11-21T02:07:59 *** Chris_Stewart_5 has quit IRC
20 2017-11-21T02:16:02 *** bule has quit IRC
21 2017-11-21T02:16:23 *** bule has joined #bitcoin-dev
22 2017-11-21T02:19:50 *** o3u is now known as Fistful_of_coins
23 2017-11-21T02:26:49 *** Murch has quit IRC
24 2017-11-21T02:27:21 *** Chris_Stewart_5 has joined #bitcoin-dev
25 2017-11-21T02:35:39 *** agricocb has joined #bitcoin-dev
26 2017-11-21T02:40:28 *** dabura667 has quit IRC
27 2017-11-21T02:49:28 *** Chris_Stewart_5 has quit IRC
28 2017-11-21T02:50:23 *** StopAndDecrypt has quit IRC
29 2017-11-21T02:54:12 *** StopAndDecrypt has joined #bitcoin-dev
30 2017-11-21T03:05:58 *** Beef has quit IRC
31 2017-11-21T03:07:41 *** Beef has joined #bitcoin-dev
32 2017-11-21T03:10:26 *** bule has quit IRC
33 2017-11-21T03:10:58 *** bule has joined #bitcoin-dev
34 2017-11-21T03:14:31 *** subo_ has joined #bitcoin-dev
35 2017-11-21T03:18:25 *** subo has quit IRC
36 2017-11-21T03:24:17 *** Chris_Stewart_5 has joined #bitcoin-dev
37 2017-11-21T03:24:18 *** jb55 has joined #bitcoin-dev
38 2017-11-21T03:45:35 *** jb55 has quit IRC
39 2017-11-21T03:46:40 *** esotericnonsense has joined #bitcoin-dev
40 2017-11-21T03:53:22 *** Giszmo has quit IRC
41 2017-11-21T03:55:14 *** nakaluna has joined #bitcoin-dev
42 2017-11-21T04:23:51 *** l4ng1t has joined #bitcoin-dev
43 2017-11-21T04:35:21 *** one_zero has quit IRC
44 2017-11-21T04:43:24 *** bule has quit IRC
45 2017-11-21T04:43:49 *** bule has joined #bitcoin-dev
46 2017-11-21T04:48:10 *** Chris_Stewart_5 has quit IRC
47 2017-11-21T04:58:39 *** Belxjander has quit IRC
48 2017-11-21T05:03:57 *** Belxjander has joined #bitcoin-dev
49 2017-11-21T05:04:25 *** ula has quit IRC
50 2017-11-21T05:11:05 *** iv3c has quit IRC
51 2017-11-21T05:27:32 *** Belxjander has quit IRC
52 2017-11-21T05:31:57 *** justanotheruser has quit IRC
53 2017-11-21T05:33:23 *** Belxjander has joined #bitcoin-dev
54 2017-11-21T05:45:35 *** bule has quit IRC
55 2017-11-21T05:45:56 *** damons has joined #bitcoin-dev
56 2017-11-21T05:45:58 *** bule has joined #bitcoin-dev
57 2017-11-21T05:46:52 *** oleganza has joined #bitcoin-dev
58 2017-11-21T05:48:42 *** oleganza has quit IRC
59 2017-11-21T06:01:03 *** TheSeven has quit IRC
60 2017-11-21T06:01:23 *** TheSeven has joined #bitcoin-dev
61 2017-11-21T06:01:59 *** easye has joined #bitcoin-dev
62 2017-11-21T06:09:37 *** Belxjander has quit IRC
63 2017-11-21T06:10:08 *** Belxjander has joined #bitcoin-dev
64 2017-11-21T06:12:26 *** damons has quit IRC
65 2017-11-21T06:12:41 *** Michail1 has quit IRC
66 2017-11-21T06:13:50 *** Michail1 has joined #bitcoin-dev
67 2017-11-21T06:16:30 *** geezas has joined #bitcoin-dev
68 2017-11-21T06:23:01 *** l4ng1t has quit IRC
69 2017-11-21T06:25:41 *** wizkid057 has quit IRC
70 2017-11-21T06:26:17 *** Belxjander has quit IRC
71 2017-11-21T06:26:59 *** damons has joined #bitcoin-dev
72 2017-11-21T06:27:23 *** wizkid057 has joined #bitcoin-dev
73 2017-11-21T06:32:16 *** Belxjander has joined #bitcoin-dev
74 2017-11-21T06:43:48 <geezas> what are the rules on block timestamps?
75 2017-11-21T06:44:23 <geezas> other than timestamps need to be increasing in value
76 2017-11-21T06:45:00 *** bule has quit IRC
77 2017-11-21T06:45:05 <eck> https://en.bitcoin.it/wiki/Block_timestamp
78 2017-11-21T06: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
79 2017-11-21T06:45:51 <geezas> basically, what keeps reported block timestamps in sync with real time?
80 2017-11-21T06:45:55 <eck> and numerous other notes at https://en.bitcoin.it/wiki/Protocol_documentation
81 2017-11-21T06:45:57 <geezas> thanks for the link, reading now
82 2017-11-21T06:47:02 <eck> consider a node that is being bootstrapped, it is receiving block from the (distant) path
83 2017-11-21T06:47:04 <eck> *past
84 2017-11-21T06:47:33 <eck> in this case the freshness check on the timestamp only really applies to up-to-date nodes
85 2017-11-21T06:48:21 <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
86 2017-11-21T06:48:52 <geezas> ok, so from the first link, valid timestamp range is essentially loosely enforced by the network
87 2017-11-21T06:49:46 <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
88 2017-11-21T06:49:52 <geezas> is that really so? no external references
89 2017-11-21T06:50:18 <geezas> network time + 2 hours rule seems like an external reference
90 2017-11-21T06:50:46 <eck> yeah I am not an expert, this is what someone else (a core dev) told me
91 2017-11-21T06:50:52 <geezas> i mean, it says it's a median of all connected nodes
92 2017-11-21T06:51:01 <geezas> ok got it
93 2017-11-21T06:51:03 <eck> you could imagine though how you'd validate "new" blocks different from old blocks though
94 2017-11-21T06:51:25 <eck> i would love to be corrected by someone who knows better though
95 2017-11-21T06: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
96 2017-11-21T06:52:07 <eck> i think that's accurate
97 2017-11-21T06:52:25 <geezas> but the rule that prevents invalid timestamps way into the future relies on the network reported time
98 2017-11-21T06:52:39 *** justanotheruser has joined #bitcoin-dev
99 2017-11-21T06:52:41 <geezas> a decentralized external reference if you will
100 2017-11-21T06:53:20 <eck> have you read the original whitepaper?
101 2017-11-21T06:53:33 <geezas> yes
102 2017-11-21T06:53:35 <eck> it refers to the blockchain itself as a "timestamp server"
103 2017-11-21T06:53:38 <geezas> why?
104 2017-11-21T06:53:57 <eck> as i understand it, for precisely this reason
105 2017-11-21T06:54:02 <eck> to avoid the need to depend on external clocks
106 2017-11-21T06:54:33 <geezas> well...
107 2017-11-21T06:54:42 <eck> you provide a PoW problem, and use that to enforce time constraints
108 2017-11-21T06:54:57 *** BashCo_ has quit IRC
109 2017-11-21T06:55:32 <geezas> it's more like the network is assumed, on average, to report valid time (within some range)
110 2017-11-21T06:55:35 *** BashCo has joined #bitcoin-dev
111 2017-11-21T06:55:42 <eck> I think that's accurate
112 2017-11-21T06:55:59 <geezas> and because of that, once the block is found, it confirms the timestamp, just like the transactions
113 2017-11-21T06:55:59 <eck> if enough miners lied about the current time, they could get valid blocks in that wouldn't be valid according to (true time)
114 2017-11-21T06:56:03 *** POJO has joined #bitcoin-dev
115 2017-11-21T06:56:20 <geezas> so it serves as an immutable ledger as well as immutable timestamp chain
116 2017-11-21T06:56:27 <eck> to abuse this though, you would need a lot of mining nodes to lie
117 2017-11-21T06:56:41 <geezas> but the timestamps are only accurate to within a few hours
118 2017-11-21T06:57:07 <eck> again, as i understand it: the reason there are timestamps at all is for the difficulty adjustment
119 2017-11-21T06:57:18 <eck> the difficulty adjustment has a 10m target
120 2017-11-21T06:57:30 <geezas> I think you're right, it's definitely needed for DA
121 2017-11-21T06:57:33 <eck> therefore it needs to know the difference between the first block and the last block
122 2017-11-21T06:57:50 <geezas> the reason I'm looking into this now
123 2017-11-21T06:57:52 <eck> other than that, there is no need (AFAIK) for human-understandable time epochs
124 2017-11-21T06:58:14 <geezas> is because I was wondering if it would be possible to do ellapsed-time-scaled block size limits
125 2017-11-21T06:58:35 <eck> where you would rely on an external timestamp server?
126 2017-11-21T06:58:50 <geezas> this would allow for a lot more steady TX throughput without messing with difficulty adjustment algo
127 2017-11-21T06:59:18 <eck> who would you trust?
128 2017-11-21T06:59:55 <geezas> I'm not suggesting to trust some external timestamp server
129 2017-11-21T07:00:01 *** BashCo has quit IRC
130 2017-11-21T07:00:31 <geezas> but I'm interested to see if it's doable with the existing timekeeping methods
131 2017-11-21T07:00:43 <geezas> to preserve the same trust model
132 2017-11-21T07:01:00 <geezas> or consensus model I guess
133 2017-11-21T07:02:51 <geezas> eli5 of what I'm thinking of:
134 2017-11-21T07:03:26 * eck waits
135 2017-11-21T07: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
136 2017-11-21T07:04:10 <eck> how would you know the tlsb (time since last block)?
137 2017-11-21T07:04:13 <geezas> if block is found 20 minutes after last block, its size limit is double of the nominal 10 min rated block size
138 2017-11-21T07:05:08 <geezas> right, that's my question as well, but for that I needed to know how time is handled currently
139 2017-11-21T07:05:52 <geezas> I don't see why nodes couldn't keep track of current time accurately
140 2017-11-21T07:06:13 <eck> suppose you're a new node
141 2017-11-21T07:06:15 <geezas> assuming they could, they just calculate elapsed time as current time - time of last block
142 2017-11-21T07:06:20 <eck> and you're syncing from scratch
143 2017-11-21T07:06:29 <eck> how would it work then?
144 2017-11-21T07:07:06 <geezas> for syncing you'd just look at timestamp deltas between blocks
145 2017-11-21T07:07:15 <eck> right, that's what the current algo does
146 2017-11-21T07:07:22 <geezas> to determine if each block is within the size limit and therefore valid
147 2017-11-21T07: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
148 2017-11-21T07:08:09 <geezas> ts server?
149 2017-11-21T07:08:15 <eck> timestamp servedr
150 2017-11-21T07:08:39 <eck> seems like someone could trick me
151 2017-11-21T07:09:27 <geezas> isn't the same applies to the current system?
152 2017-11-21T07:09:48 <geezas> I mean, somebody would need to trick majority of the nodes, no?
153 2017-11-21T07:09:59 <eck> yes, for 11 blocks
154 2017-11-21T07:10:20 <eck> not impossible, but mining 11 blocks on your own would be quite a feat
155 2017-11-21T07: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
156 2017-11-21T07:12:20 <eck> you could trick me at <current time>, and i could follow your chain for a short time
157 2017-11-21T07: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
158 2017-11-21T07:12:37 <eck> if i'm a Real Merchant though, i require X confirmations
159 2017-11-21T07:12:55 *** l4ng1t has joined #bitcoin-dev
160 2017-11-21T07:12:58 <eck> so you'd have to trick me for X blocks to double-spend
161 2017-11-21T07:13:28 <Sentineo> interesting reading!
162 2017-11-21T07:13:55 <Sentineo> are all miners connected to fibre?
163 2017-11-21T07:14:01 <geezas> I think I need visualize better what we're talking about with concrete examples
164 2017-11-21T07:14:20 <eck> i think (hope) i can explain
165 2017-11-21T07:14:29 <Sentineo> eck: was reading your point about malicious miners with wrong time, if theh ate interconnected directly they can do it
166 2017-11-21T07:14:40 <Sentineo> but would the other part of tje network follow?
167 2017-11-21T07: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)
168 2017-11-21T07:15:02 <Sentineo> I think not ... - but might be wrong
169 2017-11-21T07:15:22 <geezas> right, my impression that correct timekeeping security model is that invalid times would not propagate through honest nodes
170 2017-11-21T07: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
171 2017-11-21T07:15:31 * Sentineo lets u guys finish your thoughts
172 2017-11-21T07:16:10 <Sentineo> geezas: that assumption is correct (block propagation)
173 2017-11-21T07:18:52 *** damons has quit IRC
174 2017-11-21T07:19:50 <geezas> eck, I still don't see how timestamp manipulation can allow for a possible double spend attack
175 2017-11-21T07:20:24 <geezas> that's somehow different from the one not involving timestamps
176 2017-11-21T07:20:37 <eck> geezas: i'd have to both manipulate the timestamp + build a long enough valid chain for you to follow it
177 2017-11-21T07:21:05 <geezas> right, so it seems it's still a pow-based attack
178 2017-11-21T07:21:09 <eck> which is different of course than just building the wrong chain in the first place (in terms of timestamp)
179 2017-11-21T07:21:15 <eck> yes
180 2017-11-21T07:21:30 <eck> the whole timestamp concept is built aroudn pow
181 2017-11-21T07:21:50 <geezas> I don't think so
182 2017-11-21T07:22:02 <eck> i might be wrong
183 2017-11-21T07:22:05 <geezas> timestamps are locked in with pow, but that's not what makes them valid
184 2017-11-21T07:22:19 <eck> go on
185 2017-11-21T07:22:47 <geezas> network consensus rules are used to enforce valid timestamps, otherwise, propagation is blocked
186 2017-11-21T07:23:01 <geezas> that's the mechanism that keeps timestamps valid
187 2017-11-21T07:23:09 <eck> maybe, or maybe the nodes are lyring
188 2017-11-21T07:23:13 <eck> *lying
189 2017-11-21T07:23:35 <geezas> that the timestamps get locked into the blockchain with pow after that is is another part of this
190 2017-11-21T07: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
191 2017-11-21T07:25:04 <Sentineo> nodes check the validity of a block
192 2017-11-21T07:25:11 <geezas> but what enforces upper limits on timestamps?
193 2017-11-21T07:25:22 <Sentineo> median time being in the correct range is one of them
194 2017-11-21T07:25:50 <eck> what upper limit?
195 2017-11-21T07:25:51 <geezas> it seems to me that's enforced by nodes keeping track of their own time
196 2017-11-21T07:25:53 <Sentineo> 20 mins in future is allowed max iirc
197 2017-11-21T07:26:19 <Sentineo> geezas: yes
198 2017-11-21T07:26:21 <geezas> so if a block is not mined for an hour, the timestamp still goes up by no more than 20 mins?
199 2017-11-21T07:26:43 <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
200 2017-11-21T07:27:16 <geezas> let's say ~94% of hash rate goes away for a day, we mine 1 block every 3h, 8 blocks in total
201 2017-11-21T07:27:20 <eck> ok
202 2017-11-21T07:27:24 <eck> with you so far
203 2017-11-21T07:27:26 <Sentineo> it can not be less than median time, no more than now + 20mins
204 2017-11-21T07:27:51 <geezas> would timestamps of each block increment by 10-20 mins or so?
205 2017-11-21T07:27:57 <Sentineo> where now is nodes curret time
206 2017-11-21T07:28:00 <eck> geezas: no
207 2017-11-21T07:28:50 <geezas> so in this scenario, what are valid ranges for the 8 blocks?
208 2017-11-21T07:29:08 <geezas> assume blocks were 10 mins apart before then and that timestamps were exact for those
209 2017-11-21T07:29:13 <eck> based on the median time of the last 11 blocks, same as any other node
210 2017-11-21T07: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"
211 2017-11-21T07:30:14 <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
212 2017-11-21T07:30:45 <geezas> now a new block is mined at 3am
213 2017-11-21T07:30:45 <eck> it could be arbitrarily long
214 2017-11-21T07:30:57 <geezas> what's the valid range for the timestamp of this block?
215 2017-11-21T07:31:09 <geezas> it must be greater than 11pm yesterday
216 2017-11-21T07:31:13 <eck> sure
217 2017-11-21T07:31:15 <geezas> what's the upper limit?
218 2017-11-21T07:31:25 <eck> so worst case, assume zombie apocalypse
219 2017-11-21T07:31:36 <geezas> a miner picks the timestamp, so what's the upper limit?
220 2017-11-21T07:31:45 <eck> in the zombie apocalypse case, i would lie
221 2017-11-21T07:32:01 <eck> upper limit is given by the median of the last 11 blocks
222 2017-11-21T07:32:09 <geezas> that's lower limit
223 2017-11-21T07:32:17 <eck> nah
224 2017-11-21T07:32:21 *** cornfeedhobo has quit IRC
225 2017-11-21T07:32:27 <geezas> in my mind time increases
226 2017-11-21T07:32:29 <eck> that's the lower acceptable limit
227 2017-11-21T07:32:33 <eck> not the lower limit
228 2017-11-21T07:33:03 <geezas> how about we use more specific terms, min and max instead of lower upper
229 2017-11-21T07:33:23 <geezas> my assumption that min timestamp value = median of last 11 blocks
230 2017-11-21T07:33:43 <geezas> you're saying it's not correct, right?
231 2017-11-21T07:33:49 <eck> one second
232 2017-11-21T07:33:52 <eck> let me rtfs
233 2017-11-21T07:34:36 *** dermoth has quit IRC
234 2017-11-21T07:35:10 <geezas> ha, ok, I will summarize how I understood that link about block timestamp
235 2017-11-21T07:35:37 <eck> as i understand the code, if you controlled many nodes to me, you could lie and i would be tricked
236 2017-11-21T07:35:43 <geezas> next block timestamp minimum allowed value = median of previous 11 blocks
237 2017-11-21T07:35:46 <eck> *connected to me
238 2017-11-21T07:36:02 <geezas> so minimum limit can't be tricked
239 2017-11-21T07:36:08 *** dermoth has joined #bitcoin-dev
240 2017-11-21T07:36:15 <eck> but i would detct if i waited long enough
241 2017-11-21T07:36:19 <geezas> as the source of that limit is pow-confirmed blocks
242 2017-11-21T07:36:30 *** ongolaBoy has joined #bitcoin-dev
243 2017-11-21T07:36:35 <Sentineo> eck: it does not sound right
244 2017-11-21T07:36:38 <eck> how manmy pow-confirmed blocks you accept is up to you
245 2017-11-21T07:36:41 <geezas> but the maximum limit comes from peer nodes
246 2017-11-21T07:36:53 *** qrest has quit IRC
247 2017-11-21T07:36:53 <Sentineo> if a ts is not ok, my full node rejects your block
248 2017-11-21T07:37:10 <geezas> eck, for timestamp, it's not up to you, it's median of 11 previous block timestamps
249 2017-11-21T07:37:17 <eck> right
250 2017-11-21T07: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
251 2017-11-21T07:38:03 <eck> i think that's right
252 2017-11-21T07:38:06 <geezas> but
253 2017-11-21T07:38:10 <geezas> for upper limit
254 2017-11-21T07:38:19 <geezas> it's what they call "Network-adjusted time"
255 2017-11-21T07:38:34 <eck> from first principles, every node should get to the same final state
256 2017-11-21T07:38:46 <eck> even if their individual clocks are different
257 2017-11-21T07:38:58 <geezas> if I understand it correctly, for the purpose of validating historical blocks, there is no limit
258 2017-11-21T07:39:26 <geezas> but for propagating new blocks, it's NAT (network-adjusted time) + 2 hours
259 2017-11-21T07:39:41 *** BashCo has joined #bitcoin-dev
260 2017-11-21T07:40:09 <eck> well
261 2017-11-21T07:40:22 <eck> old blocks should be treated same as new blocks
262 2017-11-21T07:40:35 <eck> how do you know if you're in old mode vs new mode?
263 2017-11-21T07:40:44 <geezas> right, that's where I'm interesting in understanding this better
264 2017-11-21T07:41:22 <eck> bingo
265 2017-11-21T07:42:28 <geezas> I think the network relies on the majority of nodes reporting correct current time, give or take
266 2017-11-21T07:42:39 <Sentineo> nodes syncing have a special state
267 2017-11-21T07:42:50 <Sentineo> forgot the name ibd I think
268 2017-11-21T07:42:59 <Sentineo> look for it in the debug.log
269 2017-11-21T07:43:09 <geezas> but for syncing, I wonder if there's an upper limit on valid timestamp, I don't think there is
270 2017-11-21T07:43:16 <eck> most nodes are connected to only 8 other nodes
271 2017-11-21T07:43:23 <eck> so it is pretty easy to trick them
272 2017-11-21T07:43:25 <Sentineo> and its activation deoends from the time
273 2017-11-21T07:44:05 <Sentineo> eck: they will accept the longest most proof of work chain and trust the tkmestamp
274 2017-11-21T07:44:42 <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)
275 2017-11-21T07:44:44 <Sentineo> the timestamp is really enforced by up to date nodes
276 2017-11-21T07:44:54 <Sentineo> not ibd ones
277 2017-11-21T07:44:59 <geezas> that would be a valid block, right?
278 2017-11-21T07:45:09 <Sentineo> geezas: yes
279 2017-11-21T07:45:43 <geezas> ok, makes sense, so there's no upper limit on timestamp delta between blocks
280 2017-11-21T07:45:58 <Sentineo> ah that is what you mean
281 2017-11-21T07:46:00 <geezas> other than current time + 2 hours
282 2017-11-21T07:46:02 <Sentineo> no there is not
283 2017-11-21T07:46:15 <Sentineo> right
284 2017-11-21T07:46:16 <geezas> which is enforced by majority nodes reporting correct current time
285 2017-11-21T07:46:18 <Sentineo> considerr
286 2017-11-21T07:46:27 <geezas> but for syncing it does not matter
287 2017-11-21T07:46:28 <Sentineo> 80% of hashpower disapears
288 2017-11-21T07:46:48 <Sentineo> 2016 blocks would take a loong time
289 2017-11-21T07:47:11 <Sentineo> you do not know how much in advance, so such rule would be problematic and not solve anything
290 2017-11-21T07:47:48 <geezas> Sentineo, I agree, I'm not considering such a rule, but somehow conversation with eck lead to that
291 2017-11-21T07:48:08 <geezas> initially he said that timestamps do not rely on any external clocks or time servers
292 2017-11-21T07:48:09 <Sentineo> yeas, agree
293 2017-11-21T07:48:25 <Sentineo> the external is important there
294 2017-11-21T07:48:42 <Sentineo> you can drop blocks just cause you have a bad clock
295 2017-11-21T07:49:03 <Sentineo> e.g. you stay in 2015
296 2017-11-21T07: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)
297 2017-11-21T07:49:20 <Sentineo> you would not get new blocks added to your chain
298 2017-11-21T07:49:22 <geezas> which is actually enforced by so called external system(s)
299 2017-11-21T07:49:42 <geezas> right
300 2017-11-21T07:50:10 <Sentineo> but it is external to the system (btc)
301 2017-11-21T07: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
302 2017-11-21T07:50:25 <Sentineo> not how eck ment it , and how I understand what he wrote
303 2017-11-21T07:50:29 <geezas> plus, that's assuming you don't have your own clock for sanity checking
304 2017-11-21T07:51:24 <geezas> so, now that I'm pretty clear on current workings of this
305 2017-11-21T07:51:35 <geezas> (thanks eck and Sentineo)
306 2017-11-21T07:52:14 *** dermoth has quit IRC
307 2017-11-21T07:52:19 <Sentineo> I will set my own clock to 2015
308 2017-11-21T07:52:26 <Sentineo> want to see the log messages ;)
309 2017-11-21T07:52:30 <Sentineo> never tried it
310 2017-11-21T07:52:39 *** dermoth has joined #bitcoin-dev
311 2017-11-21T07:52:40 <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
312 2017-11-21T07:53:05 <Sentineo> well you would see no increase in the way you described it
313 2017-11-21T07:53:08 <geezas> Sentineo, I think your node might be using NAT (network adjusted time)
314 2017-11-21T07:53:12 <Sentineo> but even it could decrease
315 2017-11-21T07:53:14 <geezas> not your system clock
316 2017-11-21T07:53:25 <geezas> from link, eck posted earlier: https://en.bitcoin.it/wiki/Block_timestamp
317 2017-11-21T07:53:28 <Sentineo> geezas: of course I would turn it off
318 2017-11-21T07:53:52 <geezas> oh, sorry, never ran a node, so I don't know how configurable it is
319 2017-11-21T07:54:08 <geezas> so you can turn off NAT, is what you're saying, right?
320 2017-11-21T07:54:25 <Sentineo> if u mean ntp, yes
321 2017-11-21T07:54:54 <geezas> what's ntp?
322 2017-11-21T07:55:31 <geezas> the link I just posted, it says: "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.
323 2017-11-21T07:56:04 <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.
324 2017-11-21T07:56:59 <Sentineo> well i am not sure if bitcoind will consider system time at all then
325 2017-11-21T07:57:07 <Sentineo> we will see
326 2017-11-21T07:57:08 <geezas> anyway, back to my inquiry about block size as a function of timestamp delta
327 2017-11-21T07:57:40 <Sentineo> cause if it does not, eck is right that miners can fool nodes (not how I thought it works)
328 2017-11-21T07:58:03 *** Belxjander has quit IRC
329 2017-11-21T07:58:21 <geezas> pause on my inquiry... how can miners fool nodes?
330 2017-11-21T07:58:43 <geezas> nodes report time to other nodes
331 2017-11-21T07:59:02 <Sentineo> they should not report, it requires trust
332 2017-11-21T07:59:16 *** Belxjander has joined #bitcoin-dev
333 2017-11-21T07:59:31 <Sentineo> but do not know
334 2017-11-21T07:59:42 *** fronti has left #bitcoin-dev
335 2017-11-21T07:59:48 <Sentineo> never tried ;)
336 2017-11-21T08:00:07 <geezas> right, but then it's not specifically miners than can fool nodes, but just nodes in general
337 2017-11-21T08: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
338 2017-11-21T08: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
339 2017-11-21T08:03:03 <Sentineo> reporting time means sending a block
340 2017-11-21T08:03:13 <Sentineo> blocks need PoW
341 2017-11-21T08:03:19 <Sentineo> so you need miners
342 2017-11-21T08:03:39 <geezas> whereas with NAT, only 50% + 1 malicious nodes is enough to trick a node into getting a wrong time
343 2017-11-21T08:03:54 <geezas> you don't need miners for NAT
344 2017-11-21T08:04:01 <geezas> which is then used to validate blocks
345 2017-11-21T08:04:06 <geezas> so here is an attack scenario
346 2017-11-21T08:04:14 *** qrestlove has joined #bitcoin-dev
347 2017-11-21T08:04:27 <Sentineo> how do I get NAT?
348 2017-11-21T08:04:39 <Sentineo> you think it is a protocol of some sort?
349 2017-11-21T08:04:45 <geezas> what do you mean by get?
350 2017-11-21T08:05:02 <geezas> sorry, I am going solely off of that definition from the link
351 2017-11-21T08:05:18 <geezas> I assume it's in the protocol
352 2017-11-21T08:05:47 <geezas> whether it's something the node software tells you I don't know
353 2017-11-21T08:05:48 <eck> geezas: how do you pick your peers in the NAT?
354 2017-11-21T08:05:52 <geezas> since I never ran a node
355 2017-11-21T08:06:37 <geezas> eck: it says it's the "median of the timestamps returned by all nodes connected to you"
356 2017-11-21T08:06:37 *** Mottengrotte has joined #bitcoin-dev
357 2017-11-21T08:06:45 <eck> alright
358 2017-11-21T08:06:53 <Sentineo> no
359 2017-11-21T08:06:57 <eck> maybe i'm a student a university X
360 2017-11-21T08:07:02 <Sentineo> for sure not
361 2017-11-21T08:07:05 <eck> and my peers in my dorm lie to me
362 2017-11-21T08:07:27 <eck> ideally, there is some way to get back onto the main chain
363 2017-11-21T08:07:29 <eck> even if they lie to me
364 2017-11-21T08:07:32 <Sentineo> you should count stuff from blocks, not from messages from peers
365 2017-11-21T08:07:50 <eck> right
366 2017-11-21T08:08:11 <geezas> Sentineo, yes and no
367 2017-11-21T08:08:42 <geezas> if you're syncing, and you're currently at last year block
368 2017-11-21T08:08:59 <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
369 2017-11-21T08:09:03 <geezas> if peers report to you that current time is 2017 January
370 2017-11-21T08:09:36 <geezas> how do you know that 2017 January is invalid reported time? blocks wont help you here
371 2017-11-21T08:09:38 <Sentineo> geezas: we afe not syncing
372 2017-11-21T08:09:40 <eck> the timestamp is in the block
373 2017-11-21T08:09:45 <eck> not in what peers tell you
374 2017-11-21T08:09:54 <Sentineo> exactlt
375 2017-11-21T08:09:57 <eck> it's part of the block header
376 2017-11-21T08:09:58 <Sentineo> eck has the point
377 2017-11-21T08:09:59 *** one_zero has joined #bitcoin-dev
378 2017-11-21T08:10:10 <Sentineo> you trust the BLOCK, as it is backed by PoW
379 2017-11-21T08:10:33 <Sentineo> not a peer and some time message from it (there is no such message type iirc)
380 2017-11-21T08:10:43 <geezas> yes but your lets say the latest block you synced is from last year
381 2017-11-21T08:10:49 <geezas> because you're not done syncing
382 2017-11-21T08:10:50 <eck> ok
383 2017-11-21T08:11:26 <geezas> the timestamp on the latest block you synced says lets say 2016 December something
384 2017-11-21T08:11:35 <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
385 2017-11-21T08:11:49 <eck> which am i going to follow?
386 2017-11-21T08:12:11 <geezas> eck, not sure what you're talking about, there are no sidechains or alternative chains
387 2017-11-21T08:12:13 <Sentineo> you care about the work in the chain
388 2017-11-21T08:12:16 <geezas> just the main chain for now
389 2017-11-21T08:12:36 <Sentineo> geezas: there are, you implicitly have 2 if you are talking about an attack
390 2017-11-21T08:12:49 <eck> geezas: we're discussing how a node would trick the network, which implies the node double-spends
391 2017-11-21T08:12:59 <Sentineo> right
392 2017-11-21T08:13:00 <eck> if not a double spending attack, what are you worrried about?
393 2017-11-21T08:13:03 <geezas> I'm not talking about an attack where false blocks are given to you
394 2017-11-21T08:13:13 <geezas> at least not at this point
395 2017-11-21T08:13:24 <Sentineo> ok, try again ;)
396 2017-11-21T08:13:40 <geezas> ok, so I'm a new node
397 2017-11-21T08:13:45 <geezas> I start syncing to the main chain
398 2017-11-21T08:13:50 <eck> alright
399 2017-11-21T08:14:18 <geezas> I'm being given blocks that follow whatever my latest block I've synced is
400 2017-11-21T08:14:23 <eck> ok
401 2017-11-21T08:14:32 <geezas> so I start and get block 1 then 2 then 3 etc
402 2017-11-21T08:14:50 <geezas> so I reach block whatever, let's say 100000
403 2017-11-21T08:15:14 <geezas> and lets say timestamp on that block is 2016 December whatever
404 2017-11-21T08:15:18 *** one_zero has quit IRC
405 2017-11-21T08:15:19 <eck> ok
406 2017-11-21T08:16:07 <geezas> I'm connected to 21 nodes, 11 are malicious and are reporting current time as 2017 January 5
407 2017-11-21T08:16:36 <geezas> so I will keep syncing until I reach a block with timestamp 2017 January 5 + 2 hours
408 2017-11-21T08:16:47 <geezas> after which, I will thing I'm getting blocks which are in the future and thus invalid
409 2017-11-21T08:16:56 <geezas> so I will start rejecting those
410 2017-11-21T08:17:07 <geezas> and think I'm done syncing
411 2017-11-21T08:17:12 <eck> i haved not rtfs, but i believe what happens is you see two chains
412 2017-11-21T08:17:13 <geezas> since I'm not getting any more valid blocks
413 2017-11-21T08:17:23 <geezas> there are no two chains
414 2017-11-21T08:17:27 <geezas> it's still one chain
415 2017-11-21T08:17:29 <eck> why not
416 2017-11-21T08:17:40 <geezas> where is the 2nd chain you're speaking of?
417 2017-11-21T08:17:42 <eck> syncing != 1 chain
418 2017-11-21T08:17:58 <geezas> all blocks are referencing each other in one chain
419 2017-11-21T08:18:01 <Sentineo> geezas: you are not correct if you assume nodes are reporgint time, they are not
420 2017-11-21T08:18:02 <eck> sure
421 2017-11-21T08:18:16 <eck> each block references the hash of the previous block
422 2017-11-21T08:18:22 <geezas> Sentineo, maybe that's true, but that's not what bitcoin wiki says about it
423 2017-11-21T08:18:29 <Sentineo> geezas: nodes send you blocks, and those have timestamps ... so sending different time means you send an alternative chain (different blocks)
424 2017-11-21T08:18:35 <eck> or more accurately, its merkle root
425 2017-11-21T08:18:50 <Sentineo> geezas: bitcoin wiki has like 7 sentences, you want to analyse a protocol based on that?
426 2017-11-21T08:18:56 <eck> so as a new syncing node, i see we all agree up to block X
427 2017-11-21T08:19:06 <eck> after block X, i see two new possible merkle roots
428 2017-11-21T08:19:13 <Sentineo> no no
429 2017-11-21T08:19:14 <eck> i follow the one with the most pow behind it
430 2017-11-21T08:19:16 <Sentineo> merkle root is for txes
431 2017-11-21T08:19:27 <geezas> eck, merkle roots are not related to this
432 2017-11-21T08:19:28 <eck> the merkle root is in the block header
433 2017-11-21T08:19:34 <Sentineo> block header's hash is used in the blocks
434 2017-11-21T08:19:38 <eck> it references the previous block
435 2017-11-21T08:19:52 <Sentineo> eck: not merkle root references the txes in the current block
436 2017-11-21T08:19:58 <Sentineo> and you are right they are in the block header
437 2017-11-21T08:20:04 <geezas> right, so here's the simplified block chain: A -> B -> C -> D -> E (current)
438 2017-11-21T08:20:05 <Sentineo> there is a previous block header field in the header
439 2017-11-21T08:20:06 <eck> if i mine block X, how do i know which block is X-1?
440 2017-11-21T08:20:22 <geezas> eck: each block references previous block
441 2017-11-21T08:20:25 <eck> right
442 2017-11-21T08:20:36 <geezas> so let me redo me diagram: A <- B <- C <- D <- E (current)
443 2017-11-21T08: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
444 2017-11-21T08:21:04 <eck> more accurately, the block header has merkle root (this block) + merkel root (prev block) + other stuff (e.g. version bits)
445 2017-11-21T08:21:32 <Sentineo> eck: no :)
446 2017-11-21T08:21:44 <eck> alright
447 2017-11-21T08:21:47 <eck> enlighten me
448 2017-11-21T08:21:56 <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
449 2017-11-21T08:22:18 <Sentineo> eck: look at https://bitcoin.org/en/developer-reference#block-headers
450 2017-11-21T08:22:38 <eck> Sentineo: which part did i get wrong?
451 2017-11-21T08:22:49 <Sentineo> eck: you have two 256 bit fields in the header, one for merkle root, the other for previous block hash
452 2017-11-21T08:22:58 <Sentineo> eck: you sounded like you say they are the same
453 2017-11-21T08: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
454 2017-11-21T08:23:17 <Sentineo> geezas: you are not given NAT man ...
455 2017-11-21T08:24:14 <geezas> Sentineo, either documentation is correct or it's not, which is it?
456 2017-11-21T08:24:33 <Sentineo> it is the user who is interpreting words incorectly
457 2017-11-21T08:24:38 <Sentineo> you write as
458 2017-11-21T08:24:44 <Sentineo> if NAT was a protocol or something
459 2017-11-21T08:24:48 <Sentineo> it is just a concept
460 2017-11-21T08:25:42 <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 ... :)
461 2017-11-21T08:26:51 <geezas> well, it sure sounds like protocol is being described
462 2017-11-21T08:27:07 <geezas> it explicitly says what is considered a valid timestamp (of a block)
463 2017-11-21T08:27:37 *** one_zero has joined #bitcoin-dev
464 2017-11-21T08:27:46 <geezas> it says it must be greater than median of last 11 timestamps and less than n.a.t.
465 2017-11-21T08:27:59 <Sentineo> you can spin up a node, use tcpdump or wireshark to capture the messages between them
466 2017-11-21T08:28:07 <Sentineo> and tell me there you see a NAT message
467 2017-11-21T08:28:07 <geezas> I presume if timestamp is invalid, the block is considered invalid
468 2017-11-21T08:28:31 <Sentineo> nat is calculated from a block, not from a message from a peer
469 2017-11-21T08:28:31 <geezas> there does not need to be a nat message
470 2017-11-21T08:28:37 <Sentineo> and that makes the whole difference
471 2017-11-21T08:28:45 <geezas> is there ever a timestamp when communicating with nodes?
472 2017-11-21T08:28:55 <geezas> that's enough to get a timestamp from a node
473 2017-11-21T08:29:02 <Sentineo> from your assumptions it sounds like you think there is a separate message and you get time from peers
474 2017-11-21T08:29:10 <Sentineo> geezas: no there is not
475 2017-11-21T08:29:17 <geezas> then "NAT" is calculated internally, by taking a median of all timestamps, one from each node
476 2017-11-21T08:29:58 <geezas> so what does "timestamps returned by all nodes connected to you" phrase mean?
477 2017-11-21T08:32:45 <Sentineo> internaly from blocks you have
478 2017-11-21T08:32:59 <Sentineo> from the blocks they send
479 2017-11-21T08:33:16 <Sentineo> you have no way of knowing you are on the valid chain
480 2017-11-21T08:33:26 <Sentineo> e.g. if your node goes off
481 2017-11-21T08:33:37 *** damons has joined #bitcoin-dev
482 2017-11-21T08:33:37 <Sentineo> and comes back 2 hours later and there is no new block since
483 2017-11-21T08:33:47 <Sentineo> you see the progress indicator as 0.9999 something, not 1
484 2017-11-21T08:34:00 <Sentineo> as it does not know if it is out of sync, or just there was no new block
485 2017-11-21T08:34:06 <Sentineo> it will know once a new blocks gets to it
486 2017-11-21T08:36:33 *** JackH has quit IRC
487 2017-11-21T08:53:53 *** l4ng1t has quit IRC
488 2017-11-21T08:54:54 <geezas> Sentineo
489 2017-11-21T08:55:47 <geezas> so what happens if a miner mines a block with a timestamp that's dated 30 days into the future?
490 2017-11-21T08:56:15 <geezas> by your explanation, it would be a perfectly valid block and all nodes would accept it as the next block
491 2017-11-21T09:02:09 <Sentineo> no they would not
492 2017-11-21T09:02:18 <Sentineo> as they check the blocks timestamp to their time
493 2017-11-21T09:02:30 <Sentineo> in case they are synced of course
494 2017-11-21T09:02:47 *** l4ng1t has joined #bitcoin-dev
495 2017-11-21T09:12:06 *** dermoth has quit IRC
496 2017-11-21T09:12:30 *** dermoth has joined #bitcoin-dev
497 2017-11-21T09:17:33 *** txter has joined #bitcoin-dev
498 2017-11-21T09:18:32 *** czaanja_ has joined #bitcoin-dev
499 2017-11-21T09:22:21 *** stiell has quit IRC
500 2017-11-21T09:23:47 *** stiell has joined #bitcoin-dev
501 2017-11-21T09:28:30 *** Belxjander has quit IRC
502 2017-11-21T09:35:03 *** Belxjander has joined #bitcoin-dev
503 2017-11-21T09:42:13 *** one_zero has quit IRC
504 2017-11-21T10:11:43 *** Belxjander has quit IRC
505 2017-11-21T10:13:54 *** sdfgsdfg has joined #bitcoin-dev
506 2017-11-21T10:14:30 *** Belxjander has joined #bitcoin-dev
507 2017-11-21T10:22:05 *** dermoth has quit IRC
508 2017-11-21T10:23:43 *** dermoth has joined #bitcoin-dev
509 2017-11-21T10:23:51 *** dermoth has quit IRC
510 2017-11-21T10:24:15 *** dermoth has joined #bitcoin-dev
511 2017-11-21T10:38:17 *** pergaminho has joined #bitcoin-dev
512 2017-11-21T11:04:14 *** Cogito_Ergo_Sum has joined #bitcoin-dev
513 2017-11-21T11:09:08 *** l4ng1t has quit IRC
514 2017-11-21T11:18:19 <cluelessperson> Would someone who's been around be able to help me with some media and opinions?
515 2017-11-21T11:29:37 *** POJO has quit IRC
516 2017-11-21T11:51:38 *** dviola has joined #bitcoin-dev
517 2017-11-21T11:54:09 *** jtimon has quit IRC
518 2017-11-21T12:15:18 *** POJO has joined #bitcoin-dev
519 2017-11-21T12:49:54 *** SopaXorzTaker has joined #bitcoin-dev
520 2017-11-21T12:53:56 *** contrapumpkin has quit IRC
521 2017-11-21T12:54:57 *** contrapumpkin has joined #bitcoin-dev
522 2017-11-21T13:00:14 *** ghost43 has quit IRC
523 2017-11-21T13:00:50 *** Chris_Stewart_5 has joined #bitcoin-dev
524 2017-11-21T13:02:31 *** ghost43 has joined #bitcoin-dev
525 2017-11-21T13:06:53 *** StopAndDecrypt has quit IRC
526 2017-11-21T13:07:11 *** StopAndDecrypt_ has joined #bitcoin-dev
527 2017-11-21T13:26:41 *** |Clown| is now known as Guest23471
528 2017-11-21T13:26:43 *** |Clown| has joined #bitcoin-dev
529 2017-11-21T13:33:27 *** Giszmo has joined #bitcoin-dev
530 2017-11-21T13:41:16 *** iv3c has joined #bitcoin-dev
531 2017-11-21T13:43:49 *** nakaluna has quit IRC
532 2017-11-21T13:58:38 *** Cogito_Ergo_Sum has quit IRC
533 2017-11-21T14:02:04 *** Chris_Stewart_5 has quit IRC
534 2017-11-21T14:03:03 *** meshcollider has quit IRC
535 2017-11-21T14:33:55 *** Guyver2 has joined #bitcoin-dev
536 2017-11-21T14:44:17 *** POJO has quit IRC
537 2017-11-21T14:48:54 *** Cogito_Ergo_Sum has joined #bitcoin-dev
538 2017-11-21T14:55:01 *** Chris_Stewart_5 has joined #bitcoin-dev
539 2017-11-21T15:07:32 *** satwo has quit IRC
540 2017-11-21T15:08:03 *** contrapumpkin has quit IRC
541 2017-11-21T15:08:31 *** contrapumpkin has joined #bitcoin-dev
542 2017-11-21T15:18:30 *** satwo has joined #bitcoin-dev
543 2017-11-21T15:24:07 *** POJO has joined #bitcoin-dev
544 2017-11-21T15:53:51 *** hkjn0 has joined #bitcoin-dev
545 2017-11-21T16:00:04 <hkjn0> hey, I have my node running with txindex=1 and restarted with -reindex, but I still get "no such transaction" from getrawtransaction calls..
546 2017-11-21T16:00:21 <hkjn0> I guess the reindexing is still going? can I check the status of reindexing with some RPC?
547 2017-11-21T16: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
548 2017-11-21T16:21:44 *** cornfeedhobo has joined #bitcoin-dev
549 2017-11-21T16:24:37 *** geezas has quit IRC
550 2017-11-21T16:27:52 *** bule has joined #bitcoin-dev
551 2017-11-21T16:38:29 *** Dizzle has joined #bitcoin-dev
552 2017-11-21T16:39:23 *** iv3c has quit IRC
553 2017-11-21T16:39:43 *** iv3c has joined #bitcoin-dev
554 2017-11-21T16:40:36 *** dviola has quit IRC
555 2017-11-21T16:42:58 *** hidden has joined #bitcoin-dev
556 2017-11-21T16:43:11 <hidden> 2017-11-21 11:14:34 [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE].
557 2017-11-21T16:43:11 <hidden> 2017-11-21 12:20:28 No coin database inconsistencies in last 7 blocks (13599 transactions)
558 2017-11-21T16:43:11 <hidden> 2017-11-21 12:20:28 block index 4051611ms
559 2017-11-21T16:43:11 <hidden> 2017-11-21 12:20:28 init message: Loading wallet...
560 2017-11-21T16:43:11 <hidden> 2017-11-21 12:20:28 nFileVersion = 32400
561 2017-11-21T16:43:12 <hidden> 2017-11-21 12:20:28 Keys: 102 plaintext, 0 encrypted, 0 w/ metadata, 102 total
562 2017-11-21T16:43:14 <hidden> 2017-11-21 12:20:28 wallet 65ms
563 2017-11-21T16:43:16 <hidden> 2017-11-21 12:20:28
564 2017-11-21T16:43:18 <hidden> ************************
565 2017-11-21T16:43:20 <hidden> EXCEPTION: St13runtime_error
566 2017-11-21T16:43:22 <hidden> GenerateNewKey: AddKey failed
567 2017-11-21T16:43:24 <hidden> C:\Program Files\Bitcoin\bitcoin-qt.exe in Runaway exception
568 2017-11-21T16:43:28 <hidden> 2017-11-21 16:34:08 CDBEnv::EnvShutdown: Error -30974 shutting down database environment: DB_RUNRECOVERY: Fatal error, run database recovery
569 2017-11-21T16:44:56 *** jtimon has joined #bitcoin-dev
570 2017-11-21T16:53:43 *** ula has joined #bitcoin-dev
571 2017-11-21T16:53:54 *** dviola has joined #bitcoin-dev
572 2017-11-21T17:06:39 *** Mottengrotte has quit IRC
573 2017-11-21T17:10:33 *** BashCo has quit IRC
574 2017-11-21T17:11:08 *** BashCo has joined #bitcoin-dev
575 2017-11-21T17:15:37 *** BashCo has quit IRC
576 2017-11-21T17:19:12 *** Skirmant has quit IRC
577 2017-11-21T17:19:56 *** ongolaBoy has quit IRC
578 2017-11-21T17:34:15 *** BashCo has joined #bitcoin-dev
579 2017-11-21T17:42:56 *** StopAndDecrypt_ has quit IRC
580 2017-11-21T17:45:11 *** hidden has quit IRC
581 2017-11-21T17:59:15 *** photonclock_ has quit IRC
582 2017-11-21T18:17:48 *** contrapumpkin has quit IRC
583 2017-11-21T18:17:53 *** iv3c has quit IRC
584 2017-11-21T18:18:13 *** iv3c has joined #bitcoin-dev
585 2017-11-21T18:18:44 *** contrapumpkin has joined #bitcoin-dev
586 2017-11-21T18:19:14 *** dqx has joined #bitcoin-dev
587 2017-11-21T18:19:59 *** dqx has quit IRC
588 2017-11-21T18:20:07 *** PaulCapestany has quit IRC
589 2017-11-21T18:23:13 *** PaulCapestany has joined #bitcoin-dev
590 2017-11-21T18:24:45 *** iv3c has quit IRC
591 2017-11-21T18:25:45 *** iv3c has joined #bitcoin-dev
592 2017-11-21T18:27:57 *** dqx has joined #bitcoin-dev
593 2017-11-21T18:45:01 *** ThomasV has joined #bitcoin-dev
594 2017-11-21T18:53:26 *** jb55 has joined #bitcoin-dev
595 2017-11-21T18:58:44 *** dviola has quit IRC
596 2017-11-21T19:05:13 *** StopAndDecrypt has joined #bitcoin-dev
597 2017-11-21T19:08:48 *** bule has quit IRC
598 2017-11-21T19:09:25 *** bule has joined #bitcoin-dev
599 2017-11-21T19:16:11 *** Belxjander has quit IRC
600 2017-11-21T19:20:57 *** ThomasV has quit IRC
601 2017-11-21T19:22:14 *** Belxjander has joined #bitcoin-dev
602 2017-11-21T19:22:44 *** SopaXorzTaker has quit IRC
603 2017-11-21T19:24:09 *** Skirmant has joined #bitcoin-dev
604 2017-11-21T19:28:19 *** pergaminho has quit IRC
605 2017-11-21T19:30:35 *** jb55 has quit IRC
606 2017-11-21T19:41:36 *** satwo has quit IRC
607 2017-11-21T19:49:51 *** Skirmant has quit IRC
608 2017-11-21T19:59:27 *** dcousens has quit IRC
609 2017-11-21T20:00:42 *** dcousens has joined #bitcoin-dev
610 2017-11-21T20:00:56 *** test123456 has joined #bitcoin-dev
611 2017-11-21T20:05:46 *** meshcollider has joined #bitcoin-dev
612 2017-11-21T20:06:57 *** czaanja_ has quit IRC
613 2017-11-21T20:11:00 *** dqx has quit IRC
614 2017-11-21T20:15:32 *** fullstep has joined #bitcoin-dev
615 2017-11-21T20:17:42 *** Chris_Stewart_5 has quit IRC
616 2017-11-21T20:29:53 *** POJO has quit IRC
617 2017-11-21T20:33:36 <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?
618 2017-11-21T20:35:36 *** satwo has joined #bitcoin-dev
619 2017-11-21T20:43:33 *** Skirmant has joined #bitcoin-dev
620 2017-11-21T21:00:07 *** jb55 has joined #bitcoin-dev
621 2017-11-21T21:00:13 *** test123456 has quit IRC
622 2017-11-21T21:00:26 *** jb55 has quit IRC
623 2017-11-21T21:09:07 *** dviola has joined #bitcoin-dev
624 2017-11-21T21:16:57 *** instagibbs has joined #bitcoin-dev
625 2017-11-21T21:17:11 *** jb55 has joined #bitcoin-dev
626 2017-11-21T21:20:22 *** iv3c has quit IRC
627 2017-11-21T21:20:42 *** iv3c has joined #bitcoin-dev
628 2017-11-21T21:26:25 *** jb55 has quit IRC
629 2017-11-21T21:29:03 <eck> it's unsigned
630 2017-11-21T21:29:41 <eck> https://en.bitcoin.it/wiki/Block_timestamp
631 2017-11-21T21:31:12 *** jtimon has quit IRC
632 2017-11-21T21:36:40 *** sh_smith has quit IRC
633 2017-11-21T21:37:53 *** ula has quit IRC
634 2017-11-21T21:38:20 *** sh_smith has joined #bitcoin-dev
635 2017-11-21T21:39:26 *** rundom has joined #bitcoin-dev
636 2017-11-21T22:00:43 *** Guyver2 has quit IRC
637 2017-11-21T22:01:35 *** Belxjander has quit IRC
638 2017-11-21T22:02:15 *** rundom has quit IRC
639 2017-11-21T22:02:35 *** jtimon has joined #bitcoin-dev
640 2017-11-21T22:07:07 *** one_zero has joined #bitcoin-dev
641 2017-11-21T22:08:35 *** Belxjander has joined #bitcoin-dev
642 2017-11-21T22:15:21 *** meshcollider has quit IRC
643 2017-11-21T22:22:41 *** ingenius is now known as mariano
644 2017-11-21T22:23:27 *** mariano is now known as ingenius
645 2017-11-21T22:24:49 *** meshcollider has joined #bitcoin-dev
646 2017-11-21T22:32:25 *** ThomasV has joined #bitcoin-dev
647 2017-11-21T22:35:24 *** Chris_Stewart_5 has joined #bitcoin-dev
648 2017-11-21T22:39:08 *** arubi has quit IRC
649 2017-11-21T22:40:00 *** Anduck has quit IRC
650 2017-11-21T22:40:35 *** Anduck has joined #bitcoin-dev
651 2017-11-21T22:42:00 *** masterjack has joined #bitcoin-dev
652 2017-11-21T22:45:10 *** Dizzle has quit IRC
653 2017-11-21T22:53:50 *** masterjack has quit IRC
654 2017-11-21T22:55:02 *** CheckDavid has quit IRC
655 2017-11-21T23:10:27 *** ThomasV has quit IRC
656 2017-11-21T23:12:24 *** txter has quit IRC
657 2017-11-21T23:27:54 *** Cogito_Ergo_Sum has quit IRC
658 2017-11-21T23:33:30 *** tknp has joined #bitcoin-dev
659 2017-11-21T23:37:38 *** chjj has quit IRC
660 2017-11-21T23:39:08 *** Chris_Stewart_5 has quit IRC
661 2017-11-21T23:40:46 *** wxss has quit IRC
662 2017-11-21T23:53:43 *** damons has quit IRC
663 2017-11-21T23:55:11 *** damons has joined #bitcoin-dev