Option to Contribute - Indicate in Bitcoin Core [Incentivizing Giving, Adding Smart Property Element]

[ABISprotocol]

Many people have different ideas of how to contribute to the system that they use and what contribution means to them. The fees are only one method whereby someone can provide support to the overall network. This particular issue suggests that there be indicated or expressed in Bitcoin Core, perhaps below where confirmed transactions are displayed, or in a menu, a question that is expressed, such as "Would you like to contribute to help the Bitcoin network?" or some variant thereof. Potentially this could present options (in a menu dropdown), for example:

• donations of bitcoin (one form of contribution) to a pool where bitcoin developers could opt in or out either totally or on a per commit basis, such as WhisperSystems / BitHub
• contributions of time and energy for Bitcoin (may indicate a suggested area to visit such as the bitcoin/bitcoin repository)
• Other - could default to a site such as the bitcoin.org participate page - currently titled 'Support Bitcoin'
• Volunteer activities relating to bitcoin which could then be expressed as transactions

These are some initial thoughts that are specific to how full client users could be presented with additional options to contribute - from the wallet itself - specifically, in ways that would result in contributions of bitcoin, time, energy, volunteer activity, or other, and at the user's option, make record of that in the transactions area.

Issue modified based on comments to include the following as suggested elements:

• options that can be easily generated by users or groups of users, such as the concepts shown in sx tools in what is described as the charity donations section
• a feature similar to that suggested by @gmaxwell that would process small change and tiny txouts to user specified donation targets, in an incentivized process. Those running full nodes (Bitcoin Core all the time), processing their change and txouts through Core, would be provided incentives in the form of a 'decentralizing lottery' such that all participants who are running nodes and donating no matter how infrequently (and no matter who they donate to) will be entered in the 'decentralizing lottery,' the 'award amounts' (which would be distinct from 'block rewards' for any mining) would vary from small to large bitcoin amounts depending on how many participants are involved in the donations process. This would help incentivize individuals to run full nodes as well as encouraging giving and microdonations. The option could be expressed in the transactions area to contribute to help bitcoin core development for those that are setting up change and txouts for donations, regarding the microdonation portion (which has also has been expressed conceptually at abis.io
• The simplest implementation of this idea has individuals benefiting from running full nodes and performing microdonations, but more could be done. Depending on how this is implemented, it could work in such a way that individuals running full nodes (Bitcoin Core) are increasingly incentivized, or, in which miners are incentivized to give hashing power away (ensuring decentralization continues) in the form of smart property as microdonations (where the incentive would be the possibility of miners receiving 'award amounts.') The smart property representing the mining or hashing power would be distributed throughout the network. In the latter case, the 'award amounts' of bitcoin associated with the 'decentralizating lottery' described above could increase as mining becomes more concentrated or centralized, thus creating a disincentive for ongoing centralization and a greater incentive for decentralization via microdonations.

[ABISprotocol]

@nikosbentenitis @willpangman There was this ongoing discussion for a while in Education Committee about how people could best contribute to core devs but I've somewhat modified and expanded the issue a bit here. Let me know your thoughts.

[gmaxwell]

I'd prefer brainstorming go someplace else other than github issues on the repository.

[ABISprotocol]

@gmaxwell Thank you. What are your thoughts on the concept described in this issue?

[gmaxwell]

That it isn't yet well enough defined that I can say if its something I would support or not. Some of the things you've mentioned I probably would not support such as promoting centralized 'tipping' services... but the Bitcoin core code repository issue tracker isn't really the right forum for discussing non-concrete proposals.

[ABISprotocol]

@gmaxwell Thank you. I'd like to hear some other thoughts from those mentioned above and from some other developers as well, and keep this open for a bit. Cheers.

[laanwj]

Directing people to the 'how to support' page would make sense. I think it was Mozilla that has a reminder that it is open source software and that everyone can contribute when you first launch it. We could do a similar thing. Maybe also add it to the 'about' dialog.

As for donations, yes, the technical implementation is easy: add a button to contribute a chosen amount of BTC to 'Bitcoin Core Development'. I'm pretty sure that some people will click it.

The larger problem is how to divide the money, and who does it. I don't believe bounties per commit have much usefulness beyond sparking people's initial interest. It also gives a distorted incentive.

[gmaxwell]

@laanwj WRT website... such as http://whatcanidoforbitcoin.org/ ?

As far as donations go, rather than having an explicit donation, it might be useful to instead have a wallet dusting feature where you can tell the wallet to send dust (e.g. small change and tiny txouts) to a list of user specified donation targets with a monthly quota on how much will be sent, and then it just automatically sends and reports on the results. Then you get a three way benefit: the user gets a less fragmented wallet, the network gets a less fragmented utxo set, and the recipient of the funds gets the funds.

[laanwj]

I like the explicit donation as well. Many people want to explicitly donate toward bitcoin development. Your scheme with dust transactions is nice, but users cannot control how much they donate. Could have both.

[gmaxwell]

@laanwj I suppose. I understand the miner software authors have had negative experiences with the explicit donation options in their software (and have removed them), likewise for p2pool... complaints mostly being that they bring in very little but cause a lot of negative attitudes relative to what they bring in (including support entitlement and a belief that contribution in other ways, e.g. clear bug reports are no longer something you 'owe' the community that produces the software since your due is paid).

[laanwj]

Everything you do will get you negative attitudes... there's just no way around that, especially in the bitcoin community. But I agree that the experiences from mining software developers are not very promising.

Wouldn't dust also bring in very little? What feels as a drawback to me is that it is entirely bound to the wallet part of the software. It won't work anymore if bitcoin core is just bitcoin core. A donate button could show an address and URI and QR-code that could be paid with any wallet.

[gmaxwell]

Yes, I would expect dust to also bring in small amounts but (hopefully!) also not have the negative effects— and maybe more than we might guess think, since the everyone benefits from sweeping dust it isn't merely a donation. (I don't necessarily just mean DUST dust, but general amounts which are much smaller than the amount being typically spent, up to a configured limit).

