Topic: Instawallet introduces new approach to instant payment: Green address technique - page 2. (Read 30213 times)

How will this list of green addresses be populated?

Instawallet will directly accept transactions from green addresses at some point. I am currently reworking the backend to make this easier for me to achieve and also be able to manage the risk (e.g. put a limit on the amount of unconfirmed funds that can be pending at any moment).

I see a few implementations now of web services offering a green address option for sending bitcoins. But are there currently any that have stated they will accept them? Clearly, the easy step is for web services to offer a green address, because it doesn't involve any risk. The harder step is convincing services to accept green addresses, because that involves a certain amount of trust.

This is a great idea.

It would be nice to have a public, pgp-signed list of trusted addresses.  Each site that has a green address should at least host their own with some sort of protection from tampering.

EDIT: And ripple sounds awesome! I have been doing this with my roommates with a spreadsheet, but ripple is way cooler.

Green transactions with multiple hops is a great beginning. It allows you to pay to a merchant that doesn't trust your e-wallet provider directly. As you say, the e-wallet providers can use ripple later when multiple tx fees become a concern.

Yes, I suppose that's true, an unconfirmed bitcoin transaction from a known address is functionally equivalent if not better than for example a PGP signed IOU.

I haven't yet talked with them regarding this sort of thing, as I first want to develop a more flexible back end that could actually handle these things. But I would definitely like to see some progress in that direction. I think it would be great, if one could do something like Instawallet mobile app -> Bit-Pay -> TradeHill all in a matter of seconds.

I'm not opposed to doing this outside the p2p network, if some kind of standard could be agreed on, but for the moment I will probably focus on doing all of these with green transactions. Bitcoin transactions are still pretty cheap so I'm currently not too worried to pay for one or two extra transaction hops. And everyone already speaks Bitcoin and the communication channel is clear.

And I would imagine it to be easier to get parties on board, as even an unconfirmed transaction is worth more than just some IOU delivered via a web service. The latter can easily be screwed up by some bugs in the code, whereas the former requires to actually perform a double spend attack before it becomes a problem. So I would feel much more comfortable accepting some other e-wallets green transactions, then just their promises that they will pay later. I would think, that parties like MtGox and TradeHill feel the same way.

As transactions get more expensive, one could then switch to another, cheaper mechanism and only settle from time to time in the blockchain to save on fees. This is where I could see Bitcoin going to in the long term anyway, as a backbone system to a ripple-style web of trust or maybe something open-transaction-like as well.

As a side note: I think green transactions can be used as a poor man's Ripple system as well for the moment. If a merchant accepts Instawallet's green address, and someone convinces me to accept their green address, then they can route their payment through Instawallet to have it be accepted by the merchant.

Actually the current system is hierarchical and ripple would be more resiliant to "defaults". Now we have to trust the banks (they create the money), but with ripple we could trust our friends, neighbors and partners instead.
http://ripplepay.com/essay/

ewallets could clear their ripple balances every hour too. As frequently as they want (well, the limit is in bitcoin blocks). The advantage is that each ewallet company could trust a few others instead of all other companies out there and they can still be indirectly connected in the ripple graph.


les say we have this trust graph:

A <-> B <-> C
A pays 10 to C, so now A owes 10 to B and B owes 10 to C
B buys something for 10 to A and their debt gets cleared
C wants to buy something from B but B rejects to make good on his debt.
C asks to be paid back in the currency that was the denomination of the IOUs, say bitcoins but B says no again.
C takes the losses. He shouldn't had to trust B in the first place.
If B was C supplier he won't be that anymore
If B was C friend he won't be that anymore

jtimon, I added a note on the bottom of my previous post.

Yes, I think Ripple is precisely the model. However, Ripple seems (though I haven't looked at the system in detail) to be a bit like the problem global finance faces today with credit default swaps. Credit gets passed around until default 'ripples' around the network unpredictably. I'm proposing a much more flat system with immediate (hourly) rebalancing. How does ripple mitigate counter-counter-counter-party risk?

But it's true, if a <--(trusts)--> b <--(trusts)--> c <--(trusts)--> a, then rebalancing could be a bit more elegant. It could be that rebalancing ("margin calls") must occur for the previous x blocks after y confirmations. For example 140000-140100 must be balanced after the 140200'th block.

I'm just concerned about a <--(trusts)--> b <--(trusts)--> c |--(does not trust)--| a

I suggested that they could use ripple between them. They could make ripple IOUs "legal debts" through a contract.
Of course it would be better if there were a decentralized ripple implementation.

Jav, have you considered contacting MtGox, TradeHill, Bit-Pay and other well known exchange/merchant/wallets regarding faster transactions, perhaps with a signed balance sheet outside of the p2p network, but rebalanced in the normal bitcoin network? I could imagine certain legal contracts, auditing, and norms (balance never to exceed w BTC, balancing the accounts every x hours, no transactions greater y BTC, no more than z transactions per hour). For example, Instawallet and Tradehill could simply sign transaction+balance.


Users could transfer a reasonable buffer of coins to a unique InstaWallet (or child allowance in a few years) then spend and confirm transactions instantly (I expect most merchants will use a proxy/ewallet in the near future). Rather than wait for confirmation at checkout, users receive confirmation while eating breakfast, shopping, or waiting in queue, then the merchant relies on trusted third parties rather than the block chain. It's similar to green addresses (recipients still need to trust the green address). The merchant only needs to trust their receiving party (InstaWallet, for example) who accepts the counter party risk of their partners (TradeHill, for example).

And I ping pong agree. Even with Green addresses, I think the vendor must realistically include parameters anyway, specifically which green (type or list of) addresses it will accept.

G23456789123456789?green=instawallet,mtgox&absolutelynot=mybitcoin.com

I'm aware of that. Conversely the world is full of over-engineered specs. I think it's sometimes better to just take a stand on something, even if there is a risk of being wrong - but that's just my opinion.

And I think in this case it's even less of an issue, because if we really start running out of characters - proving my assumption wrong - we could still switch midway and pick one of the 'last remaining' characters to be the general prefix for all following extensions.

That said, I was lately thinking that it might be best to select a character that isn't in Bitcoin's Base58. Since that limits the selection somewhat, I might then indeed go with the more general approach.


I agree - I was just pointing out that one would definitely need a version parameter or a "what type of extension is it" parameter among these. So the system can decide whether it is able to interpret the remaining parameters correctly.


Currently Instawallet's normal transactions explicitly don't use coins from the green address (to not deplete it). So I would either have to adjust that or make sure that enough 'non-green' funds are available.

What's "too much"?  What's the downside to having funds held by the 'green' address?

The entire history of hardware and software kludge was spawned from the utterance, "It seems to me that we won't be running out of..."

The "G" does not identify the address. It identifies what can be done with the address. At its simplest, it says "stop! do not send as legacy clients normally would. You must handle this differently or abort."

This might be followed by numerous parameters such as price, expiration of offer, ordernumber, productnumber, etc. Those same parameters might be used by other systems that do not require green address senders, but still require preemptive processing. A service might require that sent coins only come from previously registered addresses, or from political affiliation, or from non-anonymous addresses, or from an address that had not been used in a long time. There are many potential services with a functionally equivalent halt/bootstrap early in the transaction process.

I believe that at 30 or 58 characters, prefixes are already a scarce resource. Alternate Fadcoins (such as GeistGeld, a G prefix I presume) are popping up every week. With multiple bitcoin prefixes, we won't have a clue what any address is; we'll then need a parameter just to identify the currency. '1' has clearly been bitcoin. 'X' could be bitcoin with required extensions. But much beyond that and you will lose control of the prefix.

That's a good point! I have thought about it a little bit, but I think it doesn't make much of a difference either way. I see two options: You just have one general prefix (G or X or whatever) and then you need some kind of version or type parameter so the system can figure out whether it understands this particular extension. Or you treat the prefix character as the version/type information and whenever the system doesn't recognize a particular character it can conclude that it doesn't understand this particular extension. It seems to me that we won't be running out of possible prefix characters just yet, so both approaches look to me about the same in terms of "kludginess".


Interesting idea! :-) You would probably have to monitor though, whether you get enough funds this way and maybe turn it of if it's too much and add extra transfers if it's not enough. Given that transactions are still really cheap, I don't think I would go to the trouble of that. Neat trick though. =)

@jtimon: He is talking about regular Instawallet transactions, where currently the change is going back to a new, random Bitcoin address (standard Bitcoin behaviour) and which instead could be used to replenish the green address.

There's only a green address for each payment processor instead of one green address per user.
Why should you deposit in the green address (which the payment processor controls, not you) by default?

How about if you were to direct the 'change' from all withdrawals to your green address.  So even if I do a regular withdrawal, the change gets returned to your green address.  That way you should get away without ever having to manually 'replenish' the green address.

Yeah, or an X for eXtended info. Has X been used on some project yet?

Hi Jav, I certainly agree with your thinking that the protocol should pro-actively prevent accidentals and your solution would do that elegantly. I am concerned though that you are setting a kludge precedent. It's not like many systems accept the URI notation today anyway. The G-prefix is a good solution at this time, but I would urge you to continue the discussion of a simple, robust, extensible URI format. It would be a pity if every great new idea prefixed bespoke symbols in order to deliberately invalidate addresses.

EDIT: For example, It could be that the G-prefix should be interpreted to mean further protocol parameters required where 'ga' is one such parameter.