An existing tool that can show this is the list of unconfirmed transactions at http://bitcoincharts.com/bitcoin/ .

Indeed. This is what I was aiming at with this paragraph:

Thanks! And by the way: Congratulations on the launch of your merchant services! :-) I saw excerpts of the Bitcoin show about it and it looks great!


No special meaning (well maybe green as a symbol for "go ahead, it's safe"). I just picked a name for it so it's easier to talk about it.


I was thinking of creating a vanity address, but then decided not to do it. I was wondering if people might start relying on recognizing the address from memory. That might be dangerous, as it is not hard to create another vanity address that looks similar and that might slip by such a "manual check". So this way people might rather give the task of comparing it to a computer, which tends to not be fouled by these things. ;-)


Interesting suggestion. But I think that is putting a little bit too much stuff into the Bitcoin daemon which isn't really related to the "core" protocol. I would (and probably will soon) rather go the way of providing an RPC call that returns input addresses used by a transaction and then build an external tool around that.


My reasoning here is, that in some situations you can _only_ accept instant payments and it's a little bit of a problem when you have to rely on the user to actually do that (you know how users can be). Let's say you build an ATM machine based on this: ATM machine shows QR code, says "please use a green address", receives the transaction, checks the green address and gives you some bills. Great until the first user comes along who ignores the "please use a green address" (such a person will appear very quickly) and sends a "normal" transaction. Now your machine is in trouble. It can't accept a zero-confirmation transaction and blocking the machine until enough confirmations are there isn't really an option either. There is also no easy way of returning the money, but of course you can't just keep it either. So it turns into a support case where you have to manually intervene and return the funds.

On the other hand, if the ATM machine could already signal this "please use a green address" in the QR code itself, then the mobile app (at some point hopefully) would understand that and - even if it doesn't support this mechanism - prevent the user from doing something that won't work anyway.

Well, maybe a big sign on the ATM machine saying "Only green address from Instawallet accepted here" would also work, but I'm not entirely convinced on that. =)

I'm happy to announce that the "green address feature" just went live on Instawallet.org.

Green address technique

The idea is simple: When you send money using Instawallet and activate this option, your transaction will be created in such a way that it only uses coins from a specific Instawallet address: 1CDysWzQ5Z4hMLhsj4AKAEFwrgXRC8DqRN. By looking for this "green address", others can verify that this transaction was created by Instawallet.

This allows Instawallet to act as a trusted third party for instant payments. If you trust that Instawallet will not perform double-spends, you can accept transactions from this green address without having to wait for confirmations. This mechanism has the advantage, that it is "in-band": As long as you are receiving Bitcoin transactions, you can implement this check. Furthermore, the technique can be easily implemented by other third parties (Mybitcoin.com, Mt.Gox, Tradehill, etc.). It is up to the recipient to decide from which green addresses they allow zero-confirmation transactions.

In summary: This mechanism allows to implement secure, zero-confirmation transactions with the help of a trusted third party while staying completely within the Bitcoin protocol.

Possible uses:

• instant payment at a vending machine
• instant payment at a store
• instant deposit at a gambling website
• lots of other possibilities!

Implementation notes

In theory, checking for a specific green address is very easy. In practice, unfortunately, the Bitcoin daemon currently provides no way of accessing this information using the RPC interface. A patch will have to be written and used. But this is a temporary problem, which should be easy to fix. Of course Blockexplorer or Bitcoincharts also provide a way of checking the input addresses used by a transaction.

Vision

I hope this technique gains some traction and will be implement by a number of online wallets. It could then - for now, until a more sophisticated solution emerges - provide a way to do secure instant payments. By having this implemented by multiple parties, it should help to keep everyone honest and fees low (Instawallet currently provides this feature free of charge).

Merchants will have to decide which green addresses they accept and it might be necessary to standardize on a protocol that would communicate this automatically. I propose the following convention for the moment: When using a bitcoin URI (bitcoin:14Z1mazY4HfysZyMaKudFr63EwHqQT2njz?amount=5) the additional parameter (green_address=r) should indicate, that the recipient _requires_ the use of a green address. This allows clients which recognize this parameter to prevent a "standard" transaction from being used, where it might end up not being accepted - let's say at a vending machine, where instant payments are the only option. Of course you can not prevent people from sending you money ;-) , but this would at least provide an automatic way of warning them about the fact, that you might not accept just any transaction.

