An alternative consensus algorithm to both proof-of-work and proof-of-stake, proof-of-loss addresses all their deficiencies, including the lack of an organic block size limit, the risks of mining centralization, and the "nothing at stake" problem:

With the feedback on Proof-of-Loss (always privately to my email), I realized the article was hard to understand for lacking:

* A more explicit definition of transaction rights.* An overview of how the algorithm works.

As an abstract could not contain all that, I wrote an introduction with examples.

I also adopted a suggestion of including the current block height in the proof-of-loss data once I realized:

* Preventing the same proof-of-loss from chaining consecutive blocks was not the purpose of the proof-of-loss context, which did it statistically rather than logically.* The presence of that height in the block header made serial chaining easier to enforce, by removing the need to include additional block height information.

An alternative consensus algorithm to both proof-of-work and proof-of-stake, proof-of-loss addresses all their deficiencies, including the lack of an organic block size limit, the risks of mining centralization, and the "nothing at stake" problem:

Post by Mirelo via bitcoin-devWith the feedback on Proof-of-Loss (always privately to my email), I* A more explicit definition of transaction rights.* An overview of how the algorithm works.As an abstract could not contain all that, I wrote an introduction with examples.I also adopted a suggestion of including the current block height in the* Preventing the same proof-of-loss from chaining consecutive blocks wasnot the purpose of the proof-of-loss context, which did it statisticallyrather than logically.* The presence of that height in the block header made serial chainingeasier to enforce, by removing the need to include additional block heightinformation.* Transaction prioritization (which now uses fees instead of rights).* Inactivity fees.Finally, the new version more aptly derives the design and often has better wording.https://proof-of-loss.money/Mirelo-------- Original Message --------Subject: Proof-of-LossLocal Time: February 4, 2017 10:39 AMUTC Time: February 4, 2017 12:39 PMlinuxfoundation.org>An alternative consensus algorithm to both proof-of-work andproof-of-stake, *proof-of-loss* addresses all their deficiencies,including the lack of an organic block size limit, the risks of mining*https://proof-of-loss.money/ <https://proof-of-loss.money/>*_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

On Apr 5, 2017 5:28 PM, "Mirelo via bitcoin-dev" <bitcoin-***@lists.linuxfoundation.org> wrote:With the feedback on Proof-of-Loss (always privately to my email), I realized the article was hard to understand for lacking:

* A more explicit definition of transaction rights.* An overview of how the algorithm works.

As an abstract could not contain all that, I wrote an introduction with examples.

I also adopted a suggestion of including the current block height in the proof-of-loss data once I realized:

* Preventing the same proof-of-loss from chaining consecutive blocks was not the purpose of the proof-of-loss context, which did it statistically rather than logically.* The presence of that height in the block header made serial chaining easier to enforce, by removing the need to include additional block height information.

An alternative consensus algorithm to both proof-of-work and proof-of-stake, proof-of-loss addresses all their deficiencies, including the lack of an organic block size limit, the risks of mining centralization, and the "nothing at stake" problem: