[Worker Proposal] Percentage-based transfer fees

[abit]

Update:
Jakub has approved the proposal 1.10.309 which will remove him from the authorities of bsip10-worker. See https://cryptofresh.com/p/1.10.309

Update2:
Above proposal has been approved by the Committee. the bsip-worker account is now a 2/2 multi-sig account controlled by me and the committee (see https://cryptofresh.com/u/bsip10-worker).

[abit]

From what I can tell this worker originally wanted 4.5 million BTS... They are going to receive between 3.5 and 3.6 million bts at current rates by the time the worker proposal is finished.

3.5-3.6 is your good will probably. From What I can see, it would be around 2.5.

Are we getting anything out of this or is it just 3.5 million BTS down the drain because 1 guy, who doesn't appear to be critical to the operation other than holding an owner key, disappeared?

With this special worker, the committee decides finally release the fund or not. The committee is controlled by voters. If they want to give you zero, you won't get more.

Are we getting anything? All code is public, it works fine with an earlier release. If someone wants to finish it, technically it's sure possible. Just me won't get anything.

As I predicted, the worker is voted out right now. Current balance is 2.42M.

Perhaps someone have interest to create a prediction market for this? 

[abit]

why is the Threshold 100%?

i would really like to see, that you get this funds, but the failure is the bad design of the worker proposal.

would it be not better to set the threshold to 60%?  now this, funds are locked if jakub is not coming back.

pls choose a better threshold next time.

--

what i don't get is, that the committee decided to pay the funds to make 0 fees happen, and CNX said everything is fine, and without information of the committee CNX and you decide to push this feature back. i don't get why this is handled this way. This is not a call of CNX to decide.

@abit

thanks for your hard work, you are 1 great asset this community have and i hope you will tackle more stuff
in the future.

Thanks.
This worker is not for the 0 fee feature, it's another one.
Perhaps the 0 fee feature will come earlier.

The 100% threshold is set to make the committee be able to make final judgement, it's the idea, to show our confidence, loyalty, etc. Otherwise it's no need to do like that. Maybe an option would be adding another account as 2nd escrow.

[Shentist]

why is the Threshold 100%?

i would really like to see, that you get this funds, but the failure is the bad design of the worker proposal.

would it be not better to set the threshold to 60%?  now this, funds are locked if jakub is not coming back.

pls choose a better threshold next time.

--

what i don't get is, that the committee decided to pay the funds to make 0 fees happen, and CNX said everything is fine, and without information of the committee CNX and you decide to push this feature back. i don't get why this is handled this way. This is not a call of CNX to decide.

@abit

thanks for your hard work, you are 1 great asset this community have and i hope you will tackle more stuff
in the future.

[BunkerChainLabs-DataSecurityNode]

Are we getting anything out of this or is it just 3.5 million BTS down the drain because 1 guy, who doesn't appear to be critical to the operation other than holding an owner key, disappeared?

Correction.. one anonymous guy disappeared. Thus bringing me back to my preference that workers be doxable.

He could still show up.. and if the funds become available perhaps it can be brought back to life.

Fact is though this dev working on it for months with no payment now doesn't see a way forward where he doesn't come out screwed despite his best efforts.

For a proxy voter who was overtly critical over the Committees decisions, this certainly doesn't look good for his reputation.. whatever that maybe .. being anonymous.

The work that has been done thus far has been done.. its there.. just not complete.. and the dev hasn't seen another for it and won't.

I have a feeling if there ever comes a point where @jakub does make an appearance again, I think a portion should be sent to abit for whats been done thus far.. and the rest returned to the reserve pool. @jakub shouldn't see anything for effectively derailing this project by abandoning it and also not fulfilling his work obligation. That's just my take though.

[abit]

Some updates here:

After CNX reviewed the first version of my code, we decided to postpone the development, the most important reason is this feature need to  extend the global fee schedule which I've done in my way, but we think it's best to improve the implementation of fee schedule structure first so it will be easier to be extended both this time and in the future. CNX did make some efforts on the development on fee schedule improvement, but apparently it need more efforts to have the work done. Since now the maintenance worker has been voted out (maybe temporarily), I don't know whether it will affect the development work on CNX side.

Related discussions in github:
* https://github.com/cryptonomex/graphene/issues/583
* https://github.com/cryptonomex/graphene/issues/554

Another thing is about @jakub, OP of this thread. Due to some reasons (See https://bitsharestalk.org/index.php/topic,19247.msg278204.html#msg278204), he is no longer active here (maybe temporarily, as well). IMO it's a pity. A part of work of this worker was supposed to be done by him, and he did ask for paid. I don't know if it's still possible to ask him to finish the work. Anyway, most of his work need to done after the code is stable, but now the development itself is paused, so even if he come back right now, he can only finish the work later. But if need to wait too much time, perhaps value of his work will be less than supposed (he supposed to write the first document/tutorial for coding inside Graphene).

Jakub is one of the owner authorities of creator of this worker (see https://cryptofresh.com/u/bsip10-worker), which means nobody can get payment from this worker without his approval (unless hardfork). From this POV, his inactivity is a bit annoying to other developers (mostly to me).

Yet another thing is about voting. Recently this worker became not fully funded, and probably be voted out very soon. Yes, this is the game, worker proposal is not contract, even if some parties agreed the proposal at start, nobody will guarantee the agreement will be kept to the end. Asking the committee as escrow is also a joke, since the members of committee can change every hour, so the committee can't guarantee anything. An "approved" BSIP means nothing as well. If we see BitShares as a company, it's really bad reputation.

OK, some personal words (or complaints) at the end. Perhaps I am the only loser because I've put much efforts into the work already but will get no return in the end (except so-called knowledge, skills, experience etc). For me, right now, if I found it's impossible to get what I asked 3M BTS which was accepted by whoever in this system, I won't work on this feature anymore. In addition, I tend to start working after I got 1.5M BTS (half paid) to my account (not the multi-authority account). Whatever, who cares. Will I work on other items in the system? We will see.

So you are gong to discontinue working on this, while still getting paid at the 57% funding rate??

Perhaps you missed this part in a rather large report with numerous things to address.. he didn't get paid.. he can't get paid because the other guy involved who created this worker has abandoned it. So at this point he doesn't see how everything he has done is even going to result in him getting paid anything at all unless the maker of the worker decides to show up and do something.

It would be a lot easier to handle situations like this if there was even a degree of accountability that had some semblance to the real world. ie. we have the full name, address, and contact info of the Worker prior to approving them. By maintaining an anonymous profile, it makes it that much easier to just up and leave with zero consequence.

But this worker is going to continue receiving pay correct?  Is it really the BTS shareholders fault that one of the owners disappeared?  We are paying the group of Dev's to implement the feature, once the money is in their hands the obligation should be that it is finished.  The process of how they pay each other shouldn't fall on shareholders shoulders.

From what I can tell this worker originally wanted 4.5 million BTS... They are going to receive between 3.5 and 3.6 million bts at current rates by the time the worker proposal is finished.

3.5-3.6 is your good will probably. From What I can see, it would be around 2.5.

Are we getting anything out of this or is it just 3.5 million BTS down the drain because 1 guy, who doesn't appear to be critical to the operation other than holding an owner key, disappeared?

With this special worker, the committee decides finally release the fund or not. The committee is controlled by voters. If they want to give you zero, you won't get more.

Are we getting anything? All code is public, it works fine with an earlier release. If someone wants to finish it, technically it's sure possible. Just me won't get anything.

[Pheonike]

Dont blame the worker. It was the BitShares stake holders who changed the conditions of agreement by voting it out.

[lil_jay890]

Some updates here:

After CNX reviewed the first version of my code, we decided to postpone the development, the most important reason is this feature need to  extend the global fee schedule which I've done in my way, but we think it's best to improve the implementation of fee schedule structure first so it will be easier to be extended both this time and in the future. CNX did make some efforts on the development on fee schedule improvement, but apparently it need more efforts to have the work done. Since now the maintenance worker has been voted out (maybe temporarily), I don't know whether it will affect the development work on CNX side.

Related discussions in github:
* https://github.com/cryptonomex/graphene/issues/583
* https://github.com/cryptonomex/graphene/issues/554

Another thing is about @jakub, OP of this thread. Due to some reasons (See https://bitsharestalk.org/index.php/topic,19247.msg278204.html#msg278204), he is no longer active here (maybe temporarily, as well). IMO it's a pity. A part of work of this worker was supposed to be done by him, and he did ask for paid. I don't know if it's still possible to ask him to finish the work. Anyway, most of his work need to done after the code is stable, but now the development itself is paused, so even if he come back right now, he can only finish the work later. But if need to wait too much time, perhaps value of his work will be less than supposed (he supposed to write the first document/tutorial for coding inside Graphene).

Jakub is one of the owner authorities of creator of this worker (see https://cryptofresh.com/u/bsip10-worker), which means nobody can get payment from this worker without his approval (unless hardfork). From this POV, his inactivity is a bit annoying to other developers (mostly to me).

Yet another thing is about voting. Recently this worker became not fully funded, and probably be voted out very soon. Yes, this is the game, worker proposal is not contract, even if some parties agreed the proposal at start, nobody will guarantee the agreement will be kept to the end. Asking the committee as escrow is also a joke, since the members of committee can change every hour, so the committee can't guarantee anything. An "approved" BSIP means nothing as well. If we see BitShares as a company, it's really bad reputation.

OK, some personal words (or complaints) at the end. Perhaps I am the only loser because I've put much efforts into the work already but will get no return in the end (except so-called knowledge, skills, experience etc). For me, right now, if I found it's impossible to get what I asked 3M BTS which was accepted by whoever in this system, I won't work on this feature anymore. In addition, I tend to start working after I got 1.5M BTS (half paid) to my account (not the multi-authority account). Whatever, who cares. Will I work on other items in the system? We will see.

So you are gong to discontinue working on this, while still getting paid at the 57% funding rate??

Perhaps you missed this part in a rather large report with numerous things to address.. he didn't get paid.. he can't get paid because the other guy involved who created this worker has abandoned it. So at this point he doesn't see how everything he has done is even going to result in him getting paid anything at all unless the maker of the worker decides to show up and do something.

It would be a lot easier to handle situations like this if there was even a degree of accountability that had some semblance to the real world. ie. we have the full name, address, and contact info of the Worker prior to approving them. By maintaining an anonymous profile, it makes it that much easier to just up and leave with zero consequence.

But this worker is going to continue receiving pay correct?  Is it really the BTS shareholders fault that one of the owners disappeared?  We are paying the group of Dev's to implement the feature, once the money is in their hands the obligation should be that it is finished.  The process of how they pay each other shouldn't fall on shareholders shoulders.

From what I can tell this worker originally wanted 4.5 million BTS... They are going to receive between 3.5 and 3.6 million bts at current rates by the time the worker proposal is finished.

Are we getting anything out of this or is it just 3.5 million BTS down the drain because 1 guy, who doesn't appear to be critical to the operation other than holding an owner key, disappeared?

[BunkerChainLabs-DataSecurityNode]

Some updates here:

After CNX reviewed the first version of my code, we decided to postpone the development, the most important reason is this feature need to  extend the global fee schedule which I've done in my way, but we think it's best to improve the implementation of fee schedule structure first so it will be easier to be extended both this time and in the future. CNX did make some efforts on the development on fee schedule improvement, but apparently it need more efforts to have the work done. Since now the maintenance worker has been voted out (maybe temporarily), I don't know whether it will affect the development work on CNX side.

Related discussions in github:
* https://github.com/cryptonomex/graphene/issues/583
* https://github.com/cryptonomex/graphene/issues/554

Another thing is about @jakub, OP of this thread. Due to some reasons (See https://bitsharestalk.org/index.php/topic,19247.msg278204.html#msg278204), he is no longer active here (maybe temporarily, as well). IMO it's a pity. A part of work of this worker was supposed to be done by him, and he did ask for paid. I don't know if it's still possible to ask him to finish the work. Anyway, most of his work need to done after the code is stable, but now the development itself is paused, so even if he come back right now, he can only finish the work later. But if need to wait too much time, perhaps value of his work will be less than supposed (he supposed to write the first document/tutorial for coding inside Graphene).

Jakub is one of the owner authorities of creator of this worker (see https://cryptofresh.com/u/bsip10-worker), which means nobody can get payment from this worker without his approval (unless hardfork). From this POV, his inactivity is a bit annoying to other developers (mostly to me).

Yet another thing is about voting. Recently this worker became not fully funded, and probably be voted out very soon. Yes, this is the game, worker proposal is not contract, even if some parties agreed the proposal at start, nobody will guarantee the agreement will be kept to the end. Asking the committee as escrow is also a joke, since the members of committee can change every hour, so the committee can't guarantee anything. An "approved" BSIP means nothing as well. If we see BitShares as a company, it's really bad reputation.

OK, some personal words (or complaints) at the end. Perhaps I am the only loser because I've put much efforts into the work already but will get no return in the end (except so-called knowledge, skills, experience etc). For me, right now, if I found it's impossible to get what I asked 3M BTS which was accepted by whoever in this system, I won't work on this feature anymore. In addition, I tend to start working after I got 1.5M BTS (half paid) to my account (not the multi-authority account). Whatever, who cares. Will I work on other items in the system? We will see.

So you are gong to discontinue working on this, while still getting paid at the 57% funding rate??

Perhaps you missed this part in a rather large report with numerous things to address.. he didn't get paid.. he can't get paid because the other guy involved who created this worker has abandoned it. So at this point he doesn't see how everything he has done is even going to result in him getting paid anything at all unless the maker of the worker decides to show up and do something.

It would be a lot easier to handle situations like this if there was even a degree of accountability that had some semblance to the real world. ie. we have the full name, address, and contact info of the Worker prior to approving them. By maintaining an anonymous profile, it makes it that much easier to just up and leave with zero consequence.

[lil_jay890]

Some updates here:

After CNX reviewed the first version of my code, we decided to postpone the development, the most important reason is this feature need to  extend the global fee schedule which I've done in my way, but we think it's best to improve the implementation of fee schedule structure first so it will be easier to be extended both this time and in the future. CNX did make some efforts on the development on fee schedule improvement, but apparently it need more efforts to have the work done. Since now the maintenance worker has been voted out (maybe temporarily), I don't know whether it will affect the development work on CNX side.

Related discussions in github:
* https://github.com/cryptonomex/graphene/issues/583
* https://github.com/cryptonomex/graphene/issues/554

Another thing is about @jakub, OP of this thread. Due to some reasons (See https://bitsharestalk.org/index.php/topic,19247.msg278204.html#msg278204), he is no longer active here (maybe temporarily, as well). IMO it's a pity. A part of work of this worker was supposed to be done by him, and he did ask for paid. I don't know if it's still possible to ask him to finish the work. Anyway, most of his work need to done after the code is stable, but now the development itself is paused, so even if he come back right now, he can only finish the work later. But if need to wait too much time, perhaps value of his work will be less than supposed (he supposed to write the first document/tutorial for coding inside Graphene).

Jakub is one of the owner authorities of creator of this worker (see https://cryptofresh.com/u/bsip10-worker), which means nobody can get payment from this worker without his approval (unless hardfork). From this POV, his inactivity is a bit annoying to other developers (mostly to me).

Yet another thing is about voting. Recently this worker became not fully funded, and probably be voted out very soon. Yes, this is the game, worker proposal is not contract, even if some parties agreed the proposal at start, nobody will guarantee the agreement will be kept to the end. Asking the committee as escrow is also a joke, since the members of committee can change every hour, so the committee can't guarantee anything. An "approved" BSIP means nothing as well. If we see BitShares as a company, it's really bad reputation.

OK, some personal words (or complaints) at the end. Perhaps I am the only loser because I've put much efforts into the work already but will get no return in the end (except so-called knowledge, skills, experience etc). For me, right now, if I found it's impossible to get what I asked 3M BTS which was accepted by whoever in this system, I won't work on this feature anymore. In addition, I tend to start working after I got 1.5M BTS (half paid) to my account (not the multi-authority account). Whatever, who cares. Will I work on other items in the system? We will see.

So you are gong to discontinue working on this, while still getting paid at the 57% funding rate??

[tbone]

Some updates here:

After CNX reviewed the first version of my code, we decided to postpone the development, the most important reason is this feature need to  extend the global fee schedule which I've done in my way, but we think it's best to improve the implementation of fee schedule structure first so it will be easier to be extended both this time and in the future. CNX did make some efforts on the development on fee schedule improvement, but apparently it need more efforts to have the work done. Since now the maintenance worker has been voted out (maybe temporarily), I don't know whether it will affect the development work on CNX side.

Related discussions in github:
* https://github.com/cryptonomex/graphene/issues/583
* https://github.com/cryptonomex/graphene/issues/554

Another thing is about @jakub, OP of this thread. Due to some reasons (See https://bitsharestalk.org/index.php/topic,19247.msg278204.html#msg278204), he is no longer active here (maybe temporarily, as well). IMO it's a pity. A part of work of this worker was supposed to be done by him, and he did ask for paid. I don't know if it's still possible to ask him to finish the work. Anyway, most of his work need to done after the code is stable, but now the development itself is paused, so even if he come back right now, he can only finish the work later. But if need to wait too much time, perhaps value of his work will be less than supposed (he supposed to write the first document/tutorial for coding inside Graphene).

Jakub is one of the owner authorities of creator of this worker (see https://cryptofresh.com/u/bsip10-worker), which means nobody can get payment from this worker without his approval (unless hardfork). From this POV, his inactivity is a bit annoying to other developers (mostly to me).

Yet another thing is about voting. Recently this worker became not fully funded, and probably be voted out very soon. Yes, this is the game, worker proposal is not contract, even if some parties agreed the proposal at start, nobody will guarantee the agreement will be kept to the end. Asking the committee as escrow is also a joke, since the members of committee can change every hour, so the committee can't guarantee anything. An "approved" BSIP means nothing as well. If we see BitShares as a company, it's really bad reputation.

OK, some personal words (or complaints) at the end. Perhaps I am the only loser because I've put much efforts into the work already but will get no return in the end (except so-called knowledge, skills, experience etc). For me, right now, if I found it's impossible to get what I asked 3M BTS which was accepted by whoever in this system, I won't work on this feature anymore. In addition, I tend to start working after I got 1.5M BTS (half paid) to my account (not the multi-authority account). Whatever, who cares. Will I work on other items in the system? We will see.

This is clearly a flaw in the system that needs to be fixed.  Once a proposal is approved, it needs to be funded to completion.  Of course, for this particular worker proposal we are at a standstill anyway since @jakub is not around.  Hopefully he will consider coming back, not just to complete this project, but because overall he was a very valuable, contributing member of this community. 

In the meantime, we need to move on fixing this flaw in the system ASAP.

[abit]

Some updates here:

After CNX reviewed the first version of my code, we decided to postpone the development, the most important reason is this feature need to  extend the global fee schedule which I've done in my way, but we think it's best to improve the implementation of fee schedule structure first so it will be easier to be extended both this time and in the future. CNX did make some efforts on the development on fee schedule improvement, but apparently it need more efforts to have the work done. Since now the maintenance worker has been voted out (maybe temporarily), I don't know whether it will affect the development work on CNX side.

Related discussions in github:
* https://github.com/cryptonomex/graphene/issues/583
* https://github.com/cryptonomex/graphene/issues/554

Another thing is about @jakub, OP of this thread. Due to some reasons (See https://bitsharestalk.org/index.php/topic,19247.msg278204.html#msg278204), he is no longer active here (maybe temporarily, as well). IMO it's a pity. A part of work of this worker was supposed to be done by him, and he did ask for paid. I don't know if it's still possible to ask him to finish the work. Anyway, most of his work need to done after the code is stable, but now the development itself is paused, so even if he come back right now, he can only finish the work later. But if need to wait too much time, perhaps value of his work will be less than supposed (he supposed to write the first document/tutorial for coding inside Graphene).

Jakub is one of the owner authorities of creator of this worker (see https://cryptofresh.com/u/bsip10-worker), which means nobody can get payment from this worker without his approval (unless hardfork). From this POV, his inactivity is a bit annoying to other developers (mostly to me).

Yet another thing is about voting. Recently this worker became not fully funded, and probably be voted out very soon. Yes, this is the game, worker proposal is not contract, even if some parties agreed the proposal at start, nobody will guarantee the agreement will be kept to the end. Asking the committee as escrow is also a joke, since the members of committee can change every hour, so the committee can't guarantee anything. An "approved" BSIP means nothing as well. If we see BitShares as a company, it's really bad reputation.

OK, some personal words (or complaints) at the end. Perhaps I am the only loser because I've put much efforts into the work already but will get no return in the end (except so-called knowledge, skills, experience etc). For me, right now, if I found it's impossible to get what I asked 3M BTS which was accepted by whoever in this system, I won't work on this feature anymore. In addition, I tend to start working after I got 1.5M BTS (half paid) to my account (not the multi-authority account). Whatever, who cares. Will I work on other items in the system? We will see.

[valtr]

Here you have this situation: you have abit who is surely one of the most talented guys (in technical terms) outside CNX, you have funding for the next 7 years and you hesitate whether you can afford him or not.
This is utter nonsense.

and bear in mind that 7 years in technology is too long time. The world will not be the same by that time.

[pc]

Here you have this situation: you have abit who is surely one of the most talented guys (in technical terms) outside CNX, you have funding for the next 7 years and you hesitate whether you can afford him or not.
This is utter nonsense.

[kenCode]

Even if we spent the maximum of 5 BTS per second (which is 432k per day), it would take us 7.5 years to spend all our money meant for development.
7.5 years! That's a huge amount of time in this fast-changing crypto-world.

In 7-10 years BitShares will either be huge or dead.
So we need to send the money now, not in the future, because this way the future will not come. You'll be left with unspent funds and a dead project.

Here you have this situation: you have abit who is surely one of the most talented guys (in technical terms) outside CNX, you have funding for the next 7 years and you hesitate whether you can afford him or not.
This is utter nonsense.

It's like being in a space rocket destined to Mars and being hesitant if you can afford to feed the crew.
We have exactly one astronaut willing to fly with us (no other astronaut has come forward) and we pretend that we are not sure if we can pay him a decent salary, while we sleep on unspent cash.
In a corporate environment, a board of directors making such an absurd decision would be immediately fired.

For me one thing is absolutely clear: we cannot afford to lose abit's willingness to work for us.
If we had 10 people like abit to choose from and if we were already spending 432k a day, it would make sense to think about choosing the best offer.
But we are not even close to this.

^^ THIS !!

 

[xeroc]

Even if we spent the maximum of 5 BTS per second (which is 432k per day), it would take us 7.5 years to spend all our money meant for development.
7.5 years! That's a huge amount of time in this fast-changing crypto-world.

In 7-10 years BitShares will either be huge or dead.
So we need to send the money now, not in the future, because this way the future will not come. You'll be left with unspent funds and a dead project.

Here you have this situation: you have abit who is surely one of the most talented guys (in technical terms) outside CNX, you have funding for the next 7 years and you hesitate whether you can afford him or not.
This is utter nonsense.

It's like being in a space rocket destined to Mars and being hesitant if you can afford to feed the crew.
We have exactly one astronaut willing to fly with us (no other astronaut has come forward) and we pretend that we are not sure if we can pay him a decent salary, while we sleep on unspent cash.
In a corporate environment, a board of directors making such an absurd decision would be immediately fired.

For me one thing is absolutely clear: we cannot afford to lose abit's willingness to work for us.
If we had 10 people like abit to choose from and if we were already spending 432k a day, it would make sense to think about choosing the best offer.
But we are not even close to this.

^^ THIS !!

[cube]

Thanks for asking.

But I have to agree with alt on one thing, we need a budget and control spendings. Just because we have some money it doesn't mean we can spend it on stuff just because they sound like good ideas. We need a budget...

We need a plan. We don't have one.
...

I agree with Akado. This project has a good cause and it needs support from the big stakeholders.

Perhaps by addressing their concerns, it would help gain their support.  How about working on the following (if possible and viable) ? :

1) Is there a detailed function/product specification?

Please see OP, the first page.

2) What is the projected number of transactions using the new percent-based transfer function (an estimation based on some figures would do)?  From there we can derive a projected revenue.

Sorry I didn't get your point. However, revenue largely depends on sales/marketing/direction of the whole platform, and the over all fee schedule matters a lot. If flat fee is 30 BTS and percentage fee bottom is 1 BTS, more assets will adopt percentage fee; if flat fee is 1 BTS and percentage fee bottom is 1 BTS, few if not zero asset will adopt it. Since there is lack of stable pricing strategy right now, I'm unable to give out a estimation.

3) A cost breakdown would help. 
- What are the tasks?
- How many manhours needed for each task?

4) Cost comparison.
- How is the cost of source code development and documentation manpower as compared to the market?  Some figures to compare would help.

Sorry, but manhour is nonsense. We're selling products, not labor force.

5) What are the deliverables?  What is the roadmap/timeline for the tasks and deliverables?

Please check OP.

6) Warranty for the function/product.  How long is the warranty that ensures a working function/product as stated in the specification?

I think one year of warranty is fair.
Maintenance work due to other changes is not included.

Thanks for the reply.  I believe this would help the shareholders to make a more informed decision.

[jakub]

It's all fine now, giving a few touches to the network, etc, but then when the time comes to implement big stuff (ie bond markets, other new ideas that might appear, urgent fixes, etc) that require more spending but are really needed, we won't have the money. Or we might have but will be restricting ourselves in someway, etc.

We can't just keep popping worker proposals and approve them, even though they're positive, without seeing the bigger picture and the effect those will have in the future and what limitations those will create.

Then when the time comes we won't be able to do what's really needed/urgent.

Even if we spent the maximum of 5 BTS per second (which is 432k per day), it would take us 7.5 years to spend all our money meant for development.
7.5 years! That's a huge amount of time in this fast-changing crypto-world.

In 7-10 years BitShares will either be huge or dead.
So we need to send the money now, not in the future, because this way the future will not come. You'll be left with unspent funds and a dead project.

Here you have this situation: you have abit who is surely one of the most talented guys (in technical terms) outside CNX, you have funding for the next 7 years and you hesitate whether you can afford him or not.
This is utter nonsense.

It's like being in a space rocket destined to Mars and being hesitant if you can afford to feed the crew.
We have exactly one astronaut willing to fly with us (no other astronaut has come forward) and we pretend that we are not sure if we can pay him a decent salary, while we sleep on unspent cash.
In a corporate environment, a board of directors making such an absurd decision would be immediately fired.

For me one thing is absolutely clear: we cannot afford to lose abit's willingness to work for us.
If we had 10 people like abit to choose from and if we were already spending 432k a day, it would make sense to think about choosing the best offer.
But we are not even close to this.

[abit]

Thanks for asking.

But I have to agree with alt on one thing, we need a budget and control spendings. Just because we have some money it doesn't mean we can spend it on stuff just because they sound like good ideas. We need a budget...

We need a plan. We don't have one.
...

I agree with Akado. This project has a good cause and it needs support from the big stakeholders.

Perhaps by addressing their concerns, it would help gain their support.  How about working on the following (if possible and viable) ? :

1) Is there a detailed function/product specification?

Please see OP, the first page.

2) What is the projected number of transactions using the new percent-based transfer function (an estimation based on some figures would do)?  From there we can derive a projected revenue.

Sorry I didn't get your point. However, revenue largely depends on sales/marketing/direction of the whole platform, and the over all fee schedule matters a lot. If flat fee is 30 BTS and percentage fee bottom is 1 BTS, more assets will adopt percentage fee; if flat fee is 1 BTS and percentage fee bottom is 1 BTS, few if not zero asset will adopt it. Since there is lack of stable pricing strategy right now, I'm unable to give out a estimation.

3) A cost breakdown would help. 
- What are the tasks?
- How many manhours needed for each task?

4) Cost comparison.
- How is the cost of source code development and documentation manpower as compared to the market?  Some figures to compare would help.

Sorry, but manhour is nonsense. We're selling products, not labor force.

5) What are the deliverables?  What is the roadmap/timeline for the tasks and deliverables?

Please check OP.

6) Warranty for the function/product.  How long is the warranty that ensures a working function/product as stated in the specification?

I think one year of warranty is fair.
Maintenance work due to other changes is not included.

[cube]

But I have to agree with alt on one thing, we need a budget and control spendings. Just because we have some money it doesn't mean we can spend it on stuff just because they sound like good ideas. We need a budget...

We need a plan. We don't have one.
...

I agree with Akado. This project has a good cause and it needs support from the big stakeholders.

Perhaps by addressing their concerns, it would help gain their support.  How about working on the following (if possible and viable) ? :

1) Is there a detailed function/product specification?

