summaryrefslogtreecommitdiff
path: root/58/971b9fb5fb3cc13bdaab5611d1b7d26e24d62e
blob: 0e37e763ecb593500a997950d39663789bf7b08b (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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	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 1VHUtL-0005yE-57
	for bitcoin-development@lists.sourceforge.net;
	Thu, 05 Sep 2013 08:26:15 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.52 as permitted sender)
	client-ip=209.85.219.52; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f52.google.com; 
Received: from mail-oa0-f52.google.com ([209.85.219.52])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1VHUtJ-0004QO-0w
	for bitcoin-development@lists.sourceforge.net;
	Thu, 05 Sep 2013 08:26:15 +0000
Received: by mail-oa0-f52.google.com with SMTP id f4so1838775oah.11
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 05 Sep 2013 01:26:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.45.102 with SMTP id l6mr5477039oem.36.1378369567233; Thu,
	05 Sep 2013 01:26:07 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.80.165 with HTTP; Thu, 5 Sep 2013 01:26:07 -0700 (PDT)
In-Reply-To: <879EBFD7-3047-4ECD-B03B-941857F7970C@grabhive.com>
References: <879EBFD7-3047-4ECD-B03B-941857F7970C@grabhive.com>
Date: Thu, 5 Sep 2013 10:26:07 +0200
X-Google-Sender-Auth: 28mgQC5ZTlSAqvV7czrT9wFN4io
Message-ID: <CANEZrP1zAJ0bQHsqKgH=L4BpgE_kHGKNh=+mv=Tk++7OWA4C2g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Wendell <w@grabhive.com>
Content-Type: multipart/alternative; boundary=089e0149ce366c9e0804e59eacff
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: 1VHUtJ-0004QO-0w
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 08:26:15 -0000

--089e0149ce366c9e0804e59eacff
Content-Type: text/plain; charset=UTF-8

Hey Wendell,

Interesting idea you have there!

On Wed, Sep 4, 2013 at 9:47 PM, Wendell <w@grabhive.com> wrote:

> Obviously there are a couple of brain-dead approaches: We could track what
> users do in the app, and send the business a bill (with blockchain proof,
> of course).
>

It might be simpler to not think of it as an app store, but rather see it
as a set of affiliate schemes. To get placed into the apps section you can
say that the business must have an affiliate scheme in place (i.e. open to
more than just you) and then you use the normal mechanisms of affiliate
codes and so on. The apps don't have to be offline. They can (and probably
should) be online, so the businesses can retain control of their features
and brand. If you refer a lot of users to that business, you get the
referral bonuses. Affiliate schemes are a common way for open source
projects to monetize - e.g. Firefox development is largely paid for by
search engine referrals. It's compatible with the ideals of openness
because their income relies directly on their traffic, and there are
several competing search engines the projects can play off against each
other to get the best prices. Also, users expect search engine integration
these days, so they'd be sending search traffic regardless.

The main downside, of course, is it distorts technical judgement. You can
get projects pushing certain businesses heavily not because it's
technically the best thing for users, but because their income depends on
it.

One alternative funding model you could explore is allowing users to bid on
assurance contracts for feature development. This means you think up a
bunch of improvements you could make, then allow users to pledge
Kickstarter-style towards their development. The upside is it allows the
community to direct development, and users feel directly involved and not
exploited. The downside is, no recurring income you can use to support
yourself whilst engaged in other endeavours.

2) Although our BitcoinKit.framework supports both bitcoind and bitcoinj,
> we will be using bitcoinj with an integrated VM for the time being. The
> main draw is SPV, although to be honest we would prefer to support the
> network more via something like Peter Todd's partial UTXO sets idea (hint
> hint, anyone?).
>

Bear in mind that regardless of how much *you* want to support the network,
it's ultimately *your users* resources that will actually get spent. That's
why I'm a bit skeptical of any schemes that rely on random end users
donating lots of cpu time or bandwidth to the network. If they want to do
it, partial UTXO sets and other interesting ideas are worthwhile, but I
guess most users won't. I think Bitcoin will over time be more and more
like Tor where relays are run on dedicated servers by people who have some
modicum of knowledge and community involvement.

--089e0149ce366c9e0804e59eacff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hey Wendell,<div><br></div><div>Interesting idea you have =
there!<br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed,=
 Sep 4, 2013 at 9:47 PM, Wendell <span dir=3D"ltr">&lt;<a href=3D"mailto:w@=
grabhive.com" target=3D"_blank">w@grabhive.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Obviously there are a couple of brain-dead approaches: We =
could track what users do in the app, and send the business a bill (with bl=
ockchain proof, of course). <br>
</blockquote><div><br></div><div>It might be simpler to not think of it as =
an app store, but rather see it as a set of affiliate schemes. To get place=
d into the apps section you can say that the business must have an affiliat=
e scheme in place (i.e. open to more than just you) and then you use the no=
rmal mechanisms of affiliate codes and so on. The apps don&#39;t have to be=
 offline. They can (and probably should) be online, so the businesses can r=
etain control of their features and brand. If you refer a lot of users to t=
hat business, you get the referral bonuses. Affiliate schemes are a common =
way for open source projects to monetize - e.g. Firefox development is larg=
ely paid for by search engine referrals. It&#39;s compatible with the ideal=
s of openness because their income relies directly on their traffic, and th=
ere are several competing search engines the projects can play off against =
each other to get the best prices. Also, users expect search engine integra=
tion these days, so they&#39;d be sending search traffic regardless.</div>
<div><br></div><div>The main downside, of course, is it distorts technical =
judgement. You can get projects pushing certain businesses heavily not beca=
use it&#39;s technically the best thing for users, but because their income=
 depends on it.</div>
<div>=C2=A0</div><div>One alternative funding model you could explore is al=
lowing users to bid on assurance contracts for feature development. This me=
ans you think up a bunch of improvements you could make, then allow users t=
o pledge Kickstarter-style towards their development. The upside is it allo=
ws the community to direct development, and users feel directly involved an=
d not exploited. The downside is, no recurring income you can use to suppor=
t yourself whilst engaged in other endeavours.<br>
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex">2) Although our BitcoinKit.framework =
supports both bitcoind and bitcoinj, we will be using bitcoinj with an inte=
grated VM for the time being. The main draw is SPV, although to be honest w=
e would prefer to support the network more via something like Peter Todd&#3=
9;s partial UTXO sets idea (hint hint, anyone?).<br>
</blockquote><div><br></div><div>Bear in mind that regardless of how much <=
i>you</i>=C2=A0want to support the network, it&#39;s ultimately <i>your use=
rs</i>=C2=A0resources that will actually get spent. That&#39;s why I&#39;m =
a bit skeptical of any schemes that rely on random end users donating lots =
of cpu time or bandwidth to the network. If they want to do it, partial UTX=
O sets and other interesting ideas are worthwhile, but I guess most users w=
on&#39;t. I think Bitcoin will over time be more and more like Tor where re=
lays are run on dedicated servers by people who have some modicum of knowle=
dge and community involvement.</div>
</div></div></div></div>

--089e0149ce366c9e0804e59eacff--