Going further, it might become necessary at some point for a merchant to communicate which green addresses they accept. For this I propose the additional parameter "green_address_details=URI", where URI points to a JSON document describing acceptable green addresses. The format for this document should be extensible, as to allow both static addresses as well as pointing to yet other places (maybe some from of global green address directory?).

To keep Bitcoin URIs short (as they have to fit into QR codes), I also propose that for each of the possible arguments a short version is defined that can be used instead:

• a for amount
• l for label
• ga for green_address
• gad for green_address_details

Turning an URI like "bitcoin:...?amount=5&green_address=r" into "bitcoin:...?a=5&ga=r". While on the topic of Bitcoin URIs: I would have preferred for the amount value to be in Satoshis, but it seems that specifying it in BTC has already become common practice, so I guess I won't go against the grain on that issue then.

Short term

The above suggestions are of course still a long way off and might not materialize. For the moment it should be fine to assume the acceptable green address implicitly (as, of course, only Instawallet is implementing it right now anyway) and thus only support the additional parameter "green_address=r" or "ga=r". I will be putting together a small point-of-sale demo shortly, to demonstrate the use of this technique. (Merchant shows QR code, customer scans code and uses Instawallet to pay, merchant checks for green address and the sale is complete).

Looking forward to your comments!

Update: Those looking to create green-address-style transactions themselves, might want to have a look at this Github branch https://github.com/javgh/bitcoin/tree/greenaddress and my comments about it further down ( https://bitcointalk.org/index.php?topic=32818.msg418326#msg418326 ). Although in the long run it might be better to implement this as a standalone solution, possible based on bitcoinj, which would only manage a single green address. This would keep it from interfering with other activities.

Update: There is now a point of sale implementation based on this approach. See this thread: https://bitcointalk.org/index.php?topic=38893.msg475829#msg475829 .

Yes, I will change it like that at some point.

Note though, that the attacker - depending on the situation - might be able to use multiple small transactions to get around this. So you will need to limit this on a global level, rather than on a per-transaction level. This puts an upper limit on the number of zero-confirmation transactions you can accept in a given time span.

I also don't agree that it can be put in an easy formula like that. It depends on the situation and what kind of service or product is being sold. Especially if the attacker can try lots of times (maybe because it's very easy to refund the product that he bought when the attack wasn't successful), there are some realistic attacks to consider. More thoughts on this can be found in this thread: http://forum.bitcoin.org/index.php?topic=27417.msg347403#msg347403 .

I have now deleted a bunch of old accounts to ease the load on the system. Accounts with ALL of the following conditions

• balance of zero
• never received a transaction
• not been accessed in the last couple of weeks

have been deleted. I can't imagine anyone being affected by this, but if you had such an account, the associated Bitcoin address is now no longer valid and you have to revisit the site to get a new one.

If you experience any problems because of this clean up, please get in touch with me, as I have backups of all deleted accounts.


I won't disclose BTC volume for now (although sooner or later someone will probably extract that from the block chain - it's not that hard with the right tools). But in terms of number of transactions, the site has about 70 per day.

As I said, it's not terrible much. The scaling issues are mostly the big number of accounts and really inefficient algorithms. There are many possible solutions to this, but all of them will take a bit of time.

It's mostly the fact that I'm using the account feature of bitcoind. I didn't realize in the beginning, that the account code often calculates things from scratch (for example when calculating the balance of an account). I have already written a cache ( https://github.com/javgh/bitcoin/tree/balancecache ), but it will need some more fundamental changes to scale further.

I currently have around 30000 accounts (almost all of them empty of course, that's the nature of the site). If you don't make much use of the account feature, than you will probably not run into the same problems.


I agree, I also don't like asking for donations. So scratch that "donate for bigger server" idea. (You are of course welcome to donate and I appreciate that very much, but I don't want to give anyone the feeling, that they are obliged to donate).

