MtGox: Green address option

[mndrix]

Either approach doesn't work today and will require further work. For Mike's proposal wallet providers would need to start publishing their transactions and for green addresses it needs to be easier to verify those transactions. I'm not sure which one is more likely to happen soonish.

This probably speaks as much to my personal experiences as anything, but I find the following two snippets (what I'd need to verify incoming transactions and publish outgoing transactions on CoinCard or CoinPal) easier than modifying and compiling a custom bitcoind:

Code:

    # is this transaction "green"?
    my $status = get("https://mtgox.com/api/is_our_txn?txn_id=$txn_id");
    my $is_txn_green = $status eq 'OK';

Code:

    # is this transaction one that we sent?
    my $txn_id = $c->req->param->{txn_id} || '';
    my $txn = $c->model('Txns')->find($txn_id);
    $c->res->body( $txn ? 'OK' : 'NO' );

In the long run, with bitcoind support, I think green addresses are a better solution.  Does anyone have a patch for making gettransaction return information about a transaction's source addresses?

[MagicalTux]

It is usually seen as a good thing to not use the same public/private key pair for a long long time, especially when using those to sign a lot of crap.

Our private keys are generated via openssl's cryptobytes random generator.

[JoelKatz]

It is usually seen as a good thing to not use the same public/private key pair for a long long time, especially when using those to sign a lot of crap.

You'd be using the key for the same amount of time to sign the same number of things. Whether or not you hold Bitcoins in that account has no effect on either of these two factors.

When you setup a green address, you are asking people to trust the security of that address. The fact that you have clearly stated that *you* do not trust its security makes the green address useless. If you don't trust it, why should anyone else? If you don't trust the key to secure your own funds, why should I trust the ownership of that very same key to protect against double-spending attacks?

I'm 99.9% sure you're protecting against an attack that does not, and cannot, exist. But if it does, your solution doesn't at all solve the problem. If it does exist, until you solve it, you cannot have a persistent green address.

[JoelKatz]

mtgox.com could just expose a list of recent transaction hashes that it has generated (eg in the past 24 hours) on its website. Fetching this list via SSL authenticates it as coming from mtgox.com. It has the following advantages over green addresses:

• Key rotation is handled automatically (via the usual SSL mechanisms)
• It does not require any special software or hacks, you can just use the RPC API to get transaction hashes from recent sends
• After 24 hours the data goes away, so it's no longer possible to do privacy violations via block chain analysis (of course the authorities can still contact MtGox directly)
• Does not require 2 transactions

It's also conceptually simpler.

Actually, that's vastly inferior, because nobody would know when to contact Mt. Gox. You wouldn't want to separately contact every green address provider on every transaction.

However, it does suggest a superior scheme. If sites could somehow broadcast their green addresses and a range of valid dates for each one in a signed form, that could fairly easily be polled. The rule could be you must announce a new green address at least a week before you use it. So people would only need to pull that list every three days or so.

This would allow green addresses to be rotated easily and wouldn't require a poll on every transaction.

[netrin]

Re: key rotation, ssl list

However, it does suggest a superior scheme.

I haven't yet understood the purpose of this scheme. For precisely the reasons you stated before, it's "protecting against an attack that does not, and cannot, exist." What additional value does this scheme provide except to grossly complicate an elegant solution (green addresses)?

[Mike Hearn]

I think people are over-thinking the scalability needs of this thing.

Step back - what does this solve? It solves the problems of large transactions that need to be processed immediately. It's unnecessary for pizzas and it's unnecessary for things like selling your car, where waiting an hour or so isn't exactly a big deal (people wait days for bank wires to clear currently).

So for this specific, fairly rare, class of transactions what are the problems?

Firstly, as I said, most merchants cannot and will not track huge numbers of trust relationships. You're expecting random sellers to evaluate the trustworthyness of not just MtGox, but also Vibanko and so on. I have been in the Bitcoin community for a while, so MtGox I know about. But I have absolutely no idea of whether Vibanko can be trusted - is it secure? Are its operators likely to take the money and run? What about the government of wherever it operates? Are the owners about the sell the company and force me to re-evaluate their trustworthyness all over again? Would I even notice if they did?

Figuring out the answers to these questions is hard work and is pretty much the justification for having large banks that then become "too big to fail".

Secondly, the assumption here is that wallet providers will become a very common way for people to use Bitcoin. They might, or they might not. People feel safe putting their money into banks because banking is heavily regulated, insured and dominated by large companies that have been around for a long time. Despite that banks regularly seem to lose massive bets and require intervention in order to avoid people losing their deposits.

Bitbanks provide none of those assurances and we've already seen the biggest basically lose half of all its money. I can easily see people using lots of small bitbanks in combination with keys they control themselves, as then you don't need quite as much trust, but if there are lots of small bitbanks merchants won't bother to evaluate all their trust levels assuming green addresses can even be implemented there. If usage of Bitcoin coalesces around a small number of very large bitbanks like MtGox, then Bitcoin has simply become the existing system with a smaller and flakier currency - making it fairly pointless.

[jav]

Step back - what does this solve? It solves the problems of large transactions that need to be processed immediately.

It's also useful for small amounts. There are many cases which differ from the pizza scenario. For example online gambling, which can not accept zero-confirmation transactions even for small amounts (otherwise people would deposit, play and then double-spend in case they lose - besides, you can't really enforce the small amounts, as an attacker can always pose as multiple people and combine many small transactions to make the attack more worthwhile).

