Bitcoin Forum

Our little "New York City Bitcoin Users Meetup" we created on meetup.com ( http://www.meetup.com/bitcoin/ ) has yielded some major brainstorming, collaboration, and development projects.   For example, there is now a new Bitcoin Users Meetup in the Washington, DC area too. ( http://www.meetup.com/BitcoinDC/ )

Also...  Here in New York City, our little group is already working on quickly developing two FOSS software products:

• Bitcoin POS (& SDK)
• Bitcoin AH

The point of sale software (& SDK) is the component that the retail store merchant runs.
Many Bitcoin POS stations talk to one Bitcoin AH (Account Hub).
The Bitcoin AH processes transactions instantly.

The Bottom Line:

Customer walks into coffee shop.  Orders coffee.  At cash register he says, "I'd like to pay with Bitcoin please".  Merchant touches the "Bitcoin" button on his cash register, the cash register displays, "Code: 736".  Merchant tells customer "Code 736".  The Customer then touches the "Pay" button (on the Bitcoin App on his Android or iPhone), and his app prompts him to touch in the code, "736".  The app displays, "Chelsea Coffee, Mocha Latte large, US$2.57, BTC 8.57".  Customer touches "Yes" button.  Cash register instantly says, "Paid".
Done.

A Bit about How it Works:

On the Bitcoin AH ( account hub ) side, the coffee shop's POS system sends an "invoice" to it.... which the AH matches to the customer's Pay command by cordinating geolocation + time + unique 3 digit code. 

( If the Geolocations do not match, and only the Time and the Code match, an additional confirmation prompt will pop up, so that telephone orders could also be processed with this same system.  For example, it will pop up a message to say, "You are in Toledo, OH and you are about to make a payment to London, England, UK. Is this correct?" )

All of this software will be free open source.

Meanwhile, we are also working with 3 point of sale / cash register vendors.... including 2 of the most used restaurant / coffee shop cash register systems in Manhattan... to get them to include the Bitcoin POS components.

So far, 1 has already agreed to do so.

:-)

This sounds amazing!

I am in tight with a community supported cafe/community center here in Portland, OR. I could probably get them on board, even if its only me who uses BTC at first. I help with their accounting, business planning, etc, and spend about $25 a week at the cafe, so I could probably convince them :). Keep me posted!

Outstanding, Bruce!

I was wondering where you had disappeared to lately.  I didn't think that someone with so much enthusiasim would simply just drop off the forum.

Is there a website that we could go and look at these projects?

Sounds good.

I am curious about your Android/iPhone apps though. I take it you're already making them, or ... ?

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

That's really cool bruce!
Why don't we have an european bruce wagner??

Maybe we should instead fund the real, one-and-only Bruce a flight ticket from NY to London.
Or to Paris, Berlin, Madrid, Rome, Athens, etc together with a corresponding language course?

Hah, that would be a fun bounty!
I pledge free translation services!

Me too in Lausanne/Geneve (German or French) but anyhow the key people in the target audience speak English here as well.

Maybe this is the start of the Bruce Wagner Europe Tour 2011 (sorry Bruce it's just too funny to creatively brainstorm on this. I'll stop anytime)

LOL

Hey, I'm GLOBAL, Baby!    :)

First stop on the "Bruce Wagner Europe Tour 2011" is definite.....

• Barcelona ---> (dates to be announced, some time around... between 13-23 March) 

Can you guys make it there then?

Hey this is really cool! Keep us updated. I believe there is a pledge for an Android app such as this and the POS. Let me check the Project Development section.

It really sounds like you have got a lot of great ideas and might actually be making progress.  I would like to hear how this develops.  Also the NY meetup is intriguing.  Where do you do this I might not be too far away.

NFC seems to be an upcoming technology particularly suited to this type of thing.

This is my email... planning our weekly skype conference call.
A few of us hold a weekly skype conference call to brainstorm and discuss our Bitcoin projects....
_________

Tuesday's good for me too.
Wow.  Tuesday's a big Bitcoin day for me.
Earlier Tuesday afternoon, Ed & I will be meeting Jed of MtGox (again) at Andrew's office.
We'll be introducing those two guys for the first time, and talking all about the POS / AH / Mobile Apps.... and how they will tie in to MtGox for instant US$ or Euro conversion, and daily merchant bank deposits. 
Also, late Tuesday evening I'll be doing another "radio interview" about Bitcoin for that Libertarian podcast. (They contacted me a few weeks ago.)
And... last night (about 12 hours ago), we had our monthly Bitcoin Users Meetup.  ( By the way, I highly recommend starting one on Meetup.com !  It's been a gold mine for building a network of awesome local Bitcoin contacts! )
We met two new people - Ravi and Ivy - both brand new to Bitcoin.  It was sort of a "Bitcoin 101" beginners class....  But the brainstorming ended with some new serious commitments to work together on a grassroots promotion campaign.  The idea is:   We'll target a group of merchants, and use social engineering to convince them that they really want to accept Bitcoin.
Ivy is really enthusiastic about leading the charge on this project to market Bitcoin acceptance to local brick & mortar merchants, and she & I totally see eye to eye on the most effective ways to sell them on it. Ed wants to help with the calls too. ( Random customers call and ask if they accept Bitcoin yet. Sometimes asking for the manager, or owner. Other times not. Sometimes male. Sometimes female. Consistently, every few days. Also, we call or stop in person with a complete Bitcoin Merchant package - almost like an informational Press Kit - a Bitcoin Merchant Kit.  This gives them something physical to hold on to, and a business card, and the basic information about the advantages of Bitcoin and links to BitcoinMe.com ... so, as they keep getting a continuous stream of emails and phone calls from customers asking if they accept Bitcoin, they know who to call... for more information and to pursue it.
We figure we'll start by targeting Only independent coffee shops, Only in one neighborhood.  Hell's Kitchen (which is our own neighborhood).
As soon as we get the first business to accept Bitcoin, we'll begin holding weekly meetups THERE.... to support their business by spending Bitcoins there.
Also, by sticking to one type of business, in one area, it'll be an easier sell.  "But why doesn't Cuppa Joe accept Bitcoin? All the other coffee shops here in the neighborhood do. Wisdom Coffee does. The Normal Grind does. Why don't you?"
After penetration of one neighborhood, we expand to coffee shops in other neighborhoods...
Eventually, we expand to restaurants...    Then to independent grocery stores, etc.
A grass roots movement.... a new local economy.
It won't be long before the media gets wind of it, and decides to do a story about it for the newspaper or local tv...  spreading the word and spawning more growth even faster.
The idea is:   We want to get every merchant in the country to accept Bitcoin as fast as possible -- before The Fed even notices.  It'll happen so fast, they won't know what hit them!
Of course, it's crucial that our FOSS software systems -- the point of sale system sdk, account hub, and smartphone apps, must be ready to implement FAST... in order for this plan to work.   That's why Andrew's development work is so essential. 
And my own project of working with the major cash register/point of sale vendors to incorporate Bitcoin POS into their systems.... is also crucial.  We've already established a working relationship with one such POS vendor, and they've agreed to include our Bitcoin POS software into their system!  It's called ShopKeep.com
Soon.... Every merchant in the world who uses ShopKeep.com will automatically be set up to accept Bitcoin if they choose to.  Their entire cash register software will be going open source soon.
The other two major POS vendor companies I plan to reach out to... are Micros and Aloha.
If all of us work hard on this.... we really WILL change the world.  ....very quickly.
As Andrew gets his software to an alpha state, I'm sure he'll publish it on his githib, so all the developers out there all over the world can begin scouring it, reviewing it, suggesting improvements, studying it for security bugs, etc.
What we do here in New York City -- the plan is -- should be a cookie-cutter prototype for exactly what YOU will do in your own town...  Petaluma California, Bern Switzerland, Taipei Taiwan, London England, Hamburg Germany, ...and the main street merchants and shopkeepers of YOUR town.
Exciting stuff.
PS - Ed and I are happy to see our investment in buying Bitcoins going up in value.  It's growing much faster than numismatic gold and silver coins are!
PPS - Ed and I are planning to launch a new Bitcoin "tv talk show" --- a weely video netcast that's a talk show all about Bitcoin.  We'll have guests -- both locally here in New York, and globally via skype video.   Cool eh!?!

Bruce you are awesome. Your energy is unbounded.

Cant wait to see the new show.

I encourage EVERYONE to go to http://bitcoin.meetup.com and sign up as "I am interested in a Bitcoin Meet-up in my area...

Our NYC Bitcoin Meet-up is held here at Ed & I's apartment,  here in Midtown Manhattan... for now.  As we outgrow our apartment, we'll most likely begin meeting at a local restaurant or coffee shop that accepts Bitcoin ( to support them ).  Last night was only our 2nd monthly Meet-up.

Absolutely!   You're in charge of the Portland initiative.
Keep in touch with me....  and I'll keep you abreast of the status of the POS system, and its readiness.
I HIGHLY recommend creating a Portland Bitcoin Meet-up on Meetup.com and schedule a regular monthly Meetup to be held at that same cafe you mentioned!

This reply just came in from Andrew...


And regarding...


Thanks, creighto.

As for a place to see the progress of the project's code development.  See Andrew's github page: 

That's Great, mh !    I encourage you to work together with Andrew and see how your work can benefit each other's work.   Everything he does, he has committed, will definitely be FOSS.   See his github page:  https://gist.github.com/767423

Hey, is the app 2-way transaction enabled? Ex, could I pay|lend|gift bitcoins to a friend?

I like the way you are targeting a local area where you plan to have Bitcoin-spending customers lined up.  This is crucial since merchants will quickly lose interest if they go to the trouble of accepting Bitcoin and then don't see any business. 

Sounds good! I'll get started working on this.

Yes.  Absolutely.

By the way, to explain a little more about this system:  The Bitcoin AH (Account Hub) + Bitcoin POS (Point of Sale SDK) + The Bitcoin Mobile Apps = the complete system

The primary problem it solves is:   The need for instantaneous transfer

This way, there's no waiting for an hour for a transaction to clear (get verified by 7+ standard bitcoin nodes).  The transaction happens instantly.... so there's no waiting when you buy a large cafe latte...  and there's a line of people waiting behind you.

However, yes, the Mobile App will let you pay anyone who has an account on the Bitcoin Account Hub.  

I'm going to recommend that Andrew also include the capability to pay NON-Bitcoin AH members using the standard Bitcoin network... as long as the user is notified of, and approves of, the necessary delay in the transaction fully clearing.

The "Bitcoin Account Hub" acts very similarly to a MyBitcoin.com-type service.   Both parties must have an active account on a trusted "Bitcoin AH" in order for the transaction to clear instantly.

The main differences are:  

• All of the software is to be completely FOSS (Free Open Source Software)
• Anyone can set up a Bitcoin AH Account Hub (community groups, church groups, university IT labs, Linux user groups, merchants, anyone!)
• Multiple Account Hubs can establish "trust relationships" with each other (this extends the network to all account holders of all trusted networks)
• Transactions always happen instantly - no matter which Bitcoin AH the two parties have accounts on (unless the recipient doesn't have an AH account; in which case the normal Bitcoin network is used)
• The Mobile Apps will have the same abilities to easily make AND RECEIVE transactions, just like the POS system can, and works exactly the same way:  The recipient touches "RECEIVE" button on his phone app, then enters a NAME OF RECIPIENT, and a TEXT DESCRIPTION and an AMOUNT, in either US$ or Euro or Bitcoin, then touches OK.  He sees, "Code 953". The recipient then tells the payer verbally, "The code is 953."  Next, the payer touches "PAY" button on his phone app, then he see, "Enter Code", he enters 9-5-3, then he sees the NAME OF RECIPIENT, the TEXT DESCRIPTION, and the AMOUNT listed in US$ and Euros and BTC equivalents. He touches PAY again to confirm. The payment is instantly acknowledged on both devices.
• The Mobile App might also have extra features, like the ability to Display your Bitcoin Address as a QR Code ~and/or~ Scan someone else's Bitcoin Address as a QR Code (for non-Account Hub transactions; since the recipient's Bitcoin Address is not needed if both parties have an AH account -- the transaction is connected by time + 3-digit-confirmation-code + confirmation screen with transaction details for sender to acknowledge)
• Everything you can do with the Mobile App, can also be done with a web browser via the web interface to the Account Hub

Sound good?   Thoughts?    Ideas?

Can we help you with anything? How is the progress? This is really awesome. :)

The more I think about it...

The more I think that we should develop this in three phases:


PHASE ONE

First, the Bitcoin AH which does everything MyBitcoin.com can do and more... but AH-style...  And, all transactions can be completed using any WEB BROWSER via the internet and the AH's Web Interface.

This way, anyone can use Bitcoin AH ~now~ immediately...  via any computer or phone with a web browser...  from ANYWHERE....  GLOBALLY....   (even if there's only one operational AH at the moment).

Also, designed from the ground up to inter-operate with other Bitcoin AH (account hubs) running this identical software, with it's own internal database of "trusted relationships" between other AH's.


PHASE TWO

Second, the Bitcoin Mobile App.....   which does everything the web interface does...  plus a few other additional mobile features, like QR Codes.   

This way, merchants could actually use the Mobile App ~or~ any Web Browser.....   as their POS solution.....   for now.    Instantly.    They could ring up the sale using some unused "Comp Sale" button or code...  which would indicate to their internal accounts that it's a Bitcoin transaction...   and then they'd just ring up the RECEIVE transaction using either:   The Mobil App on a phone, or the AH Web Interface on a computer or a phone.


PHASE THREE

Third, the Bitcoin POS SDK.     

The POS software would also contain built-in calls to API's to automatically upload Bitcoin to MtGox (and/or potentially any other exchange sites), and initiate the sale of those Bitcoins for USD or Euros, and initiate the request for a direct bank deposit of the USD or Euros into the merchant's bank account.

_____

Since merchants could begin transacting business after only Phase One (above) is complete....  That's gotta be first.    Of course, friends could also make instant transactions to each other at this point too.

Phase Two would add lots more convenience....  and mobility.

Phase Three would just be the slick professionalism for merchant processing on a large scale --- the icing on the cake.

Also, I think that it's important that the Payment Process ALWAYS be consistent.... and work the same way.... on all platforms....  for ease of use, and easy consumer adoption....

• Recipient/Merchant touches the RECEIVE button.
• Recipient/Merchant is asked to enter these text fields:  NAME, DESCRIPTION, AMOUNT, USD/EUR/BTC  (if on web or phone, cash register POS-SDK does not enter these automatically).
• Recipient/Merchant's display shows, "Confirm Code 745" (for example).
• Recipient/Merchant verbally tells the Payer/Customer the confirm code.
• Payer/Customer touches PAY button.
• Payer/Customer's display shows, "Enter the Confirm Code".
• Payer/Customer enters 745 (for example).
• Payer/Customer sees the correct information displayed for: NAME, DESCRIPTION, AMOUNT, USD/EUR/BTC and sees, "OK TO PAY"
• Payer/Customer touches "OK TO PAY".
• Both the Recipient/Merchant ~and~ the Payer/Customer see, "Payment Confirmed" on their respective displays.

..... no matter whether either party is using...

• The Web Interface for the AH,
• The Mobile App, or
• The POS SDK integration
• One "Receive" request, and one matching "Payment" request, makes one complete Transaction, once confirmed.  These requests are matched up by the system based on near enough:  CURRENT TIME + CONFIRM CODE + GEOLOCATION

If the CURRENT TIME + CONFIRM CODE agree.....   but the GEOLOCATION is more than 5 miles off, one additional confirmation dialog is displayed for the Payer/Customer.  For example, "You are near Cleveland Ohio USA and you are about to send a payment to Bangkok Thailand. Is this correct?"    The Payer/Customer must touch, "YES" to proceed with making the payment.

Whatta ya think?

Agree?

that is not the right way to do it. specify a protocol that all AH's have to adhere to, do NOT specify the software they have to run.

Maybe you would like to get the Ripple P2P implementation up and running instead of the Account Hub.
http://ripple-project.org/Protocol/Index (http://ripple-project.org/Protocol/Index)

If you get it implemented I will send you 10 BTC. :)
(Will add more as I mine)

EDIT: BTW, feel free to improve the design. :)

