Bitcoin Forum
April 17, 2014, 04:20:22 PM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 4 5  All
  Print  
Author Topic: Instawallet introduces new approach to instant payment: Green address technique  (Read 18515 times)
jav
Full Member
***
Offline Offline

Activity: 238


View Profile

Ignore
July 29, 2011, 04:16:01 PM
 #1

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 .

Hive, a beautiful wallet for Mac OS X, now available for testing. Follow the story here.
BitcoinKit.framework and Tor.framework, now available to iOS and Mac OS X developers.
Tweeting at @hivewallet. Donations appreciated at 142m1MpXHhymF4aASiWwYohe1Y55v5BQwc.
1397751622
Hero Member
*
Offline Offline

Posts: 1397751622

View Profile Personal Message (Offline)

Ignore
1397751622
Reply with quote  #2

1397751622
Report to moderator
1397751622
Hero Member
*
Offline Offline

Posts: 1397751622

View Profile Personal Message (Offline)

Ignore
1397751622
Reply with quote  #2

1397751622
Report to moderator
GAWMiners.com
ASIC Scrypt Miners
Guaranteed Satisfaction + Same-Day Shipping For FREE!
Simply Enter "freeshipping" at checkout

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1397751622
Hero Member
*
Offline Offline

Posts: 1397751622

View Profile Personal Message (Offline)

Ignore
1397751622
Reply with quote  #2

1397751622
Report to moderator
BitPay Business Solutions
Hero Member
*****
Offline Offline

Activity: 756



View Profile WWW

Ignore
July 29, 2011, 04:47:56 PM
 #2

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

Looking forward to your comments!

Jan - we loved this idea the first time we heard it.  We'll work with you to support this 100% on the merchant side.

BitPay : The World Leader in Bitcoin Business Solutions

https://bitpay.com

Does your website accept bitcoins?
netrin
Sr. Member
****
Offline Offline

Activity: 322


FirstBits: 168Bc


View Profile

Ignore
July 29, 2011, 04:48:52 PM
 #3

Something like this was inevitable, but none the less brilliant. Glad to see Instawallet ahead with simple innovations.

What is the significance of the name "Green" address?

I would have hoped your address would be more memorable, perhaps a "vanity" address with short 5 character firstbits. The best I can do for mnemonic is CoDe-YeS-W.


implemented by other third parties (Mybitcoin.com, Mt.Gox, Tradehill, etc.). It is up to the recipient to decide from which green addresses
...
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.

Why not patch the C++ client to accept a list of "green addresses" from bitcoin.conf and display 0/green_unconfirmed in the transaction log? I expect you'll find support for it. Later we can consider a more complex DECENTRALIZE WOT model. You are in the best position to immediately implement this and see how sticky the patch is. We vote with fork pulls.


honest and fees low (Instawallet currently provides this feature free of charge).

As long as it's free, it'll be a value-add for your service. I would never pay for this a la carte.


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)

Fair enough if the community finds consensus or demands this, but I don't immediately see the need. I would be worried that merchants will just as soon accept "Google" bitcoin payments only to the detriment of great services like Instawallet.

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
jav
Full Member
***
Offline Offline

Activity: 238


View Profile

Ignore
July 29, 2011, 05:26:58 PM
 #4

Jan - we loved this idea the first time we heard it.  We'll work with you to support this 100% on the merchant side.

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!

What is the significance of the name "Green" address?

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 would have hoped your address would be more memorable, perhaps a "vanity" address with short 5 character firstbits. The best I can do for mnemonic is CoDe-YeS-W.

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

Why not patch the C++ client to accept a list of "green addresses" from bitcoin.conf and display 0/green_unconfirmed in the transaction log? I expect you'll find support for it. Later we can consider a more complex DECENTRALIZE WOT model. You are in the best position to immediately implement this and see how sticky the patch is. We vote with fork pulls.

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.

Fair enough if the community finds consensus or demands this, but I don't immediately see the need. I would be worried that merchants will just as soon accept "Google" bitcoin payments only to the detriment of great services like Instawallet.

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

Hive, a beautiful wallet for Mac OS X, now available for testing. Follow the story here.
BitcoinKit.framework and Tor.framework, now available to iOS and Mac OS X developers.
Tweeting at @hivewallet. Donations appreciated at 142m1MpXHhymF4aASiWwYohe1Y55v5BQwc.
wumpus
Hero Member
*****
Offline Offline

Activity: 630

No Maps for These Territories


View Profile

Ignore
July 29, 2011, 05:41:34 PM
 #5

