Contributing to MultiBit development

[guti]

Hey,

I want to jump in and help a bit in the MultiBit development (really love that client). I wasn't sure if this is the right place for this so I'll just shoot and redirect me to the appropriate place if needed -

While reading across a couple of threads here I really liked to idea of adding a txn fee-per-kb slider so I thought about starting with this.

What do you guys think? If I have any coding-style questions should I direct them here?

Thanks in advance!

[jim618]

Hi Guti,

Thanks for your interest.

Currently Gary and I are working in 'stealth mode' on the next version of MultiBit (MultiBit HD) so it is mainly maintenance work being done on the MultiBit code.

If you'd like to write code for a bitcoin client I would recommend creating your own !
Mike Hearn wrote a post in 'Alternative Clients' about how easy it is now to write a client:
https://bitcointalk.org/index.php?topic=323541.0

The reason I suggest that is that MultiBit has now become a bit of a victim of its own success. There are so many users now that I have to be ultraconservative with making changes. Everything has to be as robust as possible, fully unit tested, everything documented on the help pages and regression tested on each release. As much as possible it has to be both backward and forward compatible with earlier versions of MultiBit and those not yet even written.

(It's actually getting a bit painful).

Mike's example wallet app is a lot cleaner code than MultiBit and would be a nicer codebase to start with.
Having more SPV clients would be better for Bitcoin in the long run too as we should have more decentralisation.

Something to think about anyhow !

:-)

[Mike Hearn]

Whilst Jim has a point that adding features to MultiBit got a bit painful, there's no reason you couldn't just fork the code and continue to evolve it in the direction you like. A fee-per-kb slider would be an interesting first project, although bear in mind that in future fees will start to float and be estimated by the code itself (users should not have to think about manually setting fees).

[guti]

Mike - I'm totally aware that the fee-giving code in the future is going to be different than what we have today, I just wanted to have an immediate solution to a problem some of the users experience (I personally waited for 1-2 hours for first confirmation with the current fee mechanism)

And in regard to forking and maintaining my own wallet - I actually wanted to avoid that at this point, I want to start getting into the Bitcoin development world and jumping right into creating my own wallet seems a bit too fast. Contributing to existing code at first seems like a better plan to me.

I know everything is open source but still I'd like to have a couple of wallets that I can count on rather than hundreds of different wallets from small unknown authors.

Thanks for your answers!

[Mike Hearn]

Pushing fees ever upwards gives me a sad face

We need to get a really good grip on why transactions are taking so long to confirm. It's not because we ran out of block space. Transactions in Bitcoin are already too expensive due to the recent runup in value. Making them even moreso is a real problem.

[guti]

Actually it's not *that* clear to me why it takes time to confirm transactions  .

Indeed we're not close to reaching the current block size (1mb right?) and the maximum number of signature operations is MAX_BLOCK_SIZE/50 if I understand correctly, so that gives us 20000 transactions (with 1 input 1 output) per block.

Why won't miners just put all the verified transactions they get?
Is it an expensive operation? (bandwidth to the ASIC? something else?)

[jim618]

Game theory wise that is one of the reasons I think for users it is better to have the fee fixed (or as low as we can go)

We could get into a situation where people start rewarding miners (by increasing their fees) for NOT including transactions. All users lose if we have to pay to 'jump ahead in the queue'.

[Peter Todd]

Game theory wise that is one of the reasons I think for users it is better to have the fee fixed (or as low as we can go)

We could get into a situation where people start rewarding miners (by increasing their fees) for NOT including transactions. All users lose if we have to pay to 'jump ahead in the queue'.

Read the analysis that Michael Gronager and myself have been doing on optimal block sizes:

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03209.html
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03230.html

Including transactions in blocks absolute does have a cost to miners due to orphans, and that cost is based on the hashing power of the miner and the time it takes for blocks to propagate around the network. Michael has derived a rough estimate that the 0.1mBTC/KB fee assumed by many wallets is something like ~8-4 times too small to be profitable.

What's interesting about the analysis is how the cost is in terms of Bitcoins, not dollars, because the inflation subsidy is huge right now. (~$30 USD/tx) In any case, fixed fees just won't work. First of all because it's a competitive market, and secondly because if you set them too low miners have no incentive to include transactions at all.

[jim618]

Very interesting Peter.