Transactions as Proof-of-Stake & The End of Mining

[valtr]

At this moment I am mining Protoshares 24 hours daily + I am runing the Protoshares wallet with >100 nodes connected. I hope running the wallet is helpfull for the community.
As far as I understand running Bitshares client will be the same + some litle income to help cover the cost of running computer.

[vikram]

I have been working on the consensus algorithm and while it is fast it has the following problems:
1) There is no way to compensate people for running full nodes. 
2) The cost of running full nodes grows with N^2 the number of nodes participating in the consensus process
3) There is no way to reward nodes that participate in consensus to cover the cost of bandwidth growing
4) If you rely on charity, the regulatory risks may result in nodes not proliferating
5) If you do reward nodes participating in the consensus process your costs either grow N^2 or nodes on the UNL have financial incentive NOT to add new nodes to the inner circle.
6) If you rely on indirect benefits then the incentives might not be properly aligned.

My conclusion is that the primary benefit for using the consensus algorithm is automatic failover in the event some nodes go down.  I also believed it was more decentralized that BTC but perhaps less so than NXT.

To this end it seems I must strive to achieve the goal of decentralization and thus have a new proposal for implementing TPOS. 

1) The "mining" reward will be kept to 1% of transaction fees.  We do not want significant resources thrown at this because the only purpose of mining now is to decide on the next block, NOT to secure the network.  The cost of mining should thus be very small and amount to an election.

2) Let N be the number of blocks per year
    Let M be the money supply at the start of the year
    Let m be the money transacted and n be the number of days since it was last moved.
    Let CDD be m*n
    Let ACDD be the Average CDD per block which can be calculated as N*M/N or M
    Let T be the base mining difficulty target (adjusted via moving average)
    Let BCDD be the CDD actually destroyed by the block.

    IF( BCDD > ACDD ) BCDD = ACDD.

    Given the above we can define the target difficulty for solving a block as:
   
    1 + T*(1- BCDD/ACDD)^2

3) The only transactions that count toward CDD are those that reference a prior block in the chain, thus miners will be unable to build secret chains using CDD of transactions produced by regular users.
4) If two blocks are found that extend the same chain, the one with the most CDD wins.
5) If two blocks with the same CDD are found then the one with the higher hash wins.

Results:  everyone can mine and attempt to produce a block at some 'base level' that is not perceptible to the user.  Someone with a large amount of the share supply would have limited advantage because everyone gets to mine POS using everyone else's transactions and everyone is mining at a base level, say 1% of CPU. 

The only thing a 'miner' can do to harm the network is Denial of Service (blocking transactions), but a miner attempting to do this would be at a disadvantage against all of the miners which are including transactions. 

So what can someone with unlimited hashing power do...  they can still perform a DOS on the network provided they have  100,000 * the number of computers on the network in hash power.  Unfortunately for them, the cost would far exceed the fees earned. 

Something to think about.

How is that for decentralized?

• Overall, this seems to precisely be an implementation of the original TaPOS paper. Are there any fundamental differences?
• Do transactions reference a "parent" block, or just any "recent" block (and what does "recent" mean)?
• How exactly are transactions from a forked chain migrated to the true chain?
• What is target block time?
• So making a transaction with large CDD can be used to immeditately confirm block before target block time?
• Why the square in the block target difficulty calculation?
• What hashing algorithm?

[bytemaster]

This is very similar to the original TaPOS paper, the primary difference is difficulty adjustment and mining reward. 

Transactions must reference one of the 2 most recent blocks for their CDD to count toward reducing the mining difficulty.

Transactions from a forked chain can be migrated like any new transaction, their CDD does not count when migrated.

Target block time is 5 minutes.

In my implementation I have removed the square after further review.

Momentum is the hashing algorithm.

[toast]

5) So making a transaction with large CDD can be used to immeditately confirm block before target block time?

You missed this one

The only thing a 'miner' can do to harm the network is Denial of Service (blocking transactions), but a miner attempting to do this would be at a disadvantage against all of the miners which are including transactions. 

I think that if miners still have the ability to choose transaction order then pools will form that pay out higher rewards from selling transaction order advantage to traders

[vikram]

This is very similar to the original TaPOS paper, the primary difference is difficulty adjustment and mining reward. 

Transactions must reference one of the 2 most recent blocks for their CDD to count toward reducing the mining difficulty.

