An ATM bitcoin to cash manufacturer is testing the functionality right now and another one is planning to integrate it when they implement the payment protocol.

There's also other users that can check either inside the GreenAddress wallet or at https://greenaddress.it/instant

it's called GreenAddress because when I thought about the concept, end of 2012 beginning of 2013 it wasn't yet associated with the bad reputation or MtGox double spends and I felt anyhow that it could be improved (which I think we did).

The modus operandi of the platform is different from the original GreenAddress concept as the instant confirmation comes out of band and is based on multisignature allowing the system to prevent users double spends.

However, like the original GreenAddress concept, it is based on third party trust, there is no magic bullet.

How could you prevent somebody signing a transaction using your service, waiting until the nLockTime has expired, then creating a transaction that is not signed by you but valid due to the nLockTime expiry? They would then be in a position to double spend because they could use a transaction that is verified by you to buy something instantly (cash from an ATM for example) and redirect the same funds back to their own control using the single signature transaction with a high chance of success.

We only provide instant confirmations for bitcoins we know that are going to get included in a block long before the nlocktime will expire allowing you to spend them.

How long before, because that would make it impossible for people to spend their coins at all during that period, which could be annoying.

Also, does this mean that to verify a transaction can be considered instant, the merchant has to check with your servers and there is no way of verifying this independently? Isn't this a serious privacy problem?

We don't provide instant confirmation but that does not mean you can't spend your funds without it.

The minimum is 1 day or 144 blocks, default to 90 days, max is max block size.

Hi Lawrence,

probably that is the right step toward solving the transaction speed,albeit by a slightly more centralized workaround,it reminds me of a comment I made almost a year from now:

https://news.ycombinator.com/item?id=6130813

great job ;)

cheers!