Is it possible to add private key from Vanitygen?
https://bitcointalksearch.org/topic/vanitygen-vanity-bitcoin-address-generatorminer-v022-25804
I tried but I couldn't, I'm doing something wrong but I don't know what ...
Topic: Blockchain.info - Bitcoin Block explorer & Currency Statistics - page 165. (Read 482345 times)
December 04, 2011, 07:01:50 PM
December 04, 2011, 06:25:18 PM
Puik, I could foresee creating a wallet with a single address, adding some funds, printing it out as a pdf, and then I would like to be able to delete the record from your servers.
I'll add this in the next update.
Following that train of thought, your PDF could produce DIY PuiKash or, the analogy I prefer, traveller cheques. Writing the password on the cheque is equivalent to activating or signing it anonymously.
No sure i'm following you, you mean some kind of printable cheque which you then sign?What is a multi-recipient transaction? First come, first serve?
No, i meant, you an create a transaction with more than one receiving address e.g.
Public key only address?
Probably should have worded it "Address without private key".
e.g. If you add just a bitcoin address to your wallet if with be labeled like this:
So you will be able to see transactions, balances, etc. But when you try and send funds from that address you will be prompted to enter the private key. Before you enter the private key you can unplug your internet and instead of relaying the transaction immediately it will output a string which you can copy and paste into http://bitsend.rowit.co.uk/ when your ready to send it.
December 04, 2011, 03:25:17 PM
Puik, I could foresee creating a wallet with a single address, adding some funds, printing it out as a pdf, and then I would like to be able to delete the record from your servers. Following that train of thought, your PDF could produce DIY PuiKash or, the analogy I prefer, traveller cheques. Writing the password on the cheque is equivalent to activating or signing it anonymously.
What is a multi-recipient transaction? First come, first serve?
Public key only address?
Looking forward to offline transactions and upload/download wallet.dat. Your innovations and implementations never cease to amaze!
What is a multi-recipient transaction? First come, first serve?
Public key only address?
Looking forward to offline transactions and upload/download wallet.dat. Your innovations and implementations never cease to amaze!
December 04, 2011, 01:07:43 PM
What exactly is the "Other Known" on the pools chart?
All pools with less than 2 blocks relayed to avoid cluttering the pie chart. They are listed in the Known blocks table.
December 04, 2011, 12:53:05 PM
What exactly is the "Other Known" on the pools chart?
All pools with less than 2 blocks relayed to avoid cluttering the pie chart. They are listed in the Known blocks table.
December 04, 2011, 12:49:35 PM
What exactly is the "Other Known" on the pools chart?
December 04, 2011, 12:45:52 PM
Awesome site!
can I make 1 suggestion? On the main page, instead of saying "unconfirmed transactions" can you call them "new transactions" ? the term unconfirmed (to a new user) may give the impression that they are somehow invalid.
can I make 1 suggestion? On the main page, instead of saying "unconfirmed transactions" can you call them "new transactions" ? the term unconfirmed (to a new user) may give the impression that they are somehow invalid.
Glad you like the site. They are not necessarily new though, I've seen some unconfirmed transactions sit in that list for 24 hours or more. I'll put a paragraph up on the page explaining what unconfirmed means.
it is odd to go to a site named BlockChain.info for managing my hybrid javascript wallet. and then this thread gets polluted with wallet-related topics. wouldn't it be a better idea to separate the two?
the question i had though is what happens when i want to access from a different computer but don't have a link to the wallet url? isn't there a way i can give an alias so that i don't need to keep the wallet identifier?
the question i had though is what happens when i want to access from a different computer but don't have a link to the wallet url? isn't there a way i can give an alias so that i don't need to keep the wallet identifier?
I will be integrating the wallet into the site (nothing too intrusive). Fro example when you visit a address page you will be able to click 'Add to my Wallet' and have the address added in public key only mode. + I can't be bothered to setup a new domain
Good idea, but people would likely pick aliases which are easy to guess e.g. 'my-wallet' which would then exposed your encrypted wallet data. What do you think about an alias with a security question something like simple like 'What is your date of birth?'.
New features added
- Save JSON data to file
- Save Wallet as printable PDF
- Import Encrypted JSON, PlainText JSON and pywallet -dumpwallet
- Multi recipient transaction.
- Address book
- Transaction summary and client status
- Confirmation before send
Coming shortly
- Public key only addresses
- Offline Transactions
- Upload and download wallet.dat (Java applet)
December 03, 2011, 04:17:08 PM
I've put up a technical FAQ with answers to some of your questions. http://blockchain.info/wallet/faq.
it is odd to go to a site named BlockChain.info for managing my hybrid javascript wallet. and then this thread gets polluted with wallet-related topics. wouldn't it be a better idea to separate the two?
the question i had though is what happens when i want to access from a different computer but don't have a link to the wallet url? isn't there a way i can give an alias so that i don't need to keep the wallet identifier?
December 03, 2011, 12:41:50 PM
Awesome site!
can I make 1 suggestion? On the main page, instead of saying "unconfirmed transactions" can you call them "new transactions" ? the term unconfirmed (to a new user) may give the impression that they are somehow invalid.
can I make 1 suggestion? On the main page, instead of saying "unconfirmed transactions" can you call them "new transactions" ? the term unconfirmed (to a new user) may give the impression that they are somehow invalid.
Hi Bit-pay. I hear ya, but maybe that's exactly the impression the new user should have, no? This transaction is not (yet) to be trusted.
December 03, 2011, 12:36:12 PM
Awesome site!
can I make 1 suggestion? On the main page, instead of saying "unconfirmed transactions" can you call them "new transactions" ? the term unconfirmed (to a new user) may give the impression that they are somehow invalid.
can I make 1 suggestion? On the main page, instead of saying "unconfirmed transactions" can you call them "new transactions" ? the term unconfirmed (to a new user) may give the impression that they are somehow invalid.
December 02, 2011, 05:20:35 PM
Quote
Do you have any future intension to implement deterministic addresses from seed?
Possibly although I don't know if the average user can be trusted to keep a seed, wallet identifier and password safe. I'm trying to simplify the process a bit.Currently you are storing an encrypted wallet containing keys. Instead you could store an encrypted wallet containing a seed. Or, as you suggest, trust the user to generate an excellent passphrase. The combination of an obscure GUID (URL) plus a good passphrase protecting the seed exposes exactly the same vulnerable characteristics as your current implementation. But the seed may reduce the memory footprint and can be more reliably backed up.
Quote
Quote
I've never understood how transactions work. Why does the sending entity (your server in this case) need to join the network, with an up-to-date blockchain.
It doesn't need an up to date blockchain, it doesn't need a blockchain at all.I'm asking why your server (or my Satoshi client) needs to be on the network before sending. I'm sorry; it was an off topic question.
Quote
I'm curious why you store (export) the private key in decimal - why not base58?
Code:
{ "guid" : "xxxx-xxx-xxx-xxx-xxxx",
"sharedKey" : "xxxx-xxx-xxx-xxx-xxxx",
"keys" : [
{"addr" : "1AnAddressInBase58Format",
"priv" : "12345678901234567890987654321234567890987654323456789987654321234323456"}
]
} December 02, 2011, 11:47:22 AM
Thanks for your clarification. Does the client cycle through a pool of pre-generated addresses, or does it create a buffer of keys (I see only one pair in my wallet)? Are those guaranteed to be encrypted and stored on the server before they are ever used (I suspect not unless change is returned to the sending address)?
I've put up a technical FAQ with answers to some of your questions. http://blockchain.info/wallet/faq. Initially the client generates a single address only and change is returned to that address.
Quote
It is not clear to me what transaction data (API call) the client needs to request immediately before signing and sending a transaction back to the server.
The client calls
Quote
/unspent?address=HASH60
to get a list of available unspent outputs otherwise the client would not know which outputs are spent or not.Quote
Do you have any future intension to implement deterministic addresses from seed?
Possibly although I don't know if the average user can be trusted to keep a seed, wallet identifier and password safe. I'm trying to simplify the process a bit.Quote
I've never understood how transactions work. Why does the sending entity (your server in this case) need to join the network, with an up-to-date blockchain.
It doesn't need an up to date blockchain, it doesn't need a blockchain at all. The javascript client cannot talk with bitcoin nodes directly so it has to go through the server. I could make a Java applet to relay the transaction without touching the server.Quote
I look forward to transparent plaintext import/export/split/encrypted block standard formats between all clients. I'm curious why you store the private key in decimal - why not base58?
They are in base 58.Quote
What is the practical difference between the address and hash160? What is the hash160?
No real difference, both can be determined from the other. I meant a difference between public key which cannot be determined from the hash.Quote
Suppose a user gave a single key pair to another user of your system. Would that expose the first user's entire wallet to the second? Could the first user remove the key pair from his wallet? Could he create a new wallet and mix and match key pairs from an older wallet.
Do you mean sharing the private key? No, as wallets are not deterministic any other keys would be safe. If you meant wallet identifier then no also, as long as the password is not shared the second user can cannot decrypt the wallet.
December 01, 2011, 09:04:14 PM
Thanks for your clarification. Does the client cycle through a pool of pre-generated addresses, or does it create a buffer of keys (I see only one pair in my wallet)? Are those guaranteed to be encrypted and stored on the server before they are ever used (I suspect not unless change is returned to the sending address)?
I would prefer that the client pre-generates and cycles through a small set of addresses, or that the addresses were generated from a seed (deterministic). I'd then feel much safer backing up my own keys locally. It would be very cool if you also replicated them to our own personal git repository (blockchain.info/git/GUID), so that we could clone the repo ourselves (I wish all cloud services allowed me to decrypt my data locally and stored encrypted data in git).
It is not clear to me what transaction data (API call) the client needs to request immediately before signing and sending a transaction back to the server.
I've never understood how transactions work. Why does the sending entity (your server in this case) need to join the network, with an up-to-date blockchain, before sending a transaction? Sure, he should ensure that the sending addresses actually contain a positive balance, but I'd think such failures should just be ignored (arguments about spam are silly, because NOTHING prevents bogus data transmission). Does a transaction need to inject itself into a specific block before it is validated - such as the hash of the previous block (if that were true then reorgs would be unnecessarily messy and require all senders to remain on the network for hours after sending)? (I know this is off topic, but I suspect you're in a great position to answer these nagging questions).
Do you have any future intension to implement deterministic addresses from seed?
I highly appreciate that you explode the wallet in plaintext JSON. Your project and many other alternate clients give me real hope for bitcoin's future! I look forward to transparent plaintext import/export/split/encrypted block standard formats between all clients. I'm curious why you store the private key in decimal - why not base58?
What is the practical difference between the address and hash160? What is the hash160?
Suppose a user gave a single key pair to another user of your system. Would that expose the first user's entire wallet to the second? Could the first user remove the key pair from his wallet? Could he create a new wallet and mix and match key pairs from an older wallet.
Thanks for your inspiring transparency!
I would prefer that the client pre-generates and cycles through a small set of addresses, or that the addresses were generated from a seed (deterministic). I'd then feel much safer backing up my own keys locally. It would be very cool if you also replicated them to our own personal git repository (blockchain.info/git/GUID), so that we could clone the repo ourselves (I wish all cloud services allowed me to decrypt my data locally and stored encrypted data in git).
It is not clear to me what transaction data (API call) the client needs to request immediately before signing and sending a transaction back to the server.
I've never understood how transactions work. Why does the sending entity (your server in this case) need to join the network, with an up-to-date blockchain, before sending a transaction? Sure, he should ensure that the sending addresses actually contain a positive balance, but I'd think such failures should just be ignored (arguments about spam are silly, because NOTHING prevents bogus data transmission). Does a transaction need to inject itself into a specific block before it is validated - such as the hash of the previous block (if that were true then reorgs would be unnecessarily messy and require all senders to remain on the network for hours after sending)? (I know this is off topic, but I suspect you're in a great position to answer these nagging questions).
Do you have any future intension to implement deterministic addresses from seed?
I highly appreciate that you explode the wallet in plaintext JSON. Your project and many other alternate clients give me real hope for bitcoin's future! I look forward to transparent plaintext import/export/split/encrypted block standard formats between all clients. I'm curious why you store the private key in decimal - why not base58?
The server does not know the public addresses of a user but does require the hash 160 of an address to get transaction data.
What is the practical difference between the address and hash160? What is the hash160?
Suppose a user gave a single key pair to another user of your system. Would that expose the first user's entire wallet to the second? Could the first user remove the key pair from his wallet? Could he create a new wallet and mix and match key pairs from an older wallet.
Quote
CREATE TABLE `bitcoin_wallets` ( guid, updated, created, payload, last_access, shared_key, notifications_email )
Thanks for your inspiring transparency!
December 01, 2011, 05:59:27 PM
Why not have a ≈ character instead of ~ for the USD evaluation?
Do you use servers that you already own for other things? Do you plan to make money on this (not just donations), or is it just a hobby?
I would suggest changing the bottom bar so it does not merge with the background and become confusing.
Do you use servers that you already own for other things? Do you plan to make money on this (not just donations), or is it just a hobby?
I would suggest changing the bottom bar so it does not merge with the background and become confusing.
Quote
x ≈ y means x is approximately equal to y.
This may also be written ≃, ≅, ~ or ≒.
This may also be written ≃, ≅, ~ or ≒.
~ Iis the symbol I associate with approximation.
The site runs on 3 i7 Quad core Mac mini's which are collocated in a locked cabinet at a datacenter with a dedicated security guard. I am the only one with access to the servers but I do use them for other things - Backend's for a various iPhone applications, git, afp and email server. Just a hobby site for the moment, if it could pay for itself with advertising that would be great.
Thanks for the suggestion.
December 01, 2011, 05:06:51 PM
Why not have a ≈ character instead of ~ for the USD evaluation?
Do you use servers that you already own for other things? Do you plan to make money on this (not just donations), or is it just a hobby?
I would suggest changing the bottom bar so it does not merge with the background and become confusing.
Do you use servers that you already own for other things? Do you plan to make money on this (not just donations), or is it just a hobby?
I would suggest changing the bottom bar so it does not merge with the background and become confusing.
December 01, 2011, 04:45:51 PM
Are the wallets deterministic? Are newly generated keys (addresses) stored on the server (even in encrypted form)? Does the server keep track of all public addresses for each identifier? Can the client pull the network plug and continue working, sending transactions and updating balances later?
No the wallet is not deterministic, keys are generated randomly. The generated keys are stored AES encrypted on the server. The server does not know the public addresses of a user but does require the hash 160 of an address to get transaction data. These calls are made using the publicly available api @ http://blockchain.info/api. The wallet identifier and hash 160 is is not included in any queries together. Currently you can't send transactions offline because transaction data is lost if the client cannot reach the server, but it is possible with a few minor modifications.
The basic protocol structure is:
For new transactions
So what's the difference between this and StrongCoin for example?
I have to say I did not know about strongcoin, essentially it the same thing. I guess they now have some competition
blockchain.info can be more tightly integrated the block explorer site so we can provide a slicker interface which feels like a fully functioning client. December 01, 2011, 03:12:50 PM
So what's the difference between this and StrongCoin for example?
December 01, 2011, 03:08:44 PM
Quote
I believe this is the first e-wallet service to offer pure javascript transaction signing and wallet encryption/decryption. At no time do you share your private keys or password with our server. Your private keys are stored AES encrypted on servers so even if our database is compromised your wallet will still be secure.
I had that idea a few days ago!
December 01, 2011, 01:49:40 PM
Looks great. Could you provide a sequence diagram? I'm looking for message types and payload between client and server...
Are the wallets deterministic? Are newly generated keys (addresses) stored on the server (even in encrypted form)? Does the server keep track of all public addresses for each identifier? Can the client pull the network plug and continue working, sending transactions and updating balances later?
Code:
===================================================
server
(stores encrypted wallet or seed)
===================================================
| | ^
| | |
(recv (recv (send
wallet balance trans
by id) per) through
| addrs) server)
| | |
V V |
===================================================
client
(generates addresses locally)
===================================================
Are the wallets deterministic? Are newly generated keys (addresses) stored on the server (even in encrypted form)? Does the server keep track of all public addresses for each identifier? Can the client pull the network plug and continue working, sending transactions and updating balances later?
December 01, 2011, 08:17:49 AM
Announcing beta testing of blockchain.info's new e-wallet service.
http://blockchain.info/wallet
I believe this is the first e-wallet service to offer pure javascript transaction signing and wallet encryption/decryption. At no time do you share your private keys or password with our server. Your private keys are stored AES encrypted on servers so even if our database is compromised your wallet will still be secure.
This is early beta testing so do not expect everything to work perfectly and be sure you always keep a backup of your private keys on your own PC. I'm looking for feedback on browser compatibility and any errors that occur.
http://blockchain.info/wallet
I believe this is the first e-wallet service to offer pure javascript transaction signing and wallet encryption/decryption. At no time do you share your private keys or password with our server. Your private keys are stored AES encrypted on servers so even if our database is compromised your wallet will still be secure.
- Live updating interface if your browser support websockets
- Send transactions with no fees
- Client side wallet decryption, no sharing of private keys
- Instant backups upon new key generation
- Export private keys
- Import private easy using a pywallet dump
This is early beta testing so do not expect everything to work perfectly and be sure you always keep a backup of your private keys on your own PC. I'm looking for feedback on browser compatibility and any errors that occur.
Jump to: