Topic: Development things you can work on (Read 995 times)
In any development it is important to maintain a balance of quality, price and reliability. I recently started developing an important project and I needed to find good programmers who know Golang. In this I was helped by golang outsourcing and in particular the articles on this site and I learned about how to maintain a balance in development. It is useful and can help many other people who have decided to do something like this.
Happy new year!
There are many important tasks and bits of infrastructure in the Bitcoin world that aren't getting done because there aren't any developers working on them. The core team spends almost all of its time on boring but necessary things like improving performance, security and testing. Worse, many great ideas get proposed in ad-hoc discussions on IRC where other developers won't find them. The result is slow development of new features and few new people working on core infrastructure.
I'd like to summarize some tasks that can greatly improve Bitcoin for everyone, and group them by topic/experience/effort required - hopefully it may inspire one or two people to pick tasks off the list and tackle them. The list reflects my own biases and what I think is useful/cool.
But a word of warning. None of these tasks require advanced knowledge of cryptography but that doesn't mean they're easy. Don't bother trying these unless you're serious. Writing a Python script, sticking it on github and calling it a day is not serious, the Bitcoin world already has dozens of such "solutions". Now what we need are people willing to craft well thought out UIs, thorough documentation and user experiences that you could show to a journalist without being embarrassed. If you're willing to go the extra mile and make a polished product that actually gets used regularly, you can expect a lot of time from at least me and probably most other core developers. If you're going to call it quits after a week and have your work sink into obscurity, don't bother.
Most things below I already have a pretty good idea of how I'd build, if I had the time. So don't hesitate to ask if you aren't sure about design.
If there's interest I'll try and keep this post up to date.
TOPIC: Payment protocol features
The payment protocol is a new early stage project to enhance the bitcoin URI system with more sophisticated features. It lays the groundwork for many things. You can read more here:
https://bitcointalksearch.org/topic/invoicespaymentsreceipts-proposal-discussion-128442
The basic idea is to build a replacement for the humble bitcoin: URI based on more complex data structures. Clicking a link or opening a payment file tells your client how to craft the required transactions, along with other things.
Over time it will give Bitcoin users more security, better privacy, proofs of payment (receipts), access to dispute mediation, simpler handling of fees, improved efficiency and scalability and more. Although the payment protocol work isn't anywhere near done yet, most of these things can be built in parallel.
Web developers
Java developers
C++ developers
Advanced developers
TOPIC: Dispute mediation
Bitcoin today stacks the deck in favor of the seller. This is better than credit cards which stack in favor of the buyer because sellers, having brands and reputations they want to protect, tend to be more trustworthy. But Satoshi had always planned to have proper dispute mediation, it's mentioned in the first page of his paper.
Implementing this well involves MANY different tasks.
... and many other things.
TOPIC: Crowdfunding and assurance contracts
How can the community fund useful projects that'd benefit us all, but which don't easily turn into a product/services business? Kickstarter-style pledge funding is one way. A contract where an entrepreneur says they will deliver some service if they collect >X coins in pledges is called an assurance contract and it's a way to solve the free rider problem. They're applicable to funding of open source software, videos, music, games, hardware designs .... anything that can be used by all for free once created.
The Bitcoin protocol supports the creation of these using SIGHASH_ANYONECANPAY. See the wiki page or video in my sig for more information.
TOPIC: Core p2p protocol upgrades
These features all need C++ developers.
There are many important tasks and bits of infrastructure in the Bitcoin world that aren't getting done because there aren't any developers working on them. The core team spends almost all of its time on boring but necessary things like improving performance, security and testing. Worse, many great ideas get proposed in ad-hoc discussions on IRC where other developers won't find them. The result is slow development of new features and few new people working on core infrastructure.
I'd like to summarize some tasks that can greatly improve Bitcoin for everyone, and group them by topic/experience/effort required - hopefully it may inspire one or two people to pick tasks off the list and tackle them. The list reflects my own biases and what I think is useful/cool.
But a word of warning. None of these tasks require advanced knowledge of cryptography but that doesn't mean they're easy. Don't bother trying these unless you're serious. Writing a Python script, sticking it on github and calling it a day is not serious, the Bitcoin world already has dozens of such "solutions". Now what we need are people willing to craft well thought out UIs, thorough documentation and user experiences that you could show to a journalist without being embarrassed. If you're willing to go the extra mile and make a polished product that actually gets used regularly, you can expect a lot of time from at least me and probably most other core developers. If you're going to call it quits after a week and have your work sink into obscurity, don't bother.
Most things below I already have a pretty good idea of how I'd build, if I had the time. So don't hesitate to ask if you aren't sure about design.
If there's interest I'll try and keep this post up to date.
TOPIC: Payment protocol features
The payment protocol is a new early stage project to enhance the bitcoin URI system with more sophisticated features. It lays the groundwork for many things. You can read more here:
https://bitcointalksearch.org/topic/invoicespaymentsreceipts-proposal-discussion-128442
The basic idea is to build a replacement for the humble bitcoin: URI based on more complex data structures. Clicking a link or opening a payment file tells your client how to craft the required transactions, along with other things.
Over time it will give Bitcoin users more security, better privacy, proofs of payment (receipts), access to dispute mediation, simpler handling of fees, improved efficiency and scalability and more. Although the payment protocol work isn't anywhere near done yet, most of these things can be built in parallel.
Web developers
- Medium - Write a tutorial showing how to integrate the basic tools Gavin and I wrote into a web site that supports SSL. Your tutorial should show how to build a simple web app that lets the user click a button and which serves up a payment request signed using the sites SSL key. Libraries for PHP/RoR/other common web frameworks to wrap invocation of the tools would be nice. Then write code to receive the resulting payment message uploaded by the client and hand it off to another process (like a future version of bitcoind, or some other node/tool). Note that there's a big TODO file in that git repository with many other tasks that can be done quite simply.
- Large - create a cloud-based website that hosts payment request files. Today if you want to receive a payment, you can just put an address into a message. But this has poor privacy, which the payment protocol is meant to address. Also, some services won't let you link to non-HTTP(S) URLs. So build a service where users can upload payment request files generated by their clients and have them hosted by you. People who want to pay can then download the request file whenever they want. For bonus points, have the site monitor for satisfaction of the requests and allow the links to be made private, single use, etc. You could fund the site using micropayments.
Java developers
- Medium - implement the payment protocol in bitcoinj. Doing the work here will make it easy to add support to MultiBit and the Android app. I've already got some unfinished code for this. It means code to do decoding/encoding, checking of signatures/signing, support in the wallet for creating spends based on the payment requests, documentation and some other tasks. I'll help you with this if you're serious about taking it on.
- Small - once the first task is done, integrate into MultiBit and/or the Android app. It means making the apps handle the payment request MIME types and URI extensions (not currently finalized) and then plumb all the data and code together.
- Medium - tablets and phones are always on, which makes them ideal for automatically sending subscription payments. Design and implement an extension to the payment protocol for setting up recurring billing, then use Androids alarm features to have your Bitcoin wallet automatically send money at the right time. Implement a nice UI to let users manage their subscriptions and perhaps use an Android passive notification to inform the user shortly before a payment will be made.
C++ developers
- Medium - integrate payment protocol support into Bitcoin-Qt and bitcoind. See above.
Advanced developers
- Large - research and prototype DNSSEC support. Currently to sign a payment request you need an SSL certificate. This system has many flaws, but it's widely deployed. DNSSEC is shaping up to be a superior alternative. Figure out how to embed data from DNS into static payment requests like we do for the SSL PKI so anyone with a domain name can sign requests "for free". Implement tools, client support and tutorials that anyone with a web site can follow.
- Large - prototype an implementation of this proposal for allowing static payment requests to dynamic addresses. This is a security and privacy upgrade, it also makes possible NFC smart tag tip-jars. Ultra-cheap tip jars are something most payment systems never consider, it'd be nice to fix this in Bitcoin.
TOPIC: Dispute mediation
Bitcoin today stacks the deck in favor of the seller. This is better than credit cards which stack in favor of the buyer because sellers, having brands and reputations they want to protect, tend to be more trustworthy. But Satoshi had always planned to have proper dispute mediation, it's mentioned in the first page of his paper.
Implementing this well involves MANY different tasks.
- Protocol designers, medium - Designing extensions to the payment protocol so sellers can advertise mediators they trust to do a good job, building a new protocol to automate setup of the 2-of-3 transactions, providing a way for mediators to advertise their policies, protocols for starting a dispute and stepping through each state a dispute can be in to resolution.
- Java/C++ developers, medium - extending clients so users can pick a mediator of their choice at payment time, from the list provided by the merchant, with an attractive and useful GUI. Ensuring each step of the process is accessible via an easy to use GUI that provides buttons for things like "Start dispute".
- Server/web developers, large - server-side tools that mediators can run to process incoming mediation requests, tools for merchants to integrate into their web shops so they can see and manage a queue of disputed trades
... and many other things.
TOPIC: Crowdfunding and assurance contracts
How can the community fund useful projects that'd benefit us all, but which don't easily turn into a product/services business? Kickstarter-style pledge funding is one way. A contract where an entrepreneur says they will deliver some service if they collect >X coins in pledges is called an assurance contract and it's a way to solve the free rider problem. They're applicable to funding of open source software, videos, music, games, hardware designs .... anything that can be used by all for free once created.
The Bitcoin protocol supports the creation of these using SIGHASH_ANYONECANPAY. See the wiki page or video in my sig for more information.
- Designers, medium - design a protocol for describing a contract, and an app that can handle it. For instance, you might design a .assurance-contract file that contains a protocol buffer with a description of the needed output, space for a photo/image, description of the contract, URL to find out the current progress towards the goal, URL to submit pledges to, etc.
- Java developers, large - write a server (I'd strongly suggest using bitcoinj for this) that collects pledges from clients and tracks progress towards the goal. The network should be monitored to discover when pledged outputs become double spent, so the relevant pledges can be invalidated. Ideally, the server should have a way to notify the entrepreneur of important events (eg, via email). Documentation must be written so people understand how to run a contract server.
- Java developers - either upgrade MultiBit, or create an entirely new wallet app from scratch (bitcoinj makes this easy), to provide a really great pledging experience. Users should be able to send money to their app and by clicking links in their web browser, open up new contracts that they can then pledge to with one or two clicks. They should be able to see progress towards the goal by just opening up the app and waiting for it to refresh. They should be able to take back their pledge money by double-spending away the output. For bonus points, find a UI that allows users to pledge the same money to multiple different contracts without getting confusing. Whichever contract completes first wins and automatically invalidates the other pledges.
TOPIC: Core p2p protocol upgrades
These features all need C++ developers.
- A paper last year described how to increase confidence in unconfirmed transactions by implementing double spend alerts. When a double spend is seen propagating across the network, both spends are relayed everywhere so clients know to wait until the race is resolved. Unfortunately, it's never yet been implemented.
- Improve scalability by broadcasting blocks as lists of transaction hashes and let peers request the ones they didn't see yet. Eliminates double relaying of tx data.
- Add error messages to the protocol so if you try sending an invalid transaction by mistake (eg, fee rules changed and you didn't upgrade yet) you can find out quickly and directly.
Jump to: