Title: Different architecture proposal? Post by: eugene2k on July 21, 2010, 09:54:59 PM 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.
Title: Re: Different architecture proposal? Post by: dete on July 22, 2010, 04:18:04 AM 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:
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. Title: Re: Different architecture proposal? Post by: Hepatizon on July 22, 2010, 03:14:00 PM 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:
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. Title: Re: Different architecture proposal? Post by: RHorning on July 23, 2010, 06:36:45 PM 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. Title: Re: Different architecture proposal? Post by: NewLibertyStandard on July 23, 2010, 06:54:31 PM Instead of discussing it privately, I think I'd rather just hear your ideas for improvement (http://bitcointalk.org/index.php?topic=557.0). Title: Re: Different architecture proposal? Post by: dete on July 24, 2010, 07:58:12 AM 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 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. Title: Re: Different architecture proposal? Post by: dete on July 24, 2010, 08:04:01 AM 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). Title: Re: Different architecture proposal? Post by: jgarzik on July 24, 2010, 08:20:49 AM [/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. Title: Re: Different architecture proposal? Post by: Anonymous on July 24, 2010, 12:10:21 PM Oauth has been hacked hasnt it?It is supposed to be announced at blackhat.
Title: Re: Different architecture proposal? Post by: Bitcoiner on July 24, 2010, 03:40:50 PM 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:
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 :) Title: Re: Different architecture proposal? Post by: dete on July 24, 2010, 03:47:54 PM 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.) Title: Re: Different architecture proposal? Post by: Cdecker on July 27, 2010, 10:19:55 PM 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). That's exactly what I was thinking :-)In fact, I'd go so far as to say that one of the next major steps for the bitcoin system is two fold:
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. 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? ;D |