Topic: A proposal for fast POS transactions with Bitcoin (Read 8408 times)

Thank you for the videos. I think I understand OT better now.
If the market could be extended to support "composite trades", ripple could be implemented within Open transactions.
This would be nice for bitcoin instant payments.
Please, let me know if you're interested in implementing ripple inside OT. I think that it would be relatively easy, given the functionalities that OT already has.

I've read your entire post, but to be honest I did not understand it. The part I quoted is the only part I could interpret in such a way that it applies to the discussion in this thread.

Based on your response, I now believe I even misunderstood that part.

FYI, I just posted a video walkthru of OT, which will probably help you a lot in understanding the concepts, and what it actually does.

Check it out here: http://vimeo.com/28141679

No offense, but did you read that?


If you like it I'm ready to contribute poscoin.com to this project. Just PM me and I'll gladly change DNS settings to point to your hosting account.

I updated the concept description, and converted it to PDF. You can find the most recent one here. Please watch the date: I'll overwrite the document when I finish a new version. If you want to keep the current version, please keep a back-up on your own system.


Is this an advice on how to name this system? In that case, thanks for the help. However, suggestions like "do something like this" are more useful than "don't do something like this".

About Open Transactions
I think that Open Transactions is a much broader concept than my payment system. It seems to have more features, but having more features also has a disadvantage: if it also makes the software more complex, this makes it more difficult to have the source code reviewed by independent parties. I believe that having independent code reviews, and hence having clear, simple, publicly available source code are very important for building trust in software.

Maybe OT solves certain problems in a different way than the concept described by me. In that case: please point me to the disadvantages / flaws in my approach, and explain me how to do better.

Maybe OT can solve certain problems in the same way as I do. In other words: maybe my concepts can be implemented on top of OT. Even if that is the case, I will initially not use OT, for the sake of simplicity (see above reasoning). However, I will make the software layered in such a way that the top-level layer can easily be re-used on top of another bottom-layer. For instance, if an implementation on top of OT turns out to be a popular request from the community, I might decide to add that, or to switch to OT in the future.

For now, that's the last I have to say about OT.

About the Ripple
I'll keep contact with Ryan to see whether this concept fits inside the Ripple system, or whether this and the Ripple need to be separate projects.

A group of people under the name "Satoshi" showed us it is possible. Thank you! I'm going to explain, however, that this is just a fraction of what needs to be done if a bitcoin economy is the final goal. I feel sick to read this forum day after day and see how much time, resources and talent are wasted chasing barren ideas. Current thread is the closest match to some of my own ideas.

Part I - Bitcoin is not digital currency.

Although bitcoin concept is far from being flawless it can still serve well as digital gold. I would personally like to see competing block chains like digital silver, digital platinum, digital palladium or (why not) digital diamonds, and so on. All digital money must be open source distributed p2p applications and defer not only by the name but by initial distribution, cryptographic principles, network protocol specifications, mining methods, transaction fees and how they are defined, etc. All they must have floating exchange rates towards one another which will change in line with how efficiently over time they fulfill well known money functions:

"Money is a matter of functions four, a medium, a measure, a standard, a store."

Store of value
Unit (measure) of account
Medium of exchange
Standard of deferred payment

http://en.wikipedia.org/wiki/Money

During last 5000 years gold served well as money. With the advent of Industrialization and mass markets it became apparent that physical gold is not very suitable to be medium of exchange. Contradiction was resolved by issuing paper certificates of gold ownership by private banks or governments. We all know many examples of how this was abused. The most successful system used was kind of mixture - bilateral or multilateral trade agreements where unit of account for every purchase was gold but only final outstanding balances were cleared through physical delivery of gold. Yet it was (and still is) expensive drill. Takes couple of days to prepare and move gold bars and coins from one point to another using train, plane or battleship. Until 1971 when some people decided they can play God and removed the gold standard. Only 40 years later we are where we are... in front of a major economic disaster.

Bitcoin concept (arguably) is a major step forward compared to gold. Instead of train, plane or battleship and couple of days preparations now it takes Internet connected computer and 1 hour of time (6 blocks). But still, it takes 1 hour to move bitcoin (digital gold) from one address to another. Given nowadays shopping habits not just 1 hour, but even 1 minute is too much!

Conclusion:
Bitcoin is a major improvement but still is digital gold, kind of. Complimentary payment system needs to be developed based on bitcoin (digital gold) as clearing currency. I would not use terms like fast bitcoin and slow bitcoin transactions, because this suggests overlapping parts of payment instruments, systems, block chains, or network protocols. THIS MUST BE AVOIDED AT ANY COST!

Next: Dichotomy

You are correct that OT is a library. Additionally, it is also a server, a client API, and a GUI test client (in Java.)

You described its functions thusly: "for creating digital contracts, exchanging these contracts, signing them, checking signatures & so on. Is that correct?"

Yes, but much more...
OT enables you to issue CURRENCIES based on those contracts,
and it enables anyone else to open ACCOUNTS in those currency types.

It also enables users to withdraw in untraceable digital CASH.
Users may even operate CASH-ONLY (without accounts.)
OT also enables users to take advantage of OTHER INSTRUMENTS,
such as CHEQUES, CASHIER'S CHEQUES, ACCOUNT TRANSFER, etc,
the same as they would normally at the bank down the street.

Users can even trade their digital assets on MARKETS against other
asset types, the same as they do now on sites like MtGox.

OT also does these things with SIGNED RECEIPTS, in such a way that not
even a server can forge a transaction, or change your balance, without
first getting your signature. (The server cannot forge your signature on a
receipt.)

---------------------------------------------------------------



The client API, with comments, is here:
https://github.com/FellowTraveler/Open-Transactions/wiki/API

Instructions for using the client API are here:
https://github.com/FellowTraveler/Open-Transactions/wiki/Use-Cases

A sample implementation (in Java) of a test GUI, using the OT API:
https://github.com/FellowTraveler/Moneychanger

I am, of course, available to answer questions, and there is also a mailing list: [email protected]

So that anyone who pleads ignorance is without excuse.

---------------------------------------------------------------


The basic principles of its technology?

1) Ricardian Contracts. The contracts are Ricardian-style contracts, and they are used to denote the servers as well as the asset types. Any new currency on OT is issued by the issuer uploading that currency to any OT server. (The currency will have the same ID across all servers.)
You can see a sample currency contract here:  https://github.com/FellowTraveler/Open-Transactions/wiki/Sample-Currency-Contract
The functionality of OT is similar to Ricardo, which is described here (with pictures!):  http://www.systemics.com/docs/sox/overview.html
Here is the Ian Grigg URL on Ricardian Contracts: http://iang.org/papers/ricardian_contract.html

2) Triple-Signed Receipts are employed, so that servers are unable to forge transactions or change balances. (The server cannot forge your signature on the receipt. The receipt is the account.) The core transaction engine is designed in this way, so that the same protection is afforded to all instruments (such as market receipts, cheque receipts, etc.)

3) Destruction of Account History. For its core account system and financial instruments, Open-Transactions uses balance agreement and transaction numbers on every receipt, in such a way that the parties to any transaction can prove their balances, and which instruments are valid, without having to store their entire transaction history, and instead by simply producing their last signed receipt.
I describe how it all works right here:  https://github.com/FellowTraveler/Open-Transactions/wiki/Triple-Signed-Receipts
A similar protocol (Truledger) is very well described here, with examples:  http://truledger.com/doc/plain-english.html

4) Untraceable digital cash. Open Transactions uses Chaumian Blinding to offer the untraceable cash.
You can read about the technology here:
http://www.cs.bham.ac.uk/~mdr/teaching/modules06/netsec/lectures/DigitalCash.html
Here is a sample piece of OT cash and an article: https://github.com/FellowTraveler/Open-Transactions/wiki/Sample-Cash
There are various digital cash libraries floating around out there. Currently I am using this one: http://anoncvs.aldigital.co.uk/lucre/

5) Many Financial Instruments. Cheques, Cash, Markets, Payment Plans (recurring), Withdrawals and Deposits, Account-to-account transfer, Receipts, Inboxes, Contracts, etc. More coming.
Article:  https://github.com/FellowTraveler/Open-Transactions/wiki/Instruments

6) Federated Servers. Instead of a centralized model, OT tries to federate its services wherever possible. For example:
--- The same currency could be issued at multiple servers.
--- The same currency would have the same ID across all servers.
--- The same Nym would have the same ID across all servers.
--- Server-to-server transfers are possible through the issuer, since the issuer already has a presence on every server where he's issued.
--- Users can trade in basket currencies, which distribute risk across multiple issuers.
--- (coming soon) OT Servers will implement voting pools for Bitcoin, meaning a hacker could not steal your Bitcoin from a server unless he'd also hacked 90 of the other servers in the pool, and gotten their private keys and their passphrases.
--- A clever wallet software could distribute the assets of a single "account" across multiple servers, and abstract that away in the user interface.
Article: https://github.com/FellowTraveler/Open-Transactions/wiki/CENTRALIZED
Diagram: http://billstclair.com/ot/ot-diagram.jpg

So if you were to ask me the principles behind Open Transactions, in a nutshell I'd say:
Ricardian Contracts
Signed Receipts
Unforgeable Balances
Destruction of Account History
Chaumian Blinding (Untraceable Cash)
Many Financial Instruments
Federated Servers

Feel free to ask if you have any other questions.

-FT

You could certainly build this on top of Ripple as a particular kind of trust account (shared bitcoin wallet).  Nothing about the payment routing would be affected as far as i can see.

Ryan

If it is about POS transactions the name of such a project can be poscoin. But first, let me tell you that your efforts are much appreciated. This is the right direction to follow.

I agree that the major challenge ahead would be creating a distributed system based on trust. I also agree that ripple project is a good base but a lot of additional work has to be done. Not so much about technicalities but about theory, because we shall enter into uncharted territory. My advice to you would be not to go into too much technical details at this phase. A lot of theoretical questions need to be answered first. Tomorrow I'll try to post some of my considerations.

Your forum signature seems to indicate that you are familiar with the Ripple. So, to get you started with understanding my idea: it is a variation on the Ripple.
Or, more accurately: two variations. One idea is in the first post of this thread, but based on the replies I've made another idea, which has the advantage of reducing the number of transactions in the Bitcoin block chain.

About instawallet:
I see what you mean, but that approach is not really decentralized. If merchants accept only instawallet green address transactions, and instawallet suddenly stops operating properly, you have a problem. Of course you can have multiple instawallet services, but merchants will never trust more than just a few of them. What you need is a network of such services, and that brings you back to the Ripple concept.

About open transactions:
I am still trying to understand the Open Transactions project. I think the problem is that the open transactions website is mostly busy in explaining what it can be used for and what its advantages are, and fails to explain the basic principles of its technology. Is this OT project well known within the Bitcoin community?

From what I understand now, OT is basically a programming library for creating digital contracts, exchanging these contracts, signing them, checking signatures & so on. Is that correct? As such, it could be an interesting low-level layer, on top of which my ideas could be implemented. But as long as I don't understand it, I can't use it as a programmer...

I need a name for my project
Does someone have a suggestion? With a name, I can create a website, make my design documents a bit clearer, and so on.

I see the instawallet green address approach as the most promising one right now, but I should read this thread more deeply.

I managed to write down what I conceptually want to create. You can read the description here.

Notice the difference with the Ripple, in the use of a shared Bitcoin wallet to back IOUs.

I don't know whether this can be implemented on the Ripple network. I suspect it is not possible: if I am correct, there are only a limited number of message types in the Ripple protocol, and some of the things I want to do probably don't fit in these message types.

After writing this, I suspect that it might be possible to add arbitrary-currency transactions to my concept, while keeping the shared wallets based on Bitcoin. However, that is something that still needs to be investigated, and it is almost certainly going to cause some trouble and require important design choices.

My next goals are:

• have a detailed network protocol specification
• have a architectural diagram for the first implementation

But first, I am going to make some quick prototypes, to find out what works and what doesn't.

In the future, you can expect me to release a prototype with a web interface, that works with testnet. Then I want to invite the white-hat hackers in this community to tell me what's wrong with it.

In fact, if you already spot some problems in the conceptual description of my design, please tell me ASAP.

First of all: I thank all of you for your replies. I received some useful ideas and new inspiration from them.

About the ripple project:
I've heard about it, but I never found any good resources, so I never managed to understand it (until now). I worked out the principles on my own, and later I combined it with the Bitcoin idea into the concept of my original post. If there is a Ripple development forum, I think some of the ideas are better discussed over there. But for now, I will post my ideas in this thread.

About the Open Transactions project:
I still don't quite understand it. How centralized is it? I see there can be multiple OT servers, but can they form a network? If some shop only connects to a single OT server, can I still do payments if that OT server refuses to connect to me?

About using the fast verification network for reducing the number of Bitcoin transactions:
Originally, I didn't think of that, but it might be a very useful feature.