I think that anything along these lines is wallet bound, otherwise you don't get the instant gratification of a simple click, or at least otherwise it might as well be some readme text for all the visibility it would have. :)

[laanwj]

Right, you've convinced me that the software may not be the right place for this at all.

Most of the people that use Bitcoin right now and [should] care about the infrastructure are not using the Bitcoin Core software directly. And I suppose this number will only increase. Still, even for them, continued development of the P2P software which is the base of the network and consensus is important. It could just as well be some readme text or website.

Adding dust collection to the Bitcoin Core wallet is still a nice idea, but it may be too late for that to have a significant impact.

[ABISprotocol]

@laanwj You had mentioned in the about dialog, although I am interested if this could be made more dynamic than something that would appear in that dialog. I've been very interested lately in the concept of options that can be more easily generated by users or groups of users, such as the concepts shown here in what is described as the charity donations section. I see this as less of a 'charity donations' concept and more of a way in which there would be more flexibility afforded to the user. @gmaxwell mentioned that one possibility could be a feature that would process small change and tiny txouts to user specified donation targets, my thinking here is that there could be a process where this is incentivized. Those who are running full nodes (running Bitcoin Core all the time) and are processing their change and txouts through Core are provided incentives (potentially, mining / pools could have lottery established such that all participants who are running nodes and donating no matter how infrequently will be entered in a lottery, the amounts would vary from small to large btc amounts depending). I know that the lottery concept is frequently raised, but I feel it would help incentivize both the issue of declining nodes as well as encouraging giving and microdonations. This ties in directly to this open issue because at the same time the option could still be provided in the transactions area to contribute to help bitcoin core development for those that are setting up change and txouts for donations. edit: Not sure if lottery concept is supportable or not after reading this, but maybe?
another edit: Thinking about how much time / energy people devote to running a node and how is that determined and rewarded? (example of analysis relating to Tor)
Final edit to this comment: It occurred to me that there could be some confusion between this lottery idea and other reward concepts already in use, including block reward. To clarify any confusion, I want to add that the lottery would occur in addition to existing block reward processes.
Thoughts on this?

[ABISprotocol]

This issue has been modified and added to, in light of comments posted to date. To @mikehearn ~ smart property concept added in part.

[mdhaze]

The basic question is how bitcoin core developers (or any other group) can get a stake in the money flow. I am unable to separate this issue from micropayments conceptually. It occurs to me then that many other situations are not so different.

Example, we need a road from point A to B. So we create a government structure to force people to give it money which we then spend on the road. Over time (hopefully) everyone benefits. Why was this method in place? Because micropayments were did not exist - if they had, history of road building might be completely different. But now we have the rudiments of micropayments using bitcoin as the backbone. NOT well developed, implemented and spread to the diverse user communities, though.

If micropayments were well understood and embedded in practice, to the level that they were actionable on mobile devices that most people owned, would this matter be solvable in that context? Would the matter exist as a subject of discussion and / or development, and how would it be phrased? I say this because I am wondering if we ask the right question at the wrong time, such as asking "how to get to the moon", when the highest velocity chemical rocket was gunpowder. Right question, wrong time.

[ABISprotocol]

