
Show HN: Offst – A decentralized payment system - realcr
https://www.freedomlayer.org/offst/offst-release/
======
rfugger
Hey, cool! I worked on something similar a long time ago:

[http://ripple.ryanfugger.com/](http://ripple.ryanfugger.com/)

Have you looked into using the Interledger Protocol? It's the most advanced
evolution of the concept I know:

[https://interledger.org/](https://interledger.org/)

Also, how do you propose to grow this network? That always seemed like the
hardest part to me.

~~~
realcr
> Hey, cool! I worked on something similar a long time ago

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.

~~~
rfugger
My advice would be to come up with a plan to grow the system and design the
implementation around that.

------
ibeckermayer
I think this is a very interesting idea. A couple of questions:

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.

~~~
realcr
Hi, let me try to answer: 1\. Why is the mediation fee 1 credit?

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!

~~~
irq-1
Normally money is fungible and we trust _the money_ , not the people. Pirates
want gold because the gold will be accepted even if they won't be trusted.

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?

~~~
all2
> The other issue is the zero sum of credits and debits.

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.

------
dannyw
This is pretty cool. Obviously inspired by Ripple, but I like another
implementation without cryptocurrecy or global consensus.

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?

~~~
fiatjaf
Yes, but you can't do it trustlessly not even with all the crypto black magic
in the world. Otherwise it would be great.

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.

------
snthpy
I think this is the right direction as I think all money is a form of debt -
usually coupled with some settlement mechanism. Once we get a good
implementation of debt settlement then I think we might actually get a usable
decentralised money.

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

------
fiatjaf
All the ideas are simple and as old as Fugger's Ripple. The part that is
missing to all "mutual credit" payment system is how to do atomic
transactions.

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

~~~
realcr
A few people pointed out to me by that a transaction cancellation feature is
missing. (Without it, the sender of a transaction might have to wait
indefinitely). This is the next thing I'll be working on. Also, I agree that
documentation is somewhat sparse, but I felt like I have to release something,
even not complete, just to get some feedback about things I might be missing.
Messages like yours are very helpful.

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.

~~~
fiatjaf
That's not what I said.

~~~
realcr
Hi, I am sorry if I misinterpreted what you have said earlier. let me try
again. If I missed it this time too please send it again.

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

------
fnoof
There's a very similar project called Interledger.

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.

~~~
realcr
It's true. I think that the main difference between the two projects is that
in Offst there is only one type of credit. Interledger attempts to bridge
between various ledgers.

------
woah
So this is like the lightning network, but channel balances are never closed
out to any kind of global ledger? If this were to be put into use, you would
run into the following problem very quickly:

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.

~~~
tmacro
Offst includes the ability for Alice to set limits on her credit to Bob which
would prevent this.

~~~
woah
Sure, Bob is still out of luck though. This only works if Bob also receives an
equivalent amount of income through his channel with Alice which is extremely
unlikely.

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.

~~~
realcr
> I speak from experience, working on althea.org

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.

------
bitL
Could this be integrated to ActivityPub-based services, like PeerTube,
Mastodon, Friendica etc.? That was one of the missing pieces for independent
infrastructure, e.g. for paying artists or developers for their work without
getting frozen by PayPal & similar once money start flowing.

~~~
realcr
I very much hope so. Hopefully in the future you will be able to use Offst to
generally buy stuff online.

------
ktpsns
Interesting! Do you plan a less nerdy user interface? I'm afraid to say so,
but a mobile phone app could be a game changer. (Yes, it would drain the
battery, and yes, it could run on an old phone because many people have them
in their shelves)

~~~
realcr
> Do you plan a less nerdy user interface?

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.

~~~
hopscotch
When I last did mobile stuff, waking the radio was more expensive than many
CPU ops.

~~~
realcr
We just have to hope that I until I manage to set up a nice UI for mobile
phones, we will already have very good batteries (;

~~~
ktpsns
What's the use case you had in mind? Running offst as a daemon on an average
8h-a-day workstation/PC/Laptop? Or on a server? In any case, a mobile phone is
basically offline most time -- It seems to be online thanks to push-services
like the Google or Apple cloud ones, but that API is hardly usable for offset
without some kind of relay server (however, you _do_ have relays already in
the design, which is neat).

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.

------
Canada
I owe two friends money right now, and I have two friends who owe me more than
that.

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.

~~~
fiatjaf
The original Ripple concept failed for an entirely different reason: no one
could come up with a good routing and atomic payments implementation. Then
Bitcoin appeared.

I don't know why you're presenting such a wrong narrative as if it was the
absolute truth everyone agrees.

~~~
Canada
What year did Ripple debut?

~~~
fiatjaf
Ripple was never implemented.

~~~
Canada
They were certainly promoting that concept in 2012, and for _years_ after
that. Remember, everyone was going to be able to release their own promises on
it... so you could have a Euro backed promise from X which you could swap on
chain against some USD backed promise from Y? And XRP was supposed to be just
the fee currency to pay for it?

Am I wrong here?

Did Ripple predate Bitcoin?

~~~
fiatjaf
Please read the other comments (not from this thread).

~~~
Canada
What comments are you talking about?

------
olliej
I am super confused, if balances are purely a factor of owed vs owing how do
you gain credits, and how do you transfer the value of non-credit value (like
the example of a bike).

~~~
fiatjaf
I give you the bike, you give me credits.

------
all2
I don't see an API or network protocol. Will this be provided at some point?

~~~
realcr
It was very important for me to have the protocol schema separated from all
the code, you can find it here:

[https://github.com/freedomlayer/offst/tree/master/components...](https://github.com/freedomlayer/offst/tree/master/components/proto/src/schema)

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.