Yes.  You are correct.   That's exactly correct.   I misspoke when I said "running the identical software".  I should have said, "running the AH Protocol".

I don't really understand what Ripple is....  but I will pass this suggestion on to Andrew.    Is Ripple something that would be used to replace the AH Protocol?

An update from Andrew...


Bruce:   


Andrew:

Now Ripple is a F2F network of IOUs which allows payment between unknow parties if a route can be build of trusted peers between them making payments safe and easy. Totally decentralized also!

EDIT: Here it is a PDF explaining it at a glance with a Technical FAQ. http://ripple-project.org/decentralizedcurrency.pdf (http://ripple-project.org/decentralizedcurrency.pdf)
EDIT2: /offtopic would you mind me translating BitcoinMe to spanish and making fliers/leaflets/etc?

More answers from Andrew....

Bruce:


Andrew:


Bruce:


Andrew:


Bruce:


Andrew:

Would LOVE it.   Email me at email@bitcoinme.com   :)    Thanks!      Note:  Pardon problem with images displaying on the site.  I am fixing that asap.

"7+ standard bitcoin nodes" has nothing to do with anything.

Transactions are bundled into blocks, one block every 10 minutes.

One block == one confirmation.

It is standard to wait six blocks (6 * 10 == 1 hour) to be sure your transaction is confirmed, but see the snack machine thread (http://bitcointalk.org/index.php?topic=423.0;all) for discussion of shorter wait times.

bruce, I urge you to read the PDF, you will love it because it does what you want the AH to do + it is decentralized completely. :) This is being discussed and instead of starting from scratch you can help them implement it or improve the design at least. I think there is also a video in the main page of the project which pretty much sums it up in english in 5 minutes. So, good night!
/me isn't ready to get back to school. :(

Near field communication seems like a very promising technology, however it doesn't yet exist in most cash register or smartphone hardware.

It will certainly be possible to add support for it in the future though.

A couple suggestions for the mobile app - cash register communication protocal:

1. Bluetooth support to eliminate entering of codes
2. If bluetooth is not available, then the customer's phone should generate a random number to give to the clerk instead of the other way around. The clerk is better prepared to enter codes (on an actual keyboard) than the customer on their phone's touch screen.
3. Account numbers. If the customer can remember a 10-digit account number they have on the Account Hub network, then they can recite it to the clerk at the POS. When they enter it into the cash register, the customer's android phone will wake up and ask for confirmation. This would eliminate the need for the customer to waste time getting in to the app. App would wake up instead.
4. For customers without android phones, solution #3 means that the AH network could make a regular call to the customer for confirmation.


Regarding Ripple Pay and the hub network, a couple quick ideas on how to implement the hub client:
1. Start with a standard Ripple Pay client
2. Modify it to be knowledgeable about incoming bitcoin transactions via the json api with bitcoin, and to be able to send bitcoin transactions.
3. When Hub A (customer's hub) needs to send money immediately to Hub C (store's hub), and there is a trust path through Hub B, then:
i. Hub A transmits the IOU through the normal ripple pay channels (not bitcoin)
ii. Hub C is now satisfied that it holds a RipplePay IOU against Hub B so Hub C can approve the transaction at the cash register.
iii. Each hub constantly checks and resolves all RipplePay obligations via bitcoin payments to its peers. Likewise, when a hub receives a bitcoin payment from a peer and it reaches the 6 confirmation level, it updates the obligation through RipplePay as being paid.
IMPORTANT: A hub's outgoing bitcoin payments must be re-sent if they used money from recent incoming payments that were reversed by the sender! Remember, the whole idea behind ripple pay is to push debt through a trust chain. If upstream does not send you the money, you still must send your payments downstream.

This is just a start Im sure theres a lot more improvements that can be made to get RipplePay working with bitcoin. For example leveraging the fact that all bitcoin transactions are publicly available so everyone will know if a particular hub on the ripplepay network cheats.

Yeah I love leveraging Ripple here! An important point to make is that there's a good chance there won't be a trust network between any random cafe and customer initially. This is where a mybitcoin.com type clearinghouse could come in handy. If both customer and merchant trust mybitcoin, then they're good to go.

What's really cool is that mybitcoin could have a trust relationship with a bunch of other "banks", and then if the merchant and the customer trust any one of those banks (and they don't have to be both trust the same bank) they can instantly transact with each other.

Why redevelop a bitcoin handling platform from scratch ?

Why not re-use the bitcoin-central source code and simply tweak a couple of things to suit the AH spec ?

If you want to do that you'll have a couple more skilled coding hands.

Just saying ...

Because it is different to an extend. Ripple is for IOUs between trusted parties and Bitcoins for a limited quantity commodity. Ripple users could issue an IOU 5 btc by instance or any other currency/commodity/good/service.

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

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


(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


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.


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.


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.

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

:)


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?


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


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

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

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

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

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.

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

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.

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

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

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

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

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!

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

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


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

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

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

Absolutely.


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



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

About "/vX.Y/"...

How about using semver, dropping the Z?

http://semver.org/

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.

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

:)

The rest of your discussion sounds pretty complicated for a pretty much basic flow :
1. Identify which hub the X account belongs to
2. post a request for payment or invoice to the paying hub
3. redirect and have the user confirm
4. paying hub sends payment through the network (no need to send transaction data back since propagation is almost instant on the bitcoin network anyway, and could even be really instant by forcing hubs to interconnect directly)
5. payment is backed by paying hub deposit on payee's hub until the transaction is confirmed enough, deposits won't be required if some level of trust exists, otherwise they allow zero-trust policy



You don't need complicated things like identity federation or things like that, it all simply boils down to "i'm hub A, i need to map this account number to another hub so i can send it an invoice, do i know the mapping from my own database? yes? fine, confirmation, invoice. I don't? fine i broadcast the request to other hubs, they'll know for sure"

This is all a pretty simple extension of an SCI, which is btw on top of my list now :)

