creating this topic to discuss a potential issue jmzeidner found out, as of yet jmzeidner can not create threads himself
Hello,
you can find some of my other works on http://altchain.org for a bit of background on me.
I’ve recently become interested in the PoS concept and PeerCoin.
I think there may be some underlying problems with the protocol. The fact is that timestamps can be faked in Bitcoin and aren’t necessarily ‘objective’ or even ‘consensual’. This does not pose any major problems for Bitcoin users because the system does not strictly rely on timestamps. The difference here is that PoS does rely on the block ntime timestamps(as discussed in IRC). Presumably, these timestamps might be faked to a degree as to gain a comparative advantage.
The first question that needs answering here: How is coin age calculated?
I think once we establish some facts on that question, we can explore some of the other issues that were raised in IRC.
thanks, Josh Zeidner
(11:45:38 PM) Guest13412: while I suspect there probably would be a problem with faking it to a degree, there is really no way to stop people from dating TXs any way they please (11:45:43 PM) Guest13412: that goes for regular Bitcoin as well (11:46:12 PM) TheSeven: hm... the source code suggests that it actually isn't using the transaction's timestamp but the block's timestamp that the transaction is inside - that should protect against this attack, right? (11:47:58 PM) TheSeven: ...or not... it seems to check if that is at least 30 days, but then uses the TX timestamp (11:48:18 PM) TheSeven: have a look yourself... the interesting code is here: https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1694 (11:49:44 PM) Guest13412 left the room (quit: Ping timeout: 240 seconds). (11:50:32 PM) altchain [94a784f3@gateway/web/freenode/ip.x.x.x.x] entered the room. (11:50:36 PM) altchain: sorry just got disconnected (11:50:43 PM) TheSeven: [23:46:16] hm... the source code suggests that it actually isn't using the transaction's timestamp but the block's timestamp that the transaction is inside - that should protect against this attack, right? (11:50:43 PM) TheSeven: [23:48:02] ...or not... it seems to check if that is at least 30 days, but then uses the TX timestamp (11:50:43 PM) TheSeven: [23:48:21] have a look yourself... the interesting code is here: https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1694 (11:50:44 PM) altchain: this is the original questioner (11:51:01 PM) altchain: hey (11:51:27 PM) altchain: unless youve got something here there is no way to determine a correct time withotu the use of complex protocols (11:51:44 PM) TheSeven: well the time isn't always fully accurate (11:51:52 PM) altchain: the timestamp field is assumed to be correct in bitcoin because no one relies on it (11:51:57 PM) TheSeven: but nobody cares if this is off by a few hours if all that counts is days/months (11:52:13 PM) altchain: well the questino is what are the tolerance and margin levels (11:52:25 PM) TheSeven: the block ntime is kept within a few hours of reality (11:52:34 PM) altchain: this is josh zeidner from altchain.org btw (11:52:53 PM) altchain: what is 'reality'? (11:52:54 PM) TheSeven: you can't arbitrarily fake block ntimes - other nodes wouldn't accept that block if it is too far off (11:53:08 PM) bhldev__ [~briandev@x.x.x.x] entered the room. (11:53:13 PM) altchain: does the protocol detect if it's off and what does it check it against? (11:53:14 PM) eennaam: bitcoin tolerates 2 hours difference for timestamps (so i've heard) (11:53:51 PM) bhldev left the room (quit: Ping timeout: 250 seconds). (11:54:09 PM) TheSeven: I think it checks against what the previous block says - so to throw it off by more than a few hours you'd have to have the majority mining power (11:54:26 PM) TheSeven: and if you have that - well, then you can do much more critical things than messing with timestamps (11:54:32 PM) bhldev_ left the room (quit: Ping timeout: 276 seconds). (11:54:38 PM) altchain: what if my personal clock is off by a few hours? (11:54:52 PM) altchain: and if i set it to be off by a few hours, will I benefit personally? (11:55:04 PM) TheSeven: likely not, or at least not by much (11:55:21 PM) altchain: so were dealing with likelihoods - no one knows for sure (11:55:55 PM) TheSeven: I think this is a question for #bitcoin though - there are much more knowledgeable people there and peercoin uses largely the same algorithms for that kind of stuff (11:56:12 PM) altchain: bitcoin does not rely on the timestamp for anything significat (11:56:21 PM) altchain: your protocol does (11:56:24 PM) TheSeven: the more interesting question is if and how transaction timestamps are checked against block timestamps, and which of those are used for coin age calculation (11:56:43 PM) TheSeven: the bitcoin people will know how good these timestamps are though (11:57:12 PM) altchain: the problem of timestamps has been raised before, but it wasnt really a huge issue because theyre not used for anything (11:57:17 PM) TheSeven: because you can talk to the actual developers there - we're just a few people here who've had a few looks at the source code, but haven't developed it (11:58:01 PM) altchain: there was a 'timejacking' issue http://culubas.blogspot.com.es/2011/05/timejacking-bitcoin_802.html (11:59:03 PM) altchain: ok - i may post something to the peercoin forums. I'd say this is a pretty serious problem. There have been many many papers written on how to solve htis problem of time resolution in p2p environments and the PoS paper seems to trivialize it. (11:59:35 PM) TheSeven: hm, this is really something that you should discuss with sunny himself (11:59:43 PM) TheSeven: you probably know more about it than we do already ;) (11:59:45 PM) altchain: blockchain's timestamp is non sequential. https://bitcointalk.org/index.php?topic=391388.0 (4/20/2014 12:00:06 AM) TheSeven: I don't think it's a problem that they're non-sequential (12:00:11 AM) altchain: ya i've written papers about distributed exchanges. they can be found on my site (12:00:16 AM) TheSeven: the two most troublesome cases would be if: (12:00:28 AM) altchain: well if they are non-sequential then they are innaccruate (12:00:32 AM) TheSeven: 1. the block ntime can be thrown off by several days without having the majority of mining power (12:00:36 AM) altchain: and what troubles me is - can they be faked (12:01:11 AM) altchain: yes but the problem is that if they can be 'thrown off' peopel will do it intentionally and how much tolerance do we have here and what margins for error (12:01:16 AM) TheSeven: 2. or the transaction ntime could be arbitrarily far away from the block ntime and is being used for PoS coin age calculation (12:01:41 AM) altchain: ok lets assume that we use the Block timestamp to calculate coin age (12:01:48 AM) altchain: jsut to simplify the issue (12:01:50 AM) TheSeven: if one of those is true, there might be vulnerabilities that lead to the ability to transfer coins without losing their age (12:02:01 AM) altchain: i dont think thats the problem (12:02:06 AM) altchain: its the problem of faking the coin age (12:02:33 AM) altchain: in your system coin age has power and value, right? (12:03:01 AM) TheSeven: you mean pushing the block ntime massively into the future to make coins age faster? (12:03:24 AM) altchain: sounds like what im getting at yes (12:03:38 AM) TheSeven: well, that would increase *everyone's* mining power though (12:03:40 AM) altchain: you would push block ntime massively into the PAST (12:03:56 AM) TheSeven: why into the past? how does that help you? (12:04:02 AM) altchain: so lets say the time is 15:04 (12:04:04 AM) eennaam: after 90 days you dont get any additional coinage (12:04:07 AM) altchain: i date my block at 14:04 (12:04:15 AM) altchain: even though my personal clock say 15:04 (12:04:25 AM) altchain: now my block is 1:00 old according to your measurments (12:04:37 AM) TheSeven: yes... so what? (12:04:52 AM) altchain: doesnt this give me the ability to 'mint' blocks? (12:05:59 AM) TheSeven: not before 30 days are over (12:06:15 AM) altchain: ok so lets say i back date it by 30 days (12:06:18 AM) TheSeven: and I don't care if it's 29 or 30 days - it's largely random anyway (12:06:20 AM) altchain: it's just a matter of scale (12:06:36 AM) altchain: so i date the block to 30 days ago (12:06:47 AM) altchain: and magically it's mature as soon as it's created (12:06:59 AM) TheSeven: you can't advance 30 days with a single block though (12:07:04 AM) TheSeven: that's limited to a few hours per block (12:07:13 AM) TheSeven: which is why you need majority mining power to play that kind of game (12:07:38 AM) altchain: there's some kind of pre-set tolerace based on the other timestamps in the chain is what you're saying (12:08:20 AM) altchain: it regular bitcoin blocks can actually be out of order according to timestamps http://bitcoin.stackexchange.com/questions/3743/how-can-an-earlier-block-have-a-later-timestamp (12:09:16 AM) altchain: it jsut seems that PoS relies on a sense of objective time that doesn't really exist, and you're relying on conventions and assumptions (12:10:29 AM) TheSeven: we're surely relying on the assumption that an attacker doesn't have the majority mining power (12:11:24 AM) altchain: i dont think this problem depends on having majority mining power (12:11:26 AM) altchain: or in your case majority 'stake' (12:11:55 AM) altchain: unless youve added something significant, then blocks can have out of order timestampts (12:12:27 AM) altchain: the paper does not suggest a solution to this problem (12:13:04 AM) altchain: the reason why this isn't a problem in bitcoin is there is no incentive to fake the timestamps. they don't do anything. not so for PPC (12:13:26 AM) TheSeven: I don't get why out of order timestamps even are a problem, if the tolerance is just a few hours (12:13:58 AM) altchain: ok you have a chain right (12:13:59 AM) Maalike left the room (quit: Quit: Maalike). (12:14:07 AM) TheSeven: whatever you're doing to block ntime will affect others exactly like it affects yourself - so if it increases your chances to mine a block, it will do so for everyone else as well, keeping the relative mining power distribution intact (12:14:17 AM) altchain: B1 - 1:00 , B2 - 2:00, b3 - 3:00 (12:14:22 AM) altchain: 3 blocks in a chain (12:14:24 AM) altchain: ok? (12:14:27 AM) TheSeven: yes (12:14:37 AM) altchain: and lets say that the maturity time is 1:00 (12:14:53 AM) badhatter left the room (quit: Remote host closed the connection). (12:15:00 AM) altchain: so i add a block b4 - 2:00 (12:15:04 AM) altchain: we just went back in time (12:15:09 AM) altchain: now the next block is (12:15:17 AM) altchain: b5 - 4:00 (12:15:20 AM) badhatter [~badhatter@x.x.x.x] entered the room. (12:15:20 AM) badhatter left the room (quit: Changing host). (12:15:20 AM) badhatter [~badhatter@unaffiliated/plotplanexe] entered the room. (12:15:23 AM) altchain: which makes b4 fully aged? (12:15:33 AM) altchain: automatically? (12:17:13 AM) altchain: you can extend this scenario to whatever time scale you've chosen for PPC (12:21:19 AM) altchain: it seems in your choice of language earlier that you are depending on 'reality' but there is no objective time here, and otherwise we assume that all the people using the clients are not faking their time (12:21:46 AM) altchain: and people will do that if there is an incentive to do so. (12:22:57 AM) altchain: in bitcoin, there is no incentive. In PPC there is. (12:24:39 AM) TheSeven: everything that "ages" in ntime and not block height is at least 30 days worth of ntime (12:24:54 AM) TheSeven: however you can only move that ntime by 2 hours per block (12:25:31 AM) TheSeven: the only thing that I could see someone benefit from is moving ntime into the future (12:25:47 AM) TheSeven: however that affects all stakeholders similarly, so you don't get a comparative advantage (12:27:10 AM) altchain: ok so as the last link suggests, you can have blocks with out of order timestamps (12:27:17 AM) altchain: has PPC fixed that? (12:27:37 AM) TheSeven: I don't think so, but why are those a problem? (12:28:03 AM) altchain: well you are measuring the time passed by the last block, yes? (12:28:21 AM) altchain: your 30 days (12:28:56 AM) altchain: we dont need to fake the entire duration, but if it's possible to fake part of it, that might effect the viability of the whole system (12:29:26 AM) badhatter left the room (quit: Ping timeout: 240 seconds). (12:29:52 AM) TheSeven: this duration isn't strictly 30 days anyway (12:30:13 AM) altchain: fine lets call it by variable DELTA (12:30:14 AM) TheSeven: it's something between 30 and 90 days, typically 35-60 or something (12:30:29 AM) altchain: so how do you measure DELTA (12:30:42 AM) TheSeven: so if you want to cause trouble, you'll have to throw off the network's notion of time by days, not hours, to cause any noticable effect (12:30:57 AM) badhatter [~badhatter@x.x.x.x] entered the room. (12:30:57 AM) badhatter left the room (quit: Changing host). (12:30:57 AM) badhatter [~badhatter@unaffiliated/plotplanexe] entered the room. (12:31:05 AM) altchain: it may be possible (12:31:07 AM) badhatter left the room (quit: Read error: Connection reset by peer). (12:31:17 AM) TheSeven: however the effect will be the same for all miners, so I don't think this is exploitable at all - beyond messing a tiny bit with the global interest rate (12:31:24 AM) altchain: as far as I can tell there are NO controls over this problem (12:31:40 AM) altchain: again- if you will- how do you measure DELTA? (12:32:09 AM) TheSeven: what exactly is that delta? the block ntime to UTC difference? (12:32:15 AM) altchain: how do i know what age the coins are (12:32:33 AM) altchain: UTC IS DIFFERENT FOR EACH CLIENT (12:32:42 AM) TheSeven: ...by a marginal amount (12:32:52 AM) altchain: these are basic distributed systems design problem (12:33:02 AM) altchain: YOUR ASSUMING BY A MARGINAL AMOUNT\ (12:33:11 AM) altchain: what is stopping someone from setting it to a non-marginal amount? (12:33:23 AM) eennaam: please dont scream, ive got a headache (12:33:40 AM) altchain: i feel youre overlooking something very important sorry (12:33:49 AM) Gyps left the room (quit: Quit: Gyps). (12:33:53 AM) eennaam: it is always good to be critical (12:33:54 AM) eennaam: :) (12:33:56 AM) altchain: there are thousands of papers written about these problems (12:34:07 AM) TheSeven: I *think* (but am not fully certain) that the coin age is measured by looking at the new block ntime (typically current local notion of UTC, unless there is a big ntime throwoff) minus the TXN ntime of the last transaction that moved the coins, the latter of which might be unreliable (12:34:28 AM) altchain: ok so lets assume that (12:34:48 AM) TheSeven: additionally a new block can only be mined using these coins if the age of the BLOCK containing the previous TXN (new block ntime minus old block ntime) is at least 30 days (12:34:48 AM) altchain: in this case i can backdate the block ntime and i can mature my coins (12:35:17 AM) TheSeven: "mature" as in get beyond that 30 days thing? we typically call something else maturity here (12:35:58 AM) badhatter [~badhatter@x.x.x.x] entered the room. (12:35:58 AM) badhatter left the room (quit: Changing host). (12:35:58 AM) badhatter [~badhatter@unaffiliated/plotplanexe] entered the room. (12:36:02 AM) altchain: ok what do you call it when coins reach the age that they can be used as 'stake' (12:36:45 AM) TheSeven: I don't think we have a special word for that, let's call it stake-candidate or something (12:36:53 AM) altchain: ok (12:36:59 AM) TheSeven: anyway, I know what you're referring to (12:37:48 AM) eennaam: it is a little bit like maturing (12:38:02 AM) altchain: in everything youre written so far, you are assuming it's possible to detemrine the age of a block against some kind of objective time measurement (12:38:02 AM) eennaam: only not the same :) (12:38:12 AM) altchain: there is no such thing in this sort of scenario (12:38:17 AM) altchain: this doesnt pose a problem for bitcoin (12:38:35 AM) altchain: but does psoe a problem for you because you rely on 'age' in order to perform your protocol (12:38:39 AM) TheSeven: I have to go to sleep soon... I suggest you discuss whether or not ntime can be massively thrown off without having the majority mining power with the bitcoin people, as this is a necessary precondition for this kind of vulnerability. what worries me a bit is the fact that you might be able to backdate TXN timestamps, but the damage of that should also be limited (12:39:26 AM) altchain: the links I provided have already established that (12:39:32 AM) TheSeven: I think we can generally rule out block ntime causing trouble because it would affect everyone in the same way, i.e. you wouldn't have any comparative advantage (12:40:42 AM) altchain: these are some basic distributed systems problems, the fact that you dont have an objective time to rely on is a basic thing, and it's a big concern that your thinking seems to rely on this notion (12:40:46 AM) altchain: almost naively (12:41:15 AM) eennaam: altchain: do you have an account on peercointalk? (12:41:19 AM) altchain: there are other projects as well which seem to inherit this oversigh (12:41:31 AM) TheSeven: I'm not assuming that we have an *accurate* objective time - just a somewhat reasonable one (12:41:42 AM) altchain: such as peershares (12:41:54 AM) altchain: how do you compute the time of dividends usefully? (12:42:06 AM) TheSeven: I haven't fully understood why the latter wouldn't be true as long as nobody does a 51% attack (12:42:18 AM) TheSeven: but I must admit that I haven't bothered to look at that in depth (12:42:35 AM) TheSeven: anyway, how would you get any comparative advantage from messing with the global notion of time? (12:42:48 AM) TheSeven: why would you benefit from it more than anybody else?
This is a hex dump of a typical transaction in the Peercoin blockchain. the first 4 bytes represent the transaction version number and the next 4 bytes in pink represent the transaction timestamp.
This means that the transaction timestamp is embedded in the computation of the transaction hash, so that means you can’t change the transaction timestamp without changing the transaction hash. It would inadvertently make the transaction hash invalid.
This means that you cannot fake timestamps.
Note: In Bitcoin there is no transaction timestamp embedded in the transaction script, so that’s how you can fake transaction timestamps.
Here is the tx: http://ppc.blockr.io/tx/info/e8848f4dc6a24831abeac01f748656f795c217fe17364966b59213872380cfc1
Cheers. 
I think what altchain meant was that block timestamp can be faked and it is used to calculate coin-age of the stake in question basically using block timestamp minus trasaction timestamp.
altchain thinks there is an incentive for many minter to fake the block timestamp to get a larger coin-age. Since there is no way to determine the real time, if somehow many minters accepts a “faster clock”, the block with wrong timestamp will be accepted among them and becomes an exploit.
I think this exploit is no difference from subset of users trying to give themselves a larger percentage (> 1%) of POS repward and it would be just as hard to do (or as easy to do if we count in forking PPC to give large % of POS)
I think what altchain meant was that block timestamp can be faked and it is used to calculate coin-age of the stake in question basically using the block timestamp minus trasaction timestamp.
altchain thinks there is an incentive for many minter to fake the block timestamp to get a larger coin-age. Since there is no way to determine the real time, if somehow many minters accepts a “faster clock”, the block with wrong timestamp will be accepted among them and becomes an exploit.
I think this exploit is no difference from subset of users trying to give themselves a larger percentage (> 1%) of POS repward and it would be just as hard to do (or as easy to do if we count in forking PPC to give large % of POS)[/quote]
Hey mhps,
I’m having a hard time trying to understand what exactly your implying. The block timestamp is embedded in the 80 bytes needed to compute the block hash. Changing the timestamp of a block would produce an invalid block hash.
In terms of faking timestamps…I’m not sure as to how someone could achieve that ?
From the difference between the transaction timestamp and the previous transaction timestamp: https://github.com/peercoin/peercoin/blob/v0.4.0ppc/src/main.cpp#L1712
The 30 days minimum age is checked between the transaction timestamp and the block timestamp of the previous transaction: https://github.com/peercoin/peercoin/blob/v0.4.0ppc/src/main.cpp#L1708
To answer some of the other questions:
A block will be rejected by the network if it’s older than the previous block (actually older than the median time of the 11 previous blocks or older than the previous block with a 2 hours tolerance): https://github.com/peercoin/peercoin/blob/v0.4.0ppc/src/main.cpp#L1934
A block will be rejected if its timestamp is more than 2 hours in the future: https://github.com/peercoin/peercoin/blob/v0.4.0ppc/src/main.cpp#L1843
A block will be rejected if it contains any transaction whose timestamp is greater than the block timestamp: https://github.com/peercoin/peercoin/blob/v0.4.0ppc/src/main.cpp#L1882
[quote=“JetJet13, post:6, topic:2239”]Hey mhps,
I’m having a hard time trying to understand what exactly your implying. The block timestamp is embedded in the 80 bytes needed to compute the block hash. Changing the timestamp of a block would produce an invalid block hash.
In terms of faking timestamps…I’m not sure as to how someone could achieve that ?[/quote]
Timestamp of every block is written by the creater of the block. The block creater is free to choose a time stamp as long as the timestamp can be accepted by other nodes (within an error range of more than two hours wide). Am I missing something?
Hi there,
this is ‘altchain’ in the IRC log.
so it seems to me from what’s been explained here that it is possible for the creator of a TX record to backdate the timestamp. Are there any limits to how far they can backdate it? if this is possible then it’s possible to fake your coin age, and I could hypothetically send myself coins backdated that are fully aged and create a block.
while PPC might have a backup scheme(PoW) to protect against failures, here I am discussing the viability of PoS by itself.
am I missing something?
-jmz
From the difference between the transaction timestamp and the previous transaction timestamp: https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1712
The 30 days minimum age is checked between the transaction timestamp and the block timestamp of the previous transaction: https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1708
To answer some of the other questions:
A block will be rejected by the network if it’s older than the previous block (actually older than the median time of the 11 previous blocks or older than the previous block with a 2 hours tolerance): https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1934
A block will be rejected if its timestamp is more than 2 hours in the future: https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1843
A block will be rejected if it contains any transaction whose timestamp is greater than the block timestamp: https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1882[/quote]
While this doesn’t appear particularly dangerous, this is not a proven technique to generate reliable time in distributed systems. We can’t consider it in the same class as PoW because PoW was proven rigorously even before Bitcoin was invented. http://www.hashcash.org/papers/hashcash.pdf
It may be possible, for instance to distort time in this case and we don’t know definitively what effects this might have on the value or usage of the currency. In addition there are secondary concepts such as PeerShares that are inheriting similar assumptions about time. So if PeerShares for instance uses these same time metrics and time is slowed down, then technically the share issuer is liable for less dividends over a real time period, and this is equivalent to real losses for shareholders.
-jmz
[quote=“mhps, post:8, topic:2239”][quote=“JetJet13, post:6, topic:2239”]Hey mhps,
I’m having a hard time trying to understand what exactly your implying. The block timestamp is embedded in the 80 bytes needed to compute the block hash. Changing the timestamp of a block would produce an invalid block hash.
In terms of faking timestamps…I’m not sure as to how someone could achieve that ?[/quote]
Timestamp of every block is written by the creater of the block. The block creater is free to choose a time stamp as long as the timestamp can be accepted by other nodes (within an error range of more than two hours wide). Am I missing something?[/quote]
The limit is the previous transaction’s timestamp: https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1178 and https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1701
So you can’t gain any coin age doing that.
yep. that would prevent that attack. 
thx,
-jmz
The limit is the previous transaction’s timestamp: https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1178 and https://github.com/ppcoin/ppcoin/blob/master/src/main.cpp#L1701
So you can’t gain any coin age doing that.[/quote]