Topic: [ANN] Sikoba, a peer-to-peer IOU platform (Read 2955 times)
Here is an interview on Sikoba-https://www.investitin.com/sikoba/.
When A pays C using its credit relation with B, this creates a chain of transactions/obligations A → B → C.
Sometimes this will be ‘final’: A pays something to B, B pays something to C (these need not be the exact same amounts, nor even currencies), and that’s it. A becomes completely detached from the B → C transaction, A → B → C has been split into two completely independent transactions A → B and B → C.
But sometimes there will be some ongoing fees resulting from the B → C transaction, for which A will need to compensate B on an ongoing basis - until the debt is repaid or the transaction is reversed via a clearing event. A remains attached to the B → C obligation. The Sikoba system must be able to keep track of such ‘non-final’ or ‘dependent’ transactions during their entire life-cycle.
This just makes no sense to me. What possible benefit could there be from tracking them?Sometimes this will be ‘final’: A pays something to B, B pays something to C (these need not be the exact same amounts, nor even currencies), and that’s it. A becomes completely detached from the B → C transaction, A → B → C has been split into two completely independent transactions A → B and B → C.
But sometimes there will be some ongoing fees resulting from the B → C transaction, for which A will need to compensate B on an ongoing basis - until the debt is repaid or the transaction is reversed via a clearing event. A remains attached to the B → C obligation. The Sikoba system must be able to keep track of such ‘non-final’ or ‘dependent’ transactions during their entire life-cycle.
Say Alice borrows $1,000 from Bob to buy a car, which Bob borrows from Charlie. The logical thing to do is track separately that Alice owes $1,000 to Bob and Bob owes $1,000 to Charlie. This is what Ripple does.
What is the possible benefit of tracking the connection between these two transactions after it happens? The two obligations are legally and logically independent. And it makes no sense for Bob to pay back Charlie on a schedule that Alice gets to choose.
So what's the upside? Why keep them attached? What's the purpose? I don't get it.
I'm not saying there's no possible benefit, I can't prove a negative. But if there is a benefit, I don't know what it is.
And there's an obvious downside -- previous similar systems failed largely (at least in my opinion) because of their complexity. This is additional complexity. Now, instead of Bob having to manage just one relationship per counterparty (either owing them, being owed, extending credit, having credit extended), Bob has to manage one relationship per pair of counterparties and perhaps even one relationship per transaction he's been involved in even indirectly. That seems really difficult to manage. And, again, difficulty managing relationships has been a key reason previous systems have failed (at least, IMO).
Someone pointed out to me that I had not responded to JoelKatz - which is true. I did post on the Ripple forum, but not here, so am catching up now.
1) re "One thing Ripple doesn't do, that might be important to you, is make it easy to charge interest." - indeed that is one of our goals. Our plan is a bit more generic than that, as it will allow "credit scripts" between any 2 users, ie more complex fee/revenue structures than just interest.
2) from our updated FAQ:
"How is this different from Ripple?
When A pays C using its credit relation with B, this creates a chain of transactions/obligations A → B → C.
Sometimes this will be ‘final’: A pays something to B, B pays something to C (these need not be the exact same amounts, nor even currencies), and that’s it. A becomes completely detached from the B → C transaction, A → B → C has been split into two completely independent transactions A → B and B → C.
But sometimes there will be some ongoing fees resulting from the B → C transaction, for which A will need to compensate B on an ongoing basis - until the debt is repaid or the transaction is reversed via a clearing event. A remains attached to the B → C obligation. The Sikoba system must be able to keep track of such ‘non-final’ or ‘dependent’ transactions during their entire life-cycle.
Another feature of Sikoba is that an A → B → C chain of dependent obligations is not necessarily static. As the system state changes, it may be replaced automatically by another less ‘expensive’ chain of obligations, for example, A → D → E → C, which again may not be ‘final’.
From what we know, such features are not (or not yet?) available in Ripple."
These things are gradually becoming clear in my mind by now, after 18+ months of thinking about it, but I know it's not at all obvious and I have to keep working on simplifying the concept.
This bitcointalk is not the best platform to interact with me, i don't exactly find find it egosyntonic, but hey, maybe some day I'll get used to it :-)
1) re "One thing Ripple doesn't do, that might be important to you, is make it easy to charge interest." - indeed that is one of our goals. Our plan is a bit more generic than that, as it will allow "credit scripts" between any 2 users, ie more complex fee/revenue structures than just interest.
2) from our updated FAQ:
"How is this different from Ripple?
When A pays C using its credit relation with B, this creates a chain of transactions/obligations A → B → C.
Sometimes this will be ‘final’: A pays something to B, B pays something to C (these need not be the exact same amounts, nor even currencies), and that’s it. A becomes completely detached from the B → C transaction, A → B → C has been split into two completely independent transactions A → B and B → C.
But sometimes there will be some ongoing fees resulting from the B → C transaction, for which A will need to compensate B on an ongoing basis - until the debt is repaid or the transaction is reversed via a clearing event. A remains attached to the B → C obligation. The Sikoba system must be able to keep track of such ‘non-final’ or ‘dependent’ transactions during their entire life-cycle.
Another feature of Sikoba is that an A → B → C chain of dependent obligations is not necessarily static. As the system state changes, it may be replaced automatically by another less ‘expensive’ chain of obligations, for example, A → D → E → C, which again may not be ‘final’.
From what we know, such features are not (or not yet?) available in Ripple."
These things are gradually becoming clear in my mind by now, after 18+ months of thinking about it, but I know it's not at all obvious and I have to keep working on simplifying the concept.
This bitcointalk is not the best platform to interact with me, i don't exactly find find it egosyntonic, but hey, maybe some day I'll get used to it :-)
You can find more information on Sikoba in this interview with the founder : https://www.investitin.com/sikoba/
Hi Joel, thanks you for your comments and clarifications. I will review our FAQ based on your comments - am travelling today/tomorrow so please bear with me if it's not done straight away. -Alex
There is absolutely no rush. One thing Ripple doesn't do, that might be important to you, is make it easy to charge interest.
Hi Joel, thanks you for your comments and clarifications. I will review our FAQ based on your comments - am travelling today/tomorrow so please bear with me if it's not done straight away. -Alex
The FAQ makes a lot of incorrect claims about Ripple's capabilities and how it works. I posted a response on XRPChat, but here's the relevant portion:
"In Ripple, payments between users that have not established a trust relationship are made by ‘rippling’ that payment along trust lines, which is similar to the hawala system."
True, but Ripple also has embedded order books and the ability to intelligently route payments through them. This means a single payment can take multiple paths to save money and improve liquidity.
"In Ripple, the assets being transferred through chains of relationships are fungible. It is the same token at the beginning of the chain and at the end of the chain."
That is simply not so. I can pay with bitcoins and the recipient can get dollars. Or I can pay with dollars issued by Bitstamp and the recipient can get dollars issued by GateHub. Ripple even supports community credit -- I can pay with bitcoins I borrowed from Jeff and the recipient can be owed bitcoins by Sarah.
"But the standard way of transacting in Sikoba will be different. When Sikoba participants transact using their credit relations, this can also be modelled as a series of token transfers."
That is exactly what rippling is! The tokens are denominated in the same currency, but they are distinct obligations with possibly distinct counterparties.
"But the token transfer in each of the links of the chains is ruled by a specific credit relationship and that ‘token’, if we want to call it that, is not necessarily fungible with any other token in the chain of operations. The reason is that credit in general is not fungible (although it can of course be made fungible, at a cost: we then call it money)."
Yes, that's why Ripple works that way.
"Overall Ripple would provide only a very small subset of the features we need, which is why we decided not to use it."
That may or may not be true, I don't know. But it doesn't sound like you understand either Ripple's capabilities or the way it models obligations.
"In Ripple, payments between users that have not established a trust relationship are made by ‘rippling’ that payment along trust lines, which is similar to the hawala system."
True, but Ripple also has embedded order books and the ability to intelligently route payments through them. This means a single payment can take multiple paths to save money and improve liquidity.
"In Ripple, the assets being transferred through chains of relationships are fungible. It is the same token at the beginning of the chain and at the end of the chain."
That is simply not so. I can pay with bitcoins and the recipient can get dollars. Or I can pay with dollars issued by Bitstamp and the recipient can get dollars issued by GateHub. Ripple even supports community credit -- I can pay with bitcoins I borrowed from Jeff and the recipient can be owed bitcoins by Sarah.
"But the standard way of transacting in Sikoba will be different. When Sikoba participants transact using their credit relations, this can also be modelled as a series of token transfers."
That is exactly what rippling is! The tokens are denominated in the same currency, but they are distinct obligations with possibly distinct counterparties.
"But the token transfer in each of the links of the chains is ruled by a specific credit relationship and that ‘token’, if we want to call it that, is not necessarily fungible with any other token in the chain of operations. The reason is that credit in general is not fungible (although it can of course be made fungible, at a cost: we then call it money)."
Yes, that's why Ripple works that way.
"Overall Ripple would provide only a very small subset of the features we need, which is why we decided not to use it."
That may or may not be true, I don't know. But it doesn't sound like you understand either Ripple's capabilities or the way it models obligations.
I can contribute or, at least, translate the ann thread (and the whitepaper when finished) into spanish. PM me if interested.
Hello everyone, apologies for not being active on this board, may I invite you to join our slack channel at https://sikoba-presale.herokuapp.com/ and to check our website.
Here are some answers to questions raised:
Reaper3 :
+ escrow: we chose not to do escrow, however we will not have access to the ETH received unless a threshold is reached
+ info on team is on our homepage at http://www.sikoba.com under About
cengsuwuei:
our immediate need is help with identifying suitable blockchain platform(s) for the project, given that it will be computation intensive if there are many users (expertise in consensus protocols may help...)
we also welcome people who can help with marketing
later on, we will need additional devs
onemanatatime:
+ there is only one similar IOU-based project in the crypto space that I know of
+ we're raising money to develop the app, it does not exist yet
BaZiZu:
+ we're working on the whitepaper now
Here are some answers to questions raised:
Reaper3 :
+ escrow: we chose not to do escrow, however we will not have access to the ETH received unless a threshold is reached
+ info on team is on our homepage at http://www.sikoba.com under About
cengsuwuei:
our immediate need is help with identifying suitable blockchain platform(s) for the project, given that it will be computation intensive if there are many users (expertise in consensus protocols may help...)
we also welcome people who can help with marketing
later on, we will need additional devs
onemanatatime:
+ there is only one similar IOU-based project in the crypto space that I know of
+ we're raising money to develop the app, it does not exist yet
BaZiZu:
+ we're working on the whitepaper now
How is this different from any cryptocoin clone in terms of tech?
if your product - the IOU platform - is your killer app... then where is it?
if your product - the IOU platform - is your killer app... then where is it?
We are also looking for people who can contribute time and expertise to the project.
.
what do you need people join in youre team dev ?
what is position, can explain detail youre job
iam interest join
escrow?
No info on team?
No info on team?
Shouldn't this be in the Altcoin Announcements board?
It should be posted at https://bitcointalk.org/index.php?board=159.0 especially because it involves a token that is offered for ICO http://www.sikoba.com/www/presale/index.html there is no concrete information about the buying of the token because of the contact us option above all i dont think the dev is serious with this project because he does not update it frequently. 
Shouldn't this be in the Altcoin Announcements board?
{ sikoba - the people’s banking system }
Sikoba is a global and decentralised money platform based on peer-to-peer IOUs and built on blockchain technology.
http://www.sikoba.com
{ Vision }
P2P payments are already above $1 trillion annually. From almost nothing 10 years ago, P2P lending has grown to $26bn in 2015 and is expected to reach $900bn in 2024. We believe that P2P IOU systems have a similar potential and that they will soon become the next frontier in finance.
{ Sikoba summary }
Using mutual credit systems that are not backed by money, but by IOUs of participants who trust each other, the need for an external money supply is limited to a minimum. Every peer-to-peer credit relationship is governed by a contract with specific conditions, fee structure and repayment rules. Using credit conversion, a kind of configurable rippling, payments between participants who do not trust each other become possible. The system will automatically take care of optimal payment paths, netting and clearing. We will support fiat money via gateways, cryptocurrencies as well as many use cases such as inter-company credit networks. Our goal is to provide a platform for operating any monetary system one can think of, together with the tools allowing all of these different systems to interact.
{ How will it work in practice? }
The way it works that you grant other users, whom you know personally, credit on certain terms which you yourself specify. These users can then pay you by drawing on that credit. Fiat, crypto or other assets can still be used for payment, for example if payment by IOU is not possible or not desired. Also, fiat or crypto may actually be required to repay debt. Both for practical and philosophical reasons, Sikoba is not intended to be, or ever become, a pure IOU system.
In the Sikoba system, a user will only ever have exposures to users to whom he or she has explicitly given credit. To give an example: if Bob trusts Alice, and Charles trusts Bob, and Bob allows what we call “credit conversion” for Alice, then Alice can pay Charles. However, Charles will only see Bob as his counterparty, and not Alice.
{ Sikoba token presale }
Sikoba has launched a token presale. The goal is to raise enough money to produce a MVP (minimum viable product), based on which a token crowdsale will then be launched before the end of 2017
Link to presale page : http://www.sikoba.com/www/presale/index.html
Link to Ethereum contract: https://github.com/sikoba/token-presale
Link to audit: https://www.bokconsulting.com.au/blog/the-sikoba-presale-smart-contract-security-audit/
We are also looking for people who can contribute time and expertise to the project.
.
i can contribute time for your project and also will translate your project to indonesian language if you needed,
just pm me what should i do for your project
https://i.imgur.com/UORr1yF.png
{ sikoba - the people’s banking system }
Sikoba is a global and decentralised money platform based on peer-to-peer IOUs and built on blockchain technology.
http://www.sikoba.com
{ Vision }
P2P payments are already above $1 trillion annually. From almost nothing 10 years ago, P2P lending has grown to $26bn in 2015 and is expected to reach $900bn in 2024. We believe that P2P IOU systems have a similar potential and that they will soon become the next frontier in finance.
{ Sikoba summary }
Using mutual credit systems that are not backed by money, but by IOUs of participants who trust each other, the need for an external money supply is limited to a minimum. Every peer-to-peer credit relationship is governed by a contract with specific conditions, fee structure and repayment rules. Using credit conversion, a kind of configurable rippling, payments between participants who do not trust each other become possible. The system will automatically take care of optimal payment paths, netting and clearing. We will support fiat money via gateways, cryptocurrencies as well as many use cases such as inter-company credit networks. Our goal is to provide a platform for operating any monetary system one can think of, together with the tools allowing all of these different systems to interact.
{ How will it work in practice? }
The way it works that you grant other users, whom you know personally, credit on certain terms which you yourself specify. These users can then pay you by drawing on that credit. Fiat, crypto or other assets can still be used for payment, for example if payment by IOU is not possible or not desired. Also, fiat or crypto may actually be required to repay debt. Both for practical and philosophical reasons, Sikoba is not intended to be, or ever become, a pure IOU system.
In the Sikoba system, a user will only ever have exposures to users to whom he or she has explicitly given credit. To give an example: if Bob trusts Alice, and Charles trusts Bob, and Bob allows what we call “credit conversion” for Alice, then Alice can pay Charles. However, Charles will only see Bob as his counterparty, and not Alice.
{ Sikoba token presale }
Sikoba has launched a token presale. The goal is to raise enough money to produce a MVP (minimum viable product), based on which a token crowdsale will then be launched before the end of 2017
Link to presale page : http://www.sikoba.com/www/presale/index.html
Link to Ethereum contract: https://github.com/sikoba/token-presale
Link to audit: https://www.bokconsulting.com.au/blog/the-sikoba-presale-smart-contract-security-audit/
We are also looking for people who can contribute time and expertise to the project.
.
{ sikoba - the people’s banking system }
Sikoba is a global and decentralised money platform based on peer-to-peer IOUs and built on blockchain technology.
http://www.sikoba.com
{ Vision }
P2P payments are already above $1 trillion annually. From almost nothing 10 years ago, P2P lending has grown to $26bn in 2015 and is expected to reach $900bn in 2024. We believe that P2P IOU systems have a similar potential and that they will soon become the next frontier in finance.
{ Sikoba summary }
Using mutual credit systems that are not backed by money, but by IOUs of participants who trust each other, the need for an external money supply is limited to a minimum. Every peer-to-peer credit relationship is governed by a contract with specific conditions, fee structure and repayment rules. Using credit conversion, a kind of configurable rippling, payments between participants who do not trust each other become possible. The system will automatically take care of optimal payment paths, netting and clearing. We will support fiat money via gateways, cryptocurrencies as well as many use cases such as inter-company credit networks. Our goal is to provide a platform for operating any monetary system one can think of, together with the tools allowing all of these different systems to interact.
{ How will it work in practice? }
The way it works that you grant other users, whom you know personally, credit on certain terms which you yourself specify. These users can then pay you by drawing on that credit. Fiat, crypto or other assets can still be used for payment, for example if payment by IOU is not possible or not desired. Also, fiat or crypto may actually be required to repay debt. Both for practical and philosophical reasons, Sikoba is not intended to be, or ever become, a pure IOU system.
In the Sikoba system, a user will only ever have exposures to users to whom he or she has explicitly given credit. To give an example: if Bob trusts Alice, and Charles trusts Bob, and Bob allows what we call “credit conversion” for Alice, then Alice can pay Charles. However, Charles will only see Bob as his counterparty, and not Alice.
{ Sikoba token presale }
Sikoba has launched a token presale. The goal is to raise enough money to produce a MVP (minimum viable product), based on which a token crowdsale will then be launched before the end of 2017
Link to presale page : http://www.sikoba.com/www/presale/index.html
Link to Ethereum contract: https://github.com/sikoba/token-presale
Link to audit: https://www.bokconsulting.com.au/blog/the-sikoba-presale-smart-contract-security-audit/
We are also looking for people who can contribute time and expertise to the project.
.
Jump to: