Show HN: Offst – A decentralized payment system
freedomlayer.org
freedomlayer.org
Have you looked into using the Interledger Protocol? It's the most advanced evolution of the concept I know:
Also, how do you propose to grow this network? That always seemed like the hardest part to me.
Meanwhile, the debt idea is resurfacing on top of blockchains in the form of lightning payments. You can transact quickly via debts amongst a network of peers that settle their debts back to the blockchain for backing.
Great honor to get this message from you, I'm a great fan!
> Have you looked into using the Interledger Protocol?
Yes. It contains some things that I don't agree with. For example, I believe that the timeouts they have on the transactions are not secure. I also don't like that it binds users to the domain system and the traditional certificate hierarchy.
> Also, how do you propose to grow this network? That always seemed like the hardest part to me.
I'm not sure yet. I agree that this is a very difficult question. I might need some help.
1. Why is the mediation fee 1 credit? This appears to be an arbitrary choice with no rationale. Why not let the market decide?
2. What prevents me from setting up a fake node and just extending myself a bunch of credit? Is this where human judgement/trust comes in? I.e. my friends trusting me that I'm not engaged in this sort of manipulation? (I'm not saying this is inherently a flaw, just curious if you've considered it).
3. In the Alice, Bob, Charli example, why don't Bob and Charli just link up instead of more-expensively going through Alice?
I have my own answers to these questions, but I'm curious what your response is. I can see this project going in a slightly different direction from how you describe it in the initial release. Feel free to contact me at <my username> at gmail dot com if you're interested in discussing in more depth.
In the beginning I had code that allowed any node to pick any fee he wants. This caused some problems. Because of the nature of this system, whenever you want to send funds along a route you have to know ahead of time all the fees along the route. If you got some route, and before you managed to send the funds one of the nodes decides to change his fees, your transaction will fail.
It's not a final decision though. I might add this feature again in the future. In the meantime if someone wants to collect 2 credits instead of 1, he can "simulate" another node. Then the route appears to be longer. Not optimal, but possible.
And why exactly 1 credit? This is the only arbitrary choice in the protocol, so it doesn't really limit anything, and it might actually give the credit its actual value in the protocol.
Another thing I was afraid of was some kind of credits inflation: All participants will start increasing their fees gradually. If we fix the fee to be exactly one credit, we can avoid this situation.
2. You can actually set as many fake nodes as you want, but it will not give you extra buying power on the outside world. For example: I can set up two nodes, each trusting the other one with 1 million credits. It will seem that I have lots of buying power (1 million credits!), but I will not be able to use this buying power outside of the clique of nodes I invented to myself.
Your buying power will always be limited by how other entities trust you, and this is something that might be hard to fake. You might be able to fake it once, but after the first time you default people will not be willing to trust you again (Hopefully).
One more thing: Offst has a way of producing a token that proves the last operation done in a mutual credit between two nodes. This token is signed, therefore we might be able to use it as a proof in a court. I haven't yet documented this feature, but it already exists in the first release of Offst.
3. They could, but maybe Bob and Charli don't really trust each other? Imagine that you are on a vacation, you go to some hotel in Shanghai and you want to pay for your stay. You could tell the hotel manager: Hey, why don't we open a mutual credit account and I could pay through that account. But it's not a good choice for the hotel manager, because most likely he will never see you again. It is better for him if you pay through a known route.
Thanks for the interesting questions, Prepare to get an email!
This seems like an impossible obstacle -- every buyer and seller must have a connection (of trust), and the connection must have enough credit! Is the hotel manager in Shanghai going to have a connection to every customer? Is the local restaurant going to have thousand of trust connections so a relay can be found?
The other issue is the zero sum of credits and debits. How can money be added or removed from the system if "the total amount of credits in the system always remains 0"? How can you convert $100 USD to credits, spend the credits and someone else can get the $100? Does any money put into the system also need to removed at the same time? How would that work?
Let's say I've got 100USD. You've got a node and a pile of trusted friends. I spin up an account and pay you 100USD.
Initially it looks like this:
Me->Dollars: 100, Credits 0
You->Dollars: 0, Credits 0
What do I get in return? A line of credit that you extend to me. So now it looks something like this:
Me->Dollars: 0, Credits: 100
You->Dollars: 100, Credits: -100
It is up to you what you do with the cash, but there is now a debt on my account to you for what you provided to me. In this sense, a positive number of credits is "debt owed to another" and a negative number of credits is "debt that is owed to you".
Suppose I have a friend, CM, who I trust. If I want my 100USD, but you already spent your cash, I go to my friend and buy the cash with credits;
Before we trade
Me->Dollars:0, Credits: 100
CM->Dollars:???, Credits: 0
And after
Me->Dollars:100, Credits: 0
CM->Dollars:???-100, Credits: 100
Notice that you still have -100 credits. Essentially, I bought your trust. Because I gave you cash, you know that I'm good to pay you the money I've already given you. This debt owed to you will remain in the network until you are paid an equivalent amount in credit.
I can see now that lenders will be "debt sinks" that exchange cash for credit within the system. So, while the balance of the whole system is essentially 0, there will always be an imbalance because there will be those who take cash in exchange for "trust" and credit.
> Is the local restaurant going to have thousand of trust connections so a relay can be found?
No. The restaurant will trust a node that trusts many other people. I can see that as well as "debt sinks" on the network, there will also be nodes that specialize in taking on "trust" so that others don't have to. Like a bank. There will likely be a fee (in credits or cash, you choose) associated with assuming other's risks.
The key difference seems to be that there’s only one currency of account, credits. I find that interesting, not in a bad way.
Let’s say I started a trustworthy node. I offer to issue 1000 credits per bitcoin someone deposits. All publicly accountable and with some crypto black magic (for the sake of argument), trustless.
Would this create an off-chain payment solution?
This is spot on.
> Would this create an off-chain payment solution?
I think that the lightning network does this kind of thing.
People in Bitcoin space have been trying all possible off-chain payment solution they could think of. "Sidechains" are a concept similar to your thing where people deposit bitcoins, however they seem to be impossible to do on top of Bitcoin (and on top of Ethereum too, even though people there have all computation tricks in the world at their disposal).
In the Ethereum space people came up with something called "Plasma" that is supposed to solve this and allow a big number of off-chain system use-cases, but it has an insurmountable number of flaws when you look closer.
In the Bitcoin space, there's an idea for implementing sidechains in a trust-minimized way (not 100% secure, but relying on the same game-incentives the power Bitcoin itself) called "Drivechain". Most of the discussion you'll find about "sidechains" on the internet is either people pitching the drivechain solution or criticizing or ignoring it completely and talking about Liquid, an off-chain payment system managed by Blockstream that is not trustless nor has any game-incentives.
As a few comments have pointed out this similar to the Lightening network and Ripple. One comment mentioned that Ripple never found a routing algorithm and that is also a major criticism of Lightening, see for example [1].
How are you planning to address these challenges?
[1] https://www.youtube.com/watch?v=Ug8NH67_EfE
P.S. I only came across Rick Falkvinge today so I don't know how controversial he is in the crypto space. Given that he backs BCH I guess he might be.
The linked article doesn't explain that which should be the most important and non-trivial part of the entire thing, it only says:
> The core of Offst is the credit pushing mechanism. It allows to send credits along a route of mutual credit edges in a secure way. You can read more about it in the project documentation.
The project documentation doesn't have a section dedicated to explaining how they solve these problems. Or at least I couldn't find it.
EDIT:
I found it, it's called "Introduction to backwards credit payment". Basically A sends a promise to B and B a promise to C, then C signs some stuff that fulfills B's promise and B signs some stuff that fulfills A's promise. That's all great, however, if in the backwards path if A is offline or unresposive the transaction is left in a partially-committed state that hurts B, for example.
See discussion of this and many many other ideas (all flawed in some way or another) at http://ripple.ryanfugger.com/Protocol/Index.html
The Lightning Network implements the same "backwards" stuff. However the transaction cannot be abandoned in the middle because the HTLCs can be enforced on the blockchain (of course this has problems because most of the times it's not economical to enforce these things on the blockchain, but anyway).
EDIT 2:
I'm not saying this to shit on the idea. I really think it could work if it's based on real-life relationships so A is not going to try to cheat on B during a transaction, but at the same time if that is true we probably don't need so much commit things and signatures.
Now back to trust-minimized schemes, perhaps Interledger's idea of streams of minimal payments could work better in this context, or since Offst is relying on indexes, relays and other server infrastructure it could as well rely on third-party commit registries.
The way I see it, relying on dumb servers that only relay communication is very different than trusting third party registries. The worst that could happen with a bad relay is some communication problem, but if you trust a bad registry with your credits, it's a whole different story.
> A's promise. That's all great, however, if in the backwards path if A is offline or unresposive the transaction is left in a partially-committed state that hurts B, for example.
The core issue here the way I see it is that in the current design payments might take indefinite time. This is an issue I'm aware of, and I'm working these days on an atomic design for the transactions.
If you are interested, I can really use your help to review the proposal for the new design. I hope to have it done in the following week or two. My email can be found on freedomlayer's website on the about page. Please send me an email and I will inform you when the proposal is done.
> or since Offst is relying on indexes, relays and other server infrastructure it could as well rely on third-party commit registries.
I think that there are advantages to not relying on registries, and instead having every user run a node:
1. The way I see it, having only nodes is a general case of having both nodes and registries, because a registry is just a node that happens to be online most of the time and other people trust. This also means less code, less interfaces and less places to make mistakes.
2. The Offst protocol between two nodes gives cryptographic accountability between nodes. For example, if a node you are in contact with suddenly disappears, you can produce a cryptographic artifact that shows your last balance with that node.
It uses the same mechanism of credit payments over multiple hops. But denominates each hop in a particular (possibly different) asset to help settling the credit between peers.
Bob’s debt to Alice grows beyond the point where Alice is willing to trust him since Bob is mostly using the system to buy things.
Edit: I speak from experience, working on althea.org which included a similar system (although ours is backed by a blockchain and doesn’t require nodes to trust each other). The reality is that most nodes are either mostly paying or mostly being paid. The channels must constantly be refilled anyway because of this. We found that the saved transaction fees were not worth the complexity, and now nodes just use on chain transactions with no transitive trust system after about 50 cents of debt has built up in either direction.
I follow you people for a long time on /r/darknetplan! How are things going?
As tmacro noted, Offst friends put credit limits on each other. Therefore Bob will not be able to buy forever. This is not really a bug, Bob is out of credits and shouldn't be able to buy more things until he gets new ones.
How does Bob gets credits is another question. In a normal economy Bob would have to get to work or exchange something to get credits. I agree with you that initially in a small network this could be a problem, because maybe nobody in the network wants to exchange something with Bob for credits. But if this kind of credit system is widely use, I hope this won't be a problem.
Yes! I agree with you, having Offst on a mobile phone is indeed a game changer. Offst was designed from the beginning to work in environments where sudden malfunctions and network problems can occur. Having it on a mobile phone is part of the plan.
I began with a command line interface (stctrl, the first Offst application) because I knew I could finish developing it very quickly.
I hope to take a period of time to stabilize the protocol and all the APIs, and then I will begin writing a GUI interface for Offst.
Offst is written in Rust, I have no idea yet how to get it inside a mobile phone. I don't have any mobile experience at all, it will take some research on my side.
> it would drain the battery
Maybe not so much? Offst doesn't do any kind of CPU intensive operation. Maybe the communication will drain some battery though.
However, running a networking service (daemon, app, whatever you want to call it) 24h on a mobile phone will massively drain the battery, just because Wifi et al needs some power.
In order for this to work I've got to get the one who owes me to agree to create these credits and give them to me. Then, when I pay the credits to my 2 friends I owe, who is going to buy those so they can get their money out? How do I get the rest of my money out?
How could these debts be traded? Why would anyone buy them when they have to trust specific people they don't even know, and who may not even exist, to honor them?
The original Ripple concept failed for very good reason. When there's enough trust/credit/goodwill systems such as this don't add any value, and when there isn't they are useless.
I don't know why you're presenting such a wrong narrative as if it was the absolute truth everyone agrees.
Am I wrong here?
Did Ripple predate Bitcoin?
https://github.com/freedomlayer/offst/tree/master/components...
This contains a capnp definition of all the protocol.
I didn't write about it yet in the documentation because I'm pretty sure this protocol is going to break soon. This first version is only a demonstration, and there are some various small things I might decide to change there.
I also want to change all the interface related Rust crates to have an MIT license, so that you can just copy the interface and do what you want with it. This should allow anyone to write applications with any license they want.
I intend to have a very detailed explanation of the protocol on the first stable release.
EDIT: One more thing that should be fixed in this regard is the format of the Offst database. Currently it is a file, I intend to change it into an sqlite database.