Topic: MtGox: Green address option - page 2. (Read 21573 times)

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

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.

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


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


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.

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.

Re: key rotation, ssl listI 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)?

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.

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.

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.

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:



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?

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


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.


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.

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.

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.

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.

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.

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.

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

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.


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

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.

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

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.