Topic: [ANNOUNCE] Electrum - Lightweight Bitcoin Client - page 86. (Read 274562 times)

Hmm. I thought I tried and it worked. Maybe it was not really 0 confirmations, but a display or server bug at the time...

I do not think that you can spend money with 0 confirmations currently in Electrum; but this is something I was planning to add anyway

I don't think this makes much sense for a client. A user can just "accept" a transaction with however many confirmations he chooses.

Green addresses can for example be used to have a merchant accept money faster. So unless you're somehow using electrum as a merchant, this proposal doesn't seem to make much sense, since you can spend money with 0 confirmations anyway and spending is the only thing electrum can do with newly received money.

Well, that's exactly what I was referring to when I was talking about a disbursal account, so I'm not sure where the miscommunication was that made you think we were talking about different things.

Regardless, now that it's clear, let's talk about marking Bitcoin addresses (I'll call them green addresses).

You could mark a certain address from say, MtGox, as a green address, but in all likelihood, you'll never receive a withdrawal from the same address twice.  So the mark is only good the instant you see the funds pop up in your wallet.  But then, if you're watching for the payment, and know it is from MtGox, what's the use of marking it as a green address at that point?

You could argue that a private party might have a more consistent send-from address, but the default client has no control over what address is used to send coins.

You could argue that the default client could be further modified so that a sender could choose what address to send coins from, but let's step through a process in detail.

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.

And that's even assuming a full-fledged retailer is using Bitcoin on a regular basis which, so far, hasn't happened.

So what am I missing?  Why does this need to be added to the client now, when there is currently no useful purpose for it?  You mention government checks vs corporate or personal checks.  Ok, but no one is doing transactions similar to what checks are used for (paying bills, corporate remittances, etc) with Bitcoins yet.  And even there, I can't really see the usefulness.  Again, please give a specific situation (like I gave above with regards to a retail environment) where something like this would be useful.

I also don't really think green addresses are necessary. I think waiting for confirms is overly cautious anyways.

This sounds cool.  I think we should only allow HTTPS requests if we want to be secure. Tampering with HTTP is too easy.

The transaction would be treated like it has been confirmed by 6 blocks, meaning that I can use those coins for another transaction.  This will be more more helpful when we can select which inputs to use when spending coins.

If green addresses were implemented, than a POS (like https://bitcointalksearch.org/topic/ann-release-of-open-source-point-of-sale-system-w-video-38893) could easily be built without modifying the client.

I guess it is true that green addresses solve the non-existant problem of double-spends at a POS.  I still think that they are cool though and I don't think it is unimaginable that someone will come up with a better use for them in the future.

And I don't think centralization is bad. I think being forced to be centralized is bad.  Green addresses could from a central provider, but they could also come from any number of other distribution methods.

Reading email discussion about "BIP15 / Aliases" in development mailing list, lot of funny proposals here. However I pretty like proposal for using URLs for retrieving sending addresses. It's the most clean, easiest to implement and easy to understand by normal people, what I read there so far:

When you'll ask for receiving address, counter party give you general URL instead of Bitcoin address. HTTP(S) request to that URL should give you an address used to this transfer. It's on the decision of counterparty if this address is static (every HTTP request returns the same address) or it's randomly generate or counterparty provide you customized URL just for this specific trade.

Any reason why *not* implement this into Electrum (even if it won't be chosen as "official" alias system into standard client)?

I'm sorry I wasn't clear. It is the sending address that is declared "green", "golden", "disbursal" or whatever. But the logic to recognize it must be on the receiving side. So you cannot just use a single adjective "marked address" to describe the whole mechanism.

The practical examples in the USA are probably various special checks. Funds from the average check are held by the receiving bank for the "hold period". If the check is "Treasury check", "cashier check" or a "check from a corresponding bank" the "hold period" is shortened, sometimes to zero. But the exact rules of which checks deserve fast treatment are specified by the receiver, not by the sender.

So what you're saying is, the marked addresses are on the receiver's side, not the sender's side?  You might have two addresses, one for untrusted payments, and one for trusted payments?

I'm still confused how marking addresses would be useful though.  If you know what address you trust, you can just look at the client for the "received with address 1XXXXXXXXXX" to find out which address it was sent to.  If it's a trusted address, then you can finish out the transaction even if it is still at 0 confirmations.

Can you please provide a specific example of how marking those addresses would be useful in a real-world setting?

If you don't agree with me, please propose some method how to approve disbursal accounts for distributed list in a decentralized way. Is MtGox trusted enough to add his green address into the list? Tradehill? bitcoin7? mybitcoin?

I remember to our discussion about mining interface very well and I don't want to turn this thread to similar mess. Please stop repeating "you're doing everything bad". I think I understand GA idea very well, but current proposal does not fit to decentralized solution like Bitcoin.

If somebody submit a patch which allow user to define custom set of addresses which will appear in client as confirmed even with zero confirmation, then - why not. But implementing some automatic updates of this list from centralized source goes against decentralized nature of Bitcoin and it's even not solving any real issue. And by the way not everything "widely used in 21.century" is good enough.

The replies from slush and SgtSpike show that they simply don't understand generally accepted accounting principles.

The cannonical use of disbursal account is an exact opposite of what you think:

1) big organisation sets up disbursal account
2) lots of small payees use the "golden" account number as a shortcut through their credit approval process.

This is exactly the case of why a "general purpose" popular client should have a built-in ability to mark some sources of funds as requiring less verification. Since this is 21 century there should be some sort of PKI interface that allows adding and removing "trusted account" numbers. Sort of like every modern web browser has a some sort of weakly hidden tab to set up certification authorities and other PKI miscellanea.

I'd have to agree.  If you want to accept 0-confirmation payments from certain addresses, just be on the lookout for those payments.  It should pop up within seconds of the transaction being broadcast.  There's no reason to have a whole tracking system for those special addresses built in to the default client.  Any company large enough to have automated tracking of disbursal account addresses would be running bitcoind with a custom front-end anyway.

Call it green address or disbursal account, but it don't change the fact that I don't see the point in implementing this into the general purpose client.

It does not mean that I don't see the benefits, green addresses may be great for B2B clearing (like ewallets can trust themself up to some amount, so moving bitcoin funds from mtgox to tradehill will be instant). But I see that GA can be misleading for normal users unless they fully understand GA concept.

"Green Address" is just a weird name for the old practice of having a "disbursal account". There are also other names for the similar practices in the field of accounting, with various minor details changed. The general idea is that it allows for savings in the cost and delay of credit check on the receiving end and as such it is widely accepted.

Why people involved in Bitcoin keep giving new names to the old things? I don't know. Do they know?

I must say that I don't see a point in supporting green addresses.

a) It expects some central point for making decision what's "trusted enough" and what's not, making client potentially weak from some kind of attack, especially when user don't understand what "green address" mechanism mean.

b) I don't think green address mechanism is needed at all. If you're receiving few bucks for a coffee, you don't need to wait for a confirmation at all. When you're receiving money for selling your house, you will probably wait for some confirmations in any case. So where's the use case for green address?

There are few proposals for decentralized solutions for preventing double spending which should be supported by Electrum servers rather than green addresses in the future. But for now I don't see double spending as a real problem.

The idea is that if the funds come from a green address, or the transaction contains at least one input from a green address, then the funds are trusted to arrive. As such you could immediately show it as confirmed, even at zero confirmations, because you trust the sender to not try to double-spend you. You could also immediately allow spending it, in theory. Perhaps you could show it with an icon that specifies "greenlisted", and still changing it to the normal icon after 6 confirmations.

Today I pushed the new key generation method ("type 2 wallet"). You can test it already if you use git.
It will be included in version 0.34; please allow a few days of testing.

note that this change will requires another wallet upgrade; this should be the last one, unless we find a security flaw.

type 2 will allow us to implement nice features, such as the automatic synchronization between different instances of your wallet

what would be the desired behaviour when coins come from such an address?