Transactions as Proof of Stake White Paper

[jgorham]

If this proves workable it will solve some substantial problems for new coins. Well done!

[1714781351]

1714781351

[1714781351]

1714781351

[1714781351]

1714781351

[1714781351]

1714781351

[bytemaster]

Missing from the white paper but what I have figured out since is the following:

1) Eliminate all mining at all because any mining leads to control in a proof-of-stake system.
2) To select the node that gets to broadcast the block, pick the input with the greatest coin-days-destroyed to sign the block and broadcast
3) Pay a percentage of transaction fees proportional to the percent of coin-days-destroyed represented by that input
4) Adjust minimum transaction fees per block to control block production rate.

The cost to attack bitcoin today with a double-spend-attack:  6 * 25,000 in electricity consumed in 1 hour + cost of capital.
The cost to attack bitcoin under proof-of-stake:  6 * 12 Billion / 50,000  $1,440,000 held for 1 year.

Resources waisted by Bitcoin: 1.3 billion in electric costs once difficulty catches up with the recent price rise. 

[Etlase2]

2) To select the node that gets to broadcast the block, pick the input with the greatest coin-days-destroyed to sign the block and broadcast

There are some logic gaps here that I'm sure anonymint will be quick to point out.

[AnonyMint]

Etlase2, why don't you help him. He seems open to your sort of design. He is an excellent programmer.

He has funding. You could work more full-time perhaps.

[bytemaster]

2) To select the node that gets to broadcast the block, pick the input with the greatest coin-days-destroyed to sign the block and broadcast

There are some logic gaps here that I'm sure anonymint will be quick to point out.

Please fill me in on the gaps? 

[jgorham]

Would everyone on the network be able to predict which user will create the next block? If individuals can predict when they will create a block then they can cause a bit of trouble. Users can't single handedly create an alternate chain, but if they had a small group of individuals buy almost the same amount of coins at the same time (to start timer), they would potentially create blocks in order. This could allow a small group of individuals to create their own malicious chain to take advantage of the system.

There is a very high chance I don't understand your paper well enough to comment, but the above is something I was thinking about and wanted to share.

[iamnotback]

This proposal appears to be flawed, unless I am missing something. I have only read the first 4 pages thus far.

1. You propose to decrease the coin rewards as coin-days-destroyed volume increases, so this makes it less costly for an attacker to obtain > 50% of the hash rate assuming the attacker includes all the transactions. You apparently are attempting to imply there is no useful attack to do if the attacker is including the most coin-days-destroyed? Please confirm or deny then I will dig into more analysis of this vector.

2. Also how do you choose between someone who generates a proof-of-work hash with lower coin-days-destroyed several times sooner than the network propagation delay versus another who generates it that much delayed with a higher coin-days-destroyed? If you choose the latter, then you've killed the proof-of-work incentive because it means it will always pay to be later and wait for more transactions to arrive.

3. You claim to defeat my Transactions Withholding Attack, by blacklisting those who send blocks with transactions that were not recently seen by all miners. I retorted against this recently. This centralizes the network (all for one and one for all outcome) by requiring every miner to be responsible for the incoming network connectivity of other miners. And it centralizes the network in other ways, such it can't tolerate a temporary partitioning of the network due to connectivity outages.

P.S. By coin-days-destroyed, I assume you mean coin value x days, otherwise you would motivate proliferation of dust.

After some consideration I have decided to replace proof-of-work all together and use transaction fees to regulate block production.  A new block is produced once enough transaction fees have been accumulated.  The node that generates the transaction with sufficient fees broadcasts it.   Ultimately all that matters is that the network reaches consensus and orphans are no issue.  Nodes in the network can even stop propagating new blocks for a couple of minutes after the previous block.  If transactions are coming to quickly I simply up the transaction fee like you would adjust the difficulty in BTC.  These fees are then destroyed to pay dividends rather than paid to a miner. 

As a result it doesn't matter how much hash power you have because you must *pay* to submit a block and the best-fit block is the one with the most coin-days destroyed so even if you pay to submit a block with no transactions, it will be rejected.

3. Does not centralize the network, it is a local calculation performed by all nodes relative to their peers.

Yes, coin value * days.

Quoting this very important historical event, so it can't be deleted.

[SkynetInvasion]

hi
i noticed you deleted you telegram account recently
why?
i am still waiting the letter and when it arrives how can i contact you?
please contact me at @AmbrogioOrfeu on telegram

[Cryddit]

It sounds like everybody is going to be waiting for the instant when the amount they personally can spend puts the transaction fee total over the top, and then releasing blocks all at once.  Sorting it out ought to be fun.