I think it is (?). The last PM I received from you is from November 26 and I thought I had replied to it. Although I can't find it in my outbox right now - I'll send it again.

Trying it out at the moment - nice work!

For now I will just decide on a case by case basis. I think the Bitcoin community is still small enough that there aren't that many players and those that are interested to get on the list should just get in touch with me.

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

Interesting, I wasn't aware of this domain. It resolves to the correct IP address at the moment and then the redirect happens, because you are accessing it via http and it redirects you to the https version. If you would browse directly to the https version, it should result in a certificate warning. Just be careful: This isn't run by me and whoever is behind that might change it to point somewhere else at any moment.

The problem seems to be my domain registrar. On its status page it is claiming that their DNS servers are under a lot of load at the moment and might be unresponsive in the following hours. The Instawallet server is up and doing fine. You can connect to it at 88.198.48.147, but that will give you a certificate warning.

This is indeed pretty huge. It will be interesting to see if they run into any regulatory problems in terms of money laundering laws. Which also leads to the question of how much identity verification they will or have to do before they give you such a debit card. I mean - a debit card that can be funded with 'anonymous' digital money surely can't be that easy to obtain?

I'm curious: why do you think that would be easier? That "credit card" processing machine will cost something as well, won't it? And if the solution here can be deployed on a cheap Android tablet where it might be possible to hit a price point of around $100 it seems to me those two options are pretty much the same in terms of up front cost.

And would a small business really be that concerned about a one time cost of $100 if they wanted to try Bitcoin? Actually, it might be interesting to explore alternative businesss models here. Maybe if - for example - Bit-Pay would offer an affiliate model, you could give a tablet like this for free to a small shop, help them get set up and everything and try to get your money back through affiliate earnings. It might be a little early for this kind of setup (probably not enough people would pay with Bitcoin at this point to make enough in affiliate earnings), but it might be an option at some point.

I think that should be possible.


I am not sure what exactly you have in mind here. Your requirement is no additional equipment as well as no additional software? That seems tricky (?). But I'm not very familiar with current POS software systems and what kind of setups are in use today.

There isn't really any cost associated with that attack. As to time: I'm pretty sure someone would do it. You have a vending machine sitting somewhere and the prize of tricking it is a free coke. How can any decent hacker turn down this challenge? Someone would write a tool to perform the attack - not for the money, but because of the challenge. Then the tool is out there and the next thing you know is that people start using the tool all the time to get free soda from your machines. (I'm talking about a tool for the simple attack here - such a tool could be written, which would basically just need the IP address of the vending machine and the rest would be automatic.)


That's true - but that's what I said, that you need at least basic double spend protection and can't just completely ignore the problem. (Because you could also set up that central vending machine server in a naive way which still opens you up to the attack.)

Online gambling is an example where paying with 0-confirmation transactions would be nice (get started playing right away) and double-spend insurance/protection is necessary. Otherwise an attacker deposits, plays and double-spends in case they lost.

Also: If you don't do _any_ kind of double spend protection (i.e. don't monitor the network for conflicting transactions) it starts to become an even bigger problem. So if a vending machine operator wants to accept 0-confirmation transactions today, they would definitely need to monitor the Bitcoin network for double-spends. Not something your typical vending machine operator has the technical skills to program and set up, so out-sourcing this to a service provider in the form of an insurance definitely makes sense in my opinion.

If you just integrate the standard Bitcoin client into your vending machine, you would for example be open to a much simpler attack like this one: http://www.reddit.com/r/Bitcoin/comments/kmo2l/suggestion_bitcoin_confirmation_honeypot/c2lhfs1 .

The miner wouldn't follow the Bitcoin protocol, so I'm not sure I would call it 'logical'. Bitcoin can also be seen as a timestamp network (the paper specifically mentions the term "distributed timestamp server"). It is an attempt at establishing a chronological order between transactions in a distributed manner. So miners need to include the transaction they received first, if they want to follow the Bitcoin protocol. If they don't do that, I would call them malicious. (This only applies to transactions that are in conflicting with each other.)


I'm not sure to what you are referring here exactly, but I'm also not that familiar with the semantics of nLockTime.


Attempts of the attack I linked to can not be detected, so you would only notice it once its too late.

That is not correct, transactions fees are irrelevant for this situation. If a Bitcoin node (which includes miners) receives two unconfirmed transactions, that are in conflict with each other, it will only accept the one it received first and drop the second one (which means it will also not be relayed). It does not matter whether the second transaction has more transaction fees. The node will only 'change its mind' if the conflicting transaction ends up in a block (which requires a miner which, for some reason, saw the second transaction first or a malicious miner).

A couple of months ago I have considered for a while to start something like the described BDPIC. In my opinion, it is only possible if you know the involved merchants very well. I did not want to have to whitelist merchants, so I decided not to attempt it.

The problem is this: Let's assume everyone can sign up for your BDPIC. If I'm an attacker, I set up a merchant account and can now pay myself through BDPIC any amount I want at a small fee. If there are limits in place, I just open multiple merchant accounts and bundle them.

With this setup, I can now attempt to double-spend until I succeed. The only conditions is, that the total amount of fees I have to pay is less than the payoff for a single successful double-spend. This will most likely be the case, unless you charge huge fees. Let's assume you charge 2% on all transactions (already on the expensive side, I would argue), then I as an attacker can try 50 times before it becomes unprofitable. I described one attack that can be performed here: http://www.reddit.com/r/Bitcoin/comments/kmo2l/suggestion_bitcoin_confirmation_honeypot/c2lhbv1 . The attack described there can not be detected by monitoring the network and if you have 50 tries you need to have a little bit more than 2% of total hashing power to make it work.

The only way to prevent this is to make sure, that all your merchants are legit and even among the legit merchants you need to forbid things that allow attackers to try multiple times. So for example an online casino, where you can withdraw funds that you have deposited through BDPIC would not be acceptable, as it would enable this attack.

No, I'm afraid there hasn't been much happening regarding this project. Although I have recently started to collaborate with someone (user ne1), who would like to combine this with an Arduino, to get some hardware projects going. Should be interesting to see what comes out of that.

To the tablet comments here: I agree, a cheap Android tablet seems like a good hardware choice.

I just got alerted by a user, that there is a tor hidden service at the address http://zgnbvbgfmoew7uz3.onion/ which claims to be Instawallet. From what I can tell, it always displays the same Bitcoin address: 1Pk9J8gbfvrLt27shdAMxBn21gdJsXGxCK .

This is _not_ the real Instawallet server! Instawallet does not run a tor hidden service and the only way to access the real service is through https://www.instawallet.org .

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.

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.

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.

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.