BitCoinJ in 2011, 2012

[Mike Hearn]

Today is the last day I'm working, I'll be back on the 3rd January, feeling fresh and ready to go :)

2011 has been an amazing year for Bitcoin and this project specifically. This community has really developed and is great fun to work with. What started as a quick hacking session to try and get an Android wallet up and running has turned into the backbone for all kinds of apps. We've gone from a codebase that barely understood the block chain to one that has a robust test suite, better project infrastructure and which has real users. Andd we're opening up Bitcoin development to developers who would struggle to handle Satoshis codebase.

I think 2012 is going to be an even better year for BitCoinJ. Here's what I'd like to see us accomplish:

• Removing the need to fork the library to use in wallet apps: that means finishing off the pending transactions work and a few other tasks.
• Ability to handle more script types:  send-to-pubkey, OP_EVAL (scheduled to be switched on in February!). Parsing, generating.
• Lay the groundwork for multi-factor coins (a usable implementation needs upgrades to MultiBit+Android wallets).
• Improve efficiency by an order of magnitude for mobile clients, so pure p2p remains competitive with BCCAPI type approaches.
• Use getheaders to catch up the block chain quickly for new users
• Don't parse blocks that don't match interesting byte patterns
• Support storing the chain as a ringbuffer, so we can truly bound disk storage requirements
• Maybe: add support for server-side filtering to the Satoshi codebase.
• Redesign the library to be more useful outside the wallet use case. Merge in a fully indexing block store that contains transactions as well, so you can query for the balance of arbitrary keys.
• Support for rewinding the block chain to some arbitrary point, use to make key import/rescanning work well.
• Halve open bug/feature req count
• Stretch goal: experiment with auto-negotiated security assurance contracts 
• At least 6 releases with associated improvements in documentation.

Jim already posted some of his short-term goals. What about everyone else? What are your goals for 2012?

--
Google Switzerland GmbH

[Gary Rowe]

I'm working with Jim on MultiBit to get those changes in, and also on MultiBit Merchant which will offer a pure Bitcoin online shop that anyone can use right out of the box.

[Andreas Schildbach]

Nice list, and I am looking forward to see all that stuff happening in 2012!

Unfortunately, I do not have as much choice as you do. Most of my plans
are stalled because of necessary changes to BitCoinJ or
unstable/unusable Android API.

Still, I've got some plans for Q1/2012 (in random order):

- better startup experience
- nicer, more feature complete address book
- backup/restore/export/import for private keys
- make background operations "more background", e.g. happen at dock-time

- migrate BitCoinJ fork to git and use mvn to build
- get rid of the fork asap
- maybe also migrate Bitcoin Wallet itself
- (learn to) do further talks about (aspects of) Bitcoin

I can say that 2011, Bitcoin took my heart by storm. For me, it's
exactly the technical/economical/political crossover I like and its
impact can be huge! I feel I will stay with the project for a long time.

If I may make a wish, I'd love to see more focus on the basics: The
wallet persistence problem is still unsolved, despite the prediction
being "late summer" (or something like that). Its good to see that
pending transactions are finally right around the corner. I'd consider
proper fees also very important, because of the risk of stalled
transactions.

Happy christmas!

P.S. if someone happens to be around at the Chaos Communication Congress
in Berlin, drop me a note...

On 12/21/2011 06:10 PM, Mike Hearn wrote:
> Today is the last day I'm working, I'll be back on the 3rd January,
> feeling fresh and ready to go :)
>
> 2011 has been an amazing year for Bitcoin and this project specifically.
> This community has really developed and is great fun to work with. What
> started as a quick hacking session to try and get an Android wallet up
> and running has turned into the backbone for all kinds of apps. We've
> gone from a codebase that barely understood the block chain to one that
> has a robust test suite, better project infrastructure and which has
> real users. Andd we're opening up Bitcoin development to developers who
> would struggle to handle Satoshis codebase.
>
> I think 2012 is going to be an even better year for BitCoinJ. Here's
> what I'd like to see us accomplish:
>

> * Removing the need to fork the library to use in wallet apps: that

> means finishing off the pending transactions work and a few other tasks.

> * Ability to handle more script types: send-to-pubkey, OP_EVAL

> (scheduled to be switched on in February!). Parsing, generating.

> * Lay the groundwork for multi-factor coins (a usable implementation

> needs upgrades to MultiBit+Android wallets).

> * Improve efficiency by an order of magnitude for mobile clients, so

> pure p2p remains competitive with BCCAPI type approaches.

> o Use getheaders to catch up the block chain quickly for new users
> o Don't parse blocks that don't match interesting byte patterns
> o Support storing the chain as a ringbuffer, so we can truly bound
> disk storage requirements
> o Maybe: add support for server-side filtering to the Satoshi
> codebase.
> * Redesign the library to be more useful outside the wallet use case.

> Merge in a fully indexing block store that contains transactions as
> well, so you can query for the balance of arbitrary keys.

> * Support for rewinding the block chain to some arbitrary point, use

> to make key import/rescanning work well.

> * Halve open bug/feature req count
> * Stretch goal: experiment with auto-negotiated security assurance
> contracts
> * At least 6 releases with associated improvements in documentation.