Pages:
Author

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

donator
Activity: 532
Merit: 501
We have cookies
November 22, 2011, 06:01:25 PM
#69
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...
hero member
Activity: 742
Merit: 500
November 22, 2011, 04:53:08 PM
#68
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.
hero member
Activity: 784
Merit: 1000
bitcoin hundred-aire
November 22, 2011, 04:17:24 PM
#67
You can even make the input 0btc, afaik.
sr. member
Activity: 322
Merit: 251
FirstBits: 168Bc
November 22, 2011, 03:39:36 PM
#66
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.
full member
Activity: 146
Merit: 100
October 24, 2011, 06:31:45 PM
#65
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
legendary
Activity: 1596
Merit: 1012
Democracy is vulnerable to a 51% attack.
October 19, 2011, 01:12:58 PM
#64
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.
jav
sr. member
Activity: 249
Merit: 251
October 19, 2011, 03:22:23 AM
#63
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.

Quote
// 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.
sr. member
Activity: 322
Merit: 251
FirstBits: 168Bc
October 18, 2011, 09:05:31 PM
#62
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
pc
sr. member
Activity: 253
Merit: 250
October 18, 2011, 08:37:53 PM
#61
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.)
hero member
Activity: 714
Merit: 500
October 18, 2011, 07:36:46 PM
#60
Wow, better idea.
sr. member
Activity: 322
Merit: 251
FirstBits: 168Bc
October 18, 2011, 07:34:42 PM
#59
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)--> |
hero member
Activity: 714
Merit: 500
October 18, 2011, 07:32:42 PM
#58
excelent idea.
legendary
Activity: 1596
Merit: 1012
Democracy is vulnerable to a 51% attack.
October 18, 2011, 05:44:03 PM
#57
they just have to trust it on a scale from 1 to 6, and knock off some required confirmations accordingly Smiley
And if a green address provider ever cheats, the victim will have incontrovertible proof.
hero member
Activity: 812
Merit: 1000
October 18, 2011, 05:05:39 PM
#56
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 Smiley
full member
Activity: 146
Merit: 100
October 18, 2011, 04:59:13 PM
#55
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 ).
hero member
Activity: 602
Merit: 502
October 18, 2011, 04:46:58 PM
#54
Does this work both ways? Or only for withdrawals?
legendary
Activity: 1596
Merit: 1012
Democracy is vulnerable to a 51% attack.
October 18, 2011, 04:45:03 PM
#53
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.
pc
sr. member
Activity: 253
Merit: 250
October 18, 2011, 03:44:01 PM
#52
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.
jav
sr. member
Activity: 249
Merit: 251
October 18, 2011, 03:33:04 PM
#51
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.
legendary
Activity: 2128
Merit: 1073
October 16, 2011, 04:13:44 PM
#50
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".  Wink
Pages:
Jump to: