Different architecture proposal?

[eugene2k]

Instead of having bitcoind for running in server mode only and providing a simple webserver with a json interface and also having bitcoin for running in gui mode or server mode, why not have a bitcoind running as a service and providing some sort of ipc mechanism to client programs which could provide interfaces - GUI or JSON or whatever? This kind of architecture would allow interested parties to write all kinds of plugins - e.g. python modules, .net modules etc.

[1714600335]

1714600335

[1714600335]

1714600335

[1714600335]

1714600335

[dete]

I've been thinking exactly along these lines.  The main bitcoin process should NOT be tied to the UI at all (and, while a wxWidgets UI is a great way to bootstrap the project, it's NOT a good solution for the long term).

In fact, I'd go so far as to say that one of the next major steps for the bitcoin system is two fold:

• Create a proper spec of the protocol (if one exists outside of the source code at this point, I haven't found it)
• Create a second, independent implementation of the protocol

Without a second, independent implementation, you can't be sure that the protocol is correctly documented.

Perhaps the "reference" implementation (which we're all currently using) doesn't need to change, but if I were designing a bitcoin client, it's be structured a LOT differently than the current client.

[Hepatizon]

I've been thinking exactly along these lines.  The main bitcoin process should NOT be tied to the UI at all (and, while a wxWidgets UI is a great way to bootstrap the project, it's NOT a good solution for the long term).

In fact, I'd go so far as to say that one of the next major steps for the bitcoin system is two fold:

• Create a proper spec of the protocol (if one exists outside of the source code at this point, I haven't found it)
• Create a second, independent implementation of the protocol

Without a second, independent implementation, you can't be sure that the protocol is correctly documented.

Perhaps the "reference" implementation (which we're all currently using) doesn't need to change, but if I were designing a bitcoin client, it's be structured a LOT differently than the current client.

I second this.  In particular, I would like to see a lightweight client that only handles transactions and doesn't do any CPU-intensive hashing or verifications.  Simply announcing a transaction is something that is well within the capabilities of a cell phone or netbook.  You could even designate a "trusted source" to keep track of your account information - so your cell phone could just ask your home computer how much you had in your wallet rather than trying to figure it out itself.

I'd be willing to make another implementation of the protocol if I can figure out what it is.  The source code is documented ... poorly.

[RHorning]

I have a side project that would require some sort of re-implementation of the protocol as well.  Indeed, I think having multiple implementations of the protocol can do nothing but strengthen and protect the stability of Bitcoins so there isn't a single vector of attack on the network.

Mind you, I'm not against a reference implementation, and I think the current client ought to continue to be developed, but it would be healthy to actually come up with a specification document that spells out the formal data structures and perhaps describes through psuedocode in a language agnostic manner what the algorithms of Bitcoins happen to be.

Something this also promotes is to allow a hard scholarly review of the protocol and perhaps find some of the flaws in its design that can hopefully be corrected while the network is still young.  Saying that the documentation is in the reference implementation is only security through obfuscation and being lazy.  It has been a flaw in other peer to peer network designs.  No, I'm not asking satoshi to write this stuff (if he doesn't want to take the time), but I think it would be useful to start a document on the wiki that goes over the protocols in a neutral manner.

What I'm looking for is something akin to an ISO protocol document, and perhaps something that over time could even be submitted to that international body in a formal manner or some other standards body like the ECMA or IEEE.  At the very least, get it submitted as a formal RFC for internet protocols.  The wiki would be a good place to start.

[NewLibertyStandard]

I'm interested in privately discussing design differences with anyone who is honestly capable of and seriously committed to creating an alternative implementation.

Instead of discussing it privately, I think I'd rather just hear your ideas for improvement.

[dete]

I have lots of ideas, but I'm not sure I have enough time to even articulate them fully, let alone implement them.  Here's a first stab:

• A highly portable, core computation engine which doesn't depend on anything outside the standard libraries.  I don't think that a "validation only" engine is any less code than a block generating engine, so I see no reason for any bifurcation in that respect.
  
  
• A cross-platform APPEND ONLY database for storing blocks. There's lots of interesting stuff happening in the NoSQL world that would work well here.  I think it makes sense to piggyback on some other open source; the key is to find something that is lean.  Most of the NoSQL world is focussed on speed, and that's far less of an issue here.  Ideally, a library for reading the block list would be a separable component; there are some interesting BTC applications that don't need access to your wallet.
  
  
• A plugin architecture for alternate hashing engines.  Faster hashing means generating more coins for yourself.  If BTC takes off, there will be a market for fast hash engines.  Ideally, this plugin engine should require that the plugin returns ALL computed hash values, not just successes.  That way the core engine can randomly confirm that hashes are being properly computed.  (Making a fake plugin which doesn't actually do all the hashes it claimed would be really simple...)  Creating a plugin system here means fewer forked clients and much less maintenance for users and the community.
  
  
• The main "bitcoin" process should always be a daemon.  You could configure a client to quit the daemon when it shuts down, but the client and the daemon should be separate processes.
  
  
• WALLET IS ALWAYS STORED ENCRYPTED.
  
  
• A secure RPC/web service interface for clients.  Maybe based on OAuth?  The OAuth style model is best here, though.  The key thing is that you don't want to require clients to have a copy of the user's password.  No siree, Bob!  Local machine connections could be authenticated by the daemon directly, remote connections would need to provide a simple HTTPS form for authentication.
  
  
• Separate read-only/read-write permissions.  Read-only permissions could be used to check balances, verify payments, check confirmation counts.  Read-write would only be necessary for applications that send payments.  There are some useful applications which only require read-only access (eg. notify when a new payment comes in and is confirmed), but I'd be less likely to want to run a third-party app like that if I had to also give it permission to send my coins to some untraceable address!

A key design goal here is compartmentalization.  The compute engine is portable so it can be shared across platforms.  The hashing code is pluggable so that custom hash engines don't require forking the entire project.  Multiple clients can be written for each platform, and can all be safely run at the same time talking to a single core daemon.

[dete]

One more thing:

I think the daemon process (which does all the networking, hashing and database stuff) and a reference hashing plugin absolutely needs to be free and open.  I also think that a basic free client should be available for everyone.  However, I think there are some really great opportunities in creating for-profit hashing plugins and whizzy and/or specialized clients.

I suspect that NewLiberty wants to talk off list because he has some ideas about a closed, for-profit client.  I'm totally cool with that and wish him the best, but I really, really hope he doesn't think that anyone should trust the core logic of their wallet to software they can't audit (or have audited).

[jgarzik]

[/li][li]WALLET IS ALWAYS STORED ENCRYPTED.

If the wallet is stored via Berkeley DB, it should be easy to turn on DB's automatic AES encryption feature.

I agree the wallet should always be stored encrypted.

[Anonymous]

Oauth has been hacked hasnt it?It is supposed to be announced at blackhat.

[Bitcoiner]

I've been thinking exactly along these lines.  The main bitcoin process should NOT be tied to the UI at all (and, while a wxWidgets UI is a great way to bootstrap the project, it's NOT a good solution for the long term).

In fact, I'd go so far as to say that one of the next major steps for the bitcoin system is two fold:

• Create a proper spec of the protocol (if one exists outside of the source code at this point, I haven't found it)
• Create a second, independent implementation of the protocol

Without a second, independent implementation, you can't be sure that the protocol is correctly documented.

Perhaps the "reference" implementation (which we're all currently using) doesn't need to change, but if I were designing a bitcoin client, it's be structured a LOT differently than the current client.

I also agree with this. I've brought up the point in the past; the question is likely developer resources. If you guys are willing, go ahead and start working on this; I'm sure satoshi won't refuse the help

[dete]

Oauth has been hacked hasnt it?It is supposed to be announced at blackhat.

A particular implementation of OAuth was susceptible to a side-band attack.  Basically, you could get extra information about which part of your attempted fake-authentication packet was incorrect by timing how long it took for the server to reject it.

The protocol is still considered secure.  (Besides, I'm not sold on OAuth in particular, but something similar.  The key point is to not use simple password authentication, because then you end up with each client "caching" the users password independently which is a big security risk.)

[Cdecker]

I've been thinking exactly along these lines.  The main bitcoin process should NOT be tied to the UI at all (and, while a wxWidgets UI is a great way to bootstrap the project, it's NOT a good solution for the long term).

In fact, I'd go so far as to say that one of the next major steps for the bitcoin system is two fold:

• Create a proper spec of the protocol (if one exists outside of the source code at this point, I haven't found it)
• Create a second, independent implementation of the protocol

Without a second, independent implementation, you can't be sure that the protocol is correctly documented.

Perhaps the "reference" implementation (which we're all currently using) doesn't need to change, but if I were designing a bitcoin client, it's be structured a LOT differently than the current client.

That's exactly what I was thinking :-)

A simple reference client that just implements the protocol without the heavy duty computation and not even the data storage would be great. That's the reason I started this thread: https://www.bitcoin.org/smf/index.php?topic=231.0

Anyone interested in helping reverse engineer the protocol?