MtGox: Green address option

[pc]

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.

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

[1714136318]

1714136318

[1714136318]

1714136318

[netrin]

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?

Code:

GREEN  --(0.01)--> | --( 5.00 BTC )--> DEST1
                   | 
OTHER1 --(8.00)--> | --( 3.01 BTC )--> GREEN


GREEN  --(3.01)--> | --( 1.00 BTC )--> DEST2
                   | 
OTHER2 --(2.00)--> | --( 4.01 BTC )--> GREEN


<< ? or ? >>


                   | --( 5.00 BTC )--> DEST1
GREEN  --(0.01)--> |
                   | --( 3.00 BTC )--> CHNG1
OTHER1 --(8.00)--> | 
                   | --( 0.01 BTC )--> GREEN

[jav]

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.

// To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01
if (nMinFee < nBaseFee)
  BOOST_FOREACH(const CTxOut& txout, vout)
    if (txout.nValue < CENT)
      nMinFee = nBaseFee;

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.

[JoelKatz]

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.

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.

[neofutur]

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.

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

[netrin]

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.

[ineededausername]

You can even make the input 0btc, afaik.

[Red Emerald]

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.

[DeepBit]

You can even make the input 0btc, afaik.

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