I have been considering transaction fees and will probably experiment with something in that direction. Unfortunately this is another area where the bitcoin daemon needs improvement. Using the RPC interface, it is currently very hard to control when and how much fee is included (and if I start taking transaction fees, I will want to pass some of them on to the miners). So things need to improve in this area first (or me finding the time to do it myself) before I can pursue that further.

@Gornick: Those are interesting ideas. I'm also toying with different revenue models. There are definitely a number of things to try out. But you know how it is: "so much to code, so little time". ;-)

I don't have a business model at the moment. It's just a spare time project to help Bitcoin gain some traction.

I'll see how it develops. Maybe other services/solutions will make Instwallet obsolete, maybe I'll find a way to finance it that I'm happy with or maybe it will just run on donations.

For the moment the scaling issues aren't so much "lots of users", but more "really inefficient algorithms" (in some parts of the Bitcoin daemon). As I mention, that will take some time to sort out, but fundamentally the service should be able to run on very few resources to serve current demand.

On that note, I am considering throwing hardware at the problem to buy myself some time. Maybe get a dedicated server for 3 months. That would probably require around 10 BTC in donations. Would you guys be interested in that or would you rather deal with a little downtime here and there?

Quoted from the downtime thread (http://forum.bitcoin.org/index.php?topic=13230 - I will post downtime related updates only over there in the future):

It's back up.. for the moment. You guys are putting too much load on it by using it so much. ;-)

Seriously though, I'm running into a number of scaling issues which show that the Bitcoin daemon hasn't really been used in production (large wallet.dat) much. I'm afraid there isn't an over-night fix for this, so the site might be flaky over the next days/weeks until I can figure out some solutions and/or workarounds.


Thx for the encouragement. I'm glad it's useful to some people. Sorry about the downtime. I hope I can return to the previous level of stability once this growing pain is sorted out.

Yes, I just noticed that the site was down for a number of hours. Sorry about that. It's back up again now. Unfortunately I'm not sure what caused the crash, so it might happen again. :-/

Yes, I just noticed that the site was down for a number of hours. Sorry about that. It's back up again now. Unfortunately I'm not sure what caused the crash, so it might happen again. :-/

When you say central server, are you thinking of a server that does only the routing or also the automatic Bitcoin debt settlement? If it's the latter, that already exists: MyBitcoin.com, with the added benefit, that no trust connections are necessary. Everybody can pay everybody else on MyBitcoin.com instantaneously as long as they have an account there with enough Bitcoins.

If the central server only does the routing and the automatic debt settlement is done by the individual nodes then that can be seen as an addon to my proposal. Which seems indeed like a good idea: Have a decentralized system that only supports manual routes and then have a well-known directory server where everybody publishes their trust connections and can query for routes.

At some later stage that directory server can then be replaced by a mechanism that figures out the routes without requiring a central server.

On using Internet-like routing: That is a good suggestion! Although I wonder about privacy and whether it would be possible to do all that and still allow participants to not reveal all the people they trust. That might be too much to ask for, giving the complexity of the problem already, but maybe some of the other requirements could be eased (like not requiring the algorithm to find an optimal path, but use some kind of heuristic to have a good chance of finding a decent path). To me it seems like there are a lot of tradeoffs to consider.

On that note, I wonder how much of this discussion has already happened within the Ripple community. I haven't gone through their archives in much detail, but for those who are interested, I think much of the discussion regarding Ripple systems is happening over here: https://groups.google.com/group/rippleusers .

I agree. I think that a Bitcoin-specific Ripple system has lots of promise. I haven't really tried Ripple much, but I always worry that maximum credit level might quickly be reached on some routes and then the system doesn't work until a manual debt settle. For example a popular online store will probably mostly have flowing cash towards them and quickly reaching the credit limit with the nodes that trust the store.

Since Ripple supports arbitrary currencies it can't really do automatic debt settlement. But if you would limit it to Bitcoin you could occasionally do automatic Bitcoin payments.

Unfortunately the Ripple project doesn't have all that much software written. They only have centralized servers (so all the trust connections are maintained on a single server) which is nice to play around with, but ultimately it should be decentralized. They are working on a decentralized version, but its mostly in the design phase and I'm not holding my breath, because it's a very hard problem. Since you need to be able to find trust paths connecting different people that might be registered on different servers etc.

An idea I was toying around with: Maybe go for a simple prototype first where routes are manually. So you would have to tell the system specifically that you want to route your payment through alice@server1 -> bob@server1 -> claire@server2 (assuming there is trust between alice<->bob and bob<->claire). The system would keep track of the credit limits alice<->bob and bob<->claire and would occasionally settle the debt with a standard Bitcoin payment.

Quick update: Internal payments (from one Instawallet to another) are now detected and treated differently: They are instantaneous and amounts down to 1 Satoshi are possible.

Not at the moment, no.


Yes, I will try and tackle this soon (detecting internal transfers and dealing with them differently).

The thing is, the pools aren't going to promise you that the transaction will be included in the block. Because the next moment a block could come along with a conflicting transaction (the attacker might have prepared such a block) and then they aren't going to keep working on a block that will potentially end up as an orphan. After all, 50 BTC are at risk here.

So the best you can get is "we received your transaction". And you can pretty much do that already: Just open a connection to the big pools and listen for the "inv" message with the hash of your transaction. If you see it, the pool received it.

There is a third case, a variant of the Finney attack: After sending your transaction A to the merchant, you feed your conflicting transaction B to your miner (and don't broadcast it). If you happen to be the one who finds the next block (let's say you have 5% of the network hashing power, so a chance of 1 in 20), transaction A gets reversed. You can do that at no additional risk. Besides of course, that you might not find the next block and transaction A gets through.

This is still important to keep in mind, for situations where the attacker can just try lots of times and refund the things that went through. So for example if a site has some kind of balance where you can deposit Bitcoins and withdraw them later.

I'm also not so sure about racing the network being so hard: Open one connection to the merchant's Bitcoin daemon and a number of connections to all of the major mining pools. Then, at the exact same time, send transaction A over the merchant connection and transaction B to all the pools. I think you have a pretty good chance of getting transaction B into the next block, while the merchant saw A.

For this reason, I would advise merchants to not accept incoming connections (of course an attacker could wait until he sees a connection from the merchant.. might take a long time though, so maybe not much of a risk). But even in this case, you could try something like this: Open one connection to Deepbit and a bunch of other connections all over the network. Send transaction B to Deepbit and transaction A all across the network. You might end up with most of the network seeing A, but with a decent chance that Deepbit will find the next block and has B included.

All that said, I do agree though, that in a lot of cases accepting zero-confirmations is probably fine: If you sell something that isn't all that expensive (compared to 50 BTC), can't be easily refunded and you don't accept incoming connections.


I'm not sure if you saw it, but a few days ago I released an API for Instawallet. It's not mentioned on the site yet, but documented here: http://forum.bitcoin.org/index.php?topic=26910.0 . From the looks of it, you could probably do what you describe with the API.

But more generally: Why do you think this would be more decentralized than Mt.Gox's vouchers? In the end it comes down to who the merchant trusts. Does he trust the voucher? does he trust that Instawallet will pay them? Of course it would be nice to have a standardized way for doing this (and to that end, I think the vouchers aren't the best approach to that), but shadyonlinewallet.com can come along and implement the API as well.

So ultimately it's about trust again, trust between the merchant and the payment processor. And this is why I consider the Ripple Project very interesting in this context. In theory, it could help to formalize a trust network between merchants and payment processors, that isn't just a simple "Merchant A trusts wallet B", but could also be "Merchant A trusts Wallet B, which trusts Merchant C, which trusts Wallet D" allowing for funds to flow from Wallet D to Merchant A even though they don't trust each other directly.

Unfortunately the Ripple Project hasn't all that much code to use right now. Just centralized server solutions which isn't going to fly with the Bitcoin crowd and doing this properly decentralized is a pretty hard problem, so I'm not holding my breath.

I never tried this on Windows. Maybe the ' character is interpreted differently there? Have you tried something like this instead?

bitcoind.exe sendmany "" "{\"1BrendiovuqgHwxTq9QWRGvMHTkp3YSnKF\":0.0001,\"1TipMEDeqWT1VUmmhH3rmkVrkA4KYRk2C\":0.0001}"


Not sure how you ended up in this situation in the first place, but I don't think this is specific to the method I described.