TaPoS (Transactions as Proof of Stake) is a system developed by Dan Larimer in 2014. Its most important feature is the inclusion of a recent block hash into transactions. I believe most of the developers here should know already about it (for those that don’t: here is the whitepaper - initially it was meant to be a “standalone” consensus mechanism, but current approaches use it as a complement to existing algorithms).
Its main advantage: if there is a fork, everybody can know which chain are following other Peercoin users. It is a bit like synced checkpointing, only that everybody can broadcast his/her own checkpoints and others can follow it.
I think the feature of TaPoS to include a recent block hash into transactions would be an interesting addition to Peercoin to mitigate the Nothing at Stake problem. If users, in presence of an “attack chain”, can simply follow the chain their peers use (e.g. their favourite exchanges or merchants) then an attack would become very difficult - the attacker would have to lure big and well-known nodes into his attack chain.
Some PoS and DPoS coins (NXT, Bitshares …) are already using this feature - can Peercoin add it, too? Was this discussed somewhere among the developers?
The only disadvantage I can imagine is that it would add some more bytes to transactions - but maybe the signed block hashes can be pruned at some moment?
I started reading the TaPoS paper, this part is wrong:
Ultimately the network is still secured by Proof-of-Work and it is still possible to mine secret alternative chains that could be used to perform a double spend. An actor such as a government could still acquire enough hashing power to win over 51% of the proof-of-stake blocks and all of the proof-of-work blocks.
The Peercoin network is secured by PoS only. That means only PoS blocks carry weight in terms of a chain reorganization. A PoW miner cannot mine a bunch on blocks and then release them to the network causing a reorg. Theoretically a PoS staker/minter can try to do that though, you can talk about those attack vectors.
The PoW blocks do add entropy to the chain because they affect the stake-modifier value. That mitigates the “stake-grinding” scenario which a PoS-only chain could be attacked with.
Any modification to the transaction format would need to have a serious reason to do so, fixing a real problem, or following a strategic objective.
The next challenge is to decide who gets to broadcast the block when all nodes could generate the new block at the same time. We propose that the owner of the single input that destroys the most coin-days of all transactions in the block is the only one who may broadcast the block. This owner will sign the block header and broadcast the block. If someone else would like to compete to decide the block they must destroy more coin-days which effectively bids up the cost of earning the right to produce the block and in the process increasing the security per block.
To motivate nodes to perform this function in a manner that includes as many transactions as possible with as much proof-of-stake as possible as quickly as possible the broadcaster earns a cut of the transaction fees proportional to their coin-days destroyed.
These proposals change up the egalitarian Peercoin PoS block issuance with one that favors larger spenders. Also it seems the spenders also issue the block. This seems like a step backward towards centralization.
I though Bitcoin and Peercoin nodes already decide which chain to follow based on the blocks they receive from their peers. The chain that has the most weight is the one followed (not counting synced or hardcoded checkpoints).
Hi nohea,
I see, my post lacked precision … will edit it accordingly. My bad.
My proposal is not to replace the Peercoin Proof-of-Stake algorithm entirely with TaPoS, but to add the hash of a recent block to transactions. This is (afaik) currently viewed as the main “achievement” of TaPoS (and some view it as the main achievement of Dan Larimer, more so than DPoS or Steem ).
The inclusion of the hash of a recent block would make it obvious for nodes when a “secret chain attack” (51%, Long-Range, or Short-Range Nothing-at-stake attack) is performed. In the case of a large reorganization (which most likely is an attack) nodes then could opt to follow the chain “where most of the stake was” (i.e. the chain of which most “big stakers” signed a recent block hash in a transaction) before the attack, and not the chain with most chain-trust.
This could be mandatory or optional, or purely informative (like in NXT, where it’s called “Economic Clustering”) where it’s used simply to know if an attack with a secret chain is tried.
So currently we decide which chain is best using PoS difficulty. This was chosen because it is a harder thing to attain than spent coindays (you can simply hold onto coins for a long time to amass a lot of coindays, PoS difficulty requires active minting). Imagine if you’d never seen the chain before and you were presented with two options: how do you choose which is the real chain? Both chains would include self-consistent hashes. You are proposing to look at blocks recently minted by your friends for their hash, but then can’t you just check which chain your friend minted on and get the same effect? What benefit do the hashes give you?
In the normal scenario, txs are “loose” until they are included in a block. In a chain fork scenario (2 competing blocks mined or minted), txs in the mempool could actually find their way into both chains. If it is a non-attack scenario, a 1 or 2 block reorg would be minimally disruptive since most txs would be in both chains.
Of course, in an attack scenario, many blocks are mined in private and then released, possibly creating a reorg and wiping out the transactions in the other chain (possible double-spend scenario).
If you include a block hash in your tx it seems less likely for it to be included in multiple chains.
I also think nagalim is right, if you want to know if a new block is in your chain, you can check your blockchain for it. There can be other rules added to the node code to detect a large chain a blocks released without needing a block hash in the tx data. Peercoin devs are trying to actually reduce the complexity and quirks of the Peercoin tx format, not add more incompatibility with Bitcoin.
There are other consensus rules in Peercoin which already limit the threat model of “nothing at stake”, i’m not sure yet if adding this will help.
In TaPoS, the block hashes are included in transactions sent by people, e.g. “my friends”, not in blocks minted by them.
If I, as a staker, chose to mint only atop of blocks minted by people I know, and most people chose to do the same, then the whole consensus system would become an oligarchy of whales which would not let enter new minters. It would become a “permissioned” or “consortium” blockchain.
But if I can see on which chain my friends were when they made their last transactions, by checking the block hashes they signed in their TaPoS transactions, and there is a fork with two competing chains, with one of them not including the last transactions of my friends (or including them with a wrong block hash), then I can tell with a high probability that the chain with most recent transactions of my friends is the best chain. I still can mint on blocks of all minters, as long as they include all transactions of my friends, and do not have to restrict it to “known” minting addresses like in your example.
I think the inclusion of block hashes in transactions can help as an “emergency mechanism”. The weak point of PoS is that nodes that re-connect after a longer pause cannot really tell which one is the best chain - they would mint on top of an attack chain if it’s “longer” (has more accumulated PoS difficulty) than the “honest” chain. With TaPoS these nodes could compare both chains. If they see that in one of them, after the fork block, there are no transactions signed by their friends and in the other one there are some, then it’s easy to.know which one is the better chain.
Yes, there are alternatives like a “reorg limit” (as used in Nxt, where no node would re-organize more than 1440 blocks). But TaPoS would be effective even in the case of short reorgs which barely pass the number of confirmations required by merchants to confirm a payment or exchanges to credit deposits.