4 ms·

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 li

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 7y ago
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 7y ago
  That's not what I said.
  - realcr 7y ago
    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.

realcr 7y ago

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 7y ago
That's not what I said.
- realcr 7y ago
  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.