Very nice idea, great that someone finally implemented it!

And now we have a good reason to let the be able to show the source addresses somehow Smiley
Quote
Fair enough if the community finds consensus or demands this, but I don't immediately see the need. I would be worried that merchants will just as soon accept "Google" bitcoin payments only to the detriment of great services like Instawallet.
I think this fear is unfounded. The green address would only help for trusting 0-confirmation transactions from certain sources. The rest can wait for 1..6 confirmations as normal.


Bitcoin Core developer [PGP]  Tips: 1L125pF2e7himW43Qu752ZFLtBLicxQmng Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
kjj
Hero Member
*****
Offline Offline

Activity: 1022


Bitcoin Foundation - Lifetime Member


View Profile

Ignore
July 29, 2011, 05:44:13 PM
 #6

If you expect a lot of services to show up and offer these, you are going to need to find a way to negotiate which providers are acceptable to a merchant.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
bitplane
Sr. Member
****
Offline Offline

Activity: 321

Firstbits: 1gyzhw


View Profile WWW

Ignore
July 29, 2011, 05:52:55 PM
 #7

A client with a decent interface could just have an address book with a "trusted" checkbox next to people in the address list. If an address belongs to a trusted party, it could be a green "0/unconfirmed (trusted)" or whatever.

Merchants and providers could just let users download a vCard containing their bitcoin address, and/or have it embedded in their contact pages using an appropriate XHTML microformat.
jav
Full Member
***
Offline Offline

Activity: 238


View Profile

Ignore
July 29, 2011, 05:54:10 PM
 #8

If you expect a lot of services to show up and offer these, you are going to need to find a way to negotiate which providers are acceptable to a merchant.

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

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

Hive, a beautiful wallet for Mac OS X, now available for testing. Follow the story here.
BitcoinKit.framework and Tor.framework, now available to iOS and Mac OS X developers.
Tweeting at @hivewallet. Donations appreciated at 142m1MpXHhymF4aASiWwYohe1Y55v5BQwc.
CryptoCommodity
Member
**
Offline Offline

Activity: 80


View Profile

Ignore
July 29, 2011, 06:02:47 PM
 #9

Question - where would I be able to see this specific address?  When I look at my Bitcoin Client received transactions it simply states "From: unknown" and doesn't provide the address the coins originated from.  

People can use blockexplorer.com to see the orginating address but that isn't instant.
jav
Full Member
***
Offline Offline

Activity: 238


View Profile

Ignore
July 29, 2011, 06:10:34 PM
 #10

Question - where would I be able to see this specific address?  When I look at my Bitcoin Client received transactions it simply states "From: unknown" and doesn't provide the address the coins originated from.  

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

Hive, a beautiful wallet for Mac OS X, now available for testing. Follow the story here.
BitcoinKit.framework and Tor.framework, now available to iOS and Mac OS X developers.
Tweeting at @hivewallet. Donations appreciated at 142m1MpXHhymF4aASiWwYohe1Y55v5BQwc.
realnowhereman
Hero Member
*****
Offline Offline

Activity: 490



View Profile

Ignore
July 29, 2011, 06:20:59 PM
 #11

Brilliant idea.

Well done.

There is probably scope for making this green address idea peer-to-peer in parallel with bitcoin itself.

For example, one could broadcast an address to a "green" node, and it will be rebroadcast until one of the nodes broadcasts back with, say, a GPG signature of the key.  Then you can load up as many public keys from trusted "green" providers as one wishes in your shopping basket.


1AAZ4xBHbiCr96nsZJ8jtPkSzsg1CqhwDa
jimbo77
Member
**
Offline Offline

Activity: 77


View Profile

Ignore
July 29, 2011, 08:17:50 PM
 #12

Pretty neat. Can someone fake the from address? It won't make it in a block but could they fake a transaction with a fake from address? Or if the private key was stolen you would have to have some way of revoking the "green address".
Trader Steve
Hero Member
*****
Offline Offline

Activity: 633


"How do you eat an elephant? One bit at a time..."


View Profile

Ignore
July 29, 2011, 08:43:20 PM
 #13

Very nice!
coblee
Donator
Hero Member
*
Offline Offline

Activity: 826


firstbits.com/1ce5j


View Profile WWW

Ignore
July 29, 2011, 09:12:35 PM
 #14

I like the concept but don't like the name. Green is used these days as something eco friendly, which has nothing to do with this concept.

You should call it something like "trusted address" or maybe a geeky name like "zero conf address"

