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.
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.
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.
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?
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?
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.
This is spot on.
> Would this create an off-chain payment solution?
I think that the lightning network does this kind of thing.
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.
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.
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.
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.
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.
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.
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.