@davout: you don't want the user to enter his/her account number everytime they want to buy s/th, do you? If not, how does AHa know the account number of the user who just clicked on 'buy'? That is the problem federation is supposed to solve. And as I said federation is needed anyway.

Am I missing something basic?

Yes my friend, you're missing the distinction between
 - Necessary, and
 - Nice to have

:)

Is it easier to just use ripple as the hub network? Ripple will give us an API that we can use to send/receive money to other hubs. The only thing left for us to do is about 300 lines of code for a small API library to facilitate the idea of multiple users on each hub, the sending of invoices, and user confirmations of invoices:
- sendInvoice(fromUser, toUser, toHubDNS)
- sendPayment(fromUser, toUser, toHubDNS)
- payInvoice(invoiceID)
- getReceivedInvoices()
- getReceivedBy(user)
- getPaymentStatusOfSentInvoice(invoiceID)
- synchronizeRippleAccountsWithBitcoin()

The store's POS or the website's universal bitcoin payment button backend code is then built around the above API calls. The customer's bank account website also uses the same API on the back end.


I envision the following scenario:

Users' account numbers are of the form davout@hub.mybitcoin.com or joe_1@hub.mtgox.com. People's hub will be like their bank, so people will be comfortable with this email style account number. The part after the at sign is the DNS name of the hub's server.

So I go to amazon.com, click their universal bitcoin button, and tell amazon to charge my account at joe_1@hub.mtgox.com for my 25 BTC purchase. Amazon will ask hub.mtgox.com to send 25 BTC from its joe_1 account. Mtgox will text me on my phone for confirmation. When I confirm mtgox will send a ripplepay IOU to amazon's hub. Now amazon can start shipping my order.

Maybe, I know my code well, so I'll start from there ;)
Natural selection will do the rest
I think (but I can be completely wrong here since I'm too lazy to go find out) that ripple is based on debt, I'd like a system where there's no inter-hub debt involved.

I thought about the "@hub.tld" part too, it could be a nice optional convenience to help the payee's hub with the task of finding the payers hub.

From what I can tell, it's similar to a LETS mutual trust network.  Replacing the central ledger with a trust network instead.


I have doubts that is possible on a large scale.  The only way that I could think of that might work is if every hub had an account with a security deposit on every other hub.  Not only would that lock up a very large, and exponentially growing with the rate of new hub growth, amount of funds; hub owners still end up trusting that a malicious hub won't participate in a fraud to steal the security deposits.  Hubs could have a "settlement hour" once a day wherein they transfer bitcoins in order to balance out ripple debts that have accumulated across the day, with a max debt limit that if reached would trigger a bitcoin transfer immediately.  Once upon a time, this is similar to how gold standard banks would handle accepting each other's banknotes; but I can still think of complex frauds that a malicious hub could attempt against the other hubs.

I don't think it would be such a big problem, because :
 - There probably won't be that much hubs,
 - A scheme could be designed where deposits don't have to be given to each connected hub, A pays to B, but B hasn't a deposit for A, but C has a deposit for A that it acknowledge it will give to B would A fail to finalize the transfer (didn't think this one through but could be something like that)
 - Deposits would be required only to chop off the statistical variance of inter-hub debt (assuming accounts and transfers are ditributed evenly accross most hubs)
 - Amounts could get smaller and get adjusted with average transfer sizes

So yes, I think there's more thinking to be done to come up with an elegant and rock solid scheme but I think this could be a good way.

Yea, but account hubs can vanish and pop back up in no time, I think the trust-and-debt path is a dangerous one, and I'd rather avoid it.

You've basicly just described the Ripple web of trust.  Deposits really just raise the bar of trust threshold.

Honestly, I don't think that a trust-and-debit path alters the root problems, but it's not my place to tell you how to raise your baby.  I really was just trying to offer an insight.  I do still think that Ripple could save you duplication of work in your web of trust.

My goal would be to eliminate the need for trust, that what I'm aiming for :)

Hehe, it isn't really *my* baby anymore now :)
Yeah, I'll educate myself some more about Ripple before actually coding anything

I was thinking more about this account hub idea on my commute, and relised that this is basicly an example of the bitcoin 'supernode' concept discussed by myself and others in much older threads.  You could remove the need for a web of trust altogether by depending entirely on the merits of the bitcoin network itself, completely removing the web-of-trust fraud vectors altogether.

The way such an account hub would work is this...

Member merchants pay a small monthly fee to the hub, the hub 'verifies' or denys transactions based on the willingness of the hub owner to insure the transaction against a successful fraud attempt.

When the member has a customer who desires to pay with bitcoin, the account hub does these things...

1)  Checks to see if the customer is a member on the hub, if yes jump to 7

2)  Checks the transaction presented for valitity against it's own blockchain,  if valid it then....

