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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Yxv5b-0001X8-E3
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 10:31:03 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.49 as permitted sender)
client-ip=74.125.82.49; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f49.google.com;
Received: from mail-wg0-f49.google.com ([74.125.82.49])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yxv5Z-0000cf-Tr
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 10:31:03 +0000
Received: by wgbgq6 with SMTP id gq6so32383624wgb.3
for <bitcoin-development@lists.sourceforge.net>;
Thu, 28 May 2015 03:30:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.61.82 with SMTP id n18mr3800637wjr.35.1432809055947;
Thu, 28 May 2015 03:30:55 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.143.9 with HTTP; Thu, 28 May 2015 03:30:55 -0700 (PDT)
In-Reply-To: <CAAS2fgTdt9zY8KeOaob+idse1j9eraazBo5HukxJ8nkC_h=Zfw@mail.gmail.com>
References: <5550D8BE.6070207@electrum.org>
<CANEZrP2x+fBitgcvoaC2qBbJS-Ek_hgS3ZGM55UtURKc-oDZMQ@mail.gmail.com>
<CANEZrP0ZdGp6Punh34mNMgaukHDQvMwDM_KEEsnuHn8Fj3Pt2Q@mail.gmail.com>
<CAAS2fgTdt9zY8KeOaob+idse1j9eraazBo5HukxJ8nkC_h=Zfw@mail.gmail.com>
Date: Thu, 28 May 2015 12:30:55 +0200
X-Google-Sender-Auth: 8I6nX2Dz4z-d03apEg45CZDAh_4
Message-ID: <CANEZrP0toD-oJZRL62GN=TOVeG=dfd8k3MNh54mvkdteETA4XA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=047d7ba97780cf9351051721daff
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Yxv5Z-0000cf-Tr
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Long-term mining incentives
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2015 10:31:03 -0000
--047d7ba97780cf9351051721daff
Content-Type: text/plain; charset=UTF-8
>
> The prior (and seemingly this) assurance contract proposals pay the
> miners who mines a chain supportive of your interests and miners whom
> mine against your interests identically.
>
The same is true today - via inflation I pay for blocks regardless of
whether they contain or double spend my transactions or not. So I don't see
why it'd be different in future.
> There is already a mechanism built into Bitcoin for paying for
> security which doesn't have this problem, and which mitigates the
> common action problem of people just sitting around for other people
> to pay for security: transaction fees.
The article states quite clearly that assurance contracts are proposed only
if people setting transaction fees themselves doesn't work. There's some
reasonably good arguments that it probably won't work, but I don't assign
very high weight to game theoretic arguments these days so it wouldn't
surprise me if Satoshi's original plan worked out OK too.
Of course, by the time this matters I plan to be sipping a pina colada on
my private retirement beach :) It's a problem the next generation can
tackle, as far as I am concerned.
> Considering the near-failure in just keeping development funded, I'm not
> sure where the believe this this model will be workable comes from
Patience :)
Right now it's a lot easier to get development money from VC funds and rich
benefactors than raising it directly from the community, so unsurprisingly
that's what most people do.
Despite that, the Hourglass design document project now has sufficient
pre-pledges that it should be possible to crowdfund it successfully once I
get around to actually doing the work. And BitSquare was able to raise
nearly half of their target despite an incredibly aggressive deadline and
the fact that they hadn't shipped a usable prototype. I think as people get
better at crafting their contracts and people get more experience with
funding work this way, we'll see it get more common.
But yes. Paying for things via assurance contracts is a long term and very
experimental plan, for sure.
> one time cost. I note that many existing crowdfunding platforms
> (including your own) do not do ongoing costs with this kind of binary
> contract.
>
Lighthouse wasn't written to do hashing assurance contracts, so no, it
doesn't have such a feature. Perhaps in version 2.
--047d7ba97780cf9351051721daff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">The prior (and seemingly this) assurance contrac=
t proposals pay the<br>
miners who mines a chain supportive of your interests and miners whom<br>
mine against your interests identically.<br></blockquote><div><br></div><di=
v>The same is true today - via inflation I pay for blocks regardless of whe=
ther they contain or double spend my transactions or not. So I don't se=
e why it'd be different in future.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">There is already a mechanism built into Bitcoin for paying=
for<br>
security which doesn't have this problem, and which mitigates the<br>
common action problem of people just sitting around for other people<br>
to pay for security: transaction fees. </blockquote><div><br></div><div>The=
article states quite clearly that assurance contracts are proposed only if=
people setting transaction fees themselves doesn't work. There's s=
ome reasonably good arguments that it probably won't work, but I don=
9;t assign very high weight to game theoretic arguments these days so it wo=
uldn't surprise me if Satoshi's original plan worked out OK too.</d=
iv><div><br></div><div>Of course, by the time this matters I plan to be sip=
ping a pina colada on my private retirement beach :) It's a problem the=
next generation can tackle, as far as I am concerned.</div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">Considering the near-failure in just=C2=A0=
keeping development funded, I'm not sure where the believe this this=C2=
=A0model will be workable comes from</blockquote><div><br></div><div>Patien=
ce :)=C2=A0</div><div><br></div><div>Right now it's a lot easier to get=
development money from VC funds and rich benefactors than raising it direc=
tly from the community, so unsurprisingly that's what most people do.=
=C2=A0</div><div><br></div><div>Despite that, the Hourglass design document=
project now has sufficient pre-pledges that it should be possible to crowd=
fund it successfully once I get around to actually doing the work. And BitS=
quare was able to raise nearly half of their target despite an incredibly a=
ggressive deadline and the fact that they hadn't shipped a usable proto=
type. I think as people get better at crafting their contracts and people g=
et more experience with funding work this way, we'll see it get more co=
mmon.</div><div><br></div><div>But yes. Paying for things via assurance con=
tracts is a long term and very experimental plan, for sure.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">one time cost. I note that many exi=
sting crowdfunding platforms<br>
(including your own) do not do ongoing costs with this kind of binary<br>
contract.<br></blockquote><div><br></div><div>Lighthouse wasn't written=
to do hashing assurance contracts, so no, it doesn't have such a featu=
re. Perhaps in version 2.</div><div><br></div></div></div></div>
--047d7ba97780cf9351051721daff--
|
