Bitcoin Forum

Following the thread from Instawallet about green address (https://bitcointalk.org/index.php?topic=32818.0), we have decided to give it a try on MtGox.

When withdrawing on MtGox, you can check the option "Use green address" to cause your coins to be sent through the address 1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q (or pass the option green=1 to the withdraw.php API).

We have however used a slightly different implementation than Instawallet here, ensuring there is never any coin remaining on this address, reducing the interest for "bad people" to guess its private key.

Each time a transaction is sent via our "green address", a first transaction is generated to send a random amount of bitcoins (larger than the total amount of coins withdrawn) to the address, then a second transaction is generated to get the coins "out". Transactions are always sent by pair and are broadcasted together.

This, however, causes transactions sent via the "green address" option to normal targets to take longer, as two transactions needs to be confirmed. Bitcoin services recognizing our green address will, however, be able to process those deposits in real time instead of waiting for confirmations.


We are thinking of rotating the MtGox green address once in a while, with new green address announced ~1 month in advance.


Any comment on this is welcome.

https://bitcointalk.org/index.php?topic=32818.0

Thats the link Mark to the instawallet thread.

whats the point of the green address if its not 100% instant?

I dont think reducing transaction time from 60 minutes to 20 minutes or whatever is gonna be much of a difference (also why things like solidcoin isnt a good solution)

It doesn't change the transaction time - it just means the receiver can trust the transaction at zero confirmations.
If all the exchanges used this, it would mean that the prices should stop lagging the mt.gox price.

The problem is, I believe, that to forward a transaction that *arrives* at the green address, it has to wait for 2 confirmations before it is able to send it to the actual recipient.

Actually, no. We produce both transactions instantly, and send the second one without waiting for confirmations.

Ah, never mind, I misread your mention of two transactions. I assumed it was about the storage->green transfer, rather than the storage->green plus green->target transactions for a system that does not recognize green addresses.

Awesome! :-)

So if I'm understanding this correctly, it works like this:
A -> B -> C

A and B both belong to MtGox. B is the green address. C is the external recipient.

Since A -> B is an internal transaction only, you don't need to wait for confirmations at B because you know that you're not going to double spend it anyway. So this allows you to initiate the B -> C transaction right away. Likewise, if C trusts MtGox to not attempt a double spend, then C can also accept this transaction without waiting for confirmations (assuming they know the green address). So this means it gets from A to C instantly.

However, if C does not trust MtGox, or does not know about their green address, they will now have to wait for 12 confirmations before this transaction will show up as 'confirmed' in their Bitcoin client. Am I getting that right? Not sure how that bit works.

EDIT: Following the discussion below, the last bit was wrong, as I suspected. It's possible that both A -> B and B -> C can even be included in the same block! If that happens, then it would only take the usual 6 confirmations for C to show 'confirmed' in his client. So no change there.

However, this is not 100% reliable. This is because B -> C will likely have a lower priority for miners to include it into a block, due to there not being any confirmations yet for A -> B. So it's also entirely possible that it could take days for B -> C to get included into a block, in which case C would not see any confirmations for all of that time. So it's not that C would have to wait for 12 confirmations; that was completely wrong. It's that they won't necessarily begin to see any confirmations at all for maybe even a few days (though probably a lot less than that; the point is that it's not very well known at this point). They could end up seeing 0 confirmations for a while. However, if you trust MtGox and know their green address, you can be confident that it will eventually confirm. And it is also possible that in the future, miners could increase the priority of including those transactions that come from well established green addresses, which might eliminate this problem entirely. I'm not sure if this would have other ramifications though.

Obviously this means that if you're sending bitcoins to a merchant via MtGox, don't just use the green address every time. Only use it if the merchant says they are explicitly willing, because otherwise it might take a long time for the merchant to get confirmations on their side, and if so they're not going to release their goods to you for a while. And if you're going to be accepting bitcoins from the MtGox green address, be aware that you might not be able to purchase goods from others with those bitcoins for a while, for the same reason.

B cannot send to C with zero confirmations from A, so it only works if B already has a store of bitcoins. C won't know about A, so it will just be 6 confirmations as normal (though becasue C trusts mt.gox with everything C owns,  C can just accept B at zero)

Actually if you look at : http://blockexplorer.com/address/1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q

Look at transactions 597d00408b... and 557c87f205....

597d00408b... is "A to B"
557c87f205... is "B to C"

Both happened in the same block, which is the expected behaviour.


Previous tests did not always end in the same block, so I believe some miners may consider the second transaction lower priority as it involves not yet confirmed coins. In the case of those two transactions it was as fast as a normal transaction, but it cannot be guaranteed in 100% of the cases.

If we look at the previous transactions we can see it was sometimes coming out with a difference of 1 block, or even more. If pools could put priority on green addresses it'd (mostly) solve this issue.

Nope, B doesn't need a store of Bitcoins. It is perfectly valid for the transaction A -> B to be in the same block as the transaction B -> C. That being said, the transaction B -> C is guaranteed to have extremely low priority, and will require an extra fee if you want it to be in the same block as transaction A -> B. However, since C trusts B, it is perfectly safe for B not to include a fee and for C wait a few days for the transaction to confirm.

WOW! -I've learnt something new. How do I get the bitcoin client to let me do that?

Interesting. Though this of course means that C would have to wait a few days too before they are able to spend those bitcoins themselves? So even though they can be confident that it will eventually confirm, allowing instant point of sale transactions, they should be aware that they might not be able to spend those bitcoins for a while?

Given a transaction hash, how can one use the Bitcoin API to ascertain the source address for a transaction?  `gettransaction $hash` in v0.4.0 doesn't provide the information.  I know BlockExplorer shows the input addresses, but sites accepting Bitcoin payment probably want to use their local bitcoind.

Thanks.

Nope, they can spend it instantly, too. However, whoever receives the transaction would have to completely trust the sender AND the owner of the green address (in this case, MtGox). If C wants to send the coins to someone who doesn't trust them, though, they would, of course, have to wait until B -> C is confirmed. (or more accurately, C could still send the coins, but D wouldn't consider the coins received until both B -> C and C -> D were confirmed with enough confirmations)

Remember, the blockchain doesn't say who currently owns a coin. It just says what the network agrees can be trusted, even if you don't trust the person who sent you the coins at all. This is an important point to remember, since it is likely that in the future person-to-person transactions won't reach the blockchain until someone finally spends the coins at a merchant and the merchant pays a high enough fee to have the entire unconfirmed history locked in.

I don't think the client currently considers a fee on a transaction as a reason to give higher priority to "parent" transactions. It does sound awesome however, and I like the idea.


We are using a custom client to do that, I do not think the bitcoin client would let you do that at this point.

I know, hence the "future" part. And it's not my idea, it's something that Mike has been pushing for for a long time. It's such a natural evolution, though, that I feel that it's inevitable that it'll happen.

Yeah, that's true. I wasn't saying that it wasn't possible specifically. Just that in practice you won't be able to buy things with those bitcoins for a while. Let's say C wants to use those bitcoins to buy a new suit from merchant D. The merchant isn't going to agree to give up the suit until the bitcoins have some confirmations at D's address, which as you have stated may take a few days because of the very low priority (though probably a lot less than a few days, given the tests MagicalTux has showed; and miners might be willing to increase the priority on including transactions coming from well established green addresses). So in practice, anybody who accepts bitcoins from the MtGox green address should be aware that they may have to wait a while longer than normal before they can use those bitcoins to purchase goods with.

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.

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

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.

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. 

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

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

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.

no it does not.
A1, A2, A3 -> B -> C1, C2, C3
it only means one extra transaction.
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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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

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

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

Wow, better idea.

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

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?

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.

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.

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

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.

You can even make the input 0btc, afaik.

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.

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