Firstly, as I said, most merchants cannot and will not track huge numbers of trust relationships.

I don't yet know how this trust relation management would play out, but one thing I think is important to keep in mind, is that there isn't all that much trust required. After all, if you happen to trust the wrong green address, then there is still a double-spend attack required before it becomes a problem for you. So if you are selling TVs in New York and Vibanko gets hacked, then the attacker might not actually come into your store and trick you out of a TV by double-spending.

You could also go about it in a Ripple-kind of way: Have one organization assess and trust various ewallet providers and the merchant only trusts that umbrella provider. The payment would then just have to take an extra step (ewallet provider -> umbrella organization -> merchant).

Secondly, the assumption here is that wallet providers will become a very common way for people to use Bitcoin. They might, or they might not. [...] Bitbanks provide none of those assurances and we've already seen the biggest basically lose half of all its money.

It doesn't have to be either or. I could see a mix of a savings wallet, that people manage themselves, and a spending wallet with an ewallet provider with limited funds be an acceptable solution. But of course I don't know if it will play out like that, we'll have see.

[JoelKatz]

Re: key rotation, ssl list

However, it does suggest a superior scheme.

I haven't yet understood the purpose of this scheme. For precisely the reasons you stated before, it's "protecting against an attack that does not, and cannot, exist." What additional value does this scheme provide except to grossly complicate an elegant solution (green addresses)?

It permits providers to change their green addresses should they need to. It provide a uniform way to know who offers green addresses and which addresses they are using.

Right now, if you started accepting Bitcoin transactions and wanted to accept green addresses, there is no good way for you to know everyone who claims to have a green address, what that address is, and whether it has a history of reliability.

As for why it's important to allow sites to rotate green addresses, the issue is this: Right now, if you supported green addresses, and you had a slight fear that there had been some compromise to that account, what would you do? Say you had just fired someone who had access to the key. You trust them, but would prefer not to have to.

There are many other scenarios.

[netrin]

We can count the number of trusted ewallets on our thumbs. I believe a simple green.conf file would do the trick for several months, but sure, we could query a URL for updated lists, green.conf:

Code:

https://mtgox.com/green_list.xml # mtgox
1lkjhasdfuyrt # tradehill
1K8jsl9afdjal # instawallet
1myBrotherAAA # my trusted brother
1pokerPotBeer # drinking fund

The reasons I personally use exchanges as an ewallet are that (1) tiny transactions incur no fees, (2) I can speculate/hedge, (3) bandwidth is expensive and I don't like waiting for the client to start, (4) I rely on web resources such as blockchain.info any way because the client doesn't provide adequate transaction/address history.

