I strongly think what you are doing is great, I have the following advice.
If your app managed everything other than a user's private keys, and outsourced all signing and key management operations to a DLL whose source you're willing to release (and where users could replace it with a DLL of their own), then I think most people's objections would be calmed.
The level of abstraction this open-source DLL might support: the DLL should support being asked what private keys it holds (DLL returns the public keys), and the DLL should support being asked to sign a transaction (where the cleartext and hash of the transaction is passed to the DLL so it can confirm with the user if that's OK). The DLL should be relied upon to create new keypairs as well. The DLL may not necessarily have access to the private keys, or might have to get a decryption key from the user "on the fly" in the form of a password prompt.
Ideally, one should be able to create a plug-in DLL that, for example, initiates a signing operation on a smart card or hardware wallet, if that user desired.
Topic: Preview build of our new client (only for the adventurous!) (Read 2221 times)
We'll just have to agree to disagree on these points, I'm not going to allow the thread to digress into point/counter-point.
I wish you well in your endeavor, I just won't be using it.
I wish you well in your endeavor, I just won't be using it.
I don't, it's available so I read it. I provide comments on it. I participate in the community that is an open source project. Could you hide malicious code in plain sight? Sure. Would the project see the light of day when said malicious code was discovered by someone with knowledge and the time to read the code? Nope. I'll use an open source project over a closed source one in a heart beat for that reason. The likelihood something is hidden, and undiscovered, is much lower.
I am not sure what you mean about the project seeing the light of day, though I commend you for actually working your way through the code. You represent a tiny minority of computer users however and AllBitcoin is clearly not for you. OSS has many fantastic properties and I'm a big supporter of it. Many eyeballs on the code are great for security and bug finding. However OSS does not imply trust. For your amusement I recommend you check out some of the code presented here: http://underhanded.xcott.com/
Most of us trust banks, OS vendors, video game developers, etc. enough to use their closed source software. I would prefer for it to be open sourced too, but that would not influence my level of trust in these organizations.
Bitcoins have helped expose how lax our security has been and if we want it to succeed, we have a lot of work ahead of us.
And how did Bitcoins expose lax security? Because users had trojans? Because a site got hacked? What does any of that have to do with Bitcoins? We don't need new banks because someone hacked a bank.
I meant it in the sense that prior to Bitcoins, most losses due to compromised computers could generally be reversed. Bitcoins give us irreversible transactions and a store of wealth sitting directly on our hard drives. We're not quite ready for this in terms of both social and software engineering but I'm sure we'll figure it out.
I would also recommend that you don't trust binaries just because their source code is available. It is perfectly feasible to hide malicious code in plain sight or introduce something bad in the build process.
I don't, it's available so I read it. I provide comments on it. I participate in the community that is an open source project. Could you hide malicious code in plain sight? Sure. Would the project see the light of day when said malicious code was discovered by someone with knowledge and the time to read the code? Nope. I'll use an open source project over a closed source one in a heart beat for that reason. The likelihood something is hidden, and undiscovered, is much lower.
Bitcoins have helped expose how lax our security has been and if we want it to succeed, we have a lot of work ahead of us.
And how did Bitcoins expose lax security? Because users had trojans? Because a site got hacked? What does any of that have to do with Bitcoins? We don't need new banks because someone hacked a bank.
The catch is - we're closed source, at least for now. We feel that earning people's trust is about more than just dumping the source code.
Our source tree also has a lot of work in progress on cool features that we would like to be the first client to support.
Once we're ready to come out of beta, we'll re-evaluate this decision.
I am well aware of how well this will go down around here and I preemptively support your calls for my head on a spike.
There is no reason not to leave the source open from the beginning, unless you have something to hide. In fact, if you really want it to take off, then you should welcome additional eyes to assist with issues, features, and bugs.Our source tree also has a lot of work in progress on cool features that we would like to be the first client to support.
Once we're ready to come out of beta, we'll re-evaluate this decision.
I am well aware of how well this will go down around here and I preemptively support your calls for my head on a spike.
This is where I disagree - I feel that we have a very good reason for not releasing the source code (yet). Our focus is on making a client for people who may not even know what source is. For a vast majority of software users out there trust isn't derived from availability of source code. We want to keep the source to ourselves because we think it offers compelling features that other clients don't and we'd like to maintain that edge for a little while. I understand that in an OSS community this argument will fall on deaf ears but we're not forcing you to use AllBitcoin.
I would also recommend that you don't trust binaries just because their source code is available. It is perfectly feasible to hide malicious code in plain sight or introduce something bad in the build process. We're working on a distributed web of trust solution for code signing to solve these issues in general. Bitcoins have helped expose how lax our security has been and if we want it to succeed, we have a lot of work ahead of us.
Also please keep in mind this is early beta, we're simply hoping to get some feedback on our progress so far (other than 'source or GTFO')
The catch is - we're closed source, at least for now. We feel that earning people's trust is about more than just dumping the source code.
Our source tree also has a lot of work in progress on cool features that we would like to be the first client to support.
Once we're ready to come out of beta, we'll re-evaluate this decision.
I am well aware of how well this will go down around here and I preemptively support your calls for my head on a spike.
Our source tree also has a lot of work in progress on cool features that we would like to be the first client to support.
Once we're ready to come out of beta, we'll re-evaluate this decision.
I am well aware of how well this will go down around here and I preemptively support your calls for my head on a spike.
Ultimately, I cannot believe anyone would use this client until the source is posted on Sourceforge or GitHub. Why would anyone want to trust a closed source client. Earning trust can most easily be accomplished by being open and transparent. Don't give people a reason to disbelieve and they won't.
There is no reason not to leave the source open from the beginning, unless you have something to hide. In fact, if you really want it to take off, then you should welcome additional eyes to assist with issues, features, and bugs.
The long term goal is to have native clients for all major platforms. We started with Windows as it is the one platform that needed a more secure client the most. Sadly Windows doesn't have the best choice of UI APIs after we elminated Qt for various reasons. A pure win32 interface is being worked on and will yield a much leaner client, though it will take a lot more time.
Care to elaborate on why you ditched Qt? Also, why did you go with Forms and not WPF when you decided to do .Net, and not use Qt in .Net?
--
Thomas
Few reasons (in no particular order):
- Distribution size and ease. Qt DLLs are pretty weighty - the basic set (Core, Gui, Network) come in at over 11 megs on top of our download. Admittedly .Net is an order of magnitude bigger, but on most PCs the runtime is already there. Also the oneclick deployment platform automatically deals with the dependencies.
- Qt is probably as good a cross-platform UI toolkit as one could hope for, but Qt apps still fall short of the native experience. We've gone with .Net for now for speed of development but the long term plan is to have a light, snappy native Win32 client with as few dependencies as possible (a single, small EXE that can live on a USB drive would be ideal).
- Licensing - Qt would cost extra.
- There's already a Qt client project, we didn't want to duplicate efforts unnecessarily.
The long term goal is to have native clients for all major platforms. We started with Windows as it is the one platform that needed a more secure client the most. Sadly Windows doesn't have the best choice of UI APIs after we elminated Qt for various reasons. A pure win32 interface is being worked on and will yield a much leaner client, though it will take a lot more time.
Care to elaborate on why you ditched Qt? Also, why did you go with Forms and not WPF when you decided to do .Net, and not use Qt in .Net?
--
Thomas
I just thought about this but doesn't a closed source UI go against what bitcoin is all about & why it started? With bitcoin native wallet you know what code your getting in the bitcoin wallet becuase you can see what the inner workings are for your self, or even hire somebody to check it out if you don't have that kind of knowledge, I'm just giving you the big heads up with the lack of support you will receive for this project mostly because of the certain circumstances most notably the Mtgox breach, the possibility that there is a timer that will send all available funds in the infected computers to an address own by you. How do you build trust with and organization when they aren't being upfront about their product? Example: I certainly wouldn't purchase a computer to have all the side casing welded just so I'd be forced to use any restrictions or bugs that may be in the system, would you?
I'm still trying to work out what Bitcoin is all about
. I would argue that having an ecosystem of competing clients would be more in keeping with the spirit of Bitcoin. As I've mentioned before, closed source is a temporary state while we feel it makes business sense. If we succeed the way we'd like to - it is inevitable that the source code will be available for thorough inspection in some way.
I just thought about this but doesn't a closed source UI go against what bitcoin is all about & why it started? With bitcoin native wallet you know what code your getting in the bitcoin wallet becuase you can see what the inner workings are for your self, or even hire somebody to check it out if you don't have that kind of knowledge, I'm just giving you the big heads up with the lack of support you will receive for this project mostly because of the certain circumstances most notably the Mtgox breach, the possibility that there is a timer that will send all available funds in the infected computers to an address own by you. How do you build trust with and organization when they aren't being upfront about their product? Example: I certainly wouldn't purchase a computer to have all the side casing welded just so I'd be forced to use any restrictions or bugs that may be in the system, would you?
I won't be touching this until someone ILDASMs it and proves it's safe 
(Even in VM, hwo do you know it doesn't only work x days into the future on the xth second, or something silly, or if a certain transaction is in a block it picks up!)
(Even in VM, hwo do you know it doesn't only work x days into the future on the xth second, or something silly, or if a certain transaction is in a block it picks up!)I don't want to be devils advocate, but I would argue that almost everybody uses (and trusts) closed code software. Even if you run Linux and you compiled the kernel yourself chances are that you didn't get the chance to read every line of code. In fact I've been using the official Bitcoin client for month and I haven't even glanced at the code yet, just because I don't have the time right now. I trust the official client because people would complain about it and stop using it if it would be a scam.
Anyway I started to run Allbitcoin and transferred a very small amount of coins into it and it works great. I like the GUI. I like the wallet encryption and I think the JSON export/import feature is a fantastic idea to manage multiple wallets!
Well done guys. Keep up the good work. I'm looking forward to your future releases!
Oliver.
I'm allowed to be paranoid
If something is designed for use wiht bitcoin, only bitcoin users would use it = maximal impact if it did anything fishy bitcoin related. How is it:
based on 0.3.23, tracking changes as they come in
and closed source?
I won't be touching this until someone ILDASMs it and proves it's safe (Even in VM, hwo do you know it doesn't only work x days into the future on the xth second, or something silly, or if a certain transaction is in a block it picks up!)
based on 0.3.23, tracking changes as they come in
and closed source?
I won't be touching this until someone ILDASMs it and proves it's safe
(Even in VM, hwo do you know it doesn't only work x days into the future on the xth second, or something silly, or if a certain transaction is in a block it picks up!)See my earlier points about only testing with trivial amounts if at all.
I would also like to point out that it would quite monumentally stupid for us to have AllBitcoin do anything fishy at all. Any breach of trust would render all of our hard work so far useless.
I support all investigative efforts - monitor the traffic, disassemble the code, dump the memory. Look for unencrypted private keys or password - it should be highly unlikely to capture one in a memory dump and absolutely impossible over the network.
I won't be touching this until someone ILDASMs it and proves it's safe (Even in VM, hwo do you know it doesn't only work x days into the future on the xth second, or something silly, or if a certain transaction is in a block it picks up!)
(Even in VM, hwo do you know it doesn't only work x days into the future on the xth second, or something silly, or if a certain transaction is in a block it picks up!)I don't want to be devils advocate, but I would argue that almost everybody uses (and trusts) closed code software. Even if you run Linux and you compiled the kernel yourself chances are that you didn't get the chance to read every line of code. In fact I've been using the official Bitcoin client for month and I haven't even glanced at the code yet, just because I don't have the time right now. I trust the official client because people would complain about it and stop using it if it would be a scam.
Anyway I started to run Allbitcoin and transferred a very small amount of coins into it and it works great. I like the GUI. I like the wallet encryption and I think the JSON export/import feature is a fantastic idea to manage multiple wallets!
Well done guys. Keep up the good work. I'm looking forward to your future releases!
Oliver.
The catch is - we're closed source, at least for now. We feel that earning people's trust is about more than
just dumping the source code. Our source tree also has a lot of work in progress on cool features that we
would like to be the first client to support. Once we're ready to come out of beta, we'll re-evaluate this
decision. I am well aware of how well this will go down around here and I preemptively support your calls
for my head on a spike.
just dumping the source code. Our source tree also has a lot of work in progress on cool features that we
would like to be the first client to support. Once we're ready to come out of beta, we'll re-evaluate this
decision. I am well aware of how well this will go down around here and I preemptively support your calls
for my head on a spike.
Nothing against that, your choice, your program. I am curious if you have some credentials on projects you have worked on/been a part of, web sites, anything, that would make me want to put an executable file form you on my computer. Good luck btw, I know security is of course priority one, but if people want things to expand, they have to think of the UI too.
I am a C++ developer and have worked in the industry for 10 years, though I've been programming for another decade prior to that. This is my first startup and I have only limited web development experience (as evidenced by our website). Since most of my prior work was also public facing, I'm going to plead Satoshi on that to protect myself and my colleagues until I have a long and expensive talk with a lawyer.
How is it:
based on 0.3.23, tracking changes as they come in
and closed source?
I won't be touching this until someone ILDASMs it and proves it's safe (Even in VM, hwo do you know it doesn't only work x days into the future on the xth second, or something silly, or if a certain transaction is in a block it picks up!)
based on 0.3.23, tracking changes as they come in
and closed source?
I won't be touching this until someone ILDASMs it and proves it's safe
(Even in VM, hwo do you know it doesn't only work x days into the future on the xth second, or something silly, or if a certain transaction is in a block it picks up!) I agree im a person with a considerable amount of computer knowledge but i dont know windows programming so i would absolutly not use this with out a reputable programmer confirming this source code is safe.
Im sure you mean well, but its just hard to trust executables from newbs at this point im time.
Im sure you mean well, but its just hard to trust executables from newbs at this point im time.
I agree and wholeheartedly support this sentiment.
We hope to earn people's trust over time (by actually being trustworthy). We are planning a code signing system in the future - a combination of code and procedure to ensure safe, verifiable binaries. It's a tricky problem and until we figured it out we don't want to give the impression that a random binary is safe - whether from a newcomer or a trusted source.
I build all my Bitcoin related programs from source and carefully check the diffs. This is sadly not an option for the vast majority of people out there.
You had me until:
- UI is currently a .Net Windows Forms app.
The long term goal is to have native clients for all major platforms. We started with Windows as it is the one platform that needed a more secure client the most. Sadly Windows doesn't have the best choice of UI APIs after we elminated Qt for various reasons. A pure win32 interface is being worked on and will yield a much leaner client, though it will take a lot more time.
Also note that our target user likely doesn't know or care what .Net is.
I agree im a person with a considerable amount of computer knowledge but i dont know windows programming so i would absolutly not use this with out a reputable programmer confirming this source code is safe.
Im sure you mean well, but its just hard to trust executables from newbs at this point im time.
Im sure you mean well, but its just hard to trust executables from newbs at this point im time.
You had me until:
- UI is currently a .Net Windows Forms app.
i made it a little further, until:
The catch is - we're closed source, at least for now. We feel that earning people's trust is about more than just dumping the source code.
You had me until:
- UI is currently a .Net Windows Forms app.
Agreed, but I would argue that:
1) This is a vast improvement over the default Bitcoin GUI
2) They probably aren't targeting linux users at all...
So, as much as I can't stand .Net, poorer choices could have been made.
I support this project, and I'm happy to see the progress.
Well done, guys.
Jump to: