Topic: MtGox: Green address option (Read 21627 times)

0-value inputs are really great as a way to "sign" the TX.
Sadly 0-value input will require creating a 0-value output, which is not free :)
0.01 inputs can be directly reused as 0.01 outputs.

Also it's sad that MagicalTux can't discuss implementing this green-addrss thing...

I really like the idea of green addresses.  Getting multiple large sites (MtGox and Installawallet) will definitely help us get code into the main client.

Having some sort of registry would be great.  Maybe we could use a variation of the namecoin personal namespace (dot-bit.org/Personal_Namespace) so that anyone can publish an address.  Then there would be some third party that could collect lists of the addresses that they are willing to trust by checking the namecoin blockchain.  Merchants could then get a list from a trusted third party and not have to worry about managing the list themselves.

You can even make the input 0btc, afaik.

Hey Tux, I think it's great that Mt. Gox offers green transactions, but the purpose is defeated if the transaction doesn't hit the network immediately.

 not with https://en.bitcoin.it/wiki/Free_transaction_relay_policy

Just be careful that you only use funds that *you* are certain have sufficient confirmations to fund such transactions. If you use 'fresh' funds to fund a green transaction, and then a block chain re-orgranization invalidates those funds, *you* will be breaking your green address commitment.

The suggestion by pc is a great idea!

I would definitely pick 0.01 BTC coins for this purpose, as it is always a good idea to stay above the "dust spam" limit.


Where CENT is defined to be 1000000 (which is 0.01 BTC).

As others have pointed out, it's probably not such a good idea though, to reuse the same 0.01 BTC frequently. This would create transactions that depend on unconfirmed 0.01 BTC coins, which looks pretty spammy. But it's easy to work around: I would just put, let's say, 10 BTC worth of 0.01 BTC coins at the green address, to always have some available, which have a number of confirmations under their belt. And if you run out of confirmed 0.01 BTC coins, then that's a signal that you have too many unconfirmed transactions pending and should be slowing down in creating them anyway.

This sounds like a great implementation strategy to me. "Greenifying" a transaction is then basically just a post-processing step, which adds one of the available 0.01 BTC coins as an input and an extra output to send it back to the green address. This sounds modular enough, that a clean patch for this should be possible. I will probably switch Instawallet over to this mechanism at some point.

Whether the green address leaks small amounts, or recycles the same 0.01, isn't a heavily used green address input_age going to get penalized by:

priority = sum(input_value_in_base_units * input_age)/size_in_bytes

If there are multiple transactions from the same green address in the same block isn't the recycled 0.01 change going to trigger every miners' spam flags?

Creating a bunch of 1-satoshi outputs to be used as future inputs for transactions might work, but I think the transaction fee to create that seeding transaction would be higher than the one-more-input and one-more-output on each transaction that I proposed. Transactions are spent, not addresses. If your initial spend to the green address is more than the amount you're using as the token to prove the source, then you have "change" that you'd want to have in an output to the green address again, which is basically one more input and one more output per transaction, as I'd proposed. I suggested a bitcent instead of a satoshi because miners using the default algorithm would include a bitcent output without fees but would want a fee for a satoshi output since it's too small.

Of course, MtGox/Instawallet/whomever could try to make some kind of deal with major mining pools/individuals to treat their signed green transactions differently somehow. But using a 0.01 extra input and output makes it so that some kind of negotiation like that isn't needed. (I mean, there could instead be some kind of cryptographic signature in the transaction with an OP_DROP that was how clients authenticated a transaction came from a trusted source, but the whole point of the "green address" concept is that the authentication can happen with standard transactions without the rest of the network or miners needing to do anything special.)

Wow, better idea.

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.

excelent idea.

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

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

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

Does this work both ways? Or only for withdrawals?

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.

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.

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.

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