The problem is: you effectively end up accepting IOUs for payments, and that opens the road to fractional reserve "banking". How do you know that the person you trust is capable of paying his debts? Of course this can be part of the 'trust' as well, but this kind of trust doesn't stay local. If person A trusts person B, who gives IOUs to A, and backs his IOUs with IOUs from person C, then a bankruptcy of person C might affect person A, because B's IOUs are no longer backed. See the current financial problems in the world for an example on how not to do things.

I like the idea of using the block chain to prove that you own a certain amount that backs your IOUs. However, there is still the risk that a person uses one Bitcoin account for the backing multiple connections. Can this be solved with some sort of Bitcoin script? Maybe two 'trust-linked' parties can create a shared amount of bitcoins, which can only be spent if both of them agree? Then, these bitcoins can only be used for backing on that particular link, and they can be used for backing in both directions. And, having to work together to be able to spend the coins might give an incentive for staying honest and keeping the link up.

Naturally, the 'backing account' should not be modified for every transaction that flows through the link, or otherwise we would create a huge number of Bitcoin transactions, which is what we tried to avoid in the first place. Instead, it should be modified once in a while to correct for long-term transaction unbalance. Effectively, the meaning of IOUs becomes "this part of the backing account belongs to you, and the rest belongs to me".

Also, to reduce Bitcoin load even more, the IOU inbalance could be settled by detecting and eliminating IOU 'loops' in the network. Maybe this is not necessary if transactions are always sent to the 'best-quality' link: then, loops will automatically be reduced by new transactions.

About the routing problem, anonymity and atomic transactions:
For me, anonymity is an essential feature, so the question is how to do routing without letting everyone know who you trust.

First of all: your 'trust partner' (let's call him your friend) knows that you share a trust link, and he could inform the rest of the world about it. I don't think you can fix that, so you'll just have to trust him for respecting your privacy. Or you can try to make friends pseudonymously.

For establishing a link through the network, the receiving side needs to be listed in routing tables through the entire network, so that the 'link initiation message' can always be sent in the right direction. The receiving side can not be completely anonymous, but he can be 'pseudonymous'. Compare it e.g. to a TOR hidden service. This is already more anonymity than typically needed, because in real life, shops are typically not anonymous at all. Only customers can have high anonymity expectations. So, I think the customer needs to be the party who initiates the link, and the shop is the party who is listed in the routing tables.

I don't think the intermediate nodes in the link need to be known to each other. If necessary, they can create temporary pseudonyms for each transaction, and send a signed message to their friends to indicate that whatever is signed by the pseudonym, is approved by them. Having signatures from all nodes in a link might be a requirement for accepting a payment atomically, but if all signatures are made with temporary pseudonyms, then only your friends know that it's you who provided the signature.

following this

Open-Transactions (https://github.com/FellowTraveler/Open-Transactions/wiki) is perfect for the "Fast Verification Network" piece of your diagram above...

At the simplest level, you bail the BTC into the OT server, and then OT processes all the transactions for as long as you want (you can use accounts, transfers, untraceable cash, cheques, markets/trades, signed receipts, etc.)
Then the user just bails back out into BTC again, whenever he wants back off of the server.

Benefits?
1) Untraceable transactions
2) Easy convertibility to other currencies on the OT market.
3) Instant finality of settlement
4) The server cannot forge transactions, or change balances without the user's signature.
5) All parties need only to store the last signed receipt, and they can prove their current balance, as well as prove which instruments are valid and which transactions are open or closed.
6) No worries about running out of space on the block chain.


===> YOU MIGHT ASK: But what if I don't want to TRUST the OT server with my Bitcoins? What if it steals them, or disappears, or gets hacked?

===> Based on conversations with Bitcoin developers, I believe I have found the solution to this. I've got the protocol figured out, but I haven't coded everything yet...

===> I've hinted at this before, but I've got a bit more free time now, so here it is:


THE GIST:   LOW-TRUST SERVERS (For Bitcoin on OT. The protocol is different with non-crypto-currencies.)

1) Basically, instead of bailing the BTC into a single server, you bail it into a VOTING POOL of maybe 50 different servers (or however many.) These will operate like a secure escrow in the blockchain. Many of you already have discussed this concept.

2) In my own protocol, the wallet signs the bail-in request, including the amount, the relevant IDs, etc, then the server countersigns it and sends you the receipt. (All the server is doing here is verifying everything in your request, and then signing it, too.)

3) Then your client GUI sends that receipt to the voting pool AND sends the Bitcoins to the pool. (There is no single recipient on the blockchain, but a pool of recipients at once.)

4) This same process happens in reverse when bailing back out. But this time, after the pool members verify that both parties have signed the bail-out request, they then vote on the blockchain to transfer BTC out to the recipient on that request, with a 3/4ths vote (or whatever) which is what actually effects the BTC transfer back to you. Rules can also be enforced here, involving inbox notification, time delays, maximum daily transfers, or whatever we decide.

5) The "vote" between the pool members occurs on the blockchain itself, using the built-in Bitcoin script language. Normally all votes will always be 100% in the same direction, since they will always agree on the truth. So we set it to 3/4ths or 9/10ths, whatever, so that it really takes a supermajority to do any bailment out, yet still leaves enough wiggle-room for the pool to prevent the loss of any BTC, and return it to the rightful owner, even if a server disappears or fails an audit.

6) If a receipt is ever submitted to the pool that's NOT properly signed, then the pool members simply vote to reject the receipt. (And probably to distrust the bad actor who submitted it.)

7) In the event that an OT server disappears, your BTC is still safe in the pool, and it's still possible to send a signed recovery request to the pool members, get your 3/4ths vote, and have your BTC transferred back to you.


There's more to it than that, and it involves the OT audit protocol as well, which is slightly different for issuer-based digital assets than it is for BTC-based digital assets (on OT.)

...But you get the general idea.

I've already got all the code I need on the Bitcoin side, I think, and I've got the new protocol figured out on the OT side (not coded yet).

I think I can swing this with the existing Bitcoin codebase (no changes to Bitcoin itself), and with the existing mining groups, though I'll have to include some Bitcoin code into OT for everything to work. I hope to be able to demonstrate this protocol soon. (Frankly I'm shocked no one else has done this yet.)

-------------------------------------

FYI, the "Point of Sale" and "Cell Phone" devices in your diagram above (as I picture them) are simply OT-API clients -- using the OT financial instruments to send payments to each other. (Cheques, cash, transfers, receipts etc.)  Each GUI is different, which is why OT-client side is an API. That way you can focus on your point-of-sale system, and let the OT-API do all the heavy lifting.

-------------------------------------

Bitcoin adds value to OT as well, in these ways:
1) BTC is a distributed, decentralized, reserve commodity that cannot be confiscated, counterfeited, or shut down.
2) BTC has all (most?) of the unique monetary properties of gold, which properties historically always cause gold, by operation of the invisible hand of the free market, to be used as money, in all cases where force and fraud have not perverted it. (Bitcoin being transferrable p2p, recognizable, limited, homogenous, fungible, divisible, and an efficient store of value in space and time.)
3) Bitcoin has an existing network of exchangers in/out of the various fiat currencies, in the various jurisdictions.
4) Bitcoin can be a "UNIVERSAL MEDIUM" between OT servers... users will be able to store funds in gold, but then convert to BTC on OT markets, whenever they want to hop to another server. This makes Bitcoin very very very useful even for goldbug users.
5) Such transfers will also occur through DGC issuers, who are presumably already at both ends, and more importantly, through Ripple, which is being built into the OT test GUI, Moneychanger. (Thus, I also see this as a potential bridge between Bitcoin and Ripple.)
6) Bitcoin makes it possible to run transaction servers, and other darknet servers, anonymously yet at a profit. That is very useful to OT.

Yes.  It should be possible to have a timeout on the order of seconds, though, since that's how long a successful transaction should take.

That's pretty cool, but I'm not sure I see the benefit of the open transactions if you need to fully trust the other party anyway.  Why can't they just send normal transactions when it's time to settle?

If you set up a few "is this transaction pending" servers at well-known locations and only accept a transaction when it shows up at a majority of such locations (and no conflicting transactions show up at any of them) your vulnerability to a double-spend attack is so close to zero as to be negligible. (For the applications for which people routinely take credit cards or use cash.)

There must be some kind of timeout.  If I promise to pay X, then I need to reserve that portion of the trust link.  If the IOU isn't cashed in, then I can purse the funding lock.


Sorry must have missed it.


Not sure.  Ideally, a proxy server should be able to skip/pass on messages/frames that it doesn't understand and just scan for the ones that it is interested in.

The problem is that if merchants are told to just trust transactions that haven't been confirmed, then there is the possibility that the losses will be quite high.  The face that only a small percentage (zero?) of transactions are currently double spending isn't relevant, because no one out there is trusting transactions until they've been confirmed, so double-spending isn't a viable exploit.