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

[arkanaprotego]

Indeed, I think that vote by shares is the way to go. I am just unsure that spontaneous transactions are the best proxy for shares held, as it can be tightly coupled, but also completely decoupled. At the very least there should be an automated safety mechanism to try and reestablish dominance of your branch by destroying CD, should it become the shortest one, if you have been on that branch for long. I don't think most users would be able to override the detection of the longest chain to keep spending more CD on the legitimate branch.

PoS and PoW have similarities: if you want more power, you have to invest, either in ASIC or in shares. But then, unlike CD, hashrate cannot be saved for later. I think it would be nice to mimic this property, by having CD spent continuously on the branch you follow, like hashing power. Your idea of using transactions seems valid, and IMO is a generalization of PPCoin's PoS mining special transactions. What I propose is a reward for all destroyers of coin-days, proportionally to their coin-days destroyed, to reward them for securing the network, and the removal of the delay for CD regeneration, not to penalize transactions. What it means is that CDD/day is constant and equal to the number of coins that endorse a branch by "PoS mining" or spending on it, which is what you wanted to achieve with "votes by shares". As long as the main branch maintains more than 50% of the coins always "PoS mining" (EDIT: by honest nodes), your branch cannot be forked.

Lets assume that there is no delay in CD accumulation then an attacker with 1/50,000 of the money supply could spend enough CDD every other block to build 50% of the blocks on average. Putting a delay before CD start accumulating of 100 blocks means the attacker would only have 1% influence on block production assuming 1/50,000 of the money supply. 

Sorry I lost you there... You mean both the attacker who has 1/50,000 and the rest of the network that has 49,999/50,000 have the same influence? Unless I missed something, I think no delay only means that whoever has the most money wins, which seems fair in this kind of situation. If someone has more than 50% of the money then something is rotten in the Decentralization.

If I understood your paper well, I think your motivation to introduce the delay was to protect about people owning too many coins. But as you said yourself, if this happened, then any network would be vulnerable.

Unrelated remark:

Assuming you want to take on the role of securing the network, rather than just 'using the network' which is what 99% of users will be doing.  They may randomly profit when they happen to have the most coindays destroyed (because it is their first trx in a year).   So lets assume there is a certain base level of CDD providing security regardless of any other financial incentive.

No, this is just what an optimized client would do. Sooner or later it will be available to the public.

[bytemaster]

Ok so in keeping with the DAC metaphor I have realized an entirely new perspective on Proof-of-Stake.  Every shareholder is given one vote per block per share toward establishing a global consensus.   As a result shareholders must vote to the best of their knowledge and not simply vote how everyone else is voting.  The premise here is that in a well connected network there should be no 'big surprises' and thus everyone will have seen everything.  The chances of something you haven't seen being legitimate are very small.

When a new node connects it connects to friends and family as well as well known public nodes and trusts them first. 

If there is a 'dispute' among the shareholders as to which chain is legitimate, many big players get off the sidelines and vote. 

So like Ripple can reach consensus without proof of work, shareholders can also reach consensus without proof of work.  In the short term (1-3 blocks) shareholders vote by largest proof-of-stake, in the long term they vote with what they have known the longest.

To control such a network requires a majority of shareholder votes.   

In the mean time if there is a 'dispute' resulting in a chain-fork, then nodes can follow both forks and include transactions in both forks.  You can consider your transactions 'confirmed' in such a case as long as they are valid on both forks.  Eventually one fork will gain enough of a lead that the other fork stops growing and dies off due to lack of votes and therefore inability to add new blocks. 

I suppose in the event of a chain fork there is also the concept of 'new CDD' and 'used CDD' where 'new CDD' is any CDD older than the fork itself and 'used CDD' is CD earned on the fork.  This alternative measure could also be used to see if a fork is gaining acceptance from new users or simply supporting itself with its own CD.

[bytemaster]

bytemaster,
Thank you for your clarifications, but I am not sure you can neglect time that easily when considering security.

1) The best usage of your CD is still to spend them when you are the most certain that you will be the biggest CD destroyer.

Assuming you want to take on the role of securing the network, rather than just 'using the network' which is what 99% of users will be doing.  They may randomly profit when they happen to have the most coindays destroyed (because it is their first trx in a year).   So lets assume there is a certain base level of CDD providing security regardless of any other financial incentive.

3) Let me try another, more graphic attack to show some issues and try to solve them.
I have 34% of the coins. I don't move them for a year, to get the maximum CD out of them. Then I transfer them all to myself. I am most likely the biggest destroyer of CD in the block. I don't sign it. Now 4 sub-cases:
a) You ban my output and start another block without it. Right after that, I broadcast my signed block. Now all the new nodes that are plugged into the network and were not there when you banned me will follow me, because I have the chain with the biggest CDD, and you cut yourself from it. They can also not trust your ban, since you look like the attacker.
b) You don't ban it and start another block without it. I wait for a year. During this year, the average coin is moved every 2 days. With the 1 day delay after each transaction, your 66% coins generated and destroyed less CD than my 34% had then. I publish the block I had saved, and instantly reverse 1 year of transactions. Note that the more you move your coins, the less I need coins.
c) You don't ban it and include it in your next block, signed by #2 CD destroyer. You are quite sure to be in the longest chain of CDD and I have lost all my CD, unless... I publish the block, which is what you wanted me to do in the first place. I must do it fast, because if I wait too much, you will add more transactions to your chain and your chain will be longer in CDD than I can make mine.
d) Same as c, but I lied and I actually had 40% of the coins. After you start on your version of the block with my 34%, I wait until you destroy nearly as much as my remaining 6% are worth in CD, and publish a block with my 6%. This might take long or not, depending on the volume of transactions.

I think there was a misunderstanding here... when I said 'ban' I mean I just don't include the transaction in the block I produce, though anyone with more CDD is able to include that transaction.   Considering Orphans are not really an issue, anyone in the top 5 CDD inputs from unique transactions could strip out the largest transaction and broadcast all at the same time.  The network will ultimately accept the block with most CDD regardless of which of the top 5 broadcast.   

Long story short, I think the delay on CD regeneration is dangerous, because it creates distortions that can be exploited both ways, and that counting security in CDD is quite impractical if CD are not destroyed linearly, as it exposes you to forks originating far in the past. If C coins have not moved since a date T, and CDD(T, now) coin-days have been destroyed between date t and now, then the chain can be forked back to its state at t by someone who controls the coins if:
CDD(t, now) < C*max(now-T, 1 year)
To prevent this, CDD must be high. However, due to the delay, it is faster to generate unspent CD than to destroy CD.
With no delay though, the fork that accumulates CDD at a faster rate is always the one that has the most coins backing it. If these CD were spent automatically, they would prevent forks, as well as the accumulation of CD required for a fork.

We need to be very careful when looking at attacks to see what harm can be done... lets start with a very basic premise:

1) Nodes that are connected continuously to other nodes in many continents will see any fork of sufficient age as suspect.  They should not automatically switch to the chain with more CDD simply because it has more CDD.  After all, if all of the nodes on the main chain see this they could simply 'counter' with a few transactions that 'fix' the problem making the public chain the longest again.  I think any fork more than an hour old without any obvious network issues has a higher burden of proof. 

Lets assume that there is no delay in CD accumulation then an attacker with 1/50,000 of the money supply could spend enough CDD every other block to build 50% of the blocks on average. Putting a delay before CD start accumulating of 100 blocks means the attacker would only have 1% influence on block production assuming 1/50,000 of the money supply. 

Note a 51% attack on any proof-of-work network is possible if the attacker has access to 5% of the money supply, even Bitcoin.   5% of the money supply is enough to purchase 51% of the hash power.  $600 million could buy you a 51% attack on bitcoin.  So I think for the purpose of evaluating POS we should only consider attacks that are possible with less than 5% of the money supply otherwise it is an unfair comparison.

[arkanaprotego]

bytemaster,

Thank you for your clarifications, but I am not sure you can neglect time that easily when considering security.

1) The best usage of your CD is still to spend them when you are the most certain that you will be the biggest CD destroyer.