Transactions from a forked chain can be migrated like any new transaction, their CDD does not count when migrated.

Target block time is 5 minutes.

In my implementation I have removed the square after further review.

Momentum is the hashing algorithm.

What prevents someone from picking a block far in the past, adding their own transaction with large CDD to its transaction set, then mining and broadcasting a new block with the resulting higher BCDD, causing a huge reorg of all children blocks?

[bytemaster]

This is very similar to the original TaPOS paper, the primary difference is difficulty adjustment and mining reward. 

Transactions must reference one of the 2 most recent blocks for their CDD to count toward reducing the mining difficulty.

Transactions from a forked chain can be migrated like any new transaction, their CDD does not count when migrated.

Target block time is 5 minutes.

In my implementation I have removed the square after further review.

Momentum is the hashing algorithm.

What prevents someone from picking a block far in the past, adding their own transaction with large CDD to its transaction set, then mining and broadcasting a new block with the resulting higher BCDD, causing a huge reorg of all children blocks?

Because there would be no CDD built on top of that modified block.   

There is also the fact that chain will never perform a reorganization beyond a couple of blocks.  I believe bitcoin almost never has a reorg beyond one or two blocks.  Nodes assume the network has remained connected and thus any major reorganization is an indication of an attack.   Unlike bitcoin I allow the head block to be replaced when two blocks are found at once so the network doesn't split based upon latency in this case.  All nodes build off of the best current block.

Bottom line:  unless there is a problem with network infrastructure it is unlikely any new 'fork' is legitimate and it should be rejected by default.  In other words, it will not be propagated or relayed through the network except by manual intervention.  If there is a problem with network infrastructure then all trading must stop immediately on the minority chain because market transactions cannot be migrated between chains. 

In this case it works like ripple consensus, all nodes assume the public information they already have is legitimate and reject anything that would suggest otherwise.   

[yidaidaxia]

Target block time is 5 minutes.

If I understand it correctly, that means every transaction need at least 5 min to complete. I think it's too long for a efficient system where people could do their bitassets trading business on it..  Any idea to reduce the transaction time.? I know it's difficutly since ripple way does not work as your assessment.

[bytemaster]

Target block time is 5 minutes.

If I understand it correctly, that means every transaction need at least 5 min to complete. I think it's too long for a efficient system where people could do their bitassets trading business on it..  Any idea to reduce the transaction time.? I know it's difficutly since ripple way does not work as your assessment.

In a decentralized system you are limited by the speed of light if you want stability.   Strictly speaking blockchains do not need to be decentralized to serve their purpose.   Someone could implement the exact same transaction model on a central server and as long as the blockchain was public record you could trust them and if they were shutdown someone could just migrate the chain to a new server.  Such a chain could offer instant confirmations and still be trust-free, but centralized.

Thus I content that decentralization has costs but is not necessary for the trust-free revolution.   For now people expect things to be fully decentralized because of regulatory issues. 

Ripple consensus is ultimately a fig leaf of decentralization that is only slightly better than having a dedicated central server with automatic fail over.   The purpose of consensus is to agree on the next closed ledger so I can see it working something like this:

Everyone agrees to let Sam decide on the next closed ledger and he can have that role until he abuses it even once or he dies.  Then we have a chain of command where if Sam is no longer able to perform the job (arrested, etc) then Alice takes over.   Alice could even be set up behind a TOR hidden service.    Neither Sam nor Alice could generate alternative chains without getting caught their alternative chains would be rejected.  Furthermore, Alice could simply sign everything Sam produces and therefore they would have to collude to produce an alternative chain.

I think you can see from this that decentralization of block production is more a necessity of marketing than of security of the network.  Though some could argue that it is a necessity of security for those that would end up signing every block as they would become giant targets for government shutdown.  In the future, once governments lose this war against crypto, then many centralized services will compete to offer instant transactions based upon the premise of open/audit-able blockchains.

[bytemaster]

After looking at the math it is clear to me that if a block is even a few CDD shy of the target for the minimum threshold no one will mine because the difficulty would be so much higher that it will not be profitable. 

Therefore in order to 'mine' every block must destroy the minimum number of coindays.  This means that for the blockchain to progress shareholders everywhere must be ready to use their accumulated coindays to mine.   So the question becomes how to divide the transaction fees between the miners and the dividends.   This is another case where I hate to employ price fixing so whether I set it at 100% like NXT, 50% like the original BTS white paper, or 1% like I have suggested recently the result is price fixing.