The use cases for green addresses would include EVERY context where we can use credit cards today. Even if most cases are nice-to-have, credit cards set a certain convenience bar that bitcoin should rise above. Nearly all in-person sales, vending machines, cashier checkout would benefit from green transactions. If convenient and bitcoins were generally accepted, I foresee topping up my daily pocket change and child's allowance. I would expect or at least appreciate instantaneous transactions whether buying a stick of gum or a ticket at the airline desk.

[2112]

There are many other scenarios.

Eg. Dun & Broadstreet will start selling ratings for each address: pay 10BTC and you'll know whether the address is "green" or "red". 

[jav]

In the long run, with bitcoind support, I think green addresses are a better solution.  Does anyone have a patch for making gettransaction return information about a transaction's source addresses?

I will be working on such a patch in the near future. But in the meantime, I put up a webservice at https://www.greenaddress.org which returns Bitcoin addresses used in recent transactions. This could be used as a temporary solution, but of course requiring to trust that the webservice is returning correct data.

[pc]

Rather than two transactions, if MtGox were willing to keep a small amount like 0.01 BTC on the green address, couldn't each transaction just have 0.01 from a prior green address transaction as an extra input, and have an extra 0.01 BTC back to the green address as an output for use in the next green transaction? You can still authenticate it's MtGox sending it (since it has funds from the green address in its inputs), but there's only one transaction, and I don't think it'd mess up the normal priority system as much.

[JoelKatz]

Rather than two transactions, if MtGox were willing to keep a small amount like 0.01 BTC on the green address, couldn't each transaction just have 0.01 from a prior green address transaction as an extra input, and have an extra 0.01 BTC back to the green address as an output for use in the next green transaction? You can still authenticate it's MtGox sending it (since it has funds from the green address in its inputs), but there's only one transaction, and I don't think it'd mess up the normal priority system as much.

That's a great idea. So if a transaction includes any funds that come from a green address, the transaction should be considered green. That allows providers to keep only very small amounts of money in the green address and still provides the same level of assurance.

It does require a slight semantic change -- a green address provider must be considered to have breached its promise if a transaction including at least one valid input from a green address that is signed correctly by the green address is ever conflicted or fails to make it into the block chain. This applies even if the other signatures in the transaction are invalid or if another transaction that claims any of the inputs this transaction claims ever surfaces.

That is, if a transaction has a valid signature from a green address, it must always either be valid for inclusion in the block chain or already included in the block chain. Any other outcome constitutes a breach of the provider's promise.

[nmat]

Does this work both ways? Or only for withdrawals?

[neofutur]

Does this work both ways? Or only for withdrawals?

 For now it works for withdrawals because mtgox is supporting the green address idea.
 As I understand it, it could work for deposits only if other providers ( from where you send btc ) also support/use the green address feature ( and mtgox trust this "other provider" green address ).

[payb.tc]

Does this work both ways? Or only for withdrawals?

 For now it works for withdrawals because mtgox is supporting the green address idea.
 As I understand it, it could work for deposits only if other providers ( from where you send btc ) also support/use the green address feature ( and mtgox trust this "other provider" green address ).

they just have to trust it on a scale from 1 to 6, and knock off some required confirmations accordingly

[JoelKatz]

they just have to trust it on a scale from 1 to 6, and knock off some required confirmations accordingly

And if a green address provider ever cheats, the victim will have incontrovertible proof.

[finway]

excelent idea.

[netrin]

Rather than two transactions, if MtGox were willing to keep a small amount like 0.01 BTC on the green address, couldn't each transaction just have 0.01 from a prior green address transaction as an extra input, and have an extra 0.01 BTC back to the green address as an output for use in the next green transaction?

Brilliant! Perhaps it could be simpler. For every transaction, Mt. Gox would send from 2 inputs, 0.00000001 from the Green address and the intended amount minus a Satoshi from any Other address.

Code:

GREEN --(0.00000001)--> |
                        | --( 5 BTC )--> destination
OTHER --(4.99999999)--> |

[finway]

Wow, better idea.