Hey! Thanks for your great comments! :-)


I'm not sure how much of an issue the space requirement really is. I mean, a cash register can be pretty clunky as well. But it all depends on the situation I guess, and I agree, that a smaller solution would be much nicer. One reason this is open source is to be able to iterate towards a better solution. I think there are many options to be explored: Maybe a Sheevaplug could be used in combination with a USB touchpad and a USB display. Or maybe even a cheap Android phone to which a USB display is somehow hooked up (not sure how feasible that is, but I have seen some hacks in that direction). The latter would require to port the GUI parts to Android.


Instantaneous transfers among users of a specific service isn't really that special (Instawallet has it as well) and doesn't - in my opinion - really lead anywhere. Take the example of Flexcoin: Nothing against it, but merchants won't be limiting themselves to a small subset of possible Bitcoin customers. Unless that subset is close to all of Bitcoin customers and that is simply not going to happen. Bitcoiners are much too wary - and rightfully so - to let a single payment processor get so powerful.

So what we need is an open protocol that allows to split this responsibility over multiple payment processors. It should have a fairly low barrier of entry for new payment processors and it should be easy to get rid of established payment processors should they start to become annoying. The green address technique is an attempt at formulating such a protocol. It could be implement by Flexcoin and Vibanko and the merchant would then see "Verified by Flexcoin" or "Verified by Vibanko" and it's up to the merchant to decide whether that's good enough.

I'd like to point out, that I made an effort to make it fairly straightforward to run this application. Granted, it's only tested on Linux for the moment, but it has very few dependencies and can run in combination with a standard Bitcoin client (so no patches needed or anything). You can use any Bitcoin mobile client, unless you want to test the green address feature. Then you will need BitPay with my patch applied (see the GitHub link for more info about that). But hopefully, the version of BitPay in the Android market will soon be updated to make this step easier as well.

What do you think, how cheap could a hardware solution based on this be put together? I'm thinking old, used laptop (maybe an Eee PC) plus smallish external monitor. Maybe all in all for $150? Maybe less? .. I think we could reach the point, where this is a straightforward and fairly inexpensive way to get a brick and mortar merchant set up for Bitcoin payments. I think maybe the only missing piece in the puzzle would be automatic exchange to the merchant's local currency (e.g. USD) to have it be a complete worry-free (regarding exchange rates) solution. It might be interesting to interface with a Bitcoin exchange here.

Hey! I released a first version now, with a simple design I put together myself. See this thread: https://bitcointalk.org/index.php?topic=38893.0 . Of course the design can be improved/replaced etc., if one of you are still interested in working on that.

I could better justify the price tag to myself, if I can build something interesting to put into my living room or somewhere. For that I want it to be silent and "hey, have a look at my money-making aquarium" seems like a nice conversation starter. :-) From reading the beginning of the thread, I got the impression that quite a bit of cooling would be necessary, so that's why I liked newMeat1's mineral oil idea.

But of course, if passive cooling is possible and safe, I'm all for it! So will this second generation of boards already be cooled passively? If that is the case I'm probably interested in a pre-order.

Hi there! Today I'm releasing the first version of a simple Bitcoin point of sale application. It was mainly written to demonstrate the use of the green address feature, but can also be used independently of that. It is written in Python and works in combination with a standard Bitcoin client. It is targeted at standard PC hardware, e.g. laptop (used by merchant) + external monitor (facing the customer).

Here is a video of the system in action: http://www.youtube.com/watch?v=o84SfChQ-S8 . (Update: Here is another, shorter video of just the payment being performed: http://www.youtube.com/watch?v=DNpcf9rSBIk .)

More details and explanations, the code and a number of screenshots can be found on the project's page on GitHub: https://github.com/javgh/greenaddress-pos-tools .

Looking forward to your feedback! :-)

Update (Jan 2014): The system has been extended to use NFC and Bluetooth. See this thread for details: https://bitcointalk.org/index.php?topic=395469.0 .

Another question: Could this be cooled by submerging it into a small aquarium filled with mineral oil? Would one still use a heatsink in such a situation or is that unnecessary, with a liquid cooling solution?

Cool project!


I don't know too much about the hardware side of this stuff, so here are a few newbie questions:

If you would control this from a laptop, where would you get the 4-pin Molex connector from? Do you need an additional AC power adapter in that situation?

Is there such a thing as a USB to 4-pin Molex adapter? Or does a USB port not provide enough power for this?

Is my understanding correct, that previously the platform cable was used to upload some type of firmware? Is this now done over USB? or what was the function of the platform cable and by what is it replaced now?

Thanks in advance. :-)

First off: I agree that monitoring the network for conflicting transactions is a good way to make double spend attacks much harder. Whether or not to modify the protocol for that, is up for discussion. The idea to introduce some type of double spend alert message was also recently discussed on the mailing list, but the consensus seems to be for the moment not to introduce any extra communication for this.

I tend to agree with that, until the possible ramifications - especially in regards to possible DoS attacks - are better understood. And would, for the moment, think that an external tool can also fill this role, by being well connected to a lot of nodes and monitoring the network for conflicting transactions.

However:


I wouldn't dismiss the Finney attack so easily. Let's imagine this scenario: A rogue pool operator provides a little side business which accepts transactions that are conflicting with current unconfirmed transactions and will include them into the next block, should the pool be the one which finds the next block. Let's say this pool has 5 % of the hashing power of the network.

Now whenever I pay a merchant, I submit a conflicting transaction to this pool (the pool doesn't broadcast this transaction, so the network won't know about it).  Should the pool not find the next block, nothing happens. But if the pool finds the next block (a chance of 5 %) I get my money back and just have to pay some fee to the rogue pool for performing the attack. The important thing though is, that neither the pool nor I am risking anything in trying this attack.

The attack can further be made more effective, by creating the original transaction to the merchant in such a way, that it will take a long time to confirm: Use young coins, don't include enough fees etc. This will give the rogue pool more time to include the conflicting transaction into a block.

I find this attack scenario pretty realistic and as such, am not sure if I would advice a merchant today to accept zero confirmation transactions even with a double spend detection mechanism as described by you.

Thanks a lot guys, for all the kind words! I hope I can continue to provide a good service. I apologize for the site being slow from time to time at the moment. I am planning a complete rewrite of the back end to prepare the site for much higher loads which, as soon as I can complete it, should hopefully solve these problems.

This looks very interesting! Thanks for releasing this.

Can you say a little bit more about the server side? Is that part open source as well? And is it based on the Satoshi client or have you reimplemented the Bitcoin protocol yourself for the server side?

I definitely agree. I would have been in favor of specifying the amount in Satoshis, but it is my impression that things start to move to interpret the amount as BTC directly. For example the Android Bitcoin client does that. I'm generating Bitcoin URIs for a project myself, so that is what I will go with as well. Which means to have things that look like this: bitcoin:14Z1mazY4HfysZyMaKudFr63EwHqQT2njz?amount=1.23&label=optional .

You'll have to ignore all that exponent stuff on the wiki. It annoys me a lot that it floats around there, but I haven't been bothered enough to get into an edit war with the guy who pushes this sort of stuff together with his tonal agenda.

Alrighty, I just put something up on GitHub: https://github.com/javgh/greenaddress-pos-tools .

As mentioned in the README, here is how to get started:

- install dependencies: python-qrencode, python-qt4
- add "server=1" (but not daemon=1) to bitcoin.conf and configure rpcuser & rpcpassword
- edit RPC_URL in controller.py
- run: python pos-tool.py

I'm developing on Linux, so this is only tested on Linux. But I would hope this to be fairly portable. Patches to make it work (better) on Windows and/or Mac OS are welcome.

You should see two windows popping up: The merchant backend and the customer display. If you enter a BTC amount and click "show", a new Bitcoin address and associated QR code will be generated and displayed to the customer. The tool then listens for transactions to the Bitcoin address and as soon as it receives something, it changes the display to read "Payment received". If the payment was done via Instawallets green address, it will add the phrase "Verified by Instawallet". The merchant is expected to use their Bitcoin client to see if the correct amount was sent.

What is missing:

- some hardcoded stuff should be moved into a configuration file
- a button to bring the customer display to fullscreen and some logic to go back to idle mode after a while
- interfacing with Mt.Gox and/or Tradehill to do currency conversion
- slick design for the customer display

If you look at the code, you will see that it contains a simple Bitcoin node implementation. This is used to listen for transactions and get notified as soon as one arrives. This could be done much easier with a patch to bitcoind (for example a version of Gavin's monitor patch: https://github.com/bitcoin/bitcoin/pull/198 ), but an important goal of this project is to have as few dependencies as possible and especially be able to run with a vanilla Bitcoin daemon. This is why I went the route of using ArtForz' "half-a-node" implementation to listen for transactions manually. (Hopefully this can be dropped at some point in the future, when the official client allows some form of push-notification directly.)

As to the customer display: As mentioned before, I now went the route of putting it all into a single HTML file (data/customer_display.html) and using Javascript functions to toggle between the different states ("show_idle()", "show_payment_info()", "show_payment_received()"). The Javascript functions will show and hide DIVs. In designing a new look, you can pretty much just work with that HTML file directly, as it also contains some debug links to trigger those Javascript functions. This should also make it fairly easy to bundle a number of different "skins" for the system.

Looking forward to your input!

I'm not sure if some people try to use this feature to launder Bitcoins, but I just want to point out that it doesn't bring any particular advantage in that respect.

You can already use Instawallet, just like pretty much any site with a largish wallet.dat, to launder Bitcoins. Just sent them there, wait some time, then withdraw them from your account and chances are pretty good that you will get different coins. You are welcome to use Instawallet in this way and even save yourself the cost for some of the Bitcoin laundry sites around. ;-) (Of course the coins could be linked using Instawallet's logs, but that risk can be reduced by routing the coins through multiple sites. That way they can only be linked if the attacker has access to the logs at all of the sites.)

Whether or not you additionally route it through the green address doesn't really change much. So in that light, I would ask you to refrain from it. It puts unnecessary additional strain on the block chain. Currently Instawallets green address transfers require 2 transactions (from the specific wallet to the green address and then from the green address to the destination).

Note though, that this technique doesn't necessarily require 2 transactions. The green address could be replenished only from time to time with a single large transaction. But that is an optimization that I haven't implemented yet.

Cool to hear that! I was planning to use the MIT license, but as I understand it, that pretty much boils down to the same thing.

I will be putting something up on Github shortly, but want to get it a little bit into shape before I do that.

For a bit more context, here is a quote from a PM I messaged to someone else:


I'll keep you updated!

Instawallet uses offline storage as well (about 75 % of all funds are currently offline). Most people follow the "not a bank, just spare change" rule so it's not much to begin with, which is how it should be. Just to reiterate: Instawallet is a spare time project of mine, does not offer high security and is more a show-case platform to make Bitcoin more convenient. If there ever is a "bank run" on Instawallet, then it might take a day or two until I move things out of offline storage.

I don't think interpreting them as prefixes is such a good idea. Someone can come up with an address that matches the prefix in ways you didn't plan.

But as jtimon points out, it seems indeed like a good idea to interpret them like Firstbits does. So only the first match in the block chain counts. Sounds like a good idea to me! Allow a field "green_address_list" (short "gal") to specify acceptable addresses in Firstbit format directly in the QR code and only use the "green_address_details" mechanism when that starts to get too long to fit comfortably into the QR code. Thanks for the suggestion!

As to Ripple: Definitely an interesting candidate to provide a more general approach to this. I have written a little bit about that here: https://bitcointalk.org/index.php?topic=28565.msg362094#msg362094 . But that's still a little into the future, I would guess.

I highly doubt this is the real Tom Williams. Quoting again from https://bitcointalk.org/index.php?topic=22221.0 :


against:

I already posted this on Reddit a little while ago ( http://www.reddit.com/r/Bitcoin/comments/j0bva/help_me_build_a_point_of_sale_application_design/ ), but not much came out of it. So I want to give it a shot here again:

I'm working on a Point of Sale system written in Python and targeting standard PC hardware. Think laptop + external monitor. The laptop is used by the merchant to set up a new transaction and the external monitor shows the necessary details to the customer (amount, QR code, etc.).

I have most of it written and I will be releasing this as open source soon. Among other things, it will be a demonstration of the green address approach I described here: http://bitcointalk.org/index.php?topic=32818.0 . I wanted to ask the community if someone would be interested in designing the payment screens. They are just HTML pages.

Three screens are needed (the plan is to show them in a browser set to fullscreen mode):

• Payment info: Shows amount, Bitcoin address, in some cases conversion details (if the merchant entered a USD price which was converted to BTC, the course that was used will be displayed) and finally a QR code. Here is a simple page that has these components: http://pastebin.com/8Xby7nNs . You are free to modify and style the page as you see fit (also adding phrases like "Please pay to this address..." and whatever you find necessary.)
• Payment received: A page that states that a payment has been received.
• Idle: A page that will be shown when the system is idle. Maybe just a big Bitcoin logo or some kind of welcome screen. It's up to you.

If you decide to contribute, you should be willing to license your design under an open license, since this project will be open source. You can also check out the comments on the Reddit thread I linked, which has a few more details.

I hope there are a few people out there who would enjoy contributing to something like this. Looking forward to working with you!

For those looking to create green-address-style transactions themselves: This is the commit adding the feature to Instawallets Bitcoin daemon:

  https://github.com/javgh/bitcoin/tree/greenaddress

It's a little bit hacky, as it's tailored for Instawallet and has a specific address hard-coded, but is probably still a good place to start if you are looking to duplicate this functionality.

It basically modifies the coin selection method. In the case where a green address transaction is created, it only selects coins from the green address and also makes sure that any change goes back to the address (so we are not running out of funds). In the case where a standard transaction is created, it makes sure to _not_ use coins from the green address, as to have them available for later.

The feature is then made available through the RPC method "sendgreen". Sendgreen expects to be passed a Bitcoin account, which you can use to keep track of how many coins you have ready to send via a green transaction.

This can't be faked, no. The client will consider the transaction as invalid right away and not display it at all.


As far as sending these transactions from Instawallet is considered, this is already in production, yes. The best way of checking for the green address still needs to be worked out though, as the Bitcoin daemon currently provides no easy access to this information. So you might want to wait until that is sorted out before you try to integrate it. Alternatively you can write a nice patch yourself or bug the developers about it. Yay for open source. =)


As was later pointed out, you seem to be confusing some concepts. Orphan blocks have no impact on this approach at all. A green address transaction isn't really all that different from a normal transaction. And those don't disappear either when they end up in an orphaned block. They will just be confirmed with another block instead.


Yes, I plan to add this at some point.


I don't want to have "trust" in the name. It is presumptuous. Whether or not someone trusts a particular address is up to them. It has nothing to do with the address itself, so it shouldn't have a name that pretends so.



I invite you to implement such a protocol and have it gain widespread acceptance. No seriously, I also think that something like this is needed at some point. Not only in the context of green addresses, but for Bitcoin payments in general to be augmented with additional information. But my proposal for the QR codes solves the "users doesn't grok green address concept" in 80 % of all cases and requires minimal modifications to existing tools. That's a valuable thing in itself as well.


Nice idea! It seems to me, that this would be better as a separate site, as it is targeting a different user group with a different set of requirements, as you are pointing out. As such, anyone is free to to start such a site! But you might be interested to hear, that I'm working on a similar idea, however not web-based, but as a standalone tool.