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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1VHWaP-00069I-FJ
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Sep 2013 10:14:49 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.173 as permitted sender)
client-ip=209.85.214.173; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f173.google.com;
Received: from mail-ob0-f173.google.com ([209.85.214.173])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VHWaO-0003fu-Bi
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Sep 2013 10:14:49 +0000
Received: by mail-ob0-f173.google.com with SMTP id ta17so1727377obb.32
for <bitcoin-development@lists.sourceforge.net>;
Thu, 05 Sep 2013 03:14:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.32.70 with SMTP id g6mr5641458obi.81.1378376082528; Thu,
05 Sep 2013 03:14:42 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.80.165 with HTTP; Thu, 5 Sep 2013 03:14:42 -0700 (PDT)
In-Reply-To: <36036B83-CD26-497F-BC5A-FD69DAFF578C@grabhive.com>
References: <879EBFD7-3047-4ECD-B03B-941857F7970C@grabhive.com>
<CANEZrP1zAJ0bQHsqKgH=L4BpgE_kHGKNh=+mv=Tk++7OWA4C2g@mail.gmail.com>
<36036B83-CD26-497F-BC5A-FD69DAFF578C@grabhive.com>
Date: Thu, 5 Sep 2013 12:14:42 +0200
X-Google-Sender-Auth: d8g4vQMUPC3UsQrn73PqHUf-RvE
Message-ID: <CANEZrP3hrYZ5SYng=fknCqn_vg9gK4HTS7T-tdQNfc0MwZ5DtA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Wendell <w@grabhive.com>
Content-Type: multipart/alternative; boundary=089e013a09f4c4225b04e5a0308e
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: 1VHWaO-0003fu-Bi
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] An "app store" and non-network
transaction fees
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, 05 Sep 2013 10:14:49 -0000
--089e013a09f4c4225b04e5a0308e
Content-Type: text/plain; charset=UTF-8
On Thu, Sep 5, 2013 at 12:04 PM, Wendell <w@grabhive.com> wrote:
> Funny you should mention it! I just mocked this idea up last week, though
> I assumed a cruder system of "voting" to an address that corresponds to a
> feature -- literally, voting with your wallet (for your wallet, ad
> infinitum). I watched your talk about assurance contracts and other
> "hidden" features, but am not entirely sure that I understood it enough to
> know how it would work in this context. Sorry for the persistent
> hand-holding requests, but some advice would be very welcome.
>
Well, it's a bit complicated and needs some software development to do
well. The best way to fund a complex project would be to raise the money
using an assurance contr.... oh wait ;)
> If it is a real burden for the users, that's the best argument I've yet
> heard. However, my impression from Peter's post was that it would be fairly
> painless for them.
>
It could be automatic in the sense that users don't need to know it's
happening, but look at it this way. Gavin believes the future of computing
is mobile and tablets. I don't know about that, but let's assume for the
sake of argument he turns out to be right. These devices are expected to
have much longer battery life than laptops. Apps that spin up in the
background and use battery+radio can easily be seen as "abusive" by end
users. In fact, if you look in the Bitcoin Wallet section of the forum,
you'll see a giant argument by users of the Android app who are upset
because the app sometimes runs in the background *just to keep up with the
chain*! That's not even donating resources, it's just trying to ensure it
doesn't fall behind, and this enrages some users because it can have a
small but non-zero battery/bandwidth usage impact.
Given the number of complaints generated by just having the app sync
automatically, imagine what would happen if we started relaying blocks!
Generally the ethos and modus operandi of desktops is different to laptops
which is in turn different to mobiles/tablets. Things you can get away with
on more powerful machines that expect to be plugged in all the time are
verboten on more modern devices.
Now that said, I can easily see Bitcoin enthusiasts buying some kind of
cheap embedded device, maybe Raspberry Pi based, and plugging it into a
wall in order to donate to the network. That way it doesn't affect their
primary devices responsiveness or storage or battery life.
--089e013a09f4c4225b04e5a0308e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Sep 5, 2013 at 12:04 PM, Wendell <span dir=3D"ltr"=
><<a href=3D"mailto:w@grabhive.com" target=3D"_blank">w@grabhive.com</a>=
></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<div class=3D"im"><span style=3D"color:rgb(34,34,34)">Funny you should ment=
ion it! I just mocked this idea up last week, though I assumed a cruder sys=
tem of "voting" to an address that corresponds to a feature -- li=
terally, voting with your wallet (for your wallet, ad infinitum). I watched=
your talk about assurance contracts and other "hidden" features,=
but am not entirely sure that I understood it enough to know how it would =
work in this context. Sorry for the persistent hand-holding requests, but s=
ome advice would be very welcome.</span></div>
</blockquote><div><br></div><div>Well, it's a bit complicated and needs=
some software development to do well. The best way to fund a complex proje=
ct would be to raise the money using an assurance contr.... oh wait ;)</div=
>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"><span sty=
le=3D"color:rgb(34,34,34)">If it is a real burden for the users, that's=
the best argument I've yet heard. However, my impression from Peter=
9;s post was that it would be fairly painless for them.</span></div>
</blockquote><div><br></div><div>It could be automatic in the sense that us=
ers don't need to know it's happening, but look at it this way. Gav=
in believes the future of computing is mobile and tablets. I don't know=
about that, but let's assume for the sake of argument he turns out to =
be right. These devices are expected to have much longer battery life than =
laptops. Apps that spin up in the background and use battery+radio can easi=
ly be seen as "abusive" by end users. In fact, if you look in the=
Bitcoin Wallet section of the forum, you'll see a giant argument by us=
ers of the Android app who are upset because the app sometimes runs in the =
background <u>just to keep up with the chain</u>! That's not even donat=
ing resources, it's just trying to ensure it doesn't fall behind, a=
nd this enrages some users because it can have a small but non-zero battery=
/bandwidth usage impact.</div>
<div><br></div><div>Given the number of complaints generated by just having=
the app sync automatically, imagine what would happen if we started relayi=
ng blocks!</div><div><br></div><div>Generally the ethos and modus operandi =
of desktops is different to laptops which is in turn different to mobiles/t=
ablets. Things you can get away with on more powerful machines that expect =
to be plugged in all the time are verboten on more modern devices.</div>
<div><br></div><div>Now that said, I can easily see Bitcoin enthusiasts buy=
ing some kind of cheap embedded device, maybe Raspberry Pi based, and plugg=
ing it into a wall in order to donate to the network. That way it doesn'=
;t affect their primary devices responsiveness or storage or battery life.<=
/div>
</div></div></div>
--089e013a09f4c4225b04e5a0308e--
|