3)  Ships the transaction out to the network, if appropriate.

4)  Checks to see if there are any transactions in the queue that could be a double spend attempt, or any other type of transaction based fraud that we can think of in the future.

5)  Waits a few seconds to see if any other transactions come in that could also be a double spend attempt, if not...

6)  Checks with it's own 'watchdog' process, to reduce the risks of a blockchain split/takeover at the moment of sale.

7)  Approve or deny the insurance against the transaction, accepting the transaction anyway could then be up to the merchant.  Perhaps the customer is a regular, or buying something of such trivial value that it's not worth a recheck.  

You could still impliment a Ripple-like web-of-trust as well, but I don't think that would be very valuable until the cost of a transaction has risen to the point that it is advantagous for hub owners to seek ways of avoiding blockchain transactions for small, individual payments.

EDIT:  Thinking further, even the wait of a few seconds would be irrelevant, for if you pushed the transaction to all of your own connected peers, and they all accepted it as valid, you would not ever see any conflicting transactions for your peers wouldn't forward such a transaction after seeing your's first.  An account hub would want to have as many bitcoin connections, to as many major generators and other hubs, as would be possible.  In order to push their transaction across the bitcoin network as quickly as possible, thereby reducing the risks of a double spend fraud turning out poorly for *them*.  An account hub would want to have the ability to know if one of it's own peers had rejected the submitted transaction.

I totally agree that that describes Ripple's web of trust.  

Deposits, however, I don't really get.   Not sure how that adds anything.   If I have $1000 of yours.  And you have $1000 of mine.   Does that make me trust you?   ( If complete strangers exchange $100 bills, are they now trusting of one another?? )   If you deplete the $1000 I have that belongs to you (by me guaranteeing your expenses)...  then you refuse to return the $1000 of mine that you have...   We're right back to where we started.   I'm trusting you for $1000.   And you're trusting me for $1000.   The result would be EXACTLY the same thing as if we both agreed to simply....  "trust each other for up to $1000"...  (except we wouldn't need to tie up $2000 of capital to do it).   There's no need to have deposits with each other.   Mutual deposits of the same amount simply "cancel themselves out" anyway.   Or am I totally lost??


Yes, but....   The hubs' "settlement hour" could happen 10,000 times a day.... 5 milliseconds after the actual transaction.  Then the VERIFICATION that the "settlement" has cleared, would happen 5 minutes after the transaction, by simply looking at the normal bitcoin block chain.  (or 60 minutes after)... but...  No need to wait for a once-a-day event.


I think trust cannot be completely eliminated 100%... when offering instant transfers on a network that takes 60 minutes for transactions to be 100% "cleared".  

However, endian7000's scheme of "signing the transaction"... by the "owner" of that Bitcoin... (AH-x)  and Broadcasting, in effect, a "promise", to all other AH's on the network, like:  

"I promise to transfer these exact bitcoins (block number) from myself (AH-x's bitcoin address) to this other AH (AH-y's bitcoin address) at this very moment, and not attempt to double-spend them."

Then, every AH on the network could -- within only a couple of minutes -- be able to independently VERIFY that, "AH-x kept its promise."   .....or....   "AH-x did NOT keep its promise."  

The entire AH network would know, within only a few minutes, that "AH-x is NOT keeping its promise." ... for whatever reason.   ....and they could immediately stop accepting "transaction promises" (as instant transactions) from that AH-x --- processing them only as the slow traditional bitcoin method until AH-x is back online and the transactional failure is sufficiently explained...  and/or, it's later promises are now being kept (again, the entire AH network would already KNOW -- by independently verifying them -- whether AH-x's promises are being kept... at any given point in time).

I would say that you pretty much got it.


I was thinking about some time in the future that transactions were no longer cheap for transfering an amount such as a cup of coffee.


That's pretty much just an electronic check system.  I'd work well, but once transactions are no longer cheap for fast confirmations, then the AH network is going to have to wait longer to see that promise kept.

Sort of a sidebar question, but still related to the development of AH...

We have a Tonido Plug.

I wonder if the AH could / should be integrated with any other FOSS projects like:

Tonido (the FOSS Dropbox)
Amahi (the FOSS server)
Tiki.org (the FOSS Groupware/CMS)
Drupal (another FOSS CMS)
Others?

