Major Retail Point of Sale Initiative in USA

[davout]

Well, just implement a trusted bitcoin central instances list in the BC source and you're good to go

[endian7000]

Wow, I didn't realize Bruce had started talking about AH here already. I was planning to wait until there was a full spec proposal and a cool demo, then become an active forum member.

Sorry you had to first hear of my account-hub ideas through Bruce's enthusiastic but semi-technical and semi-correct wording.

So howdy, everyone. This is my first of many forum posts. I was planning to lone-wolf it until a prototype later this week, but I'm looking forward to future collaboration!

Basically, AH provides an ordinary (mybitcoin.com)-like account server with a full API and a mobile client using that API, plus

(1) There's a high-speed side network for broadcasting invoices among the AHs

(2) If you're an AH ("X") making an ordinary bitcoin transfer to another AH ("Y"), you can immediately increase Y's estimate of the probability that the transaction won't fail due to a multi-spend attempt by making an API call to Y and signing (that transfer data + your public key) with your private key and the private key used for the transfer.

That's about it so far.

I'm pretty busy today, but I'll write more this week.

Meanwhile, I pushed more documentaion this morning: https://github.com/tafa/account-hub

Why not re-use the bitcoin-central source code

(1) I hate the AGPL. AH will be under a permissive license.
(2) Competition is a good thing
(3) I wanted to focus specifically on the APIs and protocols at first
(4) (NodeJS + CoffeeScript) is awesome

I ask because I'm also working on an Android app.

A app that communicates with the Bitcoin network, or an app that just acts as a client for account servers?

I'm only doing the latter.

Everything he does, he has committed

Not true. In the public repos, I've only committed documentation so far.

There's implementation work that hasn't been added to those repos. Within a few days, that won't be the case.

...Ripple...

That could be really cool. The current AH services do not involve debt, but AHs could provide debt-related services as well...

I'll read up on all the details of Ripple soon.

[davout]

(1) I hate the AGPL. AH will be under a permissive license.
(2) Competition is a good thing
(3) I wanted to focus specifically on the APIs and protocols at first
(4) (NodeJS + CoffeeScript) is awesome

1. is not set in stone
2. so is cooperation
3. this is not specific to any implementation
4. can't argue with this one i guess...

[endian7000]

(1) I hate the AGPL. AH will be under a permissive license.
(2) Competition is a good thing
(3) I wanted to focus specifically on the APIs and protocols at first
(4) (NodeJS + CoffeeScript) is awesome

1. is not set in stone

2. so is cooperation

Absolutely!

...and with compatible licenses, there can be competing projects which

• borrow code extensively from each other
• are in open discussion with each other
• have their sets of supported APIs overlap

Speaking of which, what are your plans for bitcoin-central's API?

3. this is not specific to any implementation

Right. I meant that I wanted to build an API-server before dealing with a frontend codebase.

4. can't argue with this one i guess...

Come on in -- the coffee's hot! ...and tools will improve drastically during 2011.

[davout]

...and with compatible licenses, there can be competing projects which

• borrow code extensively from each other
• are in open discussion with each other
• have their sets of supported APIs overlap

Speaking of which, what are your plans for bitcoin-central's API?

Simply telling rails it should accept xml/json input too, and *boom* API
APIs pretty much come for free with rails and it's delicious restful way of doing things, throw in a hashed token based authentication and machines will speak to it as easily as humans

Right. I meant that I wanted to build an API-server before dealing with a frontend codebase.

Hmm... Let's play a little game, start documenting your API and see who implements it first

Come on in -- the coffee's hot! ...and tools will improve drastically during 2011.

Haha yea I'll pass on the american coffee :p

[Bruce Wagner]

So awesome that you're here,  "endian7000" !

Sorry if I jumped the gun by talking about AH here.  I assumed you were too busy to jump into the Forum for now... but I'm so glad to see you here.  I know you developers will have LOTS to talk about.  