Just my 2 bitcents.

Litecoin: http://litecoin.org - LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr
Casascius physical bitcoins database: http://casascius.appspot.com/
Trader Steve
Hero Member
*****
Offline Offline

Activity: 633


"How do you eat an elephant? One bit at a time..."


View Profile

Ignore
July 29, 2011, 09:18:46 PM
 #15

Question: Does this help with anonymity or does it create some "plausible deniability"?
coga
Full Member
***
Offline Offline

Activity: 226


www.btcbuy.info


View Profile WWW

Ignore
July 29, 2011, 09:49:52 PM
 #16

Is this service already in production? I would certainly like to support it on btcbuy.info , I am advertising my service as a "quick" one, but the fact is that I have to wait for a confirmation, which often adds a lot of extra time to the wait

GPG key: 6F8E305690A05365B58C50A
symbian
Jr. Member
*
Offline Offline

Activity: 42


View Profile

Ignore
July 29, 2011, 09:50:59 PM
 #17

This won't work out if you got eventually an orphan block first confirmed transaction. The block may be marked ORPHAN if integrity of the network would be broken for some time, so this transaction will be confirmed in other chain a lot of blocks later or may be even lost(?). That's why it's recommended to wait untiil 100 confirmations. I suppose it's quite easy to separate bitcoin clients and break network for hours or days.

coga
Full Member
***
Offline Offline

Activity: 226


www.btcbuy.info


View Profile WWW

Ignore
July 29, 2011, 09:51:50 PM
 #18

This won't work out if you got eventually an orphan block first confirmed transaction. The block may be marked ORPHAN if integrity of the network would be broken for some time, so this transaction will be confirmed in other chain a lot of blocks later or may be even lost(?). That's why it's recommended to wait untiil 100 confirmations. I suppose it's quite easy to separate bitcoin clients and break network for hours or days.

Sometimes it is cheaper to bear a loss, than to lose a customer

GPG key: 6F8E305690A05365B58C50A
BitPay Business Solutions
Hero Member
*****
Offline Offline

Activity: 756



View Profile WWW

Ignore
July 29, 2011, 10:01:59 PM
 #19

Jan - off-topic but can you add a QR image to your website home page that has the wallet bitcoin address?  you can get a free generator from Google's Chart API.  That will make it much easier to send money to the Instawallet!

BitPay : The World Leader in Bitcoin Business Solutions

https://bitpay.com

Does your website accept bitcoins?
netrin
Sr. Member
****
Offline Offline

Activity: 322


FirstBits: 168Bc


View Profile

Ignore
July 29, 2011, 10:03:24 PM
 #20

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 suppose the name 'instawallet' was already taken. Smiley I agree with a later poster. Green has little to do with it. Rather instant and trustworthy = Instantrust?


I would have hoped your address would be more memorable, perhaps a "vanity" address with short 5 character firstbits. The best I can do for mnemonic is CoDe-YeS-W.
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. ;-)

Are you familiar with firstbits? It is short, unambiguous and decentralized - indeed all that is required is the block chain and a simple algorithm. Your "green" address is 1cdysw and nothing more (nor less). The genesis address was '1'. All others are 2+ characters.

However, I guess the SENDING address does not need to be as memorable as the RECEIVING address.

Why not patch the C++ client to accept a list of "green addresses" from bitcoin.conf and display 0/green_unconfirmed in the transaction log? I expect you'll find support for it. Later we can consider a more complex DECENTRALIZE WOT model. You are in the best position to immediately implement this and see how sticky the patch is. We vote with fork pulls.
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.

It seems a purely presentation layer feature. I already see 0/unconfirmed transactions. All that has to happen is that the presentation logic recognizes the sending address, matches it against a list, and displays 0/green_unconfirmed.


in some situations you can _only_ accept instant payments ... ATM machine shows QR code, says "please use a green address", ... user comes along who ignores the "please use a green address"

Sure, but then you need a hand shaking protocol and never send the receiving address before confirming the client/user groks the green address concept.

  USR: Hello, I wanna buy a cola
  ATM: Hello, it's 0.25 BTC, payable by 1A, 1B, 1C, 1CDysW, 1D green addresses
  USR: Great, I love green addresses, what's your address?
  ATM: 1bitcola
  USR: You can expect that from 1CDysW
  ATM: Got it, Thanks. Now here's your cola

Greenlandic tupilak. Hand carved, traditional cursed bone figures. Sorry, polar bear, walrus and human remains not available for export.
Pages: [1] 2 3 4 5  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!