Rfugger, could you help clear up a misunderstanding I am having about Ripplepay? When I read your post a few days ago, I jumped to the conclusion that Ripplepay software would form a decentralized trust network. I suggested that we cut out development time by using Ripplepay for all the heavy lifting of keeping track of debts across a trust network for Bitcoin Account Hubs. On looking into Ripplepay more closely, it looks like it is not decentralized; instead, it is a centralized website that keeps track of a decentralized trust network. For our purposes, we need no central point of failure. The theory behind the ripplepay trust network still does, however, provide the basis for what we need to do.

Is there any decentralized implementation for a Ripplepay network?

Thanks!   :)

By the way, as an update:   The new show is called, "The Bitcoin Show".   It will be LIVE every week....  every Friday.... at 10AM to 11AM Easter Time (New York City time).

You will be able to watch LIVE, and join and ask questions, etc., in the LIVE chatroom, starting this coming Friday, January 21, 2011.... at 10am....   at http://onlyonetv.com

If you have suggestions for Guests we should interview about any aspect of Bitcoin, email me:  bruce@brucewagner.com

If you can't make it online at that time, it will be available for streaming or downloading, later, on that same site.

See you there!    :)

Question: what will the hardware for the POS be comprised of and how much will it cost? Will it easily integrate with current cash register systems?

That's awesome. I'm watching the show with Yehonathan and Lyrik right now.

It'll be 5AM here so I probably won't be able to watch live, but I'll see it afterwards for sure.

Another quick question:

The cafe I'm talking to is very interested, but wants to know what the hardware will cost. The same person who runs the cafe also runs a food buyers club where orders are processed online. They currently use paypal or check to process payments. Would this retail payment system jive with an online system? Could people ordering bulk food online pay with their smartphone?

Right now: yes, if you are highly technical and can obtain the full-bitcoin-for-Android build.

In the future:  yes, people are working hard on an easy bitcoin smartphone app

Ripplepay is a single-server implementation of the Ripple decentralized payment concept.  There's no distributed implementation yet.  Designs for a distributed protocol are here:

http://ripple-project.org/Protocol/Index

Ryan

Interesting...I had a hard time understanding the concepts...but nevertheless interesting.

Hey, I would like to join. I can make it to Barcelona on 13-14 March.

Any way for us to listen to a replay?

I support the notion of having replays or uploaded it so I can watch it after school!

Funny how I never ran into this system while I was living in New York!
Do you know of any similar initiatives or companies providing this service in Latin America?? I'm talking specifically about the POS system. Could be a great service to provide the customers!

Progress Report? Do you need help coding and debugging?

Yeah, what's going on with this? It seems to be the best way to get retailers to use bitcoins (account hubs)

I would also love to see this, though I am not sure about the proprietary app part.

Have there been any progressive developments on a POS implementation?

Hey, I live in Portland! Where is this cafe? Have they set up a POS kiosk yet?

There's no distributed implementation of ripple. But you don't need a complete for two AH to trust each other.
They just have to be legally liable between them. Note that they don't need to be directly liable, a web of trust can be used.
For example, Payer has an account with AH1 and seller with AH2.
At the moment of the payment a message is sent to AH2 with the form:

Do you trust AH1?

If it's not in the AH2 list of trusted AH, he can ask the same question to the AH in his list and they (before answering) can ask other AHs too.
There's only the need for a path of trust from AH2 to AH1.

You can read an interesting document about the problems for distributing ripple here:

https://groups.google.com/group/rippleusers/browse_thread/thread/acb472ad92e77d2c?hl=es

There's debate in ripple about how to adapt bitcoin technology to implement a distributed ripple. If it's done, maybe the time for ripple transaction verification doesn't fit with your protocol. Ryan has also an idea for real-time confirmation here:

http://bitcointalk.org/index.php?topic=4382.msg64109#msg64109

I don't know if its feasible.

I'm sorry. Here's the beginning of the thread:

http://bitcointalk.org/index.php?topic=4382.0

Hey Bruce,

is there any news on this? I remember everyone being very excited about this in January.

Did this die? Why did this die?

Best,

marcusaurelius

I second Marcus' question. I was this close to asking the same thing yesterday.

I was going to ask it today, after reading that bitcoin central is now open source and allows instant payments between accounts.
Just remembered the Account Hub. I think is a crucial project for bitcoin acceptance.

Am I the only one that caught this?

Don't you mean US$2.57, BTC 0.0857?

I doubt BTC will be worth $0.29 anytime in the future...  ;)

you caught what?
thats an example from january with a price from january.