2) What is the projected number of transactions using the new percent-based transfer function (an estimation based on some figures would do)?  From there we can derive a projected revenue.

3) A cost breakdown would help. 
- What are the tasks?
- How many manhours needed for each task?

4) Cost comparison.
- How is the cost of source code development and documentation manpower as compared to the market?  Some figures to compare would help.

5) What are the deliverables?  What is the roadmap/timeline for the tasks and deliverables?

6) Warranty for the function/product.  How long is the warranty that ensures a working function/product as stated in the specification?

[abit]

More progresses have been made recently.

With a new patch, now the Committee can set percentage market(trading) fees and/or percentage transfer fee for BTS. Details described in this post https://bitsharestalk.org/index.php/topic,21080.0.html.

Thanks for your support.

[chryspano]

Alt is probably waiting for the barbarians...

[abit]

@alt could you share what workers would you support? Meaning, which workers you think we need. That are indeed useful and not unnecessary? Any feature or something else in particular?

Sorry for asking here but alt doesn't have a proxy thread on the proxy sub

alt seems to reject all existing workers:
http://cryptofresh.com/u/baozi

I wanted to know if he would support something else, exactly because of that. What potential workers could be on his priority list. I'm talking about possible workers that could be created for a specific task, not necessarily the ones that already exist.

But I have to agree with alt on one thing, we need a budget and control spendings. Just because we have some money it doesn't mean we can spend it on stuff just because they sound like good ideas. We need a budget, see potential consequences in the future and have a list of the main stuff people and the network needs. And then, from that, we prioritize according to our budget and what's needed the most.

Then once that task is done, we do it all over again to re-evaluate our position and see if we can do more stuff next, if we should wait a few months, go for alternatives, etc.

We need a plan. We don't have one.

It's all fine now, giving a few touches to the network, etc, but then when the time comes to implement big stuff (ie bond markets, other new ideas that might appear, urgent fixes, etc) that require more spending but are really needed, we won't have the money. Or we might have but will be restricting ourselves in someway, etc.

We can't just keep popping worker proposals and approve them, even though they're positive, without seeing the bigger picture and the effect those will have in the future and what limitations those will create.

Then when the time comes we won't be able to do what's really needed/urgent.

If we don't have enough qualify developers, when the time comes, we'll have no one can help us. If we ask them to work for others to make a live now, when we need them to come back, why do you think they will? Why do you think you're so important when you need them?

Not everyone are entrepreneurs. Not everyone have the ability/interest to talk to VCs.

[jakub]

we need more developers like toast to ETH,
who can tell me how much payment does toast got from ETH?
how much payment does toast got from BTS?
finally, toast give his valuable to who?