3) Let me try another, more graphic attack to show some issues and try to solve them.
I have 34% of the coins. I don't move them for a year, to get the maximum CD out of them. Then I transfer them all to myself. I am most likely the biggest destroyer of CD in the block. I don't sign it. Now 4 sub-cases:
a) You ban my output and start another block without it. Right after that, I broadcast my signed block. Now all the new nodes that are plugged into the network and were not there when you banned me will follow me, because I have the chain with the biggest CDD, and you cut yourself from it. They can also not trust your ban, since you look like the attacker.
b) You don't ban it and start another block without it. I wait for a year. During this year, the average coin is moved every 2 days. With the 1 day delay after each transaction, your 66% coins generated and destroyed less CD than my 34% had then. I publish the block I had saved, and instantly reverse 1 year of transactions. Note that the more you move your coins, the less I need coins.
c) You don't ban it and include it in your next block, signed by #2 CD destroyer. You are quite sure to be in the longest chain of CDD and I have lost all my CD, unless... I publish the block, which is what you wanted me to do in the first place. I must do it fast, because if I wait too much, you will add more transactions to your chain and your chain will be longer in CDD than I can make mine.
d) Same as c, but I lied and I actually had 40% of the coins. After you start on your version of the block with my 34%, I wait until you destroy nearly as much as my remaining 6% are worth in CD, and publish a block with my 6%. This might take long or not, depending on the volume of transactions.

Long story short, I think the delay on CD regeneration is dangerous, because it creates distortions that can be exploited both ways, and that counting security in CDD is quite impractical if CD are not destroyed linearly, as it exposes you to forks originating far in the past. If C coins have not moved since a date T, and CDD(T, now) coin-days have been destroyed between date t and now, then the chain can be forked back to its state at t by someone who controls the coins if:
CDD(t, now) < C*max(now-T, 1 year)
To prevent this, CDD must be high. However, due to the delay, it is faster to generate unspent CD than to destroy CD.
With no delay though, the fork that accumulates CDD at a faster rate is always the one that has the most coins backing it. If these CD were spent automatically, they would prevent forks, as well as the accumulation of CD required for a fork.

[bytemaster]

arkanaprotego,
   Thank you for your response.   Let me see if I can address some of them and find enhancements.

1) People make transactions for the sake of the transaction, there is no need to reward them because they are already paying a fee for their transaction.  As a result choosing to reward the largest CDD (coin-days-destroyed) holder for hanging around to sign the block does not bother the others.

2) CDD variance does affect confirmation times, but does not affect security.  The reason is that security is defined in terms of CDD and not in terms of blocks.  So if there are many small blocks with low CDD then you may have to wait longer.  The good news is that some times you only have to wait 1 block if a large number of CDD are destroyed.  Thus, on average you will wait 1 hour for confirmations, but it could be 10 minutes or it could be 2 hours.   The better news is that you can use your own CDD to accelerate confirmation if you need it quickly. 

3) The DOS attack you mention is easily countered by the existing financial incentives.  If it appears the #1 CDD holder isn't going to sign in a timely manner, the #2 CDD holder will automatically attempt to claim, then the #3 CDD holder, etc...  The outputs that attempted the DOS would be flagged and not included in new blocks by any other node which would force the owner of those outputs to eventually sign a block with them or never be able to spend them.   This flagging process would have to be carefully designed to prevent honest nodes suffering from network latency from being punished, but I am sure there is a metric that will have few false positives.

4) Infancy... the great thing about POS is that your security isn't defined by blocks but by CDD.   Early stake holders can set up automated scripts to periodically provide CDD and those creating transactions can accelerate the CDD confirmations by paying fees to motivate CDD destruction.   Essentially, every honest node looking to earn extra dollars can monetize their CDD.   

[arkanaprotego]

I think the whole concept of using transactions to secure the network is a little risky, especially during the infancy of a crypto. While there are not many transactions, the network is vulnerable. If everybody is sitting on their Bitshares, the first one to move will have a disproportionate influence. Conversely, after busy trading periods, the network will be depleted in CD because of the delay on CD regeneration after transactions. The network will be more vulnerable then as well.

The first flaw I can see in your proposal is related to this: if you only reward the biggest destroyer of CD, then you implicitly penalize the smaller. So to maximize their gains, the others will just keep their CD by hoarding old coins and spending new coins. Meanwhile the network destroys fewer coins and the network is insecure. You need to provide an incentive or a mechanism to ensure there will always be a steady flow of CD. If CDD fluctuates, the blockchain security is lowered, as periods of lower CDD are opportunities for cheap attacks.

Another thing to consider in your latest proposal is that it introduces a single point of failure (the broadcaster), even though you planned some backups.

It is quite vulnerable to a DOS attack. If an attacker were to score all the highest transactions in terms of CDD, he could delay the chain for long. The more fragmented the legitimate transactions are, the cheaper it is to attack the network.

So I think you should not restrict who can broadcast using such a serial scheme.

