Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 39698360 for ; Thu, 6 Apr 2017 02:43:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f174.google.com (mail-qt0-f174.google.com [209.85.216.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9B493186 for ; Thu, 6 Apr 2017 02:43:19 +0000 (UTC) Received: by mail-qt0-f174.google.com with SMTP id i34so26345465qtc.0 for ; Wed, 05 Apr 2017 19:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to; bh=8Sr7rmYIp8+Ty8seTcMRCZohpOHjSI8h/DgEtFvJihM=; b=SSW71NJwh4v3LJXUY99Jj7tW9LVWjkpbC+UAThwKY71DS+Ag3CeUEY9k86kdTh+LTY 65q9qmxhrU9QEKBs7wxFUUqzuR/Me1iWb7Fi4AvXSB6+f0webcEo/p/0huAjbs+jSWLS TvVY6fTYgN2LjptPM6PACtQKW1IpnXKdNF5L8bjR6n9Ee/A1+rtVVMngaWxPXtufhptM ECk+3F1m2jVoDws2FrpDJ8N/cK3pm/mISdVJ55hWwqxjFuk5yBOFfmYtke44hP5d4OHz /9o+xrsMednNLZpRPZCnqE6SFWcuYbQvQ74YqAdb/zxhuzgqhNtVi/1eGGjcnTRoG58K i21g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to; bh=8Sr7rmYIp8+Ty8seTcMRCZohpOHjSI8h/DgEtFvJihM=; b=X3fFcgOCHAsyOgr5Pzl2YlmdP4Su7J/Wlu00sJWDX3q8//3zoNl7W6lMZhJMSzbASQ iGwWz/8czUlvgUUWPsFZI6GUuO4hgbA6us8pn9rihSKm76OheGyyzedgWmoIEsd4XkSh uFGfeQMDghCfUurp4FgwWhycOePUT8OgCAoReHyMdXysqD1QsaRDXzea12SZlXlusTrL MNABgW9YXOxGRXjVhRWOAFKSljvCqDBkO+grfkMGvrvAx4CL6XX2Zv465ZcUYNoUOXD5 44NinVxXygGFka5DsT1oG+flzHWuc/7/4t27N16Iw49mKd0o8dsEhdHKs2ClrASEQSCf 5h/Q== X-Gm-Message-State: AFeK/H0thWy1WOID1eXXwP/fXDfiF4OsGRqh7Gyf5tlBM8C9DaIfNNtUf9RCR5hM54KikTU4Dh+0fCrsc77/Bg== X-Received: by 10.237.59.198 with SMTP id s6mr35796705qte.161.1491446598811; Wed, 05 Apr 2017 19:43:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.55.113 with HTTP; Wed, 5 Apr 2017 19:43:18 -0700 (PDT) Received: by 10.200.55.113 with HTTP; Wed, 5 Apr 2017 19:43:18 -0700 (PDT) Reply-To: erik@q32.com In-Reply-To: References: From: Erik Aronesty Date: Wed, 5 Apr 2017 22:43:18 -0400 Message-ID: To: Mirelo , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c19053eb9471d054c7678d3 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 06 Apr 2017 02:44:25 +0000 Subject: Re: [bitcoin-dev] Proof-of-Loss X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 02:43:20 -0000 --94eb2c19053eb9471d054c7678d3 Content-Type: text/plain; charset=UTF-8 Is this the same as proof of burn? On Apr 5, 2017 5:28 PM, "Mirelo via bitcoin-dev" < bitcoin-dev@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. > > While revising the algorithm, I made some corrections, mainly to: > > * 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. > > The new text is available at: > > https://proof-of-loss.money/ > > Mirelo > > > > -------- Original Message -------- > Subject: Proof-of-Loss > Local Time: February 4, 2017 10:39 AM > UTC Time: February 4, 2017 12:39 PM > From: mirelo@deugh-ausgam-valis.com > To: bitcoin-dev@lists.linuxfoundation.org linuxfoundation.org> > > 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: > > *https://proof-of-loss.money/ * > > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --94eb2c19053eb9471d054c7678d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is this the same as proof of burn?

On Apr 5, 2017 5:28 PM, "Mire= lo via bitcoin-dev" <bitcoin-dev@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 def= inition of transaction rights.
* An overview of how the algor= ithm works.

As an abstract could not contain a= ll 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:

* Preventi= ng the same proof-of-loss from chaining consecutive blocks was not the purp= ose of the proof-of-loss context, which did it statistically rather than lo= gically.
* The presence of that height in the block header ma= de serial chaining easier to enforce, by removing the need to include addit= ional block height information.

While revising= the algorithm, I made some corrections, mainly to:

* 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.

The new text is available at:

=

Mirelo



-------- Original Message --------
Subject: Proof-of-Loss
Local Time: February 4, 2017 = 10:39 AM
UTC Time: February 4, 2017 12:39 PM

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

<= br>





____________= ___________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--94eb2c19053eb9471d054c7678d3--