MtGox: Green address option

[MagicalTux]

That's exactly it. It's a careful balance between making things more convenient for your customers and waiting longer to get paid. However, as credit cards show, businesses have long decided that customer convenience is FAR more important than how long it takes for them to get paid. (credit cards can take between days and weeks before the money is actually in the businesses bank account)

It should be noted that those "green" transactions are usually simple, they always contain only one input, and two outputs. They should be easy enough to integrate the blockchain without too much delay, and if we can get pools and/or big individual miners to mine those in priority, things would be even better.

[1714037405]

1714037405

[1714037405]

1714037405

[1714037405]

1714037405

[netrin]

...ensuring there is never any coin remaining on this address, reducing the interest for "bad people" to guess its private key... rotating the MtGox green address... ~1 month in advance.

Is a private key attack a realistic concern? If so, the implications for your business and our entire economy are devastating.

[o]

...ensuring there is never any coin remaining on this address, reducing the interest for "bad people" to guess its private key... rotating the MtGox green address... ~1 month in advance.

Is a private key attack a realistic concern? If so, the implications for your business and our entire economy are devastating.

Maybe we can interpret it as they use guessable passphrase to generate the private key, so they fear it will be guessed by someone else 

[netrin]

I think the A->B->C transactions within a single block is an interesting thought and practical experiment, but it seems to be a sub-optimal solution to a non-extant problem. It's a bit like wearing a condom to protect against a meteor impact; Awkward protection from a highly unlikely but otherwise catastrophic event.

[kokjo]

I think the A->B->C transactions within a single block is an interesting thought and practical experiment, but it seems to be a sub-optimal solution to a non-extant problem.

why? its not sub-optimal... please explain. both transactions in the same block is completely valid. its actually a beautiful solution, to a rather complex problem. if you trust mtgox, and their green address, you can comfirm the tx without it being included in a block. 

[JoelKatz]

why? its not sub-optimal...

It's sub-optimal because it at least doubles the number of transactions required. In many cases, it more than doubles them. (Because it removes the ability to consolidate multiple withdrawals into a single transaction.)

please explain. both transactions in the same block is completely valid. its actually a beautiful solution, to a rather complex problem. if you trust mtgox, and their green address, you can comfirm the tx without it being included in a block.

The problem it solves does not actually exist. It's entirely imagined.

[netrin]

why? its not sub-optimal... please explain. both transactions in the same block is completely valid. its actually a beautiful solution, to a rather complex problem. if you trust mtgox, and their green address, you can comfirm the tx without it being included in a block.  

No, green addresses are great. Tux is concerned that someone will derive the private key from the public elliptic key, transaction messages, or some side-channel attack. In order to minimize the damage, he's transferring coins as input and output of the same address/block. However, if a private key can be derived, losing a few coins will be the least of our worries. The entire bitcoin network and several other systems will be destroyed.

A condom to protect against meteors. Awkward, inadequate, unlikely.

[kokjo]

(Because it removes the ability to consolidate multiple withdrawals into a single transaction.)

no it does not.
A1, A2, A3 -> B -> C1, C2, C3
it only means one extra transaction.

The problem it solves does not actually exist. It's entirely imagined.

no, some people do not want to wait for transactions to comfirm, an want thier money secure fast.
if i trust mtgox not to double spend, it can be you as a trusted party, i don't need to thrust my customers, only mtgox, and only for a short period of time.

the problem is not imagined.

[netrin]

You're completely missing the point. The 'solution' 'solves' the 'problem' of cryptographic failure. If the cryptography fails in a cryptographic currency, it's game over.

[kokjo]

You're completely missing the point. The 'solution' 'solves' the 'problem' of cryptographic failure. If the cryptography fails in a cryptographic currency, it's game over.

hmm. you can't derive the private key, with the public key, and/or transactions. thats why its called public-key cryptography.
go read up on it. you seems not to have, missed a central point of it.

[netrin]