The issue with CDD in transactions is that they do not completely meet the non-reusability requirement that is necessary in PoW schemes, and probably in all blockchain structures. Transactions are tied to the previous block, but it does not matter what block they are included in, they are always valid. As a result it is trivial and cheap to generate a better block by simply adding a transaction to the original block. I think you need a way to make transactions depend on each other for this to work properly.

[bytemaster]

The proof-of-stake algorithm that uses coin-days-destroyed to identify the 'best chain' works for security, but is missing one benefit of mining: decentralized decision on who creates the next block and when it should be created.   

There needs to be a way to prevent an attack on the network by the constant generation of 'better blocks' that replace the current head block.
   - this could cause new transactions to 'waist' their confirmation efforts on orphan blocks and thus weaken the coin-days destroyed on the main block.
   - this could in theory prevent any new blocks from ever being added.   

The first step in this process is to solve the problem of who should be allowed to broadcast a block.  In bitcoin any block that meets the proof-of-work may be broadcast, but under proof-of-stake there is no similar metric.   I would like to propose the following set of solutions:

1) A block may only be produced by the signer of the input with the most coin-days destroyed.
2) A block must meet the minimum transaction fee threshold which is adjusted to control the rate at which blocks are produced.
3) A given output may only be used to broadcast once.
4) The creator of the block receives a percentage of the transaction fees proportional to their fraction of the coin-days destroyed in the block.

Lets see if this prevents attacks:
1) To control the production of blocks you must regularly destroy more coin-days per block than anyone else.  This is a significant limit.
2) To maximize profits you must include as many transactions with fees as possible
3) To insure you receive the transaction fees you must make sure your block destroys as many coin-days as possible or someone else could replace it (if they destroy more coin-days than you did) and then collect all of the fees. 
4) To broadcast a block, you must have a stake in that block and pay a transaction fee so this limits potential broadcasters to at most 4000 that might have a transaction in the block.  It is further limited to those with a large stake and finally limited by the need to collect enough fees.

Potential Problems:
1) Someone could broadcast a transaction that destroys a large number of coin-days and then refuse to broadcast a signed block.  In this case the transaction would have to be removed from the set of included transactions.   This would happen automatically 1 minute after a normal node would have signed and broadcast a block and the 2nd place input would become the 'first-place' input and sign the block.   

What have we achieved?
1) globally unique, expensive, one-time, deterministic selection of who has permission to broadcast a block.
2) financial incentive for this node to include as many transactions as possible in order to maximize their block reward
3) financial incentive to include as many coin-days destroyed as possible to minimize the risk of their block being orphaned and losing fees
4) automatic fail-over in the event the expected signer fails to deliver a block as expected.
5) minimum fee threshold to prevent creating blocks that don't pay the expected dividends and limit the block production rate.

So given these rules how would you take over the network for a profit?
 

[bytemaster]

I'm trying to understand all of this... I think I read elsewhere that half of the transaction fees will be paid as dividends split up amongst all holders of coins and half will be paid to the miner along with a block.. or that was just an idea, not sure.

Trx fees are paid as dividends and thus 'lost'

Why is that "lost"?

--

I think maybe this idea is okay if I understand part of it. You might want to explain in the beginning of your paper what "coin-days-destroyed" is because I wasn't familiar with this jargon.

Why is the best chain decided by CDD? You mean because people are using the currency in transactions more than just mining and sitting on them waiting for their price to go up?

How do you decide a minimum mining difficulty, just something arbitrary like coins not incurring time until after the first 24 hours as mentioned in the paper?

When I say they are lost I mean that 'destroying coins' causes equal economic transfer of wealth as a dividend payment.   With proof-of-stake there would be no mining rewards and thus 100% of transaction fees are 'destroyed' and paid as dividends. 

The only remaining purpose for 'mining' is to decide who gets to broadcast the next block.  This mining is still waisted mining that consumes electricity and opens the door for people to attack.  If we switch the metric to total trx fees then the individual who publishes the transaction that pushes it over the threshold is the one that gets to publish the block.  In this case the 'proof-of-work' is the transaction fee (paid as dividend). 

So the question then becomes what is the minimum transaction fee?   I think it could be 1% of the money supply per 100 GB of block chain data (1 year).   You are really paying for storage space in the block chain and that is independent of the content of the transaction.   The minimum fee can then be used to make sure that no more than 100 GB of blocks are generated per year.  If blocks are coming too quickly that means transaction volume is too high and fees should go up. 

Given two chains, the 'best chain' is the one with the most coin-days-destroyed.  Ties go to the chain with the lowest money supply.  When a block is assembled it should include the transactions with the most coin-days destroyed first (for security) and then highest fees second.

