[Bitcoin-development] An "app store" and non-network transaction fees

[Bitcoin-development] An "app store" and non-network transaction fees

[Wendell]

[-- Attachment #1: Type: text/plain, Size: 2690 bytes --]

Hi everyone,

Our OS X wallet "Hive" features an integrated application platform. We hope this will be a great way for folks new to Bitcoin to discover a variety of Bitcoin businesses, from exchanges, to merchants, to games. The applications are locally hosted HTML/JS, and generally feature the most stripped-down UIs possible. We display them in a mobile-proportioned WebKit frame inside of Hive itself. Transaction requests within apps trigger native Cocoa dialogue boxes and everything feels nicely integrated and secure.

Should Hive succeed in gaining a foothold, we hope that we may one day be able to sustain ourselves via an aggregate of very small fees on transactions within this app platform. We like the approach because it lets us stay focused on making Hive great, and keeping it free, but at the same time we recognize that it is a kind of obligatory middleman... With all that that implies? I'm not totally sure, and that's what the question is about.

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). Or, we could avoid troubling the business and have each user send a micro-transaction to some address of our choosing. The first one is messy and essentially makes us spyware. The second one is technically difficult, making a mess of transaction history, balances, and possibly in-app price listings. I'm not happy with either, but would lean towards the second one if I had to choose.

I'm not 100% sure if this is the appropriate venue for it, but before we make that decision, I wanted to state our intentions and see if I could get some fresher ideas in the door. We want to be as ethical and (ideally) decentralized as possible -- priorities #1 and #2 -- but are otherwise open-minded.

Some technical details for the curious:

1) Yes, everything will be free software under a GPL license -- including the app store and the apps themselves! That may seem to be risky given our proposed business model, but we are open-minded and think we very much welcome the 'competition' of a would-be forker / hope we can work together. ;-)

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

We will be at the conference in Amsterdam on the 27th of this month if any of you want to meet and discuss.

Thanks for your time,
-wendell

grabhive.com | twitter.com/grabhive | gpg: 6C0C9411


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

Re: [Bitcoin-development] An "app store" and non-network transaction fees

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2857 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 3570 bytes --]

Re: [Bitcoin-development] An "app store" and non-network transaction fees

[Wendell]

[-- Attachment #1: Type: text/plain, Size: 5306 bytes --]

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

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

Re: [Bitcoin-development] An "app store" and non-network transaction fees

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2451 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 3181 bytes --]

Re: [Bitcoin-development] An "app store" and non-network transaction fees

[Wendell]

On Sep 5, 2013, at 12:14 PM, Mike Hearn wrote:
> 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 ;)

Well, let's assume that our "public good" is based on the 5-step model described here:
https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts

This good corresponds to something like "Facebook contact synchronization" and has a target of 50 BTC, though we also want to be able to take more if people are willing to give it.

From here, it is unfortunately a little over our collective heads; we have as of yet no experience with the scripting language. I suppose I'm trying to twist your arm for an example, and maybe an anecdote. How would we do it? Does it require the donors to do anything esoteric? I saw "but they do not broadcast it" -- does this happen automatically when coins are sent to that address, for example?

Confused but enthusiastic,
-wendell

grabhive.com | twitter.com/grabhive | gpg: 6C0C9411

Re: [Bitcoin-development] An "app store" and non-network transaction fees

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

It needs people to use either a dedicated app or a wallet with the right
features. I've gone back and forth on whether it's better to have wallets
become featureful things or to have lots of separate apps. There are pro's
and con's to each.

Fortunately bitcoinj makes bringing up a new GUI wallet app quite easy
(well ... if you're writing it in java ;). So having a dedicated app just
for managing your pledges is quite straightforward.

At that point it's about contracts programming:

https://code.google.com/p/bitcoinj/wiki/WorkingWithContracts

[-- Attachment #2: Type: text/html, Size: 788 bytes --]

Re: [Bitcoin-development] An "app store" and non-network transaction fees

[Wendell]

We've gone ahead and pushed a v1 API for this idea:
https://bitcointalk.org/index.php?topic=313352

No fees yet, just the basics.

-wendell

grabhive.com | twitter.com/grabhive | gpg: 6C0C9411

On Sep 5, 2013, at 10:26 AM, Mike Hearn wrote:

> Hey Wendell,
> 
> Interesting idea you have there!