Lige præcis. Når du vågner op fra din tømmermænd, skal du blive velsignet med en AH HA øjeblik!

[kokjo]

Lige præcis. Når du vågner op fra din tømmermænd, skal du blive velsignet med en AH HA øjeblik!

har ikke tømmermænd endnu, får jeg først i aften...

men man kan altså ikke finde den private nøgle, hvis man kun har en offentelige, og nogle signature, med mindre at man bruge ECDSA algoritmen forkert. hvilket jeg ikke håber at mtgox gør. den kan sagtens klare, at man bruger den flere gange.

[netrin]

Jeg er enig med dig.

We hope that Mt. Gox hasn't botched the algorithm and that a private key can not be derived from the public key nor messages (and timing and other side-channel attacks are highly unlikely unless the attacker... I won't even go there). I think we can agree with brilliant mathematicians that elliptic keys are secure and there is no concern that "bad people" will guess the private key.

Since no one can guess the private key, there is no reason to protect against it.

And how would we protect against a compromised private key anyway? If one private key could be compromised, then all of them could be compromised, and our bitcoins would be as valuable as the gold from which they were forged.

In a simple word,
Bitcoin needs bank to get things smoothy.

That's 7 words, but in a simple word 'no'.

[finway]

In a simple word,
Bitcoin needs bank to get things smoothy.

[kokjo]

Jeg er enig med dig.

We hope that Mt. Gox hasn't botched the algorithm and that a private key can not be derived from the public key nor messages (and timing and other side-channel attacks are highly unlikely unless the attacker... I won't even go there). I think we can agree with brilliant mathematicians that elliptic keys are secure and there is no concern that "bad people" will guess the private key.

Since no one can guess the private key, there is no reason to protect against it.

And how would we protect against a compromised private key anyway? If one private key could be compromised, then all of them could be compromised, and our bitcoins would be as valuable as the gold from which they were forged.

In a simple word,
Bitcoin needs bank to get things smoothy.

That's 7 words, but in a simple word 'no'.

in fact there are actually timing attacks against ECDSA: http://eprint.iacr.org/2011/232.pdf
but the paper also proposes a fix for the problem, so its no real danger.
if the key got stolen/compromised, mtgox could issue a warning, on their webpage, and disable the green address feature.

[Mike Hearn]

I think there is probably a better way than this "green address" business, users should not have to know about this or see it exposed in the UI.

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.

[jav]

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.

The problem I see with this approach is that it doesn't seem to scale too well. Let's say you accept green transactions from 20 different providers and you receive a new transaction. Now you have to check all those 20 websites, since you don't know from which one the transaction comes.

A second disadvantage I see, is that it adds a bit of latency. After receiving the transaction, you will have to fetch that website (or websites), which will also usually include an SSL handshake (keep-alive could be used in some way, I guess). Not such a big problem, but still a disadvantage compared to green addresses.

[Mike Hearn]

Yes, that's true. But how many trust relationships can an average merchant keep track of anyway? A big, sophisticated organization might be able to track the trustworthyness of hundreds or even thousands of partners, but most merchants would only invest the time to understand the trustworthyness of a handful.

For the scaling issue, perhaps SSL+WebSockets (or a custom simple TCP thing) is one way to go. You set up long-term connections to a bunch of known-good senders. Then when they broadcast a tx, they also broadcast it to any listeners they have on the WebSocket. So it's push not pull. It can scale pretty well I think.

I think the general idea of the green address technique is sound, but it boils down to managing trust relationships. The intention of Bitcoin is to relieve you of that burden.

Approaches based on transaction radars and so on might be a better way to increase confidence in zero-confirm transactions. If you know that 80%+ of mining power accepted a tx, you can assume it will confirm and be reasonably secure. The problem today is that mining pools don't like to reveal their Bitcoin node IPs because of DDoS attacks. Some kind of central clearing house of signed tx hashes might be a good (temp) solution to that.

[mndrix]