[bytemaster]

I am trying to determine if trx fees can be used as a metric to limit block production rather than mining difficulty.  Trx fees are paid as dividends and thus 'lost' and if you increase the minimum fee per block you would slow down block production just like increasing mining difficulty. 

Every transaction that cares about being confirmed rapidly would include fees.  These fees just serve to limit the production rate without waisting CPU power on mining.  The best chain is still decided by coin-days destroyed. 

You could then have a fixed 'minimum mining difficulty' used to determine settle cases where multiple people generate transactions at the same time.   So the process is, generate trx, add it to block, check to see if min fee has been reached, if so hash block, and 1 in 100 chance that it will meet the minimum difficulty.   

So now the higher the transaction fees the more expensive it becomes to generate empty blocks and alternative chains.   

Just some thoughts, looking for feedback.

So every block needs to have a minimum amount of transaction fees. Wouldn't this cause block production to slow down when transactions slow down?

Yes it would slow down block production, but anyone who cares about rapid block production can pay a fee to speed it up.  I think BTS will be more likely suffer from too many transactions due to the built in exchange and limited block size.

[praxeologist]

I'm trying to understand all of this... I think I read elsewhere that half of the transaction fees will be paid as dividends split up amongst all holders of coins and half will be paid to the miner along with a block.. or that was just an idea, not sure.

Trx fees are paid as dividends and thus 'lost'

Why is that "lost"?

--

I think maybe this idea is okay if I understand part of it. You might want to explain in the beginning of your paper what "coin-days-destroyed" is because I wasn't familiar with this jargon.

Why is the best chain decided by CDD? You mean because people are using the currency in transactions more than just mining and sitting on them waiting for their price to go up?

How do you decide a minimum mining difficulty, just something arbitrary like coins not incurring time until after the first 24 hours as mentioned in the paper?

[phoenix]

I am trying to determine if trx fees can be used as a metric to limit block production rather than mining difficulty.  Trx fees are paid as dividends and thus 'lost' and if you increase the minimum fee per block you would slow down block production just like increasing mining difficulty. 

Every transaction that cares about being confirmed rapidly would include fees.  These fees just serve to limit the production rate without waisting CPU power on mining.  The best chain is still decided by coin-days destroyed. 

You could then have a fixed 'minimum mining difficulty' used to determine settle cases where multiple people generate transactions at the same time.   So the process is, generate trx, add it to block, check to see if min fee has been reached, if so hash block, and 1 in 100 chance that it will meet the minimum difficulty.   

So now the higher the transaction fees the more expensive it becomes to generate empty blocks and alternative chains.   

Just some thoughts, looking for feedback.

So every block needs to have a minimum amount of transaction fees. Wouldn't this cause block production to slow down when transactions slow down?

[bytemaster]

I am trying to determine if trx fees can be used as a metric to limit block production rather than mining difficulty.  Trx fees are paid as dividends and thus 'lost' and if you increase the minimum fee per block you would slow down block production just like increasing mining difficulty. 

Every transaction that cares about being confirmed rapidly would include fees.  These fees just serve to limit the production rate without waisting CPU power on mining.  The best chain is still decided by coin-days destroyed. 

You could then have a fixed 'minimum mining difficulty' used to determine settle cases where multiple people generate transactions at the same time.   So the process is, generate trx, add it to block, check to see if min fee has been reached, if so hash block, and 1 in 100 chance that it will meet the minimum difficulty.   

So now the higher the transaction fees the more expensive it becomes to generate empty blocks and alternative chains.   

Just some thoughts, looking for feedback.

[td services]

Can anyone find details on nxt proof of stake.

Code is supposed to be released 1/3/14. Parts may be requested for review and some snippets are posted at https://bitcointalk.org/index.php?topic=352286.0

So no white papers... closed development... grrr.

Yes, I liked the idea in the intro of distributed ebay type markets and wanted to invest a little, but the project seems kinda squirrely.

[bytemaster]

Can anyone find details on nxt proof of stake.

Code is supposed to be released 1/3/14. Parts may be requested for review and some snippets are posted at https://bitcointalk.org/index.php?topic=352286.0

So no white papers... closed development... grrr.

[td services]

Can anyone find details on nxt proof of stake.

Code is supposed to be released 1/3/14. Parts may be requested for review and some snippets are posted at https://bitcointalk.org/index.php?topic=352286.0