Transcript for #bitcoin-dev 2017/11/21

06:43 geezas what are the rules on block timestamps?
06:44 geezas other than timestamps need to be increasing in value
06:45 eck https://en.bitcoin.it/wiki/Block_timestamp
06:45 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
06:45 geezas basically, what keeps reported block timestamps in sync with real time?
06:45 eck and numerous other notes at https://en.bitcoin.it/wiki/Protocol_documentation
06:45 geezas thanks for the link, reading now
06:47 eck consider a node that is being bootstrapped, it is receiving block from the (distant) path
06:47 eck *past
06:47 eck in this case the freshness check on the timestamp only really applies to up-to-date nodes
06:48 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
06:48 geezas ok, so from the first link, valid timestamp range is essentially loosely enforced by the network
06:49 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
06:49 geezas is that really so? no external references
06:50 geezas network time + 2 hours rule seems like an external reference
06:50 eck yeah I am not an expert, this is what someone else (a core dev) told me
06:50 geezas i mean, it says it's a median of all connected nodes
06:51 geezas ok got it
06:51 eck you could imagine though how you'd validate "new" blocks different from old blocks though
06:51 eck i would love to be corrected by someone who knows better though
06:51 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
06:52 eck i think that's accurate
06:52 geezas but the rule that prevents invalid timestamps way into the future relies on the network reported time
06:52 geezas a decentralized external reference if you will
06:53 eck have you read the original whitepaper?
06:53 geezas yes
06:53 eck it refers to the blockchain itself as a "timestamp server"
06:53 geezas why?
06:53 eck as i understand it, for precisely this reason
06:54 eck to avoid the need to depend on external clocks
06:54 geezas well...
06:54 eck you provide a PoW problem, and use that to enforce time constraints
06:55 geezas it's more like the network is assumed, on average, to report valid time (within some range)
06:55 eck I think that's accurate
06:55 geezas and because of that, once the block is found, it confirms the timestamp, just like the transactions
06:56 eck if enough miners lied about the current time, they could get valid blocks in that wouldn't be valid according to (true time)
06:56 geezas so it serves as an immutable ledger as well as immutable timestamp chain
06:56 eck to abuse this though, you would need a lot of mining nodes to lie
06:56 geezas but the timestamps are only accurate to within a few hours
06:57 eck again, as i understand it: the reason there are timestamps at all is for the difficulty adjustment
06:57 eck the difficulty adjustment has a 10m target
06:57 geezas I think you're right, it's definitely needed for DA
06:57 eck therefore it needs to know the difference between the first block and the last block
06:57 geezas the reason I'm looking into this now
06:57 eck other than that, there is no need (AFAIK) for human-understandable time epochs
06:58 geezas is because I was wondering if it would be possible to do ellapsed-time-scaled block size limits
06:58 eck where you would rely on an external timestamp server?
06:58 geezas this would allow for a lot more steady TX throughput without messing with difficulty adjustment algo
06:59 eck who would you trust?
06:59 geezas I'm not suggesting to trust some external timestamp server
07:00 geezas but I'm interested to see if it's doable with the existing timekeeping methods
07:00 geezas to preserve the same trust model
07:01 geezas or consensus model I guess
07:02 geezas eli5 of what I'm thinking of:
07:03 geezas if block is found 5 minutes after last block, its size limit is half of the nominal 10 min rated block size limit
07:04 eck how would you know the tlsb (time since last block)?
07:04 geezas if block is found 20 minutes after last block, its size limit is double of the nominal 10 min rated block size
07:05 geezas right, that's my question as well, but for that I needed to know how time is handled currently
07:05 geezas I don't see why nodes couldn't keep track of current time accurately
07:06 eck suppose you're a new node
07:06 geezas assuming they could, they just calculate elapsed time as current time - time of last block
07:06 eck and you're syncing from scratch
07:06 eck how would it work then?
07:07 geezas for syncing you'd just look at timestamp deltas between blocks
07:07 eck right, that's what the current algo does
07:07 geezas to determine if each block is within the size limit and therefore valid
07:07 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
07:08 geezas ts server?
07:08 eck timestamp servedr
07:08 eck seems like someone could trick me
07:09 geezas isn't the same applies to the current system?
07:09 geezas I mean, somebody would need to trick majority of the nodes, no?
07:09 eck yes, for 11 blocks
07:10 eck not impossible, but mining 11 blocks on your own would be quite a feat
07:11 geezas how's mining blocks related to that, I though the tricking part was about somehow making a node get a wrong system time
07:12 eck you could trick me at <current time>, and i could follow your chain for a short time
07:12 geezas I'm probably less in touch with this subject than you, so forgive me if we might not be on the same page
07:12 eck if i'm a Real Merchant though, i require X confirmations
07:12 eck so you'd have to trick me for X blocks to double-spend
07:13 Sentineo interesting reading!
07:13 Sentineo are all miners connected to fibre?
07:14 geezas I think I need visualize better what we're talking about with concrete examples
07:14 eck i think (hope) i can explain
07:14 Sentineo eck: was reading your point about malicious miners with wrong time, if theh ate interconnected directly they can do it
07:14 Sentineo but would the other part of tje network follow?
07:14 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)
07:15 Sentineo I think not ... - but might be wrong
07:15 geezas right, my impression that correct timekeeping security model is that invalid times would not propagate through honest nodes
07:15 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
07:16 Sentineo geezas: that assumption is correct (block propagation)
07:19 geezas eck, I still don't see how timestamp manipulation can allow for a possible double spend attack
07:20 geezas that's somehow different from the one not involving timestamps
07:20 eck geezas: i'd have to both manipulate the timestamp + build a long enough valid chain for you to follow it
07:21 geezas right, so it seems it's still a pow-based attack
07:21 eck which is different of course than just building the wrong chain in the first place (in terms of timestamp)
07:21 eck yes
07:21 eck the whole timestamp concept is built aroudn pow
07:21 geezas I don't think so
07:22 eck i might be wrong
07:22 geezas timestamps are locked in with pow, but that's not what makes them valid
07:22 eck go on
07:22 geezas network consensus rules are used to enforce valid timestamps, otherwise, propagation is blocked
07:23 geezas that's the mechanism that keeps timestamps valid
07:23 eck maybe, or maybe the nodes are lyring
07:23 eck *lying
07:23 geezas that the timestamps get locked into the blockchain with pow after that is is another part of this
07:24 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
07:25 Sentineo nodes check the validity of a block
07:25 geezas but what enforces upper limits on timestamps?
07:25 Sentineo median time being in the correct range is one of them
07:25 eck what upper limit?
07:25 geezas it seems to me that's enforced by nodes keeping track of their own time
07:25 Sentineo 20 mins in future is allowed max iirc
07:26 Sentineo geezas: yes
07:26 geezas so if a block is not mined for an hour, the timestamp still goes up by no more than 20 mins?
07:26 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
07:27 geezas let's say ~94% of hash rate goes away for a day, we mine 1 block every 3h, 8 blocks in total
07:27 eck ok
07:27 eck with you so far
07:27 Sentineo it can not be less than median time, no more than now + 20mins
07:27 geezas would timestamps of each block increment by 10-20 mins or so?
07:27 Sentineo where now is nodes curret time
07:28 eck geezas: no
07:28 geezas so in this scenario, what are valid ranges for the 8 blocks?
07:29 geezas assume blocks were 10 mins apart before then and that timestamps were exact for those
07:29 eck based on the median time of the last 11 blocks, same as any other node
07:30 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"
07:30 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
07:30 geezas now a new block is mined at 3am
07:30 eck it could be arbitrarily long
07:30 geezas what's the valid range for the timestamp of this block?
07:31 geezas it must be greater than 11pm yesterday
07:31 eck sure
07:31 geezas what's the upper limit?
07:31 eck so worst case, assume zombie apocalypse
07:31 geezas a miner picks the timestamp, so what's the upper limit?
07:31 eck in the zombie apocalypse case, i would lie
07:32 eck upper limit is given by the median of the last 11 blocks
07:32 geezas that's lower limit
07:32 eck nah
07:32 geezas in my mind time increases
07:32 eck that's the lower acceptable limit
07:32 eck not the lower limit
07:33 geezas how about we use more specific terms, min and max instead of lower upper
07:33 geezas my assumption that min timestamp value = median of last 11 blocks
07:33 geezas you're saying it's not correct, right?
07:33 eck one second
07:33 eck let me rtfs
07:35 geezas ha, ok, I will summarize how I understood that link about block timestamp
07:35 eck as i understand the code, if you controlled many nodes to me, you could lie and i would be tricked
07:35 geezas next block timestamp minimum allowed value = median of previous 11 blocks
07:35 eck *connected to me
07:36 geezas so minimum limit can't be tricked
07:36 eck but i would detct if i waited long enough
07:36 geezas as the source of that limit is pow-confirmed blocks
07:36 Sentineo eck: it does not sound right
07:36 eck how manmy pow-confirmed blocks you accept is up to you
07:36 geezas but the maximum limit comes from peer nodes
07:36 Sentineo if a ts is not ok, my full node rejects your block
07:37 geezas eck, for timestamp, it's not up to you, it's median of 11 previous block timestamps
07:37 eck right
07:37 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
07:38 eck i think that's right
07:38 geezas but
07:38 geezas for upper limit
07:38 geezas it's what they call "Network-adjusted time"
07:38 eck from first principles, every node should get to the same final state
07:38 eck even if their individual clocks are different
07:38 geezas if I understand it correctly, for the purpose of validating historical blocks, there is no limit
07:39 geezas but for propagating new blocks, it's NAT (network-adjusted time) + 2 hours
07:40 eck well
07:40 eck old blocks should be treated same as new blocks
07:40 eck how do you know if you're in old mode vs new mode?
07:40 geezas right, that's where I'm interesting in understanding this better
07:41 eck bingo
07:42 geezas I think the network relies on the majority of nodes reporting correct current time, give or take
07:42 Sentineo nodes syncing have a special state
07:42 Sentineo forgot the name ibd I think
07:42 Sentineo look for it in the debug.log
07:43 geezas but for syncing, I wonder if there's an upper limit on valid timestamp, I don't think there is
07:43 eck most nodes are connected to only 8 other nodes
07:43 eck so it is pretty easy to trick them
07:43 Sentineo and its activation deoends from the time
07:44 Sentineo eck: they will accept the longest most proof of work chain and trust the tkmestamp
07:44 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)
07:44 Sentineo the timestamp is really enforced by up to date nodes
07:44 Sentineo not ibd ones
07:44 geezas that would be a valid block, right?
07:45 Sentineo geezas: yes
07:45 geezas ok, makes sense, so there's no upper limit on timestamp delta between blocks
07:45 Sentineo ah that is what you mean
07:46 geezas other than current time + 2 hours
07:46 Sentineo no there is not
07:46 Sentineo right
07:46 geezas which is enforced by majority nodes reporting correct current time
07:46 Sentineo considerr
07:46 geezas but for syncing it does not matter
07:46 Sentineo 80% of hashpower disapears
07:46 Sentineo 2016 blocks would take a loong time
07:47 Sentineo you do not know how much in advance, so such rule would be problematic and not solve anything
07:47 geezas Sentineo, I agree, I'm not considering such a rule, but somehow conversation with eck lead to that
07:48 geezas initially he said that timestamps do not rely on any external clocks or time servers
07:48 Sentineo yeas, agree
07:48 Sentineo the external is important there
07:48 Sentineo you can drop blocks just cause you have a bad clock
07:49 Sentineo e.g. you stay in 2015
07:49 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)
07:49 Sentineo you would not get new blocks added to your chain
07:49 geezas which is actually enforced by so called external system(s)
07:49 geezas right
07:50 Sentineo but it is external to the system (btc)
07:50 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
07:50 Sentineo not how eck ment it , and how I understand what he wrote
07:50 geezas plus, that's assuming you don't have your own clock for sanity checking
07:51 geezas so, now that I'm pretty clear on current workings of this
07:51 geezas (thanks eck and Sentineo)
07:52 Sentineo I will set my own clock to 2015
07:52 Sentineo want to see the log messages ;)
07:52 Sentineo never tried it
07:52 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
07:53 Sentineo well you would see no increase in the way you described it
07:53 geezas Sentineo, I think your node might be using NAT (network adjusted time)
07:53 Sentineo but even it could decrease
07:53 geezas not your system clock
07:53 geezas from link, eck posted earlier: https://en.bitcoin.it/wiki/Block_timestamp
07:53 Sentineo geezas: of course I would turn it off
07:53 geezas oh, sorry, never ran a node, so I don't know how configurable it is
07:54 geezas so you can turn off NAT, is what you're saying, right?
07:54 Sentineo if u mean ntp, yes
07:54 geezas what's ntp?
07:55 geezas the link I just posted, it says: "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.
07:56 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.
07:56 Sentineo well i am not sure if bitcoind will consider system time at all then
07:57 Sentineo we will see
07:57 geezas anyway, back to my inquiry about block size as a function of timestamp delta
07:57 Sentineo cause if it does not, eck is right that miners can fool nodes (not how I thought it works)
07:58 geezas pause on my inquiry... how can miners fool nodes?
07:58 geezas nodes report time to other nodes
07:59 Sentineo they should not report, it requires trust
07:59 Sentineo but do not know
07:59 Sentineo never tried ;)
08:00 geezas right, but then it's not specifically miners than can fool nodes, but just nodes in general
08:01 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
08:02 geezas although from what I know, many attacks require that all or almost all peer nodes are malicious for the attack to work
08:03 Sentineo reporting time means sending a block
08:03 Sentineo blocks need PoW
08:03 Sentineo so you need miners
08:03 geezas whereas with NAT, only 50% + 1 malicious nodes is enough to trick a node into getting a wrong time
08:03 geezas you don't need miners for NAT
08:04 geezas which is then used to validate blocks
08:04 geezas so here is an attack scenario
08:04 Sentineo how do I get NAT?
08:04 Sentineo you think it is a protocol of some sort?
08:04 geezas what do you mean by get?
08:05 geezas sorry, I am going solely off of that definition from the link
08:05 geezas I assume it's in the protocol
08:05 geezas whether it's something the node software tells you I don't know
08:05 eck geezas: how do you pick your peers in the NAT?
08:05 geezas since I never ran a node
08:06 geezas eck: it says it's the "median of the timestamps returned by all nodes connected to you"
08:06 eck alright
08:06 Sentineo no
08:06 eck maybe i'm a student a university X
08:07 Sentineo for sure not
08:07 eck and my peers in my dorm lie to me
08:07 eck ideally, there is some way to get back onto the main chain
08:07 eck even if they lie to me
08:07 Sentineo you should count stuff from blocks, not from messages from peers
08:07 eck right
08:08 geezas Sentineo, yes and no
08:08 geezas if you're syncing, and you're currently at last year block
08:09 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
08:09 geezas if peers report to you that current time is 2017 January
08:09 geezas how do you know that 2017 January is invalid reported time? blocks wont help you here
08:09 Sentineo geezas: we afe not syncing
08:09 eck the timestamp is in the block
08:09 eck not in what peers tell you
08:09 Sentineo exactlt
08:09 Sentineo eck has the point
08:09 eck it's part of the block header
08:10 Sentineo you trust the BLOCK, as it is backed by PoW
08:10 Sentineo not a peer and some time message from it (there is no such message type iirc)
08:10 geezas yes but your lets say the latest block you synced is from last year
08:10 geezas because you're not done syncing
08:10 eck ok
08:11 geezas the timestamp on the latest block you synced says lets say 2016 December something
08:11 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
08:11 eck which am i going to follow?
08:12 geezas eck, not sure what you're talking about, there are no sidechains or alternative chains
08:12 Sentineo you care about the work in the chain
08:12 geezas just the main chain for now
08:12 Sentineo geezas: there are, you implicitly have 2 if you are talking about an attack
08:12 eck geezas: we're discussing how a node would trick the network, which implies the node double-spends
08:13 Sentineo right
08:13 eck if not a double spending attack, what are you worrried about?
08:13 geezas I'm not talking about an attack where false blocks are given to you
08:13 geezas at least not at this point
08:13 Sentineo ok, try again ;)
08:13 geezas ok, so I'm a new node
08:13 geezas I start syncing to the main chain
08:13 eck alright
08:14 geezas I'm being given blocks that follow whatever my latest block I've synced is
08:14 eck ok
08:14 geezas so I start and get block 1 then 2 then 3 etc
08:14 geezas so I reach block whatever, let's say 100000
08:15 geezas and lets say timestamp on that block is 2016 December whatever
08:15 eck ok
08:16 geezas I'm connected to 21 nodes, 11 are malicious and are reporting current time as 2017 January 5
08:16 geezas so I will keep syncing until I reach a block with timestamp 2017 January 5 + 2 hours
08:16 geezas after which, I will thing I'm getting blocks which are in the future and thus invalid
08:16 geezas so I will start rejecting those
08:17 geezas and think I'm done syncing
08:17 eck i haved not rtfs, but i believe what happens is you see two chains
08:17 geezas since I'm not getting any more valid blocks
08:17 geezas there are no two chains
08:17 geezas it's still one chain
08:17 eck why not
08:17 geezas where is the 2nd chain you're speaking of?
08:17 eck syncing != 1 chain
08:17 geezas all blocks are referencing each other in one chain
08:18 Sentineo geezas: you are not correct if you assume nodes are reporgint time, they are not
08:18 eck sure
08:18 eck each block references the hash of the previous block
08:18 geezas Sentineo, maybe that's true, but that's not what bitcoin wiki says about it
08:18 Sentineo geezas: nodes send you blocks, and those have timestamps ... so sending different time means you send an alternative chain (different blocks)
08:18 eck or more accurately, its merkle root
08:18 Sentineo geezas: bitcoin wiki has like 7 sentences, you want to analyse a protocol based on that?
08:18 eck so as a new syncing node, i see we all agree up to block X
08:19 eck after block X, i see two new possible merkle roots
08:19 Sentineo no no
08:19 eck i follow the one with the most pow behind it
08:19 Sentineo merkle root is for txes
08:19 geezas eck, merkle roots are not related to this
08:19 eck the merkle root is in the block header
08:19 Sentineo block header's hash is used in the blocks
08:19 eck it references the previous block
08:19 Sentineo eck: not merkle root references the txes in the current block
08:19 Sentineo and you are right they are in the block header
08:20 geezas right, so here's the simplified block chain: A -> B -> C -> D -> E (current)
08:20 Sentineo there is a previous block header field in the header
08:20 eck if i mine block X, how do i know which block is X-1?
08:20 geezas eck: each block references previous block
08:20 eck right
08:20 geezas so let me redo me diagram: A <- B <- C <- D <- E (current)
08:20 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
08:21 eck more accurately, the block header has merkle root (this block) + merkel root (prev block) + other stuff (e.g. version bits)
08:21 Sentineo eck: no :)
08:21 eck alright
08:21 eck enlighten me
08:21 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
08:22 Sentineo eck: look at https://bitcoin.org/en/developer-reference#block-headers
08:22 eck Sentineo: which part did i get wrong?
08:22 Sentineo eck: you have two 256 bit fields in the header, one for merkle root, the other for previous block hash
08:22 Sentineo eck: you sounded like you say they are the same
08:23 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
08:23 Sentineo geezas: you are not given NAT man ...
08:24 geezas Sentineo, either documentation is correct or it's not, which is it?
08:24 Sentineo it is the user who is interpreting words incorectly
08:24 Sentineo you write as
08:24 Sentineo if NAT was a protocol or something
08:24 Sentineo it is just a concept
08:25 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 ... :)
08:26 geezas well, it sure sounds like protocol is being described
08:27 geezas it explicitly says what is considered a valid timestamp (of a block)
08:27 geezas it says it must be greater than median of last 11 timestamps and less than n.a.t.
08:28 Sentineo you can spin up a node, use tcpdump or wireshark to capture the messages between them
08:28 Sentineo and tell me there you see a NAT message
08:28 geezas I presume if timestamp is invalid, the block is considered invalid
08:28 Sentineo nat is calculated from a block, not from a message from a peer
08:28 geezas there does not need to be a nat message
08:28 Sentineo and that makes the whole difference
08:28 geezas is there ever a timestamp when communicating with nodes?
08:28 geezas that's enough to get a timestamp from a node
08:29 Sentineo from your assumptions it sounds like you think there is a separate message and you get time from peers
08:29 Sentineo geezas: no there is not
08:29 geezas then "NAT" is calculated internally, by taking a median of all timestamps, one from each node
08:29 geezas so what does "timestamps returned by all nodes connected to you" phrase mean?
08:32 Sentineo internaly from blocks you have
08:32 Sentineo from the blocks they send
08:33 Sentineo you have no way of knowing you are on the valid chain
08:33 Sentineo e.g. if your node goes off
08:33 Sentineo and comes back 2 hours later and there is no new block since
08:33 Sentineo you see the progress indicator as 0.9999 something, not 1
08:34 Sentineo as it does not know if it is out of sync, or just there was no new block
08:34 Sentineo it will know once a new blocks gets to it
08:54 geezas Sentineo
08:55 geezas so what happens if a miner mines a block with a timestamp that's dated 30 days into the future?
08:56 geezas by your explanation, it would be a perfectly valid block and all nodes would accept it as the next block
09:02 Sentineo no they would not
09:02 Sentineo as they check the blocks timestamp to their time
09:02 Sentineo in case they are synced of course
11:18 cluelessperson Would someone who's been around be able to help me with some media and opinions?
16:00 hkjn0 hey, I have my node running with txindex=1 and restarted with -reindex, but I still get "no such transaction" from getrawtransaction calls..
16:00 hkjn0 I guess the reindexing is still going? can I check the status of reindexing with some RPC?
16:04 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
16:43 hidden 2017-11-21 11:14:34 [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE].
16:43 hidden 2017-11-21 12:20:28 No coin database inconsistencies in last 7 blocks (13599 transactions)
16:43 hidden 2017-11-21 12:20:28 block index 4051611ms
16:43 hidden 2017-11-21 12:20:28 init message: Loading wallet...
16:43 hidden 2017-11-21 12:20:28 nFileVersion = 32400
16:43 hidden 2017-11-21 12:20:28 Keys: 102 plaintext, 0 encrypted, 0 w/ metadata, 102 total
16:43 hidden 2017-11-21 12:20:28 wallet 65ms
16:43 hidden 2017-11-21 12:20:28
16:43 hidden ************************
16:43 hidden EXCEPTION: St13runtime_error
16:43 hidden GenerateNewKey: AddKey failed
16:43 hidden C:\Program Files\Bitcoin\bitcoin-qt.exe in Runaway exception
16:43 hidden 2017-11-21 16:34:08 CDBEnv::EnvShutdown: Error -30974 shutting down database environment: DB_RUNRECOVERY: Fatal error, run database recovery
20:33 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?
21:29 eck it's unsigned
21:29 eck https://en.bitcoin.it/wiki/Block_timestamp