Until an official bitcoin release provides APIs sufficient for sending and verifying green address transactions, I think Mike's proposal is the easiest for vendors to support.  There are few enough trusted wallet providers that scaling shouldn't be an issue for a while.

[jav]

For the scaling issue, perhaps SSL+WebSockets (or a custom simple TCP thing) is one way to go. You set up long-term connections to a bunch of known-good senders. Then when they broadcast a tx, they also broadcast it to any listeners they have on the WebSocket. So it's push not pull. It can scale pretty well I think.

With this setup, you are putting a pretty big burden on those senders. Let's say there are 10000 websites and shops and whatnot which want to accept transactions from Mt.Gox, then Mt.Gox now has to keep 10000 of those connections open and publish all their transactions over all of those connections just so that the one shop which actually received the transaction knows it came from Mt.Gox.

Of course these types of solutions also then bring you to the question of why not do it all out-of-band then anyway. Have Mt.Gox make a HTTP call to the merchant which is SSL-signed and all that. And I'm not against such a solution, it's just a whole other discussion about how to specify such an out-of-band mechanism which I don't feel like tackling at the moment. But if someone were to design and prototype something like that and that out-of-band mechanism would not be limited to web, but could also work over NFC, then I would be more then willing to implement it for Instawallet.

For the moment I still think, that the fact that green addresses are completely in-band is a pretty big advantage. And I can also see it scale decently. Just some ideas: There could be a public directory of green addresses which point to the respective websites. As a merchant you could decide, that you accept all green addresses where the associated website has an EV SSL certificate. Or there could be a neutral website which manages a security deposit for each green address and basically says: If you can prove a double-spend for a green address, you will be reimbursed using the security deposit. That way a merchant can actually accept totally unknown green addresses, as long as they are sufficiently backed (of course here the merchant has to trust that those security deposits are managed correctly - as you said, the key question is always about trust).

I think the general idea of the green address technique is sound, but it boils down to managing trust relationships.The intention of Bitcoin is to relieve you of that burden.

Approaches based on transaction radars and so on might be a better way to increase confidence in zero-confirm transactions. If you know that 80%+ of mining power accepted a tx, you can assume it will confirm and be reasonably secure.

This "reasonably secure" has - in my opinion - too many limitations to be of much use. Mostly because of attacks where the double-spend transaction isn't broadcasted, but appears anyway in the next block (specifically this scenario: http://www.reddit.com/r/Bitcoin/comments/kmo2l/suggestion_bitcoin_confirmation_honeypot/c2lhbv1 ). Which prevents a number of interesting applications (like getting cash from an ATM instantly or moving Bitcoins into an exchange quickly). Ok, you might be able to buy your pizza like this reasonably secure, but then again, the merchant might also like to be able to move your payment for the pizza into an exchange right away to sell it for USD. With a heuristic like that, the exchange won't accept that. Green addresses can make it happen (You pay the pizza with Instawallet, the payment is handled by Bit-Pay which could have a green address as well and moved into an exchange that accepts green transactions and sold off immediately.)

And there is a further problem: You will always need to add a couple of seconds to listen for possible double-spends, introducing additional delay. I would claim that this is a pretty big deal for users - for them it pretty much can't get fast enough. So a green transaction can also be of use for the pizza scenario, because it allows you to go as fast as the Bitcoin network will allow without having to introduce artificial delays.

Until an official bitcoin release provides APIs sufficient for sending and verifying green address transactions, I think Mike's proposal is the easiest for vendors to support.  There are few enough trusted wallet providers that scaling shouldn't be an issue for a while.

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.

Again, I'm open to other solutions and am happy to accept and implement the group's consensus for Instawallet. Although I have to say, that at the moment I wouldn't be the first to adopt Mike's proposal for Instawallet, as I think it's a solution that will create a user experience that isn't as as good (i.e. fast) as it could be. That extra out-of-band communication will always slow things down and I consider extra latency to be a really big deal.