[RFC-0004] Remove Transaction Timestamp


#1

I published a new RFC for the peercoin protocol.

This RFC proposes a fix for a design flaw in the Peercoin protocol.
Although the flaw is not security critical, it affects Peercoin’s compatibility with most Bitcoin infrastructure like hardware wallets, block explorers, libraries and many others.

This RFC also enables the development of RFC-0003: multisignature minting

Let’s discuss :slight_smile:


#2

I am in support of this proposal. The timestamp embedded into peercoin transactions is a pain in the ass. I’ve been wanting to add peercoin to my multicoin wallet for years but have never gotten around to it because that would mean I have to use a forked bitcore-lib. I would even argue that peercoin’s timestamp issue is a big reason why peercoin’s market cap is so low compared to other coins.


#3

Thanks for proposing.

Update CheckStakeKernelHash to validate against block timestamps of UTXO and coinstake.

How are these block timestamps used exactly in your design? Use ‘the median time of the 11 previous blocks or older than the previous block with a 2 hours tolerance)’ minus the block timestamp of UTXO ?
Then one only needs to mint once after a block is found. Since there can be a finite number of valid hashes after a block is found ( because there are ~ 10% * 24million / 100 = 24,000 minting UTXOs each being able to make one hash), it is possible that none of the UTXOs can find a kernel and the network stops generating blocks completely.

Also, is the transaction timestamp used in existing RPC commands or wallet clients for purposes other than validating blocks (e.g. displaying tx info) ?


#4

The usage of block timestamps is not changed at all.
Currently the coinstake timestamp is forced to equal the block timestamp, which proves that duplicating the timestamp in the transaction is useless, transactions can just inherit the block’s timestamp.

The logic you describe is not the logic to determine the block timestamp, it’s the logic used by nodes to accept blocks minted by others. It is needed to enforce minters to mint the present and not the future or the past.


#5

So how to update CheckStakeKernelHash to validate against block timestamps of UTXO and coinstake? I thought you want to replace transaction time with block timestamp of latest found blocks (the median time of the 11 previous blocks or older than the previous block with a 2 hours tolerance) in coinage calculating hence kernel hash creating/validating.


#6

CheckStakeKernelHash compares transaction timestamps, it should be updated to compare block timestamps. Other than that, nothing changes.
I don’t understand what is confusing you.


#7

Could you show a mock update of this one line https://github.com/peercoin/peercoin/blob/0.4.2/src/kernel.cpp#L313 ?

It seems that for a UTXO, nothing in ss changes if the latest block doesn’t change (not a function of time any more)?


#8

Let me dissect this line of code for you:

ss << nTimeBlockFrom << nTxPrevOffset << txPrev.nTime << prevout.n << nTimeTx;

nTimeBlockFrom: time of the block containing the UTXO
nTxPrevOffset: offset of txPrev inside block
txPrev.nTime: timestamp of the UTXO
prevout.n: output number of the UTXO
nTimeTx: timestamp of the block to create

When removing the transaction timestamp the following would be true:
nTimeBlockFrom == txPrev.nTime
nTimeTx == newBlock.nTime

To find stake, you update the new block’s timestamps, exactly like is being done today.

That’s it.


#9

Not exactly. Today every second a UTXO generates a new hash. The number of new hashes is unlimited. No matter what current difficulty is, a UTXO will find a block after trying long enough. After proposed change, A UTXO generates exactly one new hash. If it fails once it will always fail. If you use today;s difficulty algorithm, the chain will come to a halt if none of all UTXO finds a block in their first try. (The probability for that to happen at current difficulty is 599/600 = 99.8%). If you change the difficulty algo, it has to do something to change how long since the last block the next block is found. But this is impossible as the block-finding process has nothing to do with “how long since the last block”. You can’t remove reality time and still be able to adjust block time.


#10

No, you got it wrong.
The hash is updated for every second you try to create a new block.
This is true today, where you increment both coinstake and block timestamp, they are forced to equal.
And is true after removal of the transaction timestamp where you only update the new block’s timestamp.

nTimeTx = coinstake timestamp = new block timestamp

BTW I’ve never said anything about “how long since last block”.


#11

That’s why. Thanks for taking time to explain. :thumbsup:


#12

nice work, this would simplify so many things and isn’t that hard to change :smile:
hope it will be included soonish


#13

I think by default, the RPC methods should keep the timestamp in the transaction format to avoid breaking things, but a flag can be used to provide transaction data without the timestamp.

One potential issue is that some software may assume that the transaction hashes/ids should use the timestamp in the transaction data. If the transaction hashes are made without timestamps then some software may start producing incorrect transaction hashes. Software should ideally rely on hashes provided by the RPC commands, but some software may not. I suppose the only solution is to ensure developers are given sufficient warning.

It might be best to bundle this in with any other changes that might break compatibility, so at least developers wont have to worry about changes happening over and over again.


#14

I agree that RPC interface should have an option to switch between modes for backwards compatibility, it is also mentioned in the RFC text.

I didn’t think about the hashes though. I believe that software should trust the hashes coming through the RPC interface, if software wants to validate transaction hashes, it should be updated to be aware of the new rules, otherwise a whole new set of issues would pop up.


#15

This RFC has been accepted.


#16

OMG i’m so glad this is going to happen. Wallet code dealing with raw transactions and signing is going to be simplified compared to Bitcoin and other derivatives.