Fortunately I have a solution that is fair for all and avoids price fixing.  When a miner uses their own coindays to secure the network, they get a percentage of the fees in that block proportional to percentage of the CDD they provided vs those provided by 3rd party transactions.   This means that dividends are earned when security is provided entirely by real network transactions and that mining fees are earned when security is provided by the miner using their own CDD to secure the network. 

This should motivate miners to consume as many CDD as they can as quickly as they can to earn the maximum fees and move the network along.   

The next question people may have is how will transaction fees be priced?   Minimum fee will be set such that if the blockchain was running a full capacity (512K per block) that 1% of the share supply per year would be earned as dividends.  Then I will adjust the fee like I adjust difficulty to maintain an average block size of 512K and a maximum block size of 1 MB.   So if demand picks up then so do fees and when demand falls below 512K below fees will fall back to the minimum.   

[wan3646886]

  :'(什么个意思吗。。

[wan3646886]

简直就是坑爹啊

[yidaidaxia]

Thanks for your feedback and detailed explaination. Now I see the point and agree w/ you that, currently, decentralization is more important than fast trasaction. But 5 min is still too long to current people's mind set/expectation, let's see if we could educate people to accept that and the system/market could operate effectively. The only way to do this is to conduct the bitshares XT, so looking forward to 2/28 now. 

Target block time is 5 minutes.

If I understand it correctly, that means every transaction need at least 5 min to complete. I think it's too long for a efficient system where people could do their bitassets trading business on it..  Any idea to reduce the transaction time.? I know it's difficutly since ripple way does not work as your assessment.

In a decentralized system you are limited by the speed of light if you want stability.   Strictly speaking blockchains do not need to be decentralized to serve their purpose.   Someone could implement the exact same transaction model on a central server and as long as the blockchain was public record you could trust them and if they were shutdown someone could just migrate the chain to a new server.  Such a chain could offer instant confirmations and still be trust-free, but centralized.

Thus I content that decentralization has costs but is not necessary for the trust-free revolution.   For now people expect things to be fully decentralized because of regulatory issues. 

Ripple consensus is ultimately a fig leaf of decentralization that is only slightly better than having a dedicated central server with automatic fail over.   The purpose of consensus is to agree on the next closed ledger so I can see it working something like this:

Everyone agrees to let Sam decide on the next closed ledger and he can have that role until he abuses it even once or he dies.  Then we have a chain of command where if Sam is no longer able to perform the job (arrested, etc) then Alice takes over.   Alice could even be set up behind a TOR hidden service.    Neither Sam nor Alice could generate alternative chains without getting caught their alternative chains would be rejected.  Furthermore, Alice could simply sign everything Sam produces and therefore they would have to collude to produce an alternative chain.

I think you can see from this that decentralization of block production is more a necessity of marketing than of security of the network.  Though some could argue that it is a necessity of security for those that would end up signing every block as they would become giant targets for government shutdown.  In the future, once governments lose this war against crypto, then many centralized services will compete to offer instant transactions based upon the premise of open/audit-able blockchains.

[Troglodactyl]

For a trading platform chain I think people will be comfortable with much longer block times than they are payment system focused chain.  Of course we're likely to see some clones with experimental new target times once it takes off anyway.

[alexkravets]

Mr bytemaster,

Imagine there was a modified Ripple consensus algorithm that would not need any (local) static UNL lists ... i.e. the consensus process would be done exactly as it is today in Ripple, but transaction withholding ( since transactions are digitally signed and hence self-validating AND impossible to replay, transaction withholding is the only way to attack vector left to try to frustrate the consensus) AND validation and other forms of peer message spam (as distinct from transnational spam which is controlled through adaptively escalating fees) is also handled by such a modified version.

Would such a modified Ripple consensus satisfy ALL your decentralization, instant (as permitted by bandwidth and speed of light lower bound on convergence time) confirmation and lack of UNL cartel requirements ?

(Note, your earlier remark about N^2 load growth inside ripple network as number of peer nodes growth would apply but only in the case of each peer wanting to connect to all others, instead they have the usual low and high watermark P2P networking code)

[bytemaster]

If such an algorithm existed I would be very interested in it.