small beautification request:
shouldn't line 22: from ecdsa.tuil import ... be in the try-block below to catch not-installed ecdsa?
Topic: [ANNOUNCE] Electrum - Lightweight Bitcoin Client - page 85. (Read 274537 times)
Yeah I know, I just didn't know if it was a windows only problem or not.
I answered in the windows thread; note that there is little I can to to help fix problems that occur on Windows
From the windows builds thread:
Don't know if it's just me, but on Windows 7 the 'copy' button does nothing for me so I have no way to copy and paste my receiving addresses.
Same, copy doesn't work for me also.
I created new address & it gave the seed & also gave me a sentence with easy to remember words, i selected the sentence & copy, but when i try to paste to notepad or any other text field, the paste is grayed out.
I took screen shot for my seed & i manually typed in to a notepad file.
Using win 7 Ultimate 64 bit with sp1 & Electrum-0.34-Build1
I also see an error in console , Tcl wasn't installed properly.
I created new address & it gave the seed & also gave me a sentence with easy to remember words, i selected the sentence & copy, but when i try to paste to notepad or any other text field, the paste is grayed out.
I took screen shot for my seed & i manually typed in to a notepad file.
Using win 7 Ultimate 64 bit with sp1 & Electrum-0.34-Build1
I also see an error in console , Tcl wasn't installed properly.
Ah, that's different then what I thought you two talked about.
In the seed window, Ctrl+C and/or Rightclick->Copy doesn't work.
The thing I mentioned that does work for me is going to Receive, selecting an address, and hitting "Copy to clipboard".
In the seed window, Ctrl+C and/or Rightclick->Copy doesn't work.
The thing I mentioned that does work for me is going to Receive, selecting an address, and hitting "Copy to clipboard".
Great work slush. JSON is really easy to use. I'm glad you stayed away from binary or weird sockets.
Spesimilo and Electrum should definitely work together. It seems like their only difference is that spesmilo isn't a thin client (and it's harder for me to spell).
Spesimilo and Electrum should definitely work together. It seems like their only difference is that spesmilo isn't a thin client (and it's harder for me to spell).
ThomasV, I cannot reach you on IRC, so two bug reports here:
a) HTTP poll is limiting response to 2000 bytes in electrum.php, which provide corrupted responses for addresses with more transactions.
b) Some calls of HTTP poll produces output "socket_recv() failed; reason: Success" (yep, sounds little funny). Looks like another bug of electrum.py. It happens for me for "peers" command.
a) HTTP poll is limiting response to 2000 bytes in electrum.php, which provide corrupted responses for addresses with more transactions.
b) Some calls of HTTP poll produces output "socket_recv() failed; reason: Success" (yep, sounds little funny). Looks like another bug of electrum.py. It happens for me for "peers" command.
I just pushed first version of electrum protocol implementation to https://gitorious.org/electrum-protocol
It's json-rpc based bi-directional protocol implemented (currently) on top of TCP socket transport. Current server implementation also support 'services' and service discovery; see 'service_repository/firstbits.py' and 'client.py' for an example.
In the future I want to implement more transports (HTTP Poll, HTTP Push, websocket) and more client implementations (namely PHP client and plain Python without a Twisted).
Some longer explanation of protocol design can be read here (last chapter "Services" is not finished yet): https://docs.google.com/document/d/17zHy1SUlhgtCMbypO8cHgpWH73V5iUQKk_0rWvMqSNs/edit?hl=en_US
I'm going to implement proxy for services provided by current Electrum server to enable rewriting Electrum client to this protocol. Later it would be nice to have full Electrum server implementation in Twisted.
It's json-rpc based bi-directional protocol implemented (currently) on top of TCP socket transport. Current server implementation also support 'services' and service discovery; see 'service_repository/firstbits.py' and 'client.py' for an example.
In the future I want to implement more transports (HTTP Poll, HTTP Push, websocket) and more client implementations (namely PHP client and plain Python without a Twisted).
Some longer explanation of protocol design can be read here (last chapter "Services" is not finished yet): https://docs.google.com/document/d/17zHy1SUlhgtCMbypO8cHgpWH73V5iUQKk_0rWvMqSNs/edit?hl=en_US
I'm going to implement proxy for services provided by current Electrum server to enable rewriting Electrum client to this protocol. Later it would be nice to have full Electrum server implementation in Twisted.
slush is going to working on a new qt client? And you're working on a gtk client in Python and I was working on a qt client in Python ( https://en.bitcoin.it/wiki/Spesmilo ).
I'm going to make a client eventually for libbitcoin and was planning to adapt bitcoin-qt. We have a ton of overlap between us.
When we're both around on irc and slush too might be cool to let each other know what we're all up to. Form a group or something.
I'm going to make a client eventually for libbitcoin and was planning to adapt bitcoin-qt. We have a ton of overlap between us.
When we're both around on irc and slush too might be cool to let each other know what we're all up to. Form a group or something.
and I was planning to replace bitcoind + abe with libbitcoin for the servers :-)
I didn't know Spesmilo was python-qt; yes we should talk
slush is going to working on a new qt client? And you're working on a gtk client in Python and I was working on a qt client in Python ( https://en.bitcoin.it/wiki/Spesmilo ).
I'm going to make a client eventually for libbitcoin and was planning to adapt bitcoin-qt. We have a ton of overlap between us.
When we're both around on irc and slush too might be cool to let each other know what we're all up to. Form a group or something.
I'm going to make a client eventually for libbitcoin and was planning to adapt bitcoin-qt. We have a ton of overlap between us.
When we're both around on irc and slush too might be cool to let each other know what we're all up to. Form a group or something.
You are a retailer. You wish to trust a customer and give them an immediate sale, regardless of confirmations. You have a Bitcoin wallet running on your local machine. Now you have two options:
- Your method: Ask customer for their sending Bitcoin address. Customer has to have a client running that will allow them to select which address to send from. If they can't cover the bill from a single address, they have to send from multiple addresses, which further complicates your creation of green addresses. Once you input the customer's addresses, the customer sends to your Bitcoin address. A few seconds later, you see one or more sending addresses pop up as "green" addresses, and you know it is ok to give the customer the goods without waiting for confirmations.
- My method: The customer sends to your Bitcoin address. You watch the wallet until you see the transaction pop up with 0 confirms. You make sure the total is correct with the receipt amount, then call it good.
- Your method: Ask customer for their sending Bitcoin address. Customer has to have a client running that will allow them to select which address to send from. If they can't cover the bill from a single address, they have to send from multiple addresses, which further complicates your creation of green addresses. Once you input the customer's addresses, the customer sends to your Bitcoin address. A few seconds later, you see one or more sending addresses pop up as "green" addresses, and you know it is ok to give the customer the goods without waiting for confirmations.
- My method: The customer sends to your Bitcoin address. You watch the wallet until you see the transaction pop up with 0 confirms. You make sure the total is correct with the receipt amount, then call it good.
Not sure who you in "your method" is referring too, but I think you are missing a piece. I believe that the green address thread had the idea that a transaction that has any of its inputs coming from a green adress should be considered green.
This is the workflow I was imagining for a POS that can use green transaction.
1) Create an address for the customer's payment and show it to them (maybe via a QR code or something)
2) The customer pays the given address and tells their client to send the payment through a green address (on instawallet, it's a checkbox)
3) Your POS sees the new 0 confirmation transaction contains an input from a green address and accepts it immediately.
OR
1) Create an address for the customer's payment and show it to them (maybe via a QR code or something)
2) The customer pays the given address with a wallet service that does not support green addresses
3) Your POS sees the new 0 confirmation transaction and you either give them the item now or you make them wait for 6 confirmations
The second option 3 seems pretty stupid to me though. I'm convinced now that green addresses solve a non-existant problem since waiting the 6 confirmations seems unnecessary. So I guess my new feature request is to be able to spend inputs from transactions that have a customizable number of confirmations. I think this would be simple to implement and would allow for people to setup their clients for their own needs.
https://en.bitcoin.it/wiki/Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation
Option 3 seems like it could work with Green addresses, but I no longer see the need for such heavy protection against double spends.
Thanks for the info. My goal for Electrum was to create a client that everybody can use and understand. Features that add complexity to the interface should at least be optional.
There are numerous threads where new users ask where their bitcoins have gone, after they sent them to a wallet that did not finish downloading the blockchain. Another major problem for Bitcoin acceptance is having to perform wallet backups; lots of people, including myself, do mistakes when it comes to backing up data regularly and safely. These two problems are solved by light and deterministic clients. Electrum adds nice seeds mnemonics and a fully open-source architecture to this concept.
The third problem is that people have to wait for confirmations. I do not see an easy answer to this. My gut feeling is that "green" addresses are not the correct answer. For small-amount face-to-face transactions, I would say that waiting for confirmations is unnecessary. Something like http://www.transactionradar.com/ should provide enough security. For online transactions, waiting for confirmations is, in general, much less of a problem.
There are numerous threads where new users ask where their bitcoins have gone, after they sent them to a wallet that did not finish downloading the blockchain. Another major problem for Bitcoin acceptance is having to perform wallet backups; lots of people, including myself, do mistakes when it comes to backing up data regularly and safely. These two problems are solved by light and deterministic clients. Electrum adds nice seeds mnemonics and a fully open-source architecture to this concept.
The third problem is that people have to wait for confirmations. I do not see an easy answer to this. My gut feeling is that "green" addresses are not the correct answer. For small-amount face-to-face transactions, I would say that waiting for confirmations is unnecessary. Something like http://www.transactionradar.com/ should provide enough security. For online transactions, waiting for confirmations is, in general, much less of a problem.
Any interest in having the addresses be more visible to the user? I know some people are for keeping all the "extra" addresses relatively hidden since they might confuse the user. With these patches the "extras" wouldn't be as confusing since they would all be automatically linked to their transactions. And importantly, users could also completely ignore these features and let the client pick everything automatically.
to be honest, it is not in my list of priorities at the moment (not that I am against it, but there are more urgent things).
But I think that slush mentioned coin selection as a property of his future qt gui.
I agree that there are more important parts of the client to work on. I just wanted to make sure this got put on a list. Knowing future features ahead of time can often help the current design.
Also, I found out that it is a pull request so it is pretty easy to see exactly what coderrr is changing. https://github.com/bitcoin/bitcoin/pull/415
Any interest in having the addresses be more visible to the user? I know some people are for keeping all the "extra" addresses relatively hidden since they might confuse the user. With these patches the "extras" wouldn't be as confusing since they would all be automatically linked to their transactions. And importantly, users could also completely ignore these features and let the client pick everything automatically.
to be honest, it is not in my list of priorities at the moment (not that I am against it, but there are more urgent things).
But I think that slush mentioned coin selection as a property of his future qt gui.
Thomas, that sounds exactly right.
Not to add even more to do, but I've got some more feature requests. coderrr has some patches to the main client that add what I'm thinking about.
https://bitcointalksearch.org/topic/--24784
Any interest in having the addresses be more visible to the user? I know some people are for keeping all the "extra" addresses relatively hidden since they might confuse the user. With these patches the "extras" wouldn't be as confusing since they would all be automatically linked to their transactions. And importantly, users could also completely ignore these features and let the client pick everything automatically.
Not to add even more to do, but I've got some more feature requests. coderrr has some patches to the main client that add what I'm thinking about.
https://bitcointalksearch.org/topic/--24784
Quote
TLDR: this patch allows you to:
- see all addresses, including change
- see which addresses are linked together (does recursive expansion of address linkages)
- select which address(es) to send from, rather than letting the client to chose for you
- see all addresses, including change
- see which addresses are linked together (does recursive expansion of address linkages)
- select which address(es) to send from, rather than letting the client to chose for you
Any interest in having the addresses be more visible to the user? I know some people are for keeping all the "extra" addresses relatively hidden since they might confuse the user. With these patches the "extras" wouldn't be as confusing since they would all be automatically linked to their transactions. And importantly, users could also completely ignore these features and let the client pick everything automatically.
If you want to move funds between your own wallets, why wait any time? It's not like you are going to double spend against yourself. I think it would be nice if this was an option.
the capability to spend funds immediately is a desirable feature, whether the address they come from is "green" or not.
as far as I understand, there are two aspects that users might be interested in
* the user shoud be able to see when received funds come from a green address (rendering)
* when spending, the user should be able to select "green or confirmed" inputs, or the coin selection method should automatically prioritize "green" inputs when confirmed inputs are exhausted
2112
Neither it seems do wall st. banks or the federal reserve. As I recall they suspended GAAP to weather the financial panic in 2008, as far as I'm aware those "toxic assets" that were exempted from GAAP rules are still stinking up the joint underneath a TARP somewhere, still exempt from GAAP.
Perhaps channel your anger in that direction? (i.e. the destroyers, not the creators)
Quote
The replies from slush and SgtSpike show that they simply don't understand generally accepted accounting principles.
Neither it seems do wall st. banks or the federal reserve. As I recall they suspended GAAP to weather the financial panic in 2008, as far as I'm aware those "toxic assets" that were exempted from GAAP rules are still stinking up the joint underneath a TARP somewhere, still exempt from GAAP.
Perhaps channel your anger in that direction? (i.e. the destroyers, not the creators)
Red Emerald, I think we all understand benefits of green addresses. There's only the only problem with distribution of that list of trusted (green) addresses.
I like the idea to have some user interface for manually modifying "green addresses" in the client. If merchant decide that he want to trust Instawallet or Mtgox, why not, it's his choice. But distributing green addresses with client sounds dangerous.
I don't think the client should come with any green addresses baked in. A GUI and a couple RPC commands would let people control this list in anyway they want.I like the idea to have some user interface for manually modifying "green addresses" in the client. If merchant decide that he want to trust Instawallet or Mtgox, why not, it's his choice. But distributing green addresses with client sounds dangerous.
Maybe sites like Instawallet and Mtgox could host their own addresses. Maybe someone could make a site like http://www.iblocklist.com/ only with lists of PGP-signed green addresses instead of bad IPs. Those methods won't be designed until a client or two has the ability to accept them.
A few people have mentioned having a "advanced" flag for the client. Maybe green addresses could be hidden behind something like that.
If you want to move funds between your own wallets, why wait any time? It's not like you are going to double spend against yourself. I think it would be nice if this was an option.
Red Emerald, I think we all understand benefits of green addresses. There's only the only problem with distribution of that list of trusted (green) addresses.
I like the idea to have some user interface for manually modifying "green addresses" in the client. If merchant decide that he want to trust Instawallet or Mtgox, why not, it's his choice. But distributing green addresses with client sounds dangerous.
I like the idea to have some user interface for manually modifying "green addresses" in the client. If merchant decide that he want to trust Instawallet or Mtgox, why not, it's his choice. But distributing green addresses with client sounds dangerous.
You are a retailer. You wish to trust a customer and give them an immediate sale, regardless of confirmations. You have a Bitcoin wallet running on your local machine. Now you have two options:
- Your method: Ask customer for their sending Bitcoin address. Customer has to have a client running that will allow them to select which address to send from. If they can't cover the bill from a single address, they have to send from multiple addresses, which further complicates your creation of green addresses. Once you input the customer's addresses, the customer sends to your Bitcoin address. A few seconds later, you see one or more sending addresses pop up as "green" addresses, and you know it is ok to give the customer the goods without waiting for confirmations.
- My method: The customer sends to your Bitcoin address. You watch the wallet until you see the transaction pop up with 0 confirms. You make sure the total is correct with the receipt amount, then call it good.
- Your method: Ask customer for their sending Bitcoin address. Customer has to have a client running that will allow them to select which address to send from. If they can't cover the bill from a single address, they have to send from multiple addresses, which further complicates your creation of green addresses. Once you input the customer's addresses, the customer sends to your Bitcoin address. A few seconds later, you see one or more sending addresses pop up as "green" addresses, and you know it is ok to give the customer the goods without waiting for confirmations.
- My method: The customer sends to your Bitcoin address. You watch the wallet until you see the transaction pop up with 0 confirms. You make sure the total is correct with the receipt amount, then call it good.
Not sure who you in "your method" is referring too, but I think you are missing a piece. I believe that the green address thread had the idea that a transaction that has any of its inputs coming from a green adress should be considered green.
This is the workflow I was imagining for a POS that can use green transaction.
1) Create an address for the customer's payment and show it to them (maybe via a QR code or something)
2) The customer pays the given address and tells their client to send the payment through a green address (on instawallet, it's a checkbox)
3) Your POS sees the new 0 confirmation transaction contains an input from a green address and accepts it immediately.
OR
1) Create an address for the customer's payment and show it to them (maybe via a QR code or something)
2) The customer pays the given address with a wallet service that does not support green addresses
3) Your POS sees the new 0 confirmation transaction and you either give them the item now or you make them wait for 6 confirmations
The second option 3 seems pretty stupid to me though. I'm convinced now that green addresses solve a non-existant problem since waiting the 6 confirmations seems unnecessary. So I guess my new feature request is to be able to spend inputs from transactions that have a customizable number of confirmations. I think this would be simple to implement and would allow for people to setup their clients for their own needs.
https://en.bitcoin.it/wiki/Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation
Option 3 seems like it could work with Green addresses, but I no longer see the need for such heavy protection against double spends.
Version 0.34 is now available.
It introduces "type 2" key derivation: bitcoin addresses can be generated without access to the main seed.
The immediate benefit is synchronization between multiple instances of your wallet. You can open the same wallet on two different computers, if you spend bitcoins on one of them, the second wallet will be synchronized automatically. In the future, this "type2" key derivation will also allow us to implement a BCCAPI layer on the server.
This, however, comes at a cost: another forced migration of your coins to a new wallet, because older wallets will not work with the new version.
I hope that we have now reached a final format, and that is the last time such a migration is required.
Please refer to the release notes for explanations about the upgrade.
It introduces "type 2" key derivation: bitcoin addresses can be generated without access to the main seed.
The immediate benefit is synchronization between multiple instances of your wallet. You can open the same wallet on two different computers, if you spend bitcoins on one of them, the second wallet will be synchronized automatically. In the future, this "type2" key derivation will also allow us to implement a BCCAPI layer on the server.
This, however, comes at a cost: another forced migration of your coins to a new wallet, because older wallets will not work with the new version.
I hope that we have now reached a final format, and that is the last time such a migration is required.
Please refer to the release notes for explanations about the upgrade.
Jump to: