Topic: Java developers wanted to help me out on bitcoinj (Read 930 times)
Thanks for this post. It is really helpful.
I am hoping that with the recent surge in interest, there maybe some people kicking around who are looking for ways to make themselves useful.
bitcoinj is a Java library and implementation of Bitcoin that underlies the Android app and MultiBit. It also has been used to build a variety of web apps, like SatoshiDice, along with a bunch of other things we never hear much about directly. Improving it is directly useful to both the user and developer community because it's the only true implementation of SPV mode software, which is lightweight enough to run on desktops and cheap virtual private servers.
If you'd like to help out there are a bunch of projects that'd be super useful to implement. If one of them sounds interesting to you, please join the mailing list and introduce yourself, or just private message me here, or email me.
We need someone to implement the payment protocol. This isn't particularly hard - it means writing a class that uses the Java crypto APIs to validate the cert chain and signatures on the signed payment requests, and then upgrading the Wallet class so it can take a payment request and produce a payment response as an output. Then provide a utility class to upload the response, and expose the messages functionality, and we're done. Andreas and Jim can then use the new API to integrate payment protocol support into their respective wallets.
Deterministic wallets are nearly finalised, it seems, and we really need support for that - right now to avoid disasters with people not backing up at the right time, bitcoinj by default only uses one key (the apps let you add more). This is a huge privacy leak but seems better than the risk of people losing money. Deterministic wallets let us have our cake and eat it - just one code to write down, and then in the worst case if you lose your backed up wallet files you can still get your money back. They're also highly useful for server side apps. Some Java code to implement the deterministic wallet algorithm is already written, but it needs integration with the Wallet class so keys are derived at the right times, persisted once derived (as re-deriving them each time is too slow), etc. This also has impact on bloom filtering as the filter needs to contain keys ahead of what's expected, in case the root keys are being shared between devices.
bitcoinj lacks good support for fees - a really good solution would to integrate an integer linear programming solver and then specify coin selection as a set of constraints over the unspent output set. Coin selectors are already nicely abstracted and pluggable, so you can experiment with this independently without any changes to the core library.
We could also use a collection of apps that implement useful tools, like monitoring the memory pool or measuring transaction propagation/confirmation times. As well as being independently useful, these can act as good examples for how to use the library.
There are many more things that could be improved or fixed, so if you've got any questions, let me know.
bitcoinj is a Java library and implementation of Bitcoin that underlies the Android app and MultiBit. It also has been used to build a variety of web apps, like SatoshiDice, along with a bunch of other things we never hear much about directly. Improving it is directly useful to both the user and developer community because it's the only true implementation of SPV mode software, which is lightweight enough to run on desktops and cheap virtual private servers.
If you'd like to help out there are a bunch of projects that'd be super useful to implement. If one of them sounds interesting to you, please join the mailing list and introduce yourself, or just private message me here, or email me.
We need someone to implement the payment protocol. This isn't particularly hard - it means writing a class that uses the Java crypto APIs to validate the cert chain and signatures on the signed payment requests, and then upgrading the Wallet class so it can take a payment request and produce a payment response as an output. Then provide a utility class to upload the response, and expose the messages functionality, and we're done. Andreas and Jim can then use the new API to integrate payment protocol support into their respective wallets.
Deterministic wallets are nearly finalised, it seems, and we really need support for that - right now to avoid disasters with people not backing up at the right time, bitcoinj by default only uses one key (the apps let you add more). This is a huge privacy leak but seems better than the risk of people losing money. Deterministic wallets let us have our cake and eat it - just one code to write down, and then in the worst case if you lose your backed up wallet files you can still get your money back. They're also highly useful for server side apps. Some Java code to implement the deterministic wallet algorithm is already written, but it needs integration with the Wallet class so keys are derived at the right times, persisted once derived (as re-deriving them each time is too slow), etc. This also has impact on bloom filtering as the filter needs to contain keys ahead of what's expected, in case the root keys are being shared between devices.
bitcoinj lacks good support for fees - a really good solution would to integrate an integer linear programming solver and then specify coin selection as a set of constraints over the unspent output set. Coin selectors are already nicely abstracted and pluggable, so you can experiment with this independently without any changes to the core library.
We could also use a collection of apps that implement useful tools, like monitoring the memory pool or measuring transaction propagation/confirmation times. As well as being independently useful, these can act as good examples for how to use the library.
There are many more things that could be improved or fixed, so if you've got any questions, let me know.
Jump to: