CPOS (cooperative proof of stake) discussion thread

[gamey]

My thing is that taking money from transactions fees is effectively the same as dilution.  Those transaction fees are profit that should go to shareholders (in a general sense).  So in the end, you're just decreasing the amount that shareholders receive to pay for expenses. Since dividends etc are paid in shares, it all seems like the same thing to me.  After reading Delulo's last response I thought "Oh, the user is paying the bill and thats why transaction fees are different than dilution".   Yet take it a bit further and it seems to end up being another form of dilution but just one that seems more appealing. 

[santaclause102]

If the developer is payed by transaction fees, a new developer can still take over.  No one should invest in a company that considers taxing the shareholders to cover expenses part of its long term business plan.  After the capital investment raised by selling shares is consumed, the business should be sustainable on revenue from customers.  If it permanently draws value from shareholders through dilution, rather than rewarding them with dividends, it's a zombie.

I don't have a grasp on transaction fees and how many/when a DAC would pay..  I also don't understand why transaction fees are not being considered a "tax".  Yes, a company that permanently draws value from shareholders without ever paying dividends will likely die.  That is fairly obvious, but you could (depending on your definition of dilution) dilute while rewarding with dividends.

I see no reason why transaction fees are any better than a reasonable preplanned dilution.  Paying agents/employees all comes from the same place in the end, no matter how you calculate or name it.  Those transaction fees could belong to shareholders just as much as a developer.  Honestly.. I just do not understand these distinctions.  Is it nothing more than ideology and anything that appears like a tax gets the bad connotations that go along with taxes?  Is that whats going on?

It's fairly simple. For any company there are three ways of paying for expenses:
Money raised from initial sell of shares. This is limited and fixed compared to the other two and will be used up at some point.
Income = tx fees in our case which are paid by those using the service.
Dilution which is paid by all shareholders. Also see the bottom of https://bitsharestalk.org/index.php?topic=4713.msg60584#msg60584 for a more specific definition.
The income source is always preferable. The initially raised money tends to be something a development team plans with to hire people being able to assure them to be able to pay them for a year or so. The question is just whether it makes sense to dilute shareholders if an aggressive marketing/expansion strategy is considered effective and the income source and the initially raised money is not enough to cover that. 

[gamey]

If the developer is payed by transaction fees, a new developer can still take over.  No one should invest in a company that considers taxing the shareholders to cover expenses part of its long term business plan.  After the capital investment raised by selling shares is consumed, the business should be sustainable on revenue from customers.  If it permanently draws value from shareholders through dilution, rather than rewarding them with dividends, it's a zombie.

I don't have a grasp on transaction fees and how many/when a DAC would pay..  I also don't understand why transaction fees are not being considered a "tax".  Yes, a company that permanently draws value from shareholders without ever paying dividends will likely die.  That is fairly obvious, but you could (depending on your definition of dilution) dilute while rewarding with dividends.

I see no reason why transaction fees are any better than a reasonable preplanned dilution.  Paying agents/employees all comes from the same place in the end, no matter how you calculate or name it.  Those transaction fees could belong to shareholders just as much as a developer.  Honestly.. I just do not understand these distinctions.  Is it nothing more than ideology and anything that appears like a tax gets the bad connotations that go along with taxes?  Is that whats going on?

[gyhy]

 

[Troglodactyl]

The other useful thing about some form of dilution is that it allows a developer to sell off his job.  If he just has preallocated shares we run into the same problem again where the new developer can just give up once they are paid and sell their shares.  (Or worse, you don't get that far as the dev dumps his preallocated funds)  If they are paid a salary through some mechanism of dilution then that job can be passed/sold off without the shareholders risking as much.  Infact that becomes a lot more likely way for a dev to quit a DAC.  They pass off the job to someone else if they can find someone suitable to take on the role.

If the developer is payed by transaction fees, a new developer can still take over.  No one should invest in a company that considers taxing the shareholders to cover expenses part of its long term business plan.  After the capital investment raised by selling shares is consumed, the business should be sustainable on revenue from customers.  If it permanently draws value from shareholders through dilution, rather than rewarding them with dividends, it's a zombie.

[Troglodactyl]

From the Bitcointalk thread:

I introduced a new thought that is not in the whitepaper and that is that the block creation reward, in addition to funding infrastructure and developers, could also subsidize transactions to the extent of negative transaction fees, should the abuse problem be addressed. Imaging paying Amazon or any other global Internet retailer a week's worth of block creation rewards, i.e. $13 million to get them to accept bitcoins as payment. I call this notion paying for order flow.

Would negative tx fees allow anyone to send coins back and forth and make money this way? Would the increased demand for coins through this way of making money overcompensate Bitcoin holders (on the one site the price might increases and on the other side negative tx fees have to be paid through dilution by holders)?

Yes, paying for order flow invites abuse. Human organizations prevent this by audits of the paid organization by the paying organization. This could not be easily automated, but one can imagine in some possible world, a software agent that contracts with auditing companies to perform this role.

Do you mean that an auditing company would ban every address that abuses this. Can someone not write a script/program that generates a new address for every tx?

I would have an auditing company send humans to the payment processor site for a policy, procedures and software program audit to observe payments in action. Negative transaction fees are sufficiently high motivation for honest behavior.

Another issue is that an autonomous system may need to be a legal entity for the purpose of enforcing contracts. I suppose that you all have an alternative and I would like to know more about how an anonymous bitcoin network could negotiate contracts with human organizations.

Legally enforcing contracts is rather inefficient and unreliable.  Reducing dependence on this is a significant advantage of using a blockchain rather than a traditional ledger in the first place, so if there's a way to improve the design such that external enforcement is unnecessary, that's worth a lot.  Are you talking about limiting access to this network to large, publicly known organizations?  Using a new address for every receive is common practice, so if it's an open network then preventing fraud and having negative transaction fees is implausible, even if it would be desirable.

[StephenReed]

From the Bitcointalk thread:

I introduced a new thought that is not in the whitepaper and that is that the block creation reward, in addition to funding infrastructure and developers, could also subsidize transactions to the extent of negative transaction fees, should the abuse problem be addressed. Imaging paying Amazon or any other global Internet retailer a week's worth of block creation rewards, i.e. $13 million to get them to accept bitcoins as payment. I call this notion paying for order flow.

Would negative tx fees allow anyone to send coins back and forth and make money this way? Would the increased demand for coins through this way of making money overcompensate Bitcoin holders (on the one site the price might increases and on the other side negative tx fees have to be paid through dilution by holders)?

Yes, paying for order flow invites abuse. Human organizations prevent this by audits of the paid organization by the paying organization. This could not be easily automated, but one can imagine in some possible world, a software agent that contracts with auditing companies to perform this role.

Do you mean that an auditing company would ban every address that abuses this. Can someone not write a script/program that generates a new address for every tx?

I would have an auditing company send humans to the payment processor site for a policy, procedures and software program audit to observe payments in action. Negative transaction fees are sufficiently high motivation for honest behavior.

Another issue is that an autonomous system may need to be a legal entity for the purpose of enforcing contracts. I suppose that you all have an alternative and I would like to know more about how an anonymous bitcoin network could negotiate contracts with human organizations.

[gamey]

The other useful thing about some form of dilution is that it allows a developer to sell off his job.  If he just has preallocated shares we run into the same problem again where the new developer can just give up once they are paid and sell their shares.  (Or worse, you don't get that far as the dev dumps his preallocated funds)  If they are paid a salary through some mechanism of dilution then that job can be passed/sold off without the shareholders risking as much.  Infact that becomes a lot more likely way for a dev to quit a DAC.  They pass off the job to someone else if they can find someone suitable to take on the role.

[toast]

You don't need dilution at all. Pay salaries in a BitAsset like BitUSD. Do you have to create new Bitshares to create BitUSD? No you do not. So why would you have to create new Bitshares to pay salaries in BitUSD?

Free BitUSD?? Sign me up!
(you have to buy the bitusd...)

Mastercoin has developer funds without any dilution so I'm not buying the idea that you need inflation or dilution. Price all that in at the beginning.

And the dev MSC is what exactly?


If someone is getting a higher fraction of the total, someone else has to get a lower fraction of the total.

[gamey]

You don't need dilution at all. Pay salaries in a BitAsset like BitUSD. Do you have to create new Bitshares to create BitUSD? No you do not. So why would you have to create new Bitshares to pay salaries in BitUSD?

If it's really valuable to people then people will not need dilution/inflation to pay for it. If it's trash then of course you need inflation to pay for that because no one in their right mind would want to pay for it otherwise.

Bitcoin security was an exception because at the time there was no other known way to do it. In this case there are others ways to do it so you have to show that doing it through inflation is somehow the best way out of all other possible ways which don't involve inflation.

Let's find all the possible ways and then create a pro/con list?

Mastercoin has developer funds without any dilution so I'm not buying the idea that you need inflation or dilution. Price all that in at the beginning.

 I would suggest looking at Ripple for a high profile case of a dump.  It instantly lost 40% of its value.  When you allocate shares upfront, you have to allocate enough to pay for any costs down the road.  Those funds can also just be dumped at any time on the market.  Granted there may not be enough depth to sell much, but it should be quite possible.  When a dev pays himself upfront to upkeep a DAC, there aren't near as many incentives to keep the developer honest.  The developer might see bigger things on the horizon and just dump their allocated shares and move on.  Wheres that leave the DAC?

I really don't understand why someone would be against the idea of reallocation of shares either via dilution (adding shares) or direct redistribution if it is all decided and agreed to upfront.

I suppose predefined allocation with vesting might serve the same purpose, but it all seems about the same as dilution/inflation/reallocation and only ideological reasons make one more valid than the other.

[luckybit]

It seems that if you don't dilute then you just have to allocate the creator of the DAC a larger share upfront.  Isn't that how this is supposed to work ?  That has its own problem in that the DAC creator could just dump their shares and walk away.  Unlike currencies etc the DAC could still have existing value as it continues to run.    This continuation of the DAC network somewhat mitigates the effect of a dump, but if the DAC was worth dumping then it likely won't recover.

Alternatively you constantly dilute shares via inflation and at least you mitigate a lot of the problems and types of fraud people will see.  Instead I give myself .5% but then become paid chief via dilution and with a sliding scale of payment that decreases over time.  I can't just walk away and or I lose out on what I am being paid and I can't just dump and run for a big bag of loot.  (Most likely scam outcome).  I think for a healthy DAC you need dilution to pay salaries/marketing costs, or an alternative that is worse. I think a DAC structured like this SHOULD give investors/users confidence.

You don't need dilution at all. Pay salaries in a BitAsset like BitUSD. Do you have to create new Bitshares to create BitUSD? No you do not. So why would you have to create new Bitshares to pay salaries in BitUSD?

If it's really valuable to people then people will not need dilution/inflation to pay for it. If it's trash then of course you need inflation to pay for that because no one in their right mind would want to pay for it otherwise.

Bitcoin security was an exception because at the time there was no other known way to do it. In this case there are others ways to do it so you have to show that doing it through inflation is somehow the best way out of all other possible ways which don't involve inflation.

Let's find all the possible ways and then create a pro/con list?

Mastercoin has developer funds without any dilution so I'm not buying the idea that you need inflation or dilution. Price all that in at the beginning.

[gamey]

It seems that if you don't dilute then you just have to allocate the creator of the DAC a larger share upfront.  Isn't that how this is supposed to work ?  That has its own problem in that the DAC creator could just dump their shares and walk away.  Unlike currencies etc the DAC could still have existing value as it continues to run.    This continuation of the DAC network somewhat mitigates the effect of a dump, but if the DAC was worth dumping then it likely won't recover.

Alternatively you constantly dilute shares via inflation and at least you mitigate a lot of the problems and types of fraud people will see.  Instead I give myself .5% but then become paid chief via dilution and with a sliding scale of payment that decreases over time.  I can't just walk away and or I lose out on what I am being paid and I can't just dump and run for a big bag of loot.  (Most likely scam outcome).  I think for a healthy DAC you need dilution to pay salaries/marketing costs, or an alternative that is worse. I think a DAC structured like this SHOULD give investors/users confidence.

[santaclause102]

From the Bitcointalk thread:

I introduced a new thought that is not in the whitepaper and that is that the block creation reward, in addition to funding infrastructure and developers, could also subsidize transactions to the extent of negative transaction fees, should the abuse problem be addressed. Imaging paying Amazon or any other global Internet retailer a week's worth of block creation rewards, i.e. $13 million to get them to accept bitcoins as payment. I call this notion paying for order flow.

Would negative tx fees allow anyone to send coins back and forth and make money this way? Would the increased demand for coins through this way of making money overcompensate Bitcoin holders (on the one site the price might increases and on the other side negative tx fees have to be paid through dilution by holders)?

Yes, paying for order flow invites abuse. Human organizations prevent this by audits of the paid organization by the paying organization. This could not be easily automated, but one can imagine in some possible world, a software agent that contracts with auditing companies to perform this role.

Do you mean that an auditing company would ban every address that abuses this. Can someone not write a script/program that generates a new address for every tx?

[StephenReed]

From the Bitcointalk thread:

I introduced a new thought that is not in the whitepaper and that is that the block creation reward, in addition to funding infrastructure and developers, could also subsidize transactions to the extent of negative transaction fees, should the abuse problem be addressed. Imaging paying Amazon or any other global Internet retailer a week's worth of block creation rewards, i.e. $13 million to get them to accept bitcoins as payment. I call this notion paying for order flow.

Would negative tx fees allow anyone to send coins back and forth and make money this way? Would the increased demand for coins through this way of making money overcompensate Bitcoin holders (on the one site the price might increases and on the other side negative tx fees have to be paid through dilution by holders)?

Yes, paying for order flow invites abuse. Human organizations prevent this by audits of the paid organization by the paying organization. This could not be easily automated, but one can imagine in some possible world, a software agent that contracts with auditing companies to perform this role.

[Troglodactyl]

To be clear we will not be changing code to accommodate these ideas in the first release.


Sent from my iPhone using Tapatalk

Thanks for stating that directly.