Sender: Wendell <wendel@314t.com>
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/signed;
	boundary="Apple-Mail=_B38BA84F-DAF3-454C-B57B-FBBB8B16B5C7";
	protocol="application/pgp-signature"; micalg=pgp-sha1
From: Wendell <w@grabhive.com>
In-Reply-To: <CANEZrP1zAJ0bQHsqKgH=L4BpgE_kHGKNh=+mv=Tk++7OWA4C2g@mail.gmail.com>
Date: Thu, 5 Sep 2013 12:04:26 +0200
Message-Id: <36036B83-CD26-497F-BC5A-FD69DAFF578C@grabhive.com>
References: <879EBFD7-3047-4ECD-B03B-941857F7970C@grabhive.com>
	<CANEZrP1zAJ0bQHsqKgH=L4BpgE_kHGKNh=+mv=Tk++7OWA4C2g@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] An "app store" and non-network
	transaction fees
Precedence: list


--Apple-Mail=_B38BA84F-DAF3-454C-B57B-FBBB8B16B5C7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hey Mike!

On Sep 5, 2013, at 10:26 AM, Mike Hearn wrote:
> 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.
> 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.

In the long term, I think this makes perfect sense. After all, that's =
really what the first option is at its heart. About search engines, =
that's also a great point. We've thought about doing this, but my =
concern was that the ecosystem on the whole is too young and fragmented =
for this to make much sense. Until for example speciality search engines =
for Bitcoin products and services manifest (I'm sure they are coming), I =
suspect the results might be a little vague and unsatisfying.

I really see Hive's app platform as a stepping-stone to more mature =
things. Hopefully several companies like BitPay end up offering both =
great affiliate programs and search engines very soon. Until then, =
that's why something like sending transaction fees directly from the =
user's wallet is even on the table.

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

Yes, I should clarify. We do want businesses to be able to have that =
control. However we also want to do a kind of submission/review process =
in order to ensure some user experience continuity and also to monitor =
for potential exploits. The plan is ultimately to have a public =
repository for applications, maintained by us. We will review the pull =
requests of third parties and the Hive app will always try to pull the =
latest (approved) updates. Does that make sense? It's centralized =
responsibility and potential risk if we cannot keep up with demand, but =
again -- we want to try the approach, at least while starting out.

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

That's absolutely true, but at the moment the only thing I can really =
say is that we'll cross that bridge when we get there. ;-)

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

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.

>> 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?).
>=20
> 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.

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. I guess there's also the question of =
diminishing returns: Is the network value of a full "user" Bitcoin node =
less than one run on a dedicated server? Will it eventually be? I don't =
know enough about that to comment, but I do know that in the Tor =
example, exits are chosen based on some criteria (I think, available =
bandwidth?). Is there a parallel in Bitcoin?

(Probably best as a separate thread...)

Thanks for your thoughts, Mike.
-w=

--Apple-Mail=_B38BA84F-DAF3-454C-B57B-FBBB8B16B5C7
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)

iQIcBAEBAgAGBQJSKFcqAAoJECAN2ykHU5Y6Fv0P/jPKoNvFaE/6k2l48AJXi6Gv
wpREz+HlQ/r4+QfVSB8pin4io3/op6z9uIk3dh7KC1iw0tbJiDyMTiaGsMMUcPkb
acqxtmhhqy0DZzX/QrITTjFzigpvp2/uLUnFkGKeM1UBDhFLPotQGiG+SgvgKe7K
BQ6TNJE4BDgdIEOGG20Jkh/OdJ67q8fvqf7W5dWgxsbq9+190ffYy3TZCD18msoz
ywLC//JVMxYhmCLy3ubkiEBRdegwZNbEuiV+PtkKBCIDd6YWogHWu1vJ1E7M/LlF
eypty7y1oKqUBVIs1MJsvlug0rp2yf4QsQPIaI4QhD87wc6Hm6OKNrp/B6VhhIJQ
OJ1Mm1k7MOqaEyTCXtTZb9JReWkALzuh9xiDMDKdlUkPpKkQxG9rk/JFrSbOoNGp
mfp0AfkijPI+rrKgVuYG7fkELpLNt0b7Ig0QaAKS7pOUVgmGTq7JYNp2WYWqgN3l
WSEW/yDmDXjdpqAopWURy5GFQhlRaLE5Yf8ZdxxxrcgaDKsdjPvsqUCNn8mY0P9Q
n8r+DRL9zD0W5pSgKI1/zbtvBuTFyqhZ0t1CFQE683cuRqFC3zjhG+i/1I6/IVvb
IgXkAEIgT+lWSncytsrIY2yewP65Cfv5ikejqL51hglEVD5LQcmEctPL6A9NUZ2u
RHDe89ikZZy/5s/FYoqs
=AdlL
-----END PGP SIGNATURE-----

--Apple-Mail=_B38BA84F-DAF3-454C-B57B-FBBB8B16B5C7--