On how developers can get a stake it is a question of how developers would prefer to receive something and / or how they would opt in or out of any such thing. I tend to like the WhisperSystems / Bithub model (linked in issue description) precisely because it allows for opt in / out and for those who opt in, provides them with a certain amount based on commit. One of the things that I think (on the microdonations side) that this concept would need, is the development and circulation of a Process BIP (specific kind of bitcoin improvement proposal). On the one hand there is the incorporation into wallet technology and in the case of this issue the emphasis is on Bitcoin Core, but a Process BIP would also help. There are elements of this open issue that could conceivably be implemented by developers quickly (examples being the parts that involve ways to help fund activities of developers) without any further study. However, there are various aspects of this which are complex, all of which could be handled by wallet technology (in many wallet types), but which for the purposes of incentivizing the running of full node (Bitcoin Core) and addressing the substance of this open issue, appear to need a lengthy review through bitcoin development processes so as to flesh out a process and path forward. Rather than an issue of 'wrong time,' the issue is timely, but simply requires further review and comment.

[gavinandresen]

Closing as "too abstract to take action on."

[ABISprotocol]

@gavinandresen Thanks for taking a peek at this issue. I'd rather it remained open, due to that I'd like to get more discussion going on the issue (as modified, see description) from bitcoin development list and other sources. I also don't concur that the concepts presented are too abstract to take action on. In fact @gmaxwell and @laanwj have added thoughts in comments that have made me consider that some of the concepts may be actionable more quickly (such as how to provide option for donation to bitcoin development) whereas other concepts would require more in-depth level of review. Essentially for these reasons, I'd like this to remain open. Either way, I will continue to advance these concepts and suggest them through bitcoin development list and such processes that would enable additional community discussion, development focused commentary, and so forth. (...)

[ABISprotocol]

@gavinandresen I have one more comment here on your closure of this issue. If I understand correctly, you are a Founding Member of the Bitcoin Foundation and you have been a core developer for some time. However, you have recently stepped down as Bitcoin lead developer, and @laanwj is now the Bitcoin lead developer, if I understand correctly the roles as they have changed. I noted that you closed this issue as "too abstract to take action on." In part for the reasons stated in my prior comment, and in part for the reasons in this comment, I would like to have this issue changed from closed to open (or kept closed) based on the decision of @laanwj

Regardless of what you and @laanwj decide, as mentioned previously, I will continue to advance these concepts through bitcoin development processes which are laid out in detail for interested parties. However, it is my desire that this issue be left open (that is to say, changed from 'closed' to 'open') at this time.

[mikehearn]

Hey @ABISprotocol - firstly, your energy and enthusiasm for helping us earn money is much appreciated :) Don't take the issue closure the wrong way, it's just about keeping github for specific actions that have a clear patch to fix.

There are lots of ideas for how best to support Bitcoin development. For example, here's the one I'm working on:

http://blog.vinumeris.com/2014/05/17/lighthouse/

In the past we've found that donations and bounties don't work well. Donations raise very little money. Bounties don't attract quality work due to the winner-takes-all setup they use. I'm hoping assurance contracts will be different, but we'll have to try it to find out.

W.R.T. micropayments for full nodes, that's a large and complex project that I doubt anyone working on Core will have the time for anytime soon. Also, right now there are lots of people giving away node services for free, so the cost would be zero. And we hardly want fees to go even higher than they are: bitcoin transactions are already absurdly expensive relative to their actual cost due to a broken fees market. So although Matt and I partly implemented micropayment channels in bitcoinj with this use case in mind, it's going to be a long time before that's really needed IMHO.

[ABISprotocol]

@mikehearn Thanks for elaborating on this. I've been watching with interest the announcement(s) related to lighthouse. Those are great ideas. The micropayment, peer to peer and smart property elements are bleeding edge stuff... I'm guessing you have poked around the openbazaar repository at https://github.com/OpenBazaar/OpenBazaar (incredible stuff by @drwasho and others), there are things about the lighthouse and the openbazaar that are very similar, maybe some collaboration betweent the two possible?

But back to this issue, I agree that the micropayment / incentive system described to incentivize more people to run full nodes is indeed large and complex and I appreciate you taking the time to note that it would likely be a long time before this sort of notion would be given much development attention (and fees are an issue too as you noted) I've thrown it over to the bitcoin development mailing list, and every so often will nudge it gently with a little stick. I won't give up on this sort of concept eventually gaining traction in some form or another and I hope that it inspires other, related solutions. Meanwhile, back to the wallet side ~ http://abis.io project, where my attentions are really focused.
Incentivizing giving and providing options for doing so is vital ~ our notions of what transactions are need to change, our vision of a financial future should gear towards a framework in which giving is a natural and uninhibited part of everything.