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.
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.
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) ?
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.
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.
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.
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.
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”.
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.
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.
if I get this right. The minting will be changed into:
In short, a blob of data is double sha256-hashed and compared to a target. A stake is found when the hash is lower than the target.
bytes short descr description
0-7 StakeModifier will decribe later
8-11 Block time unix time of block that contains the tx
12-15 Tx previous offset the position of previous Tx within the Block blob size 16-19 Tx previous time timestamp of block in which previous Tx resides
20-23 Tx previous index index of Tx’s previous Tx
24-27 a future time to be varied like a nounce
Please confirm so I can adjust findstakejs accordingly
In the previous tech meeting, there were general opinion that removing timestamp from coinstake can pose security concerns down the road.
The alternative approach proposed in the meeting was to only remove timestamp field for regular transactions. This means an exclusion to Coinstake and Coinbase, which will still keep their current format. It means any broadcast transactions will be compatible with Bitcoin format once the upgrade (hardfork) is complete. This proposal can also provide for additional needed Bitcoin compatibility.
Peerchemist wants me to start this new discussion. I want to see first if we should include it as part of RFC4 or a whole new RFC. Also I would like to understand the extent to which Bitcoin compatibility will be improved with this proposal.