@alt
I'm glad you've brought up the ETH example.
How would answer these questions:

(1) Does ETH have a detailed budget and a financial plan with strict price tags? I don't mean a general roadmap, I mean a detailed financial plan, as you expect us to have.

(2) I guess you are aware that ETH is currently diluting massively running its POW (and this will continue until they have some POS sorted out). How come this kind of dilution not bother you? According to your stock price "theory", ETH price should have tanked massively long time ago.

(3) If there was a company that dilutes 20% a year but makes a steady progress in building some amazing invention - do you really expect its stock price to continuously drop and finally reach zero?  Don't you think it's the expectation of the future value of a company that actually determines the stock price?

I think your approach is quite simple: you believe that xeroc's work is *not* worth the price he's asking for. The same applies for svk, cass, abit and CNX.
If you believed it was worth the price, you would have willingly paid the price. Simple as that. That's a rational behavior for our species.

Instead, you keep repeating how you appreciate their work, but when it comes to actually valuing this work, with the only objective tool that we have at our disposal (i.e. money), you just say the opposite.

EDIT: A simple test to verify if my hypothesis has any value:
If xeroc offered to work for us for $1 a day, would you still reject his worker on the basis that we cannot have any dilution?
I guess you would not be this crazy and you would accept xeroc's offer in this case. So $1 a day is some sort of estimate of the lower bound of the value of xeroc's work.

Then we could continue this experiment by raising xeroc's offer to $2 a day, $5 a day, $10 a day etc, until we reach a point when you decide to reject his offer. And this will be the financial value of xeroc's work, in your eyes.

My point is: xeroc's work has some positive financial value and this value is quite independent from our company's financial situation.
As long as we have money to spend, and we feel that spending this money brings more value to the company than it costs, the rational thing to do is spend the money, no matter what the market cap is.

[Akado]

@alt could you share what workers would you support? Meaning, which workers you think we need. That are indeed useful and not unnecessary? Any feature or something else in particular?

Sorry for asking here but alt doesn't have a proxy thread on the proxy sub

alt seems to reject all existing workers:
http://cryptofresh.com/u/baozi

I wanted to know if he would support something else, exactly because of that. What potential workers could be on his priority list. I'm talking about possible workers that could be created for a specific task, not necessarily the ones that already exist.

But I have to agree with alt on one thing, we need a budget and control spendings. Just because we have some money it doesn't mean we can spend it on stuff just because they sound like good ideas. We need a budget, see potential consequences in the future and have a list of the main stuff people and the network needs. And then, from that, we prioritize according to our budget and what's needed the most.

Then once that task is done, we do it all over again to re-evaluate our position and see if we can do more stuff next, if we should wait a few months, go for alternatives, etc.

We need a plan. We don't have one.

It's all fine now, giving a few touches to the network, etc, but then when the time comes to implement big stuff (ie bond markets, other new ideas that might appear, urgent fixes, etc) that require more spending but are really needed, we won't have the money. Or we might have but will be restricting ourselves in someway, etc.

We can't just keep popping worker proposals and approve them, even though they're positive, without seeing the bigger picture and the effect those will have in the future and what limitations those will create.

Then when the time comes we won't be able to do what's really needed/urgent.

[jakub]

@alt could you share what workers would you support? Meaning, which workers you think we need. That are indeed useful and not unnecessary? Any feature or something else in particular?

Sorry for asking here but alt doesn't have a proxy thread on the proxy sub

alt seems to reject all existing workers:
http://cryptofresh.com/u/baozi

[alt]

@alt could you share what workers would you support? Meaning, which workers you think we need. That are indeed useful and not unnecessary? Any feature or something else in particular?

Sorry for asking here but alt doesn't have a proxy thread on the proxy sub

first we need a budget, then I can decide how to use these money.
If I have 1million USD, I can hire many worker, do many development works.
If I have 10K USD, I will use these money carefully

how to use these money?
I need a  task list, analyze each task,give them a priority, put down  a roadmap....
I will try to ask for a cheap price for every task I have to do.

now, we have no manager, we spent money very genous like we are very rich, and have no plan, like a blind.

I agree with you on that.

Do you have any idea of those tasks? Any that you think is important and would at the top of your list with more priority? Ignoring the budget for now, I'm interested in knowing the tasks you think are important for BitShares at the moment, if you could share.

I guess we are much more faster than all others blockchain, even ETH.
we just need to focus on develop our business now.
I encourage all developer, try to find a partner, develop a startup business, seek the venture capital.

we need more developers like toast to ETH,
who can tell me how much payment does toast got from ETH?
how much payment does toast got from BTS?
finally, toast give his valuable to who?

[Akado]

@alt could you share what workers would you support? Meaning, which workers you think we need. That are indeed useful and not unnecessary? Any feature or something else in particular?

Sorry for asking here but alt doesn't have a proxy thread on the proxy sub

first we need a budget, then I can decide how to use these money.
If I have 1million USD, I can hire many worker, do many development works.
If I have 10K USD, I will use these money carefully

how to use these money?
I need a  task list, analyze each task,give them a priority, put down  a roadmap....
I will try to ask for a cheap price for every task I have to do.

now, we have no manager, we spent money very genous like we are very rich, and have no plan, like a blind.

I agree with you on that.

Do you have any idea of those tasks? Any that you think is important and would at the top of your list with more priority? Ignoring the budget for now, I'm interested in knowing the tasks you think are important for BitShares at the moment, if you could share.

[alt]

@alt could you share what workers would you support? Meaning, which workers you think we need. That are indeed useful and not unnecessary? Any feature or something else in particular?

Sorry for asking here but alt doesn't have a proxy thread on the proxy sub

first we need a budget, then I can decide how to use these money.
If I have 1million USD, I can hire many worker, do many development works.
If I have 10K USD, I will use these money carefully

how to use these money?
I need a  task list, analyze each task,give them a priority, put down  a roadmap....
I will try to ask for a cheap price for every task I have to do.

now, we have no manager, we spent money very genous like we are very rich, and have no plan, like a blind.

[Akado]

@alt could you share what workers would you support? Meaning, which workers you think we need. That are indeed useful and not unnecessary? Any feature or something else in particular?

Sorry for asking here but alt doesn't have a proxy thread on the proxy sub

[alt]

@alt , is there any particular reason your proxy (baozi) is actively voting against this proposal?

I don't know why we need this function,
it  make system more complex and uncertainty.
and we don't have enough money to pay for these unemergency works
and I against all dilution workers before we have a strict rule and budget plan

I believe when we dilution 1 USD value BTS, the share holders will lose more than 10 USD.

How so?

Do you think the committee would use their accumulated fee income to pay for workers instead?
I welcome your approach and am willing to be payed by other means as long as can fill my fridge

from the experience of a  common stock trade market, there are about 5%  shares active in the trade,
so if there are 1m USD available in the market trade for BTS, there are about 20m USD market cap for BTS.

for most workers, they sold  all BTS got from the payment at current price, and take away these money from market.
if they sold 10k USD, the market cap reduce 10k*20 = 200K USD
and these will caused more desperate money leave BTS at such a low price.

If I am the owner of a componey which stock is very low,
I should try to buy back as more stock as I can, not sold out, not dilution
If I don't have any money to buy back, at least I don't dilution
If I really need dilution some stock to pay for development, I only pay for the development I have to do.
If I  dilution any stock to pay for any development as I like, I guess other share holders want to killing me, more and more people will leave.

[jakub]

@alt , is there any particular reason your proxy (baozi) is actively voting against this proposal?

[kenCode]

@tbone , following your suggestion, I've made a pull request for the BSIP to include the fiat-stability issue that you've raised.
https://github.com/bitshares/bsips/pull/10
Thank you for the feedback.

Indeed!

[jakub]

Considering that your proposal includes a section entitled "rationale", one would think you'd discuss what limits you'd be targeting and how.  But you did not even touch the subject.  Even your post that introduced and linked the proposal said nothing of targeting stable limits.  I appreciate all of your efforts, but I'm sure you can see why I was so surprised.

Stable limits are simply not subject of this proposal. We just took on the task of introducing the percentage-based fees mechanism itself.
If I understand you correctly, you imply that this proposal is incomplete without the mechanism to keep the limits stable.

As far as I know, @xeroc is actively working on just that: an automated way to keep all fees synced to fiat-defined targets.
So if we combine our proposal with xeroc's project, we should end up with a complete, fiat-stable solution.

My problem is not that the mechanism was not included in the proposal.  I was just surprised you didn't mention in the proposal itself (or in your post introducing it) that the idea is to combine the proposal with some external mechanism intended to target stable fee limits.  Anyway, I'm glad to hear this is something that is being taken seriously.

@tbone , following your suggestion, I've made a pull request for the BSIP to include the fiat-stability issue that you've raised.
https://github.com/bitshares/bsips/pull/10

Thank you for the feedback.

[tbone]

Considering that your proposal includes a section entitled "rationale", one would think you'd discuss what limits you'd be targeting and how.  But you did not even touch the subject.  Even your post that introduced and linked the proposal said nothing of targeting stable limits.  I appreciate all of your efforts, but I'm sure you can see why I was so surprised.

Stable limits are simply not subject of this proposal. We just took on the task of introducing the percentage-based fees mechanism itself.
If I understand you correctly, you imply that this proposal is incomplete without the mechanism to keep the limits stable.

As far as I know, @xeroc is actively working on just that: an automated way to keep all fees synced to fiat-defined targets.
So if we combine our proposal with xeroc's project, we should end up with a complete, fiat-stable solution.

My problem is not that the mechanism was not included in the proposal.  I was just surprised you didn't mention in the proposal itself (or in your post introducing it) that the idea is to combine the proposal with some external mechanism intended to target stable fee limits.  Anyway, I'm glad to hear this is something that is being taken seriously. 

[kuro112]

this is the first proposals that i agree with the idea, cost, and method of implementation,

other people looking to do proposals should use this as a guideline to a realistic cost/benefit ratio.

hope it all works out, you have my vote.

 

[xeroc]

As far as I know, @xeroc is actively working on just that: an automated way to keep all fees synced to fiat-defined targets.
So if we combine our proposal with xeroc's project, we should end up with a complete, fiat-stable solution.

Those scripts do already exists and the committee is trying to figure out which fees to actually set.
A "complete" fiat peg may not be as easy but may have slight variance due to the facts that
a) BTS is volatile against USD
b) the committee proposal have a review period of currently 1h (and hopefully LONGER eventually to show some stability)

[jakub]

Considering that your proposal includes a section entitled "rationale", one would think you'd discuss what limits you'd be targeting and how.  But you did not even touch the subject.  Even your post that introduced and linked the proposal said nothing of targeting stable limits.  I appreciate all of your efforts, but I'm sure you can see why I was so surprised.

Stable limits are simply not subject of this proposal. We just took on the task of introducing the percentage-based fees mechanism itself.
If I understand you correctly, you imply that this proposal is incomplete without the mechanism to keep the limits stable.

As far as I know, @xeroc is actively working on just that: an automated way to keep all fees synced to fiat-defined targets.
So if we combine our proposal with xeroc's project, we should end up with a complete, fiat-stable solution.

[xeroc]

Considering that your proposal includes a section entitled "rationale", one would think you'd discuss what limits you'd be targeting and how.  But you did not even touch the subject.  Even your post that introduced and linked the proposal said nothing of targeting stable limits.  I appreciate all of your efforts, but I'm sure you can see why I was so surprised.

He made very clear in the bsip that they will solely provide the infrastructure to make those decisions and that the committee will have to decide on those numbers.

[tbone]

No, I believe the 6BTS floor is the mandatory minimum that must be paid to the network, anything above that would be split between the network and referrers.  I hope I'm missing something, otherwise this is just idiotic and will put me right near my wit's end with all of this.

6 go to the network .. everything above 6 goes to referral program

Yes, that's exactly what I said already -- the minimum to the network is 6BTS.  But the point is, what does 6BTS mean to users or to a business?  Today it means about $.02.  In a few months it could mean $.20.  How can a business build around that?  One of the rationales of this proposal is to preserve the referral program.  Yet the referrers now have much more uncertainty.  In fact, based on today's BTS value in USD, if this proposal goes through, a $200 transfer with a .1% fee would generate the equivalent of a $.20 fee, or about 60BTS.  The network would keep 6BTS plus 20% of the remaining 14BTS, leaving the other 80% of the 14BTS for the referrer. 

Now let's say, just as an example, the value of BTS goes up 10X in the coming months.  Now that same transaction fee of .20 would be the equivalent of 6BTS, so the network would take 100% and the referrer would get nothing.  So much for protecting the referral program. 

Not to mention, if the value of BTS goes up any further than that, the actual rate to the user would go up.  Or for a business built atop Bitshares, their costs would be higher due to the increased fees, potentially making their model non-viable.   

Again, unless I'm missing something, I have to say WTF are we doing here?!

@tbone
Please note that the values used in the BSIP are just an example. So those values are not really part of the proposal. I needed them just to illustrate how the mechanism would work. Maybe I could have used symbolic letters instead of numbers to avoid this confusion.

We only create a tool, it's the committee who sets the values for the parameters.

But I guess your main point is that the values are expressed in BTS, not fiat. Well, that's a problem that refers to all fees, not just those related to our proposal.

If I remember correctly, in the blockchain settings we have a tool that addresses this - I think it's called multiplier or something similar.
It enables the committee to automatically adjust all fees by a given factor and this way keep the fees in sync with BTS value.

Considering that your proposal includes a section entitled "rationale", one would think you'd discuss what limits you'd be targeting and how.  But you did not even touch the subject.  Even your post that introduced and linked the proposal said nothing of targeting stable limits.  I appreciate all of your efforts, but I'm sure you can see why I was so surprised.

[jakub]

Our total budget is 4.4m BTS, with the following split:

We appreciate your votes for 1.14.29!

Excellent work!

Minor nit: the proposal is for 50k per day for 90 days which is 4.5m BTS not 4.4m?

Thank you, pc.

You're right. There is a slight mismatch in this respect. It was not intended.

However, we will not take more payment than declared (the multi-sig account controlled by the committee will not allow us to) and any excess (including any excess from the testing budget) will be burned or returned to the pool - whatever the committee decides.

[pc]

Our total budget is 4.4m BTS, with the following split:

We appreciate your votes for 1.14.29!

Excellent work!

Minor nit: the proposal is for 50k per day for 90 days which is 4.5m BTS not 4.4m?

[abit]

If I remember correctly, in the blockchain settings we have a tool that addresses this - I think it's called multiplier or something similar.
It enables the committee to automatically adjust all fees by a given factor and this way keep the fees in sync with BTS value.

It's called "scale", which is currently set to "1x".
There was a bug related to it.
I may need to check my code again to ensure I handled it properly.

[jakub]

No, I believe the 6BTS floor is the mandatory minimum that must be paid to the network, anything above that would be split between the network and referrers.  I hope I'm missing something, otherwise this is just idiotic and will put me right near my wit's end with all of this.

6 go to the network .. everything above 6 goes to referral program

Yes, that's exactly what I said already -- the minimum to the network is 6BTS.  But the point is, what does 6BTS mean to users or to a business?  Today it means about $.02.  In a few months it could mean $.20.  How can a business build around that?  One of the rationales of this proposal is to preserve the referral program.  Yet the referrers now have much more uncertainty.  In fact, based on today's BTS value in USD, if this proposal goes through, a $200 transfer with a .1% fee would generate the equivalent of a $.20 fee, or about 60BTS.  The network would keep 6BTS plus 20% of the remaining 14BTS, leaving the other 80% of the 14BTS for the referrer. 

Now let's say, just as an example, the value of BTS goes up 10X in the coming months.  Now that same transaction fee of .20 would be the equivalent of 6BTS, so the network would take 100% and the referrer would get nothing.  So much for protecting the referral program. 

Not to mention, if the value of BTS goes up any further than that, the actual rate to the user would go up.  Or for a business built atop Bitshares, their costs would be higher due to the increased fees, potentially making their model non-viable.   

Again, unless I'm missing something, I have to say WTF are we doing here?!

@tbone
Please note that the values used in the BSIP are just an example. So those values are not really part of the proposal. I needed them just to illustrate how the mechanism would work. Maybe I could have used symbolic letters instead of numbers to avoid this confusion.

We only create a tool, it's the committee who sets the values for the parameters.

But I guess your main point is that the values are expressed in BTS, not fiat. Well, that's a problem that refers to all fees, not just those related to our proposal.

If I remember correctly, in the blockchain settings we have a tool that addresses this - I think it's called multiplier or something similar.
It enables the committee to automatically adjust all fees by a given factor and this way keep the fees in sync with BTS value.

[abit]

Can the the flat/percentage be dynamic? What I mean is the system checks to see which fee is cheapest in terms of a default reference fiat (USD,CNY,EUR).  So in addition to setting the flat fee and percent, the issue er can also set a parameter like "if flat fee) > X in fiat terms then use percentage fee. Maybe even charge the issue er a fee for extra resources to compute the fee if they choose this option.

Good idea. Thanks.
Perhaps this would be an option in the future, but won't be in this proposal.

[Pheonike]

Can the the flat/percentage be dynamic? What I mean is the system checks to see which fee is cheapest in terms of a default reference fiat (USD,CNY,EUR).  So in addition to setting the flat fee and percent, the issue er can also set a parameter like "if flat fee) > X in fiat terms then use percentage fee. Maybe even charge the issue er a fee for extra resources to compute the fee if they choose this option.

[abit]

I wonder whether one change is possible.

as I found the endless debate on transfer fee mainly come from the different business culture around the world, in China referral program is just a trouble maker, but maybe it works in US and western europe. so I also consider to split the transfer fee charging mode in order to fit the difference. the flat fee mode will be irrelevant with referral program, all the fee go to network, while for percent-based-fee mode, some part of the fee will go to the referrer.

is it possible to make the flat fee mode irrelevant with referral program?

Technically I can write code like this. But whether to do it should be decided by stake holders.

[abit]

@jakub, I understand why fees need to be charged in BTS.  But why are you not defining a target minimum fee in terms of a stable currency so that when BTS goes up ten-fold, we don't have this minimum fee also going up ten-fold?  Surely you realized that having a moving target like this means that a business model that works today may not work tomorrow.  And some users that are happy with the fees today, will not be happy tomorrow.  You are ensuring uncertainty when it comes fees, which will likely wreak major havoc.  Why are you doing that?  It seems misguided and very unnecessary.  Unless I'm missing something.  Care to explain?

From what I understood, the floor and cap is defined by each issuer and can be changed on a per asset bases as frequently as needed ..

With current BSIP, global floor/cap/percentage is defined by the committee, issuers can not define them. Otherwise the issuer will be able to game the referral program.

No, I believe the 6BTS floor is the mandatory minimum that must be paid to the network, anything above that would be split between the network and referrers.  I hope I'm missing something, otherwise this is just idiotic and will put me right near my wit's end with all of this.

6 go to the network .. everything above 6 goes to referral program

Yes, that's exactly what I said already -- the minimum to the network is 6BTS.  But the point is, what does 6BTS mean to users or to a business?  Today it means about $.02.  In a few months it could mean $.20.  How can a business build around that?  One of the rationales of this proposal is to preserve the referral program.  Yet the referrers now have much more uncertainty.  In fact, based on today's BTS value in USD, if this proposal goes through, a $200 transfer with a .1% fee would generate the equivalent of a $.20 fee, or about 60BTS.  The network would keep 6BTS plus 20% of the remaining 14BTS, leaving the other 80% of the 14BTS for the referrer. 

Now let's say, just as an example, the value of BTS goes up 10X in the coming months.  Now that same transaction fee of .20 would be the equivalent of 6BTS, so the network would take 100% and the referrer would get nothing.  So much for protecting the referral program. 

Not to mention, if the value of BTS goes up any further than that, the actual rate to the user would go up.  Or for a business built atop Bitshares, their costs would be higher due to the increased fees, potentially making their model non-viable.   

Again, unless I'm missing something, I have to say WTF are we doing here?!

The committee is responsible to adjust the global floor/cap when BTS price arise/drop by x%.

[tbone]

No, I believe the 6BTS floor is the mandatory minimum that must be paid to the network, anything above that would be split between the network and referrers.  I hope I'm missing something, otherwise this is just idiotic and will put me right near my wit's end with all of this.

6 go to the network .. everything above 6 goes to referral program

Yes, that's exactly what I said already -- the minimum to the network is 6BTS.  But the point is, what does 6BTS mean to users or to a business?  Today it means about $.02.  In a few months it could mean $.20.  How can a business build around that?  One of the rationales of this proposal is to preserve the referral program.  Yet the referrers now have much more uncertainty.  In fact, based on today's BTS value in USD, if this proposal goes through, a $200 transfer with a .1% fee would generate the equivalent of a $.20 fee, or about 60BTS.  The network would keep 6BTS plus 20% of the remaining 14BTS, leaving the other 80% of the 14BTS for the referrer. 

Now let's say, just as an example, the value of BTS goes up 10X in the coming months.  Now that same transaction fee of .20 would be the equivalent of 6BTS, so the network would take 100% and the referrer would get nothing.  So much for protecting the referral program. 

Not to mention, if the value of BTS goes up any further than that, the actual rate to the user would go up.  Or for a business built atop Bitshares, their costs would be higher due to the increased fees, potentially making their model non-viable.   

Again, unless I'm missing something, I have to say WTF are we doing here?!

[Ben Mason]

This is so important and you've put in a great deal of effort to do it right. You have my full support. Thank you.

Bitcrab, thank you for your input, sincerity and being open to all ideas.

[xeroc]

No, I believe the 6BTS floor is the mandatory minimum that must be paid to the network, anything above that would be split between the network and referrers.  I hope I'm missing something, otherwise this is just idiotic and will put me right near my wit's end with all of this.

