Major Retail Point of Sale Initiative in USA

[davout]

rapidinstant transfer between bitcoin addresses controlled by the hub

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

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.

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

[marcusaurelius]

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

[davout]

Am I missing something basic?

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

[joe]

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

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.

[davout]

Is it easier to just use ripple as the hub network?

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.

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.

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.

[MoonShadow]

Is it easier to just use ripple as the hub network?

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,

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

 I'd like a system where there's no inter-hub debt involved.

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.

[davout]

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.

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.

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.

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.

[MoonShadow]

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.

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)

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

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.

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.

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.

[davout]

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

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

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.

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

[MoonShadow]

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.

[Bruce Wagner]

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

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

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

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.

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

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

[MoonShadow]

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

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

I would say that you pretty much got it.

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

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 was thinking about some time in the future that transactions were no longer cheap for transfering an amount such as a cup of coffee.

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

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.

[Bruce Wagner]

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?

[joe]

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

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?

[Bruce Wagner]

Bruce you are awesome. Your energy is unbounded.
Cant wait to see the new show.

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!   

[Vinnie]

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.

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?

[FreeMoney]

Bruce you are awesome. Your energy is unbounded.
Cant wait to see the new show.

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!   

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.

[Vinnie]

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?

[jgarzik]

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

[rfugger]

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?

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