Bitcoin Forum
December 09, 2016, 09:43:14 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 ... 96 »
  Print  
Author Topic: [ANNOUNCE] Electrum - Lightweight Bitcoin Client  (Read 243206 times)
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
December 17, 2011, 01:33:55 AM
 #221

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.


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.

1481319794
Hero Member
*
Offline Offline

Posts: 1481319794

View Profile Personal Message (Offline)

Ignore
1481319794
Reply with quote  #2

1481319794
Report to moderator
1481319794
Hero Member
*
Offline Offline

Posts: 1481319794

View Profile Personal Message (Offline)

Ignore
1481319794
Reply with quote  #2

1481319794
Report to moderator
1481319794
Hero Member
*
Offline Offline

Posts: 1481319794

View Profile Personal Message (Offline)

Ignore
1481319794
Reply with quote  #2

1481319794
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
December 17, 2011, 02:10:38 AM
 #222

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.

Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
December 17, 2011, 06:48:31 AM
 #223

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.

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.

marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2100



View Profile
December 17, 2011, 09:55:16 PM
 #224

2112
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)

ThomasV
Legendary
*
Offline Offline

Activity: 1722



View Profile WWW
December 18, 2011, 07:33:02 AM
 #225

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

Electrum: the convenience of a web wallet, without the risks
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
December 18, 2011, 08:03:56 AM
 #226

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://bitcointalk.org/index.php?topic=24784.0

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

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.

ThomasV
Legendary
*
Offline Offline

Activity: 1722



View Profile WWW
December 18, 2011, 08:51:24 AM
 #227

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.


Electrum: the convenience of a web wallet, without the risks
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
December 18, 2011, 07:33:42 PM
 #228

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

ThomasV
Legendary
*
Offline Offline

Activity: 1722



View Profile WWW
December 18, 2011, 11:35:27 PM
 #229

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.

Electrum: the convenience of a web wallet, without the risks
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
December 19, 2011, 01:06:27 AM
 #230

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.


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.
I still don't see any benefit.  If I know the customer is trusted, why couldn't I just look for the 0-confirm payment, then tell my POS software to complete the transaction once it shows up?  Why is there a need to mark the addresses if I am staring at the customer in the face and watching my POS register?
genjix
Legendary
*
Offline Offline

Activity: 1232


View Profile
December 19, 2011, 04:28:19 AM
 #231

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.
ThomasV
Legendary
*
Offline Offline

Activity: 1722



View Profile WWW
December 19, 2011, 07:31:05 AM
 #232

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.

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

Electrum: the convenience of a web wallet, without the risks
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
December 19, 2011, 03:10:37 PM
 #233

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.

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
December 19, 2011, 09:49:34 PM
 #234

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.

Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
December 19, 2011, 09:55:29 PM
 #235

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).

BTCurious
Hero Member
*****
Offline Offline

Activity: 714


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
December 20, 2011, 01:30:51 PM
 #236

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.
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".

ThomasV
Legendary
*
Offline Offline

Activity: 1722



View Profile WWW
December 20, 2011, 01:36:40 PM
 #237

I answered in the windows thread; note that there is little I can to to help fix problems that occur on Windows

Electrum: the convenience of a web wallet, without the risks
BTCurious
Hero Member
*****
Offline Offline

Activity: 714


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
December 20, 2011, 02:05:32 PM
 #238

Yeah I know, I just didn't know if it was a windows only problem or not.

molecular
Donator
Legendary
*
Offline Offline

Activity: 2142



View Profile
December 20, 2011, 08:00:43 PM
 #239

small beautification request:

shouldn't line 22: from ecdsa.tuil import ... be in the try-block below to catch not-installed ecdsa?



PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
grondilu
Legendary
*
Offline Offline

Activity: 1134


View Profile
December 21, 2011, 09:36:22 AM
 #240

I think the mnemonic algorithm is kind of weird (using quartets of bytes??)

I suggest we use the full 2000 english words list with a complete base2000 encoding:

Code:
def mn_encode( number ):
    return [words[number],] if number < n else [words[number%n],] + mn_encode( number/n + number%n )

def mn_decode( wlist ):
    r = words.index(wlist[0])
    return r + n*(mn_decode(wlist[1:]) - r ) if len(wlist[1:])>0 else r

Well, the good thing is that anyone can do his own recipe with his client, as
the server is not supposed to be aware of the particular encoding, right?
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 ... 96 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!