6 go to the network .. everything above 6 goes to referral program

[tbone]

@jakub, I understand why fees need to be charged in BTS.  But why are you not defining a target minimum fee in terms of a stable currency so that when BTS goes up ten-fold, we don't have this minimum fee also going up ten-fold?  Surely you realized that having a moving target like this means that a business model that works today may not work tomorrow.  And some users that are happy with the fees today, will not be happy tomorrow.  You are ensuring uncertainty when it comes fees, which will likely wreak major havoc.  Why are you doing that?  It seems misguided and very unnecessary.  Unless I'm missing something.  Care to explain?

From what I understood, the floor and cap is defined by each issuer and can be changed on a per asset bases as frequently as needed ..

No, I believe the 6BTS floor is the mandatory minimum that must be paid to the network, anything above that would be split between the network and referrers.  I hope I'm missing something, otherwise this is just idiotic and will put me right near my wit's end with all of this.

[xeroc]

@jakub, I understand why fees need to be charged in BTS.  But why are you not defining a target minimum fee in terms of a stable currency so that when BTS goes up ten-fold, we don't have this minimum fee also going up ten-fold?  Surely you realized that having a moving target like this means that a business model that works today may not work tomorrow.  And some users that are happy with the fees today, will not be happy tomorrow.  You are ensuring uncertainty when it comes fees, which will likely wreak major havoc.  Why are you doing that?  It seems misguided and very unnecessary.  Unless I'm missing something.  Care to explain?

From what I understood, the floor and cap is defined by each issuer and can be changed on a per asset bases as frequently as needed ..

[tbone]

@jakub, I understand why fees need to be charged in BTS.  But why are you not defining a target minimum fee in terms of a stable currency so that when BTS goes up ten-fold, we don't have this minimum fee also going up ten-fold?  Surely you realized that having a moving target like this means that a business model that works today may not work tomorrow.  And some users that are happy with the fees today, will not be happy tomorrow.  You are ensuring uncertainty when it comes fees, which will likely wreak major havoc.  Why are you doing that?  It seems misguided and very unnecessary.  Unless I'm missing something.  Care to explain?

[kenCode]

Great work @jakub you guys have my/our full support.

[bitcrab]

I wonder whether one change is possible.

as I found the endless debate on transfer fee mainly come from the different business culture around the world, in China referral program is just a trouble maker, but maybe it works in US and western europe. so I also consider to split the transfer fee charging mode in order to fit the difference. the flat fee mode will be irrelevant with referral program, all the fee go to network, while for percent-based-fee mode, some part of the fee will go to the referrer.

is it possible to make the flat fee mode irrelevant with referral program?

 

[jakub]

As suggested by xeroc, I've amended the BSIP to make this issue clear:

The choice of the fee model is not meant to be permanent.
The issuer is always free to change his mind and switch back and forth between flat and percentage-based modes.

The only thing the issuer needs to consider, is the marketing aspect.

[xeroc]

I just want to emphasize one important aspect: this worker proposal is
the first ever attempt to introduce a significant new feature to
Graphene (and BitShares) without the direct involvement from CNX. If we
are successful, this proposal will pave the way for other entrepreneurs
and developers to follow in our footsteps and make BitShares less
dependent on CNX.

This is a great step forward!

As stated in the BSIP,  we would like to make detailed documentation a
crucial part of this proposal, thus offering an important benefit for
the whole ecosystem. The documentation produced as a result of this work
will help other developers to join the ecosystem and offer worker
proposals for further features.

This is GREAT and I would love to contrinute as much as possible.

- unit testing and testnet testing (by abit & jakub, hopefully with the help from xeroc),

Sure thing

As for vesting, initially we intended to make at least 50% of the payout
vest for a year.  However, some of our expenses (e.g. code review or GUI
support) require immediate vesting, so we've concluded that we will
stick to immediate vesting but we will introduce an escrow in the form
of the committee-account, so that no payouts can be made without the
committee agreeing that the goal of this proposal has been achieved.
https://cryptofresh.com/u/bsip10-worker

This is a great idea!

As for the time-frame (assuming the worker proposal gets approved by mid Feb):
- we estimate that 6 weeks are needed to complete the coding
- further 2 weeks are needed to produce unit tests and GUI support
- further 2 weeks should be reserved for code review and potential fixes after the review
- further 2 weeks should be reserved for testing on the public testnet
Therefore a total of 12 weeks is our target.
The process of creating full documentation will be done in parallel and should be complete before deployment.

If you have any questions or concerns, please ask in this thread.
We appreciate your votes for 1.14.29!

I support this. Reasonable price a lot to benefit. I will need to re-read the BSIP first, though

[jakub]

As announced previously in this thread by me and this thread by abit, we have created a worker proposal for percentage-based transfer fees.
You'll find it in the CLI under this id: 1.14.29 and in the GUI under this title: [BSIP10] Percentage-based transfer fee solution based on CER.

A detailed description, in the form of a BSIP, can be found on github:
https://github.com/bitshares/bsips/blob/master/bsip-0010.md

The main goal of this proposal is to make BitShares viable for transferring smaller amounts. The current flat transfer rate is not friendly for small transfers, as for these transfers the flat transfer fee makes up a significant part of the amount being sent. We want to change that by making the fee proportional to the amount being sent, thus strictly related to the usefulness of the transfer as perceived by the user. The important thing is that we will end up with two transfer fee modes (flat and percentage-based) and it will be up to issuers to choose the best option for their assets. So this is an opt-in feature decided by the issuer (committee members in case of public SmartCoins).

Also, our aim is to open up BitShares for micro-payments without doing any damage to the referral program. However, this aspect largely depends on the parameter settings that will ultimately be decided by the committee.

The concept itself, our approach and the expected outcome have all been explained in details in the BSIP so I won't repeat it here.

I just want to emphasize one important aspect: this worker proposal is the first ever attempt to introduce a significant new feature to Graphene (and BitShares) without the direct involvement from CNX. If we are successful, this proposal will pave the way for other entrepreneurs and developers to follow in our footsteps and make BitShares less dependent on CNX.

As stated in the BSIP,  we would like to make detailed documentation a crucial part of this proposal, thus offering an important benefit for the whole ecosystem. The documentation produced as a result of this work will help other developers to join the ecosystem and offer worker proposals for further features.

Our proposal includes the whole package:
- the coding (by abit),
- the code review (by CNX),
- unit testing and testnet testing (by abit & jakub, hopefully with the help from xeroc),
- full documentation & guidelines for similar projects (by jakub),
- GUI support (by svk).

As for known limitations of this proposal, please refer to the BSIP.
The most important one is this: our proposal is unable to cover stealth transfers (due to the very nature of stealth transactions).

Our total budget is 4.4m BTS, with the following split:
- abit: 3000k
- jakub: 800k
- CNX: 350k
- svk: 120k
- budget for testing: 130k

As for vesting, initially we intended to make at least 50% of the payout vest for a year.
However, some of our expenses (e.g. code review or GUI support) require immediate vesting, so we've concluded that we will stick to immediate vesting but we will introduce an escrow in the form of the committee-account, so that no payouts can be made without the committee agreeing that the goal of this proposal has been achieved.
https://cryptofresh.com/u/bsip10-worker

As for the time-frame (assuming the worker proposal gets approved by mid Feb):
- we estimate that 6 weeks are needed to complete the coding
- further 2 weeks are needed to produce unit tests and GUI support
- further 2 weeks should be reserved for code review and potential fixes after the review
- further 2 weeks should be reserved for testing on the public testnet
Therefore a total of 12 weeks is our target.
The process of creating full documentation will be done in parallel and should be complete before deployment.

If you have any questions or concerns, please ask in this thread.
We appreciate your votes for 1.14.29!