But I don't get you when you say "less control in cloud computing"... Because I'll have full control of it.
Exactly. You'd have full control of it... and could run off with the coins of all your users whenever you wish  At my cloud, your wallet will be hosted in your own Virtual Machine Instance, entirely encrypted with your password, which I don't know. I think a cloud hosted system is interseting, but having each VM with a full client would get heavy and waste a lot of disk space since each one would need the full blockchain. You need a light client like Electrum if you want to be able to scale https://bitcointalk.org/index.php?topic=50936.0. |
|
|
|
|
Why wasn't this denied? I'm glad it wasn't but I'm surprised given the number of other people who said they were denied.
|
|
|
|
Independence of concerns would go a long way to accelerate development and experimentation. Personally, I'd like to host the bitcoind south of the polar circle, pay someone for the service, or more trivially have a single standard bitcoind on a shared host (/var). A lot of the web clients and mobile apps seem to be recreating a wheel that shouldn't have needed to be recreated. If the blockchain and index is too big, slow, or bandwidth too expensive, then we should outsource the responsibility.
This. The daemon should have nothing to do with wallets. It should relay transactions, download new blocks, and maintain a local copy of the block chain along with needed indexes. +1 I have always thought this also. It seems to me the daemon is too tightly coupled with the Satoshi wallet and that requires either significant code surgery, sticking with limits of the existing wallet, or a lot of wheel inventing. What if the daemon would removed into a new project. Wallets could communicate the w/ daemon via encrypted JSON or socket messages. (i.e. check balance of this address, submit this transaction, what is current block count). It would also abstract the differences between light clients, and full clients. A light client is communicating w/ a daemon running on another computer (public, private, whatever). A full client is communicating w/ a copy of the daemon running locally. I completely agree that the wallet and the nodes need to be separated. This is pretty much what Electrum is doing. https://bitcointalk.org/index.php?topic=50936.0 |
|
|
|
Could it be made so that the deterministic addresses and the imported ones can be exported separately? That way I could export just the non-deterministic keys for backup or whatever
Thomas just posted how to export all keys above, just grab the one you imported manually and note it down. I don't want to have to worry about splitting my exports manually. That isn't feasible for scripted backups. The ability to export just the non-deterministic keys would make automated backups that don't expose the deterministic keys that don't need to be backed up. did you test the command? imported keys are marked as such. you can do : python electrum.py addresses -k | grep imported
Oh that will work just fine. I didn't realize that they were marked with "imported". |
|
|
|
Could it be made so that the deterministic addresses and the imported ones can be exported separately? That way I could export just the non-deterministic keys for backup or whatever
Thomas just posted how to export all keys above, just grab the one you imported manually and note it down. I don't want to have to worry about splitting my exports manually. That isn't feasible for scripted backups. The ability to export just the non-deterministic keys would make automated backups that don't expose the deterministic keys that don't need to be backed up. |
|
|
|
It might be easier to hook into bitcoind's rpc for creating new addresses rather than rewriting client code in PHP. This means your webserver would need access to a bitcoind, but not necessarily one that is even connected to the network. It could just be for address generation. You could export the keys generated and set them up to be swept by a different bitcoind that can't be compromised by your webserver.
That would be another service to run on a webserver which is a bit heavy duty. Also, getting all the private keys out of it would require using pywallet to export them, and then reimport them into your desktop wallet. I created a php library that uses "bitcoin-off-the-grid" (BOTG) (source: https://bitcointalk.org/index.php?topic=23081.20) which is a bash script. Here is the library: https://github.com/RobKohr/PHP-Bitcoin-Address-CreatorI trimmed out a bunch of stuff from BOTG to make it more script friendly, and wrapped a php exec call to it. It seems to work pretty well. Bitcoin 0.6 has the import/export built in so that won't be a problem much longer. Using botg is a good idea, too. |
|
|
|
Main things are implementing the block chain somehow and an unusual shape (not necessarily the one I made)
Also, I think bitcoin needs an animal mascot. Something found worldwide like a rat.
I like all of these ideas. Although I don't know if rat is a good choice. We should resurrect Clippy lol i'm bored so i figured I'd try my hand at a flag.... the text at the bottom can be changed to whatever if you choose this one  While this looks cool, I think its really important for a flag to be easy to produce. Thats why all of the world flags use only a few solid colors and generally simple shapes with straight lines. |
|
|
|
I just uploaded version 0.35 to the website. Changelog: * New 'import' command to add extra keypairs to your wallet. Example: python electrum.py import 1MtQTsraWDcb7REUnVu8LS9hZswrLfWbH9:5KeCdRAkygEGfSzQ3ZNpQ2qE6PdEYCZ52S9Uq5DoBxkSgayX6ng
Note that you can export your keypairs in the same format using: python electrum.py addresses -k
Can you confirm if the following is correct? The imported keys are not contained among the deterministic key set generated so if/when you delete your wallet the imported keys will not be coming back when you use the seed-phrase to regenerate the deterministic portion of the wallet. That goes without saying, does it not? Could it be made so that the deterministic addresses and the imported ones can be exported separately? That way I could export just the non-deterministic keys for backup or whatever |
|
|
|
|
It might be easier to hook into bitcoind's rpc for creating new addresses rather than rewriting client code in PHP. This means your webserver would need access to a bitcoind, but not necessarily one that is even connected to the network. It could just be for address generation. You could export the keys generated and set them up to be swept by a different bitcoind that can't be compromised by your webserver.
|
|
|
|
|
Oh lol. I was just so used to that being measured in MH/s that I didn't notice it read KH/s.
|
|
|
|
Dunno how I missed that example when I was reading through the docs. I'll clean it up. EDIT: https://gist.github.com/1500780I realized that most people are going to want to check multiple mining rigs and having to make a new CgminerClient for each host seemed like extra work. I made it so that the client can check multiple hosts and ports easily rather than being bound to one at creation. |
|
|
|
Transparent flag. Everyone can see that Bitcoin is not associated with a certain party (color) I lold |
|
|
|
I think that would be better stated as "there will be many ways of getting around it." I have heard talk of sites for transmitting offline transactions being developed, but are any public?
What do you mean by public connection? Like run the client at a library? That doesn't sound very feasible.
Only communicating with trusted nodes would work, but doesn't sound very feasible either. I know there are points in bitcoin where trust makes things easier, but I really believe that we should do our best to make trust unnecessary. With tor, you don't have to trust the other peers and they can't tell your IP.
tor is designed for web browsing, not for peer to peer software making tons of connections. By tons you mean 8? still high considering http only uses 1, and the connections are always present, unlike http. Um... http can use 1 but when browsing use usually use more. A quick glance at the source for this page has 2 stylesheets and a javascript file which means 4 requests plus one for all the images. |
|
|
|
http://eligius.st/~artefact2/5/1KYpHybsaBU1x2KpwLmbR7buSSncH7HHc3I used to mine primarily at eligius, but am currently hashing for goat. I have eligius set as my backup pool still, and out of habit checked my eligius account. It says that my 3 hour average is 5,567.55 KH/s (I WISH!) while my 15 minute average is 0. Both should be at or near 0. Any ideas? When I was actually mining on this pool, my hashrate was just over 1GH/s and was shown correctly. Also, is there a better place to post this?
|
|
|
|
|
Will there be merged mining?
I'm working on a personal project using namecoin and actually want to use them unlike most people who are just mining to have more things to sell.
|
|
|
|
Dedicated mining rig with 6990. Not used for any reason except mining. No antivirus. No crossfire. I turned off the fancy display features but no other windows features. Any time I do something such as open a web browser my CPU usage shoots up to 100% and all my GPU's drop. I think its too much for the CPU. Strange cause when Im not doing anything my CPU usage is 30-40%. I did notice I have 60 processes running in the task manager. What windows services can I kill to bring the processes down? Im prolly gonna grab a dual core but would like to try to make this single core work for now.
Kill all of them and install linux. It's a dedicated mining rig so you might as well run it efficiently. |
|
|
|
I think that would be better stated as "there will be many ways of getting around it." I have heard talk of sites for transmitting offline transactions being developed, but are any public?
What do you mean by public connection? Like run the client at a library? That doesn't sound very feasible.
Only communicating with trusted nodes would work, but doesn't sound very feasible either. I know there are points in bitcoin where trust makes things easier, but I really believe that we should do our best to make trust unnecessary. With tor, you don't have to trust the other peers and they can't tell your IP.
tor is designed for web browsing, not for peer to peer software making tons of connections. By tons you mean 8? |
|
|
|
|
bitaddress is done all in javascript so that the private keys are never ever seen by the server. If you moved this logic into PHP, that security is lost. What are you trying to build? Your users shouldn't have to trust that you won't steal their private keys, they should know for certain that you can't.
|
|
|
|
|
Show Posts
