I have been building DPOShub.org along with @DataSecurityNode. It's an interactive web-based platform for our community to share PR content, build business relationships and post classified listings (just a few of the many features). Check out our update in the May NullStreet Journal, and our whitepaper: http://www.dposhub.org/wp-content/uploads/2015/04/dposhubdelegateproposal.pdf

We should have a working beta soon and we will be sharing more information in a public announcement in a few weeks. Stay tuned!

Also, please don't forget to vote for our delegate: delegate.dposhub-org

Quote from: profitofthegods on June 09, 2015, 12:55:19 pm

You are comparing to Bitcoin, but things like BitUSD will never appeal to users of Bitcoin and shouldn't be trying to appeal to Bitcoin users. BitUSD should be an alternative to things like Paypal where the consumer doesn't pay any fee at all.

Why would somebody choose to use BitUSD and pay small but not insignificant fees, when they can use Paypal and pay zero fees?

Is it not possible to re-balance some of the fees towards merchants instead of consumers, eg by finding some way to force merchant checkouts accepting BitAssets to issue a pending transaction which is free to approve or deny and placing all the fees on issuing the transaction and none on approving or denying it, (as I suggested here: https://bitsharestalk.org/index.php/topic,16794.msg214909.html#msg214909)?

Not mentioned, but we plan on showing the receiver of the funds paying the fee rather than the sender.   So it will work just like paypal.

So the fee will be subtracted from the balance sent, rather than added on? This would make sense, and then the wallet could dsplay the fee as having been paid by the receiver.

Quote from: CryptoPrometheus on June 09, 2015, 08:39:41 pm

Quote from: Method-X on June 09, 2015, 08:32:27 pm

Quote from: Shentist on June 09, 2015, 08:24:32 pm

Quote from: bitmarket on June 09, 2015, 08:17:11 pm

By making the referal fees liquid you undo the attack defense.

which attack vector do the vesting balance prefent? I don't get it yet.

Someone can create a wallet and sign people up for free (auto refund registration fee). I'm not convinced this would be a problem in practice. I say go with no vesting and if it ends up being more than a purely theoretical problem, implement vesting.

It would definitely be a problem in practice because you wouldnt necessarily have to refund the full $80. Any amount refunded would give an edge over other registrars.  It might start out with "get $10 back" or "get $20 back" but eventually  competition would push it higher and higher until we have a situation like I describe above (two posts back.)

Yeah I can see that happening but why a year of vesting? One or two months should be enough to prevent this. It's more a psychological scare tactic to prevent this practice from manifesting. One year seems extremely arbitrary.

I think 60 days would be sufficient. Long enough that there is no potential draw for attracting customers. Nobody wants $20 or $50 or $80 back in two months. If its not instant, its not going to attract. There still will exist the potential for a registrar to front their own funds and offer some amount of instant cashback, but that could happen regardless of the vesting period.

The 1 Year vesting period for referral fees strikes me as something that could be a dealbreaker for a lot of inquiring companies.  Its a very long time length to prove a business model that might not even work.  And for that one year, its wasted savings that is just sitting , while it could be reinvested elsewhere or put to work.  Most importantly, this long vesting period will hurt smaller, startup type firms who would want fees as quickly as possible to reinvest into their business.

Now I understand the need for the investing period to prevent attacks.  I'm just not convinced it will work out as expected because of this one-year vesting period.  Now for the solution:

Its certainly possible for these referral members to set up a UIA that will source money from the public.  They could offer at a 95% reduction.  So a normal user could pay 95 BTS and within one year get 100 BTS out of the referral member's pool.  Of course, the referral member would never offer more UIA than he has in his fee reserves.  Effectively it will function as a bond.

The one thing I think the dev team could do better to assist the transaction, is make that special reserve acct linked to the UIA.  So at the end of the vesting period, the vested BTS will go directly to the purchaser and not the referral member.  This would alleviate cpty concerns and bring more trust into the system as a whole.  Once then this referral system will really have one to boot! 

Any thoughts?

Jonathan (@DSN) and I were discussing a similar (more trustless option than the OP) idea last night. We were wondering if it would be technically possible to create/sell a bond using vested shares as collateral. The reason I didnt post the idea is because I thought of a rebuttal:

The reason for vesting (most) of the large fees associated with the referral program is because of the "attack" that exists where someone might choose to set up a registrar/hosted walet that immediately returns the $80 of the $100 fee to the account holder, thus undermining the whole referral program. If it was possible to sell bonds collateralized with vested shares, the potential for this "attack" still exists, it just might include a small fee margin.

For example, the registrar might advertise "Register your BTS account Here and we immediately refund $70 of the $100 fee". They could then turn around and create a bond with over 5% Guaranteed interest by using $75 of the vested BTS from the registration fee, and then keep the extra $5 as their margin. The above is just one example, but in fact this "attack" could be done with any combination of "cashback offered", fee taken and bond sold.

Excellent News!!!

@phillyguy, @favdesu, Thanks for your support!

Update and Progress Report

Since last month, Jonathan and I have been working to build a simple, solid, functional and reliable platform for BitShares delegates (which now includes witnesses and workers) to organize, publish, and syndicate their shareholder updates and proposals and thus create a more efficient delivery system for vital shareholder (voter) information. We are also implementing a real time communications network similar to Slack for all account holders (both delegate and non-delegate), and a message board which will enable users to post classified listings of Meetups, Jobs/Help Wanted, Professional Services, Resumes and more. In essence, the first iteration of DPOShub.org will be a multi-facited web-based application which will include all of the functionality outlined in Phase 1 of the delegate proposal section of our whitepaper(OP of this thread), along with several bonus features that I’ve been told I am not allowed to speak about yet .

We have hired a programmer who will help us to integrate with BitShares 2.0 API so that all DPOShub account holders will have their account names verified by the blockhain. Since there is some ambiguity, not to mention future community discussion that must take place before DPOS 2.0 is fully ironed out, we are currently engaged in developing the more mundane aspects of the design and layout of DPOShub.org as well as the integration of its various feature sets.

Several community members have offered to assist with this project, and we are having ongoing discussions towards this end. Meanwhile, please consider voting for our delegate: delegate.dposhub-org, and stay tuned this thread for updates.

Thank you!