From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VHWQk-0007Pn-8I for bitcoin-development@lists.sourceforge.net; Thu, 05 Sep 2013 10:04:50 +0000 X-ACL-Warn: Received: from mail-ea0-f171.google.com ([209.85.215.171]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VHWQg-0003pA-Nf for bitcoin-development@lists.sourceforge.net; Thu, 05 Sep 2013 10:04:50 +0000 Received: by mail-ea0-f171.google.com with SMTP id n15so782039ead.16 for ; Thu, 05 Sep 2013 03:04:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=N/ANhqxhzqsEYdK6j63LzejaO9tkYNw7yUmVJWX4aSk=; b=iwCP2d1vZIAlga7e7bOqRod3NynYkXdozuTkEHOcI14FQZGjSMbvIvDf08Za0MdptZ G2irq9cmSmOE/WoekJprnGTo9+oGYsHrLa8kM2QVGdBGIYnCOTor85zR1LhMn9mrKttO 50Nz0v6uSRdBY89pY02UvTm1e1fRtp3XEoG4hdwA8oBWZtAo1YNrFEtjGzFqAyO7bam6 vhEFQNb4iw6hOHmxQ2t6DLu5Gl1al90XJv8EmN5CxiklJNbEVsfw8bZhLpqsC1fvJhwv LKR6T/JCH2kHV/PQuIaCsdIfzS605+8RERBILUpKXaZDf5nwrz7/Cpu7aptGxEoJ2Lvt NkLw== X-Gm-Message-State: ALoCoQkUdLSMG6MwQQf2HUIS6g9iMAexLTe45l5JtpFvaJki2MayFVOT8F6kAJXSjpLtSa+P4pzz X-Received: by 10.14.126.73 with SMTP id a49mr12320501eei.48.1378375479822; Thu, 05 Sep 2013 03:04:39 -0700 (PDT) Received: from [127.0.0.1] (tor18.anonymizer.ccc.de. [31.172.30.1]) by mx.google.com with ESMTPSA id h52sm47287581eez.3.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Sep 2013 03:04:39 -0700 (PDT) Sender: Wendell 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 In-Reply-To: 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> To: Mike Hearn X-Mailer: Apple Mail (2.1283) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1VHWQg-0003pA-Nf Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 10:04:50 -0000 --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--