summaryrefslogtreecommitdiff
path: root/2b/22fa466f8233339aea0a1f3c6cdd78dee53128
blob: 53bf340f5ac015169b008fe3cf642d4f9b6907d9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 39698360
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Apr 2017 02:43:19 +0000 (UTC)
Received: by mail-qt0-f174.google.com with SMTP id i34so26345465qtc.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <qdwYHL1dhGGY8vUrSAtLiPoTMnJCrpgCDO44lian2_Mi_AzAicOb2EAt_T_ajN8G9jfL8bAYCWEIxA-huazbUan40dxD4vQCwT60Us_o19I=@deugh-ausgam-valis.com>
References: <xDk8CtqtLEE1SOMmY3ztYPDFREGNIm4OvJESS_TlQpGerVbz4MNI0uOmE3ERXSsHSYEZE7gG1rfRAyXg9x-ziA0BrMkW1RdhNIQwO1MqYao=@deugh-ausgam-valis.com>
	<qdwYHL1dhGGY8vUrSAtLiPoTMnJCrpgCDO44lian2_Mi_AzAicOb2EAt_T_ajN8G9jfL8bAYCWEIxA-huazbUan40dxD4vQCwT60Us_o19I=@deugh-ausgam-valis.com>
From: Erik Aronesty <earonesty@gmail.com>
Date: Wed, 5 Apr 2017 22:43:18 -0400
Message-ID: <CAJowKgJ8NBYedU_WAAk8wyNpZaHg479a-QukdbjAGaPwdhmGkw@mail.gmail.com>
To: Mirelo <mirelo@deugh-ausgam-valis.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bitcoin-dev@lists.
> 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/ <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

<div dir=3D"auto">Is this the same as proof of burn?</div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Apr 5, 2017 5:28 PM, &quot;Mire=
lo via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"=
attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div>With the feedback on Proof=
-of-Loss (always privately to my email), I realized the article was hard to=
 understand for lacking:<br></div><div><br></div><div>* A more explicit def=
inition of transaction rights.<br></div><div>* An overview of how the algor=
ithm works.<br></div><div><br></div><div>As an abstract could not contain a=
ll that, I wrote an introduction with examples.<br></div><div><br></div><di=
v>I also adopted a suggestion of including the current block height in the =
proof-of-loss data once I realized:<br></div><div><br></div><div>* 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.<br></div><div>* 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.<br></div><div><br></div><div>While revising=
 the algorithm, I made some corrections, mainly to:<br></div><div><br></div=
><div>* Transaction prioritization (which now uses fees instead of rights).=
<br></div><div>* Inactivity fees.<br></div><div><br></div><div>Finally, the=
 new version more aptly derives the design and often has better wording.<br=
></div><div><br></div><div>The new text is available at:<br></div><div><br>=
</div><div><a href=3D"https://proof-of-loss.money/" target=3D"_blank">https=
://proof-of-loss.money/</a><br></div><div><br></div><div>Mirelo<br></div><d=
iv class=3D"m_668062992116529043protonmail_signature_block m_66806299211652=
9043protonmail_signature_block-empty"><div class=3D"m_668062992116529043pro=
tonmail_signature_block-user m_668062992116529043protonmail_signature_block=
-empty"><div><br></div></div><div class=3D"m_668062992116529043protonmail_s=
ignature_block-proton m_668062992116529043protonmail_signature_block-empty"=
><br></div></div><div><br></div><blockquote class=3D"m_668062992116529043pr=
otonmail_quote" type=3D"cite"><div>-------- Original Message --------<br></=
div><div>Subject: Proof-of-Loss<br></div><div>Local Time: February 4, 2017 =
10:39 AM<br></div><div>UTC Time: February 4, 2017 12:39 PM<br></div><div>Fr=
om: <a href=3D"mailto:mirelo@deugh-ausgam-valis.com" target=3D"_blank">mire=
lo@deugh-ausgam-valis.com</a><br></div><div>To: <a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linu=
xfoundation.org</a> &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;<=
br></div><div><br></div><div>An alternative consensus algorithm to both pro=
of-of-work and proof-of-stake, <b>proof-of-loss</b> addresses all their def=
iciencies, including the lack of an organic=20
block size limit, the risks of mining centralization, and the &quot;nothing=
=20
at stake&quot; problem:<br></div><div><br></div><div><b><a class=3D"m_66806=
2992116529043ul" href=3D"https://proof-of-loss.money/" rel=3D"noreferrer no=
follow noopener" target=3D"_blank">https://proof-of-loss.money/</a></b><br>=
</div><div class=3D"m_668062992116529043protonmail_signature_block-empty"><=
br></div><div class=3D"m_668062992116529043protonmail_signature_block m_668=
062992116529043protonmail_signature_block-empty"><div class=3D"m_6680629921=
16529043protonmail_signature_block-user m_668062992116529043protonmail_sign=
ature_block-empty"><div><br></div></div><div class=3D"m_668062992116529043p=
rotonmail_signature_block-proton m_668062992116529043protonmail_signature_b=
lock-empty"><br></div></div><div class=3D"m_668062992116529043protonmail_si=
gnature_block-empty"><br></div></blockquote><div><br></div><br>____________=
__________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div></div>

--94eb2c19053eb9471d054c7678d3--