Agree - robots have to go.

There is an opportunity to create a massive revenue stream for BTSX by acting as a market maker/escrow for 100% collateralized loans:

- Add a lending tab to the client

- Lenders designate BTSX holdings as available for lending; set interest rate, loan duration, etc. Funds are locked/escrow and go on the market.

- Borrowers bid on loans. The debtor's borrowing power is limited to the amount of collateral they have available, ie. must designate 1 BTSX as collateral for every 1 BTSX borrowed. Could also subtract interest from borrowing power. Collateral is locked/escrowed when the loan is made.

- When the loan is due the client automatically transfers collateral + interest directly from the debtor to lender. No muss, no fuss.


There are many advantages to this:

- Lenders can generate additional revenue from BTSX holdings

- Borrowers can double purchasing power without a credit rating, loan application etc.

- Speculators can leverage BTSX holdings

- A huge amount of revenue would be generated for shareholders

- No default risk, no credit scoring, no chasing down bad debt


There will eventually be a P2P lending DAC that will deal with riskier loans and all the associated headaches, ie. BTCJam.

However, Bitshares X could deal exclusively in risk free loans and do quite well.

Initially things could be kept simple with one interest rate (... 5%?) and limited loan durations (1d, 1w, 1m, 3m, 6m, 1y).

Bitshares X offers the ability to store wealth and trade assets. Why not add the ability to lend and borrow?

Quote from: cass on August 20, 2014, 04:40:16 pm

think also we should call it bitUSD

Agreed we need to make sure it is VERY crystal clear that this is bitUSD not USD.

All derived assets (bitAssets) must be clearly designated as such.

This is critical.

bitUSD, bitGLD, bitOSTK etc.

1. The analogy would be having to vote on public school funding allocations before registering your kids for classes. We do not need to force transactions, only capture the participation of those using the system. And users have to make at least one transaction a year or pay an inactivity fee.

2. This is the point of failure; we are recreating a representative democracy and this opens the system up to all of the failures we currently see in western societies. Delegates are voted in by stakeholders. Right now we have a largely benevolent stakeholder base and the delegates reflect that. But sooner or later a few folks are going to buy up large stakes and vote themselves and their buddies in. They will grow richer, acquire larger stakes, expand their power structure and control more and more delegates - this system is pay-for-play. At the same time, new users will acquire smaller and smaller stakes (percentage wise as market cap increases) and, not having been involved in or care about the development of the platform, be less and less involved in voting etc.

Have you tried voting for delegates yet? How many did you pick? How long did you spend trying to figure out who was who? I bet most people will pick 10-20 before the novelty wears off/attention span is shot. Yes, there are slates... but all of this is only worthwhile if people actually vote. I'm betting the majority of users will not vote.

TL;DR: We should be pursuing a direct democracy with mandatory participation, not a representative democracy with voluntary participation.

The point of making it "hard" to do is that it means it is less likely to happen.   People need to know that it is "hard" so they can trust the system. 

In my original idea I probably didn't make it clear enough that:

1) Only a delegate could make the proposal
2) The act of making the proposal must come with a non-refundable fee of large magnitude ($1 million) that is paid to shareholders
3) Majority of delegates must approve
4) Must happen quickly, ie: not effect balances over 24 hours old.

A hard fork costs a network millions and those millions will be paid if it will save the network 10's of millions.   

The presence of such an automated system means that the network can "capture" the millions a hard-fork would have caused. 

Because the fee is so expensive, no one would dare cry wolf or use this option lightly.
Because the fee is non-refundable even if the delegates vote "no" then it is not likely to be paid unless there is already support/consensus.

But perhaps most importantly, the fact that a procedure exists means that suggestions to hard-fork to bypass the pre-established procedure will be roundly rejected. 

I think you have to view these thinks like pressurized systems, if you don't provide a release valve then they can explode under heat. 

I think that the community should establish some very sound guidelines prior to the event that server to minimize moral hazard:

1) An exchange that didn't use cold storage... is ineligible
2) Failure to use multi-sig...
3) .... 

All of that said, with BitUSD there is almost no reason to keep your funds on exchanges any more.  So perhaps a VERY HARD policy on this would be best.

BM's proposal has merit; a hard-coded anti-theft/seizure protocol would make the platform more attractive to investors and provide a measure of protection to delegates and other stakeholders.

Eligibility criteria/rules such as suggested above, while necessary, are subject to corruption when the consensus seeking mechanism is voluntary (ie. democratic decay into cronyism via voter apathy).

I would suggest the only way to adequately mitigate the moral hazard created by a rollback protocol is to implement a mandatory voting mechanism. The protocol would look something like this:

1. Theft/seizure incident

2. Eligibility test

3. Delegate rollback proposal w/fee

4. Rollback proposal pushed through client

5. Users must vote before completing next transaction

If voter participation is mandatory:

- Delegates will not propose rollbacks unless they are in the best interest of the community, otherwise they risk getting fired

- Delegates will not propose rollbacks unless they are compliant with the eligibility criteria, otherwise they risk getting fired

- The potential for gaming the protocol through cronyism/apathy is reduced


Handling of the rollback assets is another issue:

Burning dilutes the individual profit motive but introduces a moral hazard for the voting body, as the value of the voter's assets will necessarily increase from the burn.

So it may come to pass that delegates, who are likely to be large stakeholders in a given asset class, will contrive to have assets seized/stolen that they may be burned and thereby made more valuable.

The rollback fee may mitigate this effect somewhat, but may also serve to motivate fraud on a larger scale wherein the fee is simply a cost of doing business (ie. banks laundering money for drug cartels and paying fines that are small in relation to overall profit).

Too many contrived burns would cause mass devaluation through loss of confidence, broken pegs, etc. The same holds true if rollback assets are retained (seized?) by the bank rather than burned.

A true rollback, ie. return of assets, combined with a large fee and mandatory voting would seem to present the least profit motive and consequently the least moral hazard.

Someone gaming the system would have to incur a great deal of effort and expense to simply return the system to a prior state.

However, as previously mentioned, there is theft/rollback/theft/rollback loop that may cause delegates to permit the theft rather than pay recurring rollback fees. In this scenario it might be cheaper to let the theft occur than attempt to correct it multiple times (this is also true for burns - there will be a large threshold where allowing the theft/seizure is cheaper than correcting it).

The final option would be to direct rollback assets outside of the system to a third party, with the obvious choice being charities or similar organizations.

The fatal flaw with third party distributions is achieving consensus as to allocations, particularly as the Bitshares platform is global.

Gaming/conflicts of interest also become problematic.


TL;DR: Implement a rollback protocol with concise criteria, create a mandatory voting mechanism and burn rollback assets.

So now we have global self-insured decentralized autonomous bank with hard-coded reserves and tranparent ledgers... I think I feel a glitch in the matrix...

BTSX needs momentum; market cap is how the avalanche will start.

BTC is what it is today not because of social media presence, trendy ads, political lobbying or clever P2P marketing.

BTC is what it is because there are a few very powerful and connected hands pulling the strings.

We need a few whales, not a bunch of minnows.

I3/Brian are doing this right.

Having just registered I can tell you that casual/benign users such as myself are only voting for delegates we know are 'good' based on what we can glean from the forum.

We don't vote for anyone else (who is this?) for fear of helping a 'bad' delegate.

Desperately needed is a direct link from the Delegate Info page to the delegate's Bitsharestalk profile. Link needs to be trusted.

Or delegates need to build profiles etc. so we can figure out who we are voting for.

I don't necessarily want to vote based solely on reliability, would feel much more comfortable voting with knowledge of the delegate's 'platform', ie. contribution to the community, use of fees, beliefs/values/objectives etc.

The system is young for this, but at least having a bitsharetalk profile to work from would help a great deal.