I watched the video about Ripple.  ( on this page http://ripple-project.org )

And the web-based implementation...  ( https://ripplepay.com )

And the Technical paper here...  ( http://ripple-project.org/decentralizedcurrency.pdf )

It looks like a cool way that Account Hubs could track transactions between themselves.   AH's are only really "loaning" or "guaranteeing" small amounts... between themselves... and only for about 60 minutes... (the time it takes for the transaction to be completely verified on the actual underlying bitcoin network).

Because we're normally talking about small transactions (i.e. coffee, lunch, dry cleaning, vending machines, etc.)...  And because the Bitcoin network WILL clear the transaction within an hour anyway....   The entities who run Account Hubs only have to "trust" each other for VERY SMALL AMOUNTS and for VERY SHORT PERIOD OF TIME.

This means that it'll be VERY easy to establish and build trust relationships between many entities.    Hell, I'll trust anyone in this forum for $20.... for only an Hour....  Right?    Even complete strangers would almost be willing to do that.

This, combined with the FOSS nature of the AH software, is a VERY VERY GOOD THING for quickly building up an amazing network (web) of linked AH's all over the world.

As someone pointed out, if links can be developed to existing well-know entities --- like MtGox.com and MyBitcoin.com --- then almost every AH will instantly be connected to almost every other AH with at least a trusted dollar amount ($20? $50? $100? $1000?).... trusted for only the ONE HOUR it takes to clear the Bitcoin network.

It seems like the concept of the AH + the AH Mobile client app + Ripple + the standard Bitcoin network = a brilliant automated way to transact generally-smaller-dollar-amount transactions instantly --- whether in person, over the phone, or online.

But even if Ripple is not needed for AH's to work.....   It seems like, at the very least, it would be super cool to somehow include, or integrate support for, Ripple into the AH network...   No?

Personally, I think that the Bitcoin network is an ingenious idea.   And the Account Hub with Mobile & POS clients is an ingenious idea.   And Ripple is an ingenious idea.

Combine the 3 and Bitcoin takes over the world.    Over night.

[MoonShadow]

Combine the 3 and Bitcoin takes over the world.    Over night.

Nah, it would take at least a weekend and a slashdotting...

[mizerydearia]

An unnamed friend of mine (not bitbot) replied to this thread suggesting "heh interesting... seems like a large fancy system, for basically replicating mybitcoin..."

[Bruce Wagner]

An unnamed friend of mine (not bitbot) replied to this thread suggesting "heh interesting... seems like a large fancy system, for basically replicating mybitcoin..."

Yep.   Except:

• FOSS
• Decentralized / P2P
• Instantaneous Transactions - even if not on the same node - (which is not true of mybitcoin, btw)
• Mobile Apps
• POS Integration
• Not to mention other potential additions being discussed, like Ripple

MyBitcoin is fantastic for what it is.   But it not FOSS, and it's not Decentralized.    Some people have VERY strong objections to promoting --- not to mention asking all the retailers of the world to reply on --- anything that is not FOSS and decentralized.

[fabianhjr]

I will be working on a Design Document for Ripple P2P and post it as soon as it is ready. I had been talking with marioxcc over IRC lately about this.

[Bruce Wagner]

I woke up this morning with a picture in my mind.

Yesterday, just after reading this thread, I was reading the discussion thread about the need for development of a Bitcoin Web Button --- a simple universal button that could be used to pay, or donate, via Bitcoin, with one click.

After thinking about this problem a bit yesterday....    I woke up this morning with a picture in my mind.

This solution for the need for a "universal web button" --- a "PAY WITH BITCOIN" button, a "DONATE BITCOIN" button --- could, and perhaps SHOULD, be integrated into the Bitcoin AH system.

( By the way, there IS A NEED for instantaneous transactions --- not only at point of sale cash registers and vending machines -- even OVER THE WEB.   For example, consider ordering a pizza online.   Neither the pizza shop, nor you, want to wait the extra hour for your payment to "clear" the bitcoin network...  BEFORE they start making your pizza.   This is true of anything you could order online, with a need for immediate payment, like:   delivery.com, lunch orders, any sort of immediate delivery business, a car service, any sort of business that doesn't want to delay new orders by an extra hour--possibly missing today's shipping deadline, etc., etc. )

Here's what I envision:

I visit a web site (it could be a store or a charity), I order what I want, then I click the PAY WITH BITCOIN button.

That button would take me to a centralized web page (maintain by a non-profit entity, 'the bitcoin foundation'), and it would simply say, "Please select the Bitcoin Account Hub where you have an account (or would like to create an account):" ....from a list of all known Account Hubs.   There would also be a choice called "Other" where the user could enter the URL of an AH not listed there.   (Once enough requests for a new not-listed AH were logged, that new AH could be added to the list on this page.)

The user would simply select the AH where they have an account.    Optionally, if this is their own computer, they could check the checkbox, "Save this as the default AH for all transactions from this computer. Saves it as a cookie."   ( Just below that, there'd also be a button, "Clear Default AH -- Clear the Default AH Cookie from this Computer".)    

( see image 1: http://dl.dropbox.com/u/993053/Created/Business/BitcoinMe/Images%20for%20BitcoinAH%20Discussion%20-%20Shared/BitcoinAH_Web_Button_Result_Page1.jpg )

Anyway....   Upon selecting the AH you use....   You would click CONTINUE....   and you would be taken to a Send Payment screen on that AH.

( Of course, just like Paypal, you would be responsible to always verify the URL of the AH you are on, before initiating anything. )

All the details of this transaction would have been passed through....  from the BUTTON --> the SELECT YOUR AH page --> the actual SEND A PAYMENT page on the AH where your account is held.

The details would show up as pre-filled, but still editable fields:  TO (name), TO (domain), TO (email address), BITCOIN ADDRESS, INVOICE NUMBER (possibly blank), DESCRIPTION (text description), AMOUNT-CURRENCY (i.e. btc, usd, euro, etc.), amount AMOUNT-QUANTITY.    

( see image 2: http://dl.dropbox.com/u/993053/Created/Business/BitcoinMe/Images%20for%20BitcoinAH%20Discussion%20-%20Shared/BitcoinAH_Web_Button_Result_Page2.jpg )

After clicking the SEND PAYMENT button, you would be asked to either LOGIN or SIGN UP on that Account Hub (basically just like Paypal does).

In the future, if you selected to Save your Default AH as a cookie.....   Future clicks of a PAY WITH BITCOIN button, or a DONATE BITCOIN button, would take your directly to the Account Hub YOU have an account with....  directly.....   to their SEND PAYMENT form.    (The exact amount would be listed in Bitcoin, and the amount in other currencies would be clearly labelled, "approximated based on current exchange rate of ____".)

Advantages:

• This solution would provide a universal way of making instantaneous ONLINE payments and donations, using Bitcoin, to any entity online with one click.
• You would still be in full control of which AH you trust and deal with.
• You could even set up and run your Own Personal AH, if you wanted to. (if you don't trust anyone  )
• Other similar services could also be called from that page as well --- like MtGox and MyBitcoin (although those payments would not be instantaneous, unless they add AH capabilities to their sites)

Open AH (Account Hub) integration, into a standard button, could be the solution to this.  It could initiate a payment for ANY bitcoin payment processor of your choice (i.e. MyBitcoin, MyGox, or ANY Bitcoin AH in the world, even your own AH running on your server at home,...)

[davout]

Eww, centralization.

I have better, let us, for the sake of the argument, assume that the bitcoin central code knows how to connect to other instances of the bitcoin central code (which i should probably rename to bitcoin-platform, anyway)

It becomes pretty easy to clear payments between two of these entities based on :
 - trust, or
 - Instance A maintaining a security deposit at instance B, sending a payment from A to B implying taking first from the security deposit, then wait for the transaction to get properly cleared to get the deposit back to its original status.

I'll be working on something like that

[Bruce Wagner]

I know.  Centralization sucks.  But I think that to create a "universal bitcoin button" there needs to be at least one web page that is centrally maintained -- kinda like a FOSS program itself.   Otherwise, there's no way to agree on what that button will actually do.

As for the trust relationship between any sort of 'bitcoin payment processors'/'hub'/'bitcoin centrals'...   I think this has already been designed.   I would not recommend reinventing the wheel.

I've seen two excellent approaches to this in:  the Ripple protocol, and in the proposed BitcoinAH method

It's possible that the BitcoinAH method is already superior, by design, to the Ripple system (for this specific purpose -- instantaneous bitcoin transactions) because of the way it broadcasts it's "promise to pay" to ALL nodes....  then it pays...  then ALL nodes can verify that it 'kept its word' by simply looking at the public bitcoin blockchain.  There's no delay, and every node can track the 'performance record' of all other nodes....  and there's no 'chain reaction'...  the transaction is still directly from node A to node B... with no intermediaries.

One thing to point out:   As I understand it, Ripple is NOT a system of debt.   It's really a system of fast payment processing between entities who don't know/trust each other.  It uses the concept of 'debt/trust/credit limits' among 'friends', to permit IOUs to pass freely through a web of connected nodes.

I don't know if, or how, or why, the Ripple protocol might be somehow used. or incorporated into, or as an overlay on top of, the AH system...  Perhaps to help those running an AH to decide / control which peers to trust, and for how much?   Or for a system of trust between AHs...  

For example, the AH protocol is for making instantaneous transactions between AHs.   And the Ripple component helps AH administrators find and evaluate their "trust levels" of new AH connections...?

[endian7000]

Absolutely. Centralization is unnecessary and insane for an online "Pay with BitCoin" button.

All the merchant site needs to provide the client with is e.g. {hub_url:, bitcoin_address:} and e.g. a BitCoin browser plugin can take it from there.

Though there could be some site(s) with an intro-to-bitcoin-payments page that the button would lead to if you didn't have the plugin.

[Bruce Wagner]

Absolutely. Centralization is unnecessary and insane for an online "Pay with BitCoin" button.

All the merchant site needs to provide the client with is e.g. {hub_url:, bitcoin_address:} and e.g. a BitCoin browser plugin can take it from there.

Though there could be some site(s) with an intro-to-bitcoin-payments page that the button would lead to if you didn't have the plugin.

But remember, that would require a browser plug-in for every user everywhere all the time.  And, if they didn't have a browser plug-in, the ability to go to that intro-to-bitcoin payments page would have to be built-in to every browser everywhere all the time...  (not to mention how hard it might be to get a consensus on WHAT that "intro" page would teach people).

Either way, without some central web page that helps users redirect to their own AH, we would need all the browsers to adopt a standard way of handling the button.  I think that will be a much more difficult proposition --- getting Safari and IE and Firefox and Chrome and Opra and....... to ALL agree and implement ANYTHING in the same way... is a nightmare.   They're unlikely to even acknowledge the existence of Bitcoin at this point.

One example of this is:   Click Add-ons within Firefox.   You're taken to a directory maintained by Mozilla of all Firefox Add-ons.   It is "centralized", yes.  But it is community-maintained.   And as long as you can always select, "Other", "Enter the URL: ________________"    You can't get much more open than that.

Think of the 'centralized web page' as a sort of FOSS program itself.   Community maintained.....  just like the Bitcoin app itself.    Changes must be universally agreed upon, just like changes to the source code of the Bitcoin app itself (or any other FOSS source code).    Then, the only thing that would be 'centralized' would be the hosting of the page.   But couldn't that be hosted on github or ...?

Even if every user in the world added that browser plug-in, they would still have extra work/steps in that they would have to TELL the plug-in which AH they have an account with.  They'd have to make that selection somewhere....  if not on a web page, it would have to be done within the browser plug-in.    And who is going to control all the many different versions of the Bitcoin plug-in... for all the various browsers of the world's computer and phones...?

At the end of day, SOMEBODY maintains it somewhere.   Even if it's Google maintaining the list of plug-ins for Chrome, Mozilla maintaining the plug-ins for Firefox, Microsoft maintaining the add-ons for Internet Explorer, Apple maintaining the plug-ins for Safari, etc., etc.   The 'centralization' simply moves to Google, Mozilla, Microsoft, and Apple!

[endian7000]

This should have been my first post...

hub: a generic term for bitcoin-central, account-hub, ...
A, B: specific hub instances

(the account-hub repo should probably be given a less generic name)

standard account service aspects

• ordinary bitcoin transfers to external bitcoin addresses
• rapid transfer between bitcoin addresses controlled by the hub

(1) API call: attach-identity-to-transfer

• A makes an ordinary bitcoin transfer to B
• A also makes an API call: B.com/api/vX.Y/attach-identity-to-transfer.js

This tells B that A has access to the private key which created that transfer and that A is claiming both that (i) A is the only person with that access and (ii) A will not attempt to multi-spend.

POST /api/vX.Y/attach-identity-to-transfer.js

Code:

Content-Type: application/json
X-Coinholder-Signature: ...TODO standardize...
X-Hub-Signature: ...TODO standardize...

{
    bitcoin_transfer: "...base64-encoded copy of the standard bitcoin transfer data..."
    hub_url: "..."
    hub_public_key: {...TODO standardize...}
}

...where Coinholder is the private key used in the standard bitcoin transfer.

(2) invoices

We could call them "requests", but "invoices" doesn't conflict with "HTTP requests" in our discussion.

An invoice is a JSON object:

Code:

{
    hub_url: "..."
    # Each invoice gets its own bitcoin address:
    bitcoin_address: "..."
    # Care is needed when parsing or generating these strings:
    amount: "10.7582 BTC"
    optional_info: {
        title: "..."
        t: ms since 1970
        lat: "..."
        lng: "..."
    }
}

Hubs will offer a create-invoice API call of some sort to their customers.

(3) invoice broadcasting

Suppose there's an invoice payable to an account on B, but the merchant has no way of getting the invoice directly to the customer. (e.g. for POS-machine/smartphone transfers without using near-field wireless or barcode-scanning)

Later: a well-designed P2P network

Now: B makes an HTTP request to EACH of the other hubs it knows about.

POST /api/vX.Y/post-invoice.js

Code:

Content-Type: application/json
X-Hub-Signature: ...TODO standardize...

{
    invoice: {...invoice...}
}

POST /api/vX.Y/withdraw-invoice.js

Code:

Content-Type: application/json
X-Hub-Signature: ...TODO standardize...

{
    bitcoin_address: "..."
}

So... how do (1), (2), and (3) each sound as additions to what a standard account services offer?

bitcoin-central can probably easily implement (these simple additions) before I implement (them + everything else an account service needs to do)

[endian7000]

It becomes pretty easy to clear payments between two of these entities based on :
 - trust, or
 - Instance A maintaining a security deposit at instance B

Absolutely.

- trust

Exactly what /api/vX.Y/attach-identity-to-transfer.js is trying to help with: bringing the trust requirement from "A will settle this debt" to "A won't attempt to multi-spend in conflict with this transfer"

(Well, that plus getting a copy of the ordinary bitcoin transfer data to B ASAP.)

- Instance A maintaining a security deposit at instance B

This wouldn't need any changes to B. A could open and use an ordinary account on B.

[endian7000]

About "/vX.Y/"...

How about using semver, dropping the Z?

http://semver.org/

[marcusaurelius]

.... a BitCoin browser plugin can take it from there.

It is "centralized", yes.  But it is community-maintained.   And as long as you can always select, "Other", "Enter the URL: ________________"    You can't get much more open than that.

Wrong. Don't use a browser plugin, requiring the user to install s/th is a surefire way to slow down adoption. I'd argue that this is one of the main reasons for the surge in webapps. People don't have to install anything.

Wrong. Don't use a central server, not even a community-maintained one, as this once again creates a central atack point, a single point of failure. Use federated servers like this:
*user clicks on "buy"
*new page loads from the btcAH-server of the merchant
*new page knows who the user is and asks him/her to confirm the purchase
*user confirms
*merchantAH bills userAH

How is step 3 possible? The different AHs need to form a federation, distributing user identification (might well be just an anonymous hash, point is the merchantAH trusts the userAH that the user is real) among them. They need to do that for payment anyway, so why not start a step earlier andu use the federation for user auth. That way the user is always "logged in" into every AH, no matter which one the merchant uses.

This can be down the complicated way via x-site-scripting, or using a system modeled after or actually using http://en.wikipedia.org/wiki/Shibboleth_(Internet2) - every AH is both an identity prover and a service provider trusting all other identity providers within the federation.

No plugin, no central instance.

[rfugger]

Hi.  I'm the founder and main developer on the Ripple project.  Cool discussions going on here.  Something like Ripple would be a great way to allow for a decentralized network of independent account hubs for instantaneous payment.  You might want to implement it as a centralized hub first to get some people using it, work out some of the kinks and figure out exactly what you need, then worry about doing decentralized transactions as another phase.  If there are multiple competing hubs operating, they may all be motivated to work out the best way to interoperate.  I'll be glad to help: ryan@ripplepay.com.

You should also check out http://www.opentransact.org/ for the outward-facing payment API.

Ryan