Vote: Self-sustainable Decentralized Governance by Blockchain

eduffield

Core Developer
Mar 9, 2014
1,084
5,320
183
Hello Everyone!

It seems that we have a great deal of support for our recently proposed "Self Sustainable and decentralized governance by Blockchain" initiative and that's fantastic because we believe this will be a game changer for crypto, making it much more decentralized and capable of mass-adoption. However, we won't really know if the community wants the program until we vote on it, so I'm going to open voting. This vote requires 51% of the masternodes to success.

After careful consideration from the community and looking at our current/future expenses, we’ve decided to reduce the budget program to 10% of the reward. As the program delivers results, then we are hoping price appreciation should compensate for the difference and it will still leave some upside for masternode operators to enjoy later on. So the next revenue share increases would go towards the masternode budget program and the last two would still go to masternode operators.

We also want the decentralized governance program to start slow, so we as a community have time to go through the learning curve of a new feature. This is why the program would start only with 2.5% and then follow the same reward schedule that we already had in place.

Some changes to the Budget strategy

Some members of the community have brought up a critical issue with the way the system is designed. For example, say someone makes a proposal for receiving $1000 to pay for a marketing campaign. With the original design the user would receive about 300DASH.

Problem 1: However, what if the price appreciates 20% while they're getting funded? What happens to the other 20% that is left over?

Problem 2: Or worse, what happens if the price falls 20% while they're getting funded? Now the person doesn't have enough money and would require getting refunded.

Problem 3: From a technical perspective it's very difficult to make a system to enforce these payments, especially in a decentralized way.

Solution:

Instead of paying multiple addresses directly from the blockchain, I propose we make a "masternode escrow account". This will be a new type of account, that will require a quorum of masternodes to make transactions from. For example, it might require 30 random signatures from random masternodes, to make a transaction to pay for a specific proposal.

This type of masternode account means the masternode network can hold it's own money. It has many uses for us and will be extremely useful in the future for many different applications, e.g. it would be necessary for our decentralized web wallet idea.

However, we're not ready to make that masternode multisig account yet, as it will take a good deal of groundwork. So as an interim solution, we would like to use a 10-15 person multisig, where many of the most trusted community members will each have a key. Moving money out of this account would require at least 7-10 signatures. These community members would simply run a daemon with a specific parameter (masternodeaccountkey=YOURKEY), then when a budget is approved their daemon would use special protocol messages to sign the transactions. While not a perfect solution, it should work well as a first step and be very secure.

Payment Schedule, Scoring and Volatility

Being that all money will go to an escrow account, the system will be designed to approve budgets once a month. The system will order all active proposals, then pay them in order by YES count, until a proposal can't be paid in full or no proposal fulfils the minimum required criteria.

Due to the decentralized nature of the system, it will be very difficult to update a proposal and adjust the amount paid out. Due to this restriction, it's best if we denominate all proposals in USD. This means that if the price of DASH changes, up or down, the proposal will still pay the correct amount.

Here's how this is going to work if the vote passes:

We're going to implement the budgeting software in a 4 phase process. This budgeting system is going to be very complicated and difficult to implement, so it's going to take some time. In order to do this in a safe way, we're going to roll it out in multiple phases.

Phase 1.) v11 - We will patch the reference node to pay 2.5% of the block reward to the budget program. The schedule would remain the same, except further increases would be paid to the budget program and the last two would again go to masternodes.

We can use the existing voting system to vote on the first proposals, then if needed we can make manual transactions from the multisig account.

Phase 2.) v12.0 - This will be the first semi-automatic version of the budgeting system. Masternodes will be able to vote on multiple proposals at any time. The multisig account operators will then manually make payments from the multisig account.

Phase 3.) v12.1 - This will include the "budgetkey=" parameter which will automate the process of paying the budget.

Phase 4.) v? - At some point in the future, the masternode network will be capable of holding it's own money and we can move the budget multisig to their network account.

Payment Schedule

To put the budget into effect, the system would pay the escrow account its percentage of the block rewards. This would be done in phases as the original masternode reward increases called for.




With this revised schedule the masternode program still has a pending 5% reward share to grow and strengthen the network.

How To Vote

To vote, simply copy your masternode.conf into your dash directory, open the software then execute the command “masternode vote-many yea” or “masternode vote-many nay”.

To vote with a single masternode you can use the command “masternode vote yea” or “masternode vote nay”.

To view the voting progress you will need to update your client due to a bug in the current version that clears out votes after 8 hours. Once you update this will not be an issue, the command to view the voting progress is “masternode list votes”. This is not a mandatory update, masternodes do not need to update, only users that want to follow the vote on their clients.

Voting will begin immediately and be open for 2 weeks. We will consider the vote successful if at any time we have 51% of the masternodes support.

To update visit https://www.darkcoin.io/downloads, this update is NOT required for anyone but those that would like to view the progress of the vote.

--

An update to the proposal (May 8, 2015): https://dashtalk.org/threads/vote-s...vernance-by-blockchain.4825/page-4#post-53665
 
Last edited by a moderator:

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,871
1,863
1,283
I believe they sold IPOs no? Ripple labs is also a centralized organization, no? But I agree with you, it's so unclear how governments will view and deal with us. This is outside my knowledge (for good reason, I already feel a headache coming on, LOL)

So Fernando, and all you in the know of the law and taxes, can you explain what responsibilities Masternodes my incur? Thanks!

Also, are you saying we don't actually have to load our masternode wallets, just use the dash.conf in any wallet and it will be good to vote?
 
  • Like
Reactions: Dunedoo

Sapereaude

Well-known Member
Foundation Member
Apr 30, 2014
191
235
203
So does this mean the plans to remove the reference node are being postponed or is it now a permanent fixture?

Also I doubt it's worth spending a lot of time worrying about governmental aspects influences until we are a lot larger and publicly visible. As I am certain most legislators or bureaucrats don't even know this projects exist let alone have any plan of action regarding it. Hell it will take years for them to begin to understand, just us like with any new tech.
 
Last edited by a moderator:
  • Like
Reactions: Dunedoo

Solarminer

Well-known Member
Apr 4, 2015
762
922
163
I agree with thelonecrouton. This proposal will force funds into an escrow account exposed to theft/confiscation/loss/tax. The risk is higher with the more account holders (now 2500 MN). Any account holder can be accused of something "illegal" in the eyes of a government entity and it will be traced back to this account and back to all the account holders. With all the exposed IP addresses, this could get really bad.

Can we make a change to this proposal? Let's call it Project Vote. The funds go to a specific person, let's say "Evan Duffield". The purpose of the funds, "To create a voting system." Start with 1.25% distributions and end the distribution at 3 months. This can be manually stopped in 3 months for this first revision. Then at 3 months the new system will be in place to automatically set project time limits and prioritize projects by votes up to the maximum 10% project funding cap.

The numbers above don't add up. Chart says 1.25% and text says 2.5%.
 
  • Like
Reactions: Dunedoo

David

Well-known Member
Jun 21, 2014
618
628
163
So does this mean the plans to remove the reference node are being postponed or is it now a permanent fixture?

Also I doubt it's worth spending a lot of time worrying about governmental aspects influences until we are a lot larger and publicly visible. As I am certain most legislators or bureaucrats don't even know this projects exist let alone have any plan of action regarding it. Hell it will take years for them to begin to understand, just us like with any new tech.
Very good question. I think our #1 priority needs to be eliminating the reference node. I'd like more information on how this impacts development plans on 0.12.0.x before I vote.
 
  • Like
Reactions: akhavr and Dunedoo

Minotaur

Well-known Member
Foundation Member
Apr 7, 2014
452
1,079
263
So does this mean the plans to remove the reference node are being postponed or is it now a permanent fixture?

Also I doubt it's worth spending a lot of time worrying about governmental aspects influences until we are a lot larger and publicly visible. As I am certain most legislators or bureaucrats don't even know this projects exist let alone have any plan of action regarding it. Hell it will take years for them to begin to understand, just us like with any new tech.
This is completely unrelated to eliminating the reference node, the plan to eliminate the reference node would continue exactly the same. This initiative would work without the reference node just fine.
 
Last edited by a moderator:

Minotaur

Well-known Member
Foundation Member
Apr 7, 2014
452
1,079
263
Very good question. I think our #1 priority needs to be eliminating the reference node. I'd like more information on how this impacts development plans on 0.12.0.x before I vote.
This changes nothing from 0.12.0, Evan is still working on eliminating the reference node that is one of the bigger priorities at the moment.
 

Sapereaude

Well-known Member
Foundation Member
Apr 30, 2014
191
235
203
I agree with thelonecrouton. This proposal will force funds into an escrow account exposed to theft/confiscation/loss/tax. The risk is higher with the more account holders (now 2500 MN). Any account holder can be accused of something "illegal" in the eyes of a government entity and it will be traced back to this account and back to all the account holders. With all the exposed IP addresses, this could get really bad.

Can we make a change to this proposal? Let's call it Project Vote. The funds go to a specific person, let's say "Evan Duffield". The purpose of the funds, "To create a voting system." Start with 1.25% distributions and end the distribution at 3 months. This can be manually stopped in 3 months for this first revision. Then at 3 months the new system will be in place to automatically set project time limits and prioritize projects by votes up to the maximum 10% project funding cap.

The numbers above don't add up. Chart says 1.25% and text says 2.5%.
Can some one explain to me why several people are so paranoid about goverments, in the sense that why in the current state of affairs would anyone care in the slightest about DASH? Maybe when we reach the 100+ million marketcap, until then I can not see any logic in worrying about governments or resonantly be able to predict the reaction, Even then if you are so petrified in your belief that this is a problem then there is a simple solution, host your node somewhere that don't require personal details. Hell if there is a problem you can always activate the node somewhere else. I feel this paranoia it has very little to do with the proposal and that your turning a feature of DASH(decentralized cold nodes) into a negative for no good reason.

So in your proposal there would simply one large central address that is exposed to theft/confiscation/loss/tax? Then your propose a reduction to 1.25%, what are the benefits of this against 2.5% as i don't see any. You need a reasonable amount to capital to get things done and 2.5% really is not that much money. This is the kind of idea that you either do it properly or don't, because half assing and only dipping a toe into the water it will result in it failing to lift off.
 

tungfa

Grizzled Member
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,902
6,737
1,283
Last edited by a moderator:

RenegadeMan

Member
Aug 6, 2014
61
92
58
I agree with thelonecrouton.
I don't. This is not a FinCEN area of jurisdiction as Dash isn't 'money' per se. And there's been no issuing of stock/equities. While, of course, all that may change in the future, at the moment, I don't believe what's being proferred here contains anything that would be cause for concern. Futhermore, as Sapereaude has noted, the likelihood of government being even remotely aware of Dash, let alone what the ramifications of it's existence are long-term, is probably next to nothing.

The numbers above don't add up. Chart says 1.25% and text says 2.5%.
Chart says 1.25% for the first supposed initial deduction (I'm guessing) if that had've been rolled out when this idea was first mooted, so it's most likely irrelevant now and 2.5% is the initial deduction that will send funds into the budget program.

All-in-all I think it's a great initiative and I'm very happy with how Evan has laid it out. I can see much thought has gone into it and that there's a strong awareness of the relative complexities of deploying it, and the need for a phased implementation. I too would like to be sure that this facility's dependence on the reference node doesn't prolong the reference node's necessity. We need to be moving on from that ASAP in order to negate the never ending use of it by trolls and naysayers as "proof" that Dash is centralised (as pathetic and lame an argument as that is; it will be nice never to have to hear about it again).

Great first steps Evan and team to getting this working; I'll be voting yea.
 

bigrcanada

Well-known Member
Foundation Member
Mar 9, 2014
314
361
233
Penticton, BC
www.misconductwineco.com
I don't. This is not a FinCEN area of jurisdiction as Dash isn't 'money' per se. And there's been no issuing of stock/equities. While, of course, all that may change in the future, at the moment, I don't believe what's being proferred here contains anything that would be cause for concern. Futhermore, as Sapereaude has noted, the likelihood of government being even remotely aware of Dash, let alone what the ramifications of it's existence are long-term, is probably next to nothing.



Chart says 1.25% for the first supposed initial deduction (I'm guessing) if that had've been rolled out when this idea was first mooted, so it's most likely irrelevant now and 2.5% is the initial deduction that will send funds into the budget program.

All-in-all I think it's a great initiative and I'm very happy with how Evan has laid it out. I can see much thought has gone into it and that there's a strong awareness of the relative complexities of deploying it, and the need for a phased implementation. I too would like to be sure that this facility's dependence on the reference node doesn't prolong the reference node's necessity. We need to be moving on from that ASAP in order to negate the never ending use of it by trolls and naysayers as "proof" that Dash is centralised (as pathetic and lame an argument as that is; it will be nice never to have to hear about it again).

Great first steps Evan and team to getting this working; I'll be voting yea.
I agree. The reference node is a silly issue....but none the less I understand. The Ripple situation is very different. I would say that at some point as someone discussed that we need to work on DASH behaving more like gold rather then fiat, down the road. if that makes sense. I too have voted! Get the vote out ;)
 
  • Like
Reactions: Dunedoo

Solarminer

Well-known Member
Apr 4, 2015
762
922
163
Can some one explain to me why several people are so paranoid about goverments, in the sense that why in the current state of affairs would anyone care in the slightest about DASH? Maybe when we reach the 100+ million marketcap, until then I can not see any logic in worrying about governments or resonantly be able to predict the reaction, Even then if you are so petrified in your belief that this is a problem then there is a simple solution, host your node somewhere that don't require personal details. Hell if there is a problem you can always activate the node somewhere else. I feel this paranoia it has very little to do with the proposal and that your turning a feature of DASH(decentralized cold nodes) into a negative for no good reason.

So in your proposal there would simply one large central address that is exposed to theft/confiscation/loss/tax? Then your propose a reduction to 1.25%, what are the benefits of this against 2.5% as i don't see any. You need a reasonable amount to capital to get things done and 2.5% really is not that much money. This is the kind of idea that you either do it properly or don't, because half assing and only dipping a toe into the water it will result in it failing to lift off.
The reason for the paranoia is that there are so many people getting arrested in the Bitcoin space with what seems like insignificant activities. Bitcoin is getting more traceable and the record is permanent. So as time goes by more technologies are used to go back into the blockchain to chase transactions. DASH is similar except when Darksend is used. It isn't now that matters with DASH at $3 as much as in 10 or 20 years when it is $100 or $10,000. The blockchain transactions are permanent and public, which makes tracking back overtime an issue. The confiscation of funds will happen when the wallet hits $100K or $1,000K or something significant. All that needs to happen is for it to be considered an "unlicensed money transmitter business" or "failing to report suspicious activity".

The questions we need to ask with this comingled escrow fund(not just today, but 10 or 20 years from now):
Is this a money transmitter account? (How are projects going to be paid in $? Is a proxy used to convert DASH to $)
Are we paying taxes with the funds? Are we giving out W2s or 1099s and hiring contractors? Is the project owner required to report as income? (This is a lot clearer if DASH is sent to one person directly from the block rewards. When a comingled fund pays for labor, I think this all changes.)

Hosting a node offsite still is not that answer. Your IP that you access your server is recorded. Further action could be taken with a proxy server to hide your access, but you get the point. It isn't as easy as just changing providers. I agree that I can be paranoid, but this proposal will cause problems over time. We are trying to find a solution that will last, not something that exposes all the masternode owners.

I am not saying 1.25% is the right number. The chart above says 1.25% and the text says 2.5%. I just picked one. 2.5% would be about $72,575/year at $3/DASH, not insignificant by my standards. Maybe we put in 10% for 1 month.

The last issue is that this 10% has no end. Let's vote in each project with a specific donation and timeframe. There is no mechanism stated above to return the funds if there are no projects, so inevitably this will get wasted on bad projects or abused as time goes on. (I don't think this is the intent of this proposal, but a forced donation like this will not end well even with the best intentions.)
 

deusstultus

New Member
Dec 5, 2014
29
33
13
I'll rebase some of my previous commentary. Relying on the masternode network with a randomized script metric is somewhat concerning. Looking around the community right now, it is easy to see that there are a few people who own a fair number of masternodes or otherwise hold influence over a fair number of masternodes. A voting system that relies on script signatures is concerning in this regard and insofar as masternodes marked as signatory may disappear at a moment's notice. The other risk is that if the network does poorly issue this script sig, the coins could be immediately forfeit, which does not reflect well on the state of the currency regardless of consequence.

As far as secondary impact, resolving DASH payments against USD at a blockchain level is questionable. This inevitably relies on a centralized service to establish this payout criteria. Anything moving towards decentralization should not rely on a service of this nature. And then there is the question of viablility of the masternode voting metric in the current release build. The "Dress" pilot vote seemed to prove that voter retention was not well established in the network, so relying on an incomplete software to make decisions is concerning.

I applaud the effort, and encourage the movement, but let's establish the service before using it to make decisions, especially when open questions like this remain. If there is immediate risk of proceeding (say pre 0.13.0 expected release) let's assess those now with a better degree of specificity, otherwise plan testnet introduction of this featureset before voting on implementation.

And here's the necessary legal aspect: certain nations require reporting of income regardless of origin for taxation. Income that is arguably earned but otherwise mandated for payment is not straightforward. Joe Schmoe (even masternode operator Joe) cannot necessarily afford legal council to ensure he's within his rights, and this can be concerning without at least some level of rehashing before forcing an implementation. By all means, roll forward with intent, but on a testnet fork, only push towards mainnet when we have community support and/or time to play with implications so those in the community can weigh in on impact in this and other regards.
 
Last edited by a moderator:

raganius

cryptoPag.com
Foundation Member
Masternode Owner/Operator
The reason for the paranoia is that there are so many people getting arrested in the Bitcoin space with what seems like insignificant activities. Bitcoin is getting more traceable and the record is permanent. So as time goes by more technologies are used to go back into the blockchain to chase transactions. DASH is similar except when Darksend is used. It isn't now that matters with DASH at $3 as much as in 10 or 20 years when it is $100 or $10,000. The blockchain transactions are permanent and public, which makes tracking back overtime an issue. The confiscation of funds will happen when the wallet hits $100K or $1,000K or something significant. All that needs to happen is for it to be considered an "unlicensed money transmitter business" or "failing to report suspicious activity".

The questions we need to ask with this comingled escrow fund(not just today, but 10 or 20 years from now):
Is this a money transmitter account? (How are projects going to be paid in $? Is a proxy used to convert DASH to $)
Are we paying taxes with the funds? Are we giving out W2s or 1099s and hiring contractors? Is the project owner required to report as income? (This is a lot clearer if DASH is sent to one person directly from the block rewards. When a comingled fund pays for labor, I think this all changes.)

Hosting a node offsite still is not that answer. Your IP that you access your server is recorded. Further action could be taken with a proxy server to hide your access, but you get the point. It isn't as easy as just changing providers. I agree that I can be paranoid, but this proposal will cause problems over time. We are trying to find a solution that will last, not something that exposes all the masternode owners.

I am not saying 1.25% is the right number. The chart above says 1.25% and the text says 2.5%. I just picked one. 2.5% would be about $72,575/year at $3/DASH, not insignificant by my standards. Maybe we put in 10% for 1 month.

The last issue is that this 10% has no end. Let's vote in each project with a specific donation and timeframe. There is no mechanism stated above to return the funds if there are no projects, so inevitably this will get wasted on bad projects or abused as time goes on. (I don't think this is the intent of this proposal, but a forced donation like this will not end well even with the best intentions.)
I'm afraid that this is no paranoia: "better safe than sorry".

I like the idea, it's exciting, but let's not jump blindly on it, because it needs polishing, and we do not need to rush. Let's study the pros and cons in order to not adventure ourselves with reckless decisions.

The idea is great, I know it, but the solution is almost there: We do not want it to be palliative. We want it to be good long term.

Let's open our ears and listen to all opinions... and only then decide/vote :)
 
Last edited by a moderator:

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
"US Financial Crimes Enforcement Network (FinCEN) director Jennifer Shasky Calvery said during a speech today that her agency is in the process of investigating businesses in the digital currency ecosystem......"

http://www.coindesk.com/fincen-director-examiniation-digital-currency/

I hope we're not becoming a "digital currency business" as defined by the US govt here... Where're Dash lawyers?
 

deusstultus

New Member
Dec 5, 2014
29
33
13
"US Financial Crimes Enforcement Network (FinCEN) director Jennifer Shasky Calvery said during a speech today that her agency is in the process of investigating businesses in the digital currency ecosystem......"

http://www.coindesk.com/fincen-director-examiniation-digital-currency/

I hope we're not becoming a "digital currency business" as defined by the US govt here... Where're Dash lawyers?
This endeavor of allocating funds towards developers, regardless of how well-intentioned or well-implemented would inevitably draw further attention in this regard.
 

Solarminer

Well-known Member
Apr 4, 2015
762
922
163
...And here's the necessary legal aspect: certain nations require reporting of income regardless of origin for taxation. Income that is arguably earned but otherwise mandated for payment is not straightforward. Joe Schmoe (even masternode operator Joe) cannot necessarily afford legal council to ensure he's within his rights, and this can be concerning without at least some level of rehashing before forcing an implementation. By all means, roll forward with intent, but on a testnet fork, only push towards mainnet when we have community support and/or time to play with implications so those in the community can weigh in on impact in this and other regards.
If the block rewards go directly to a project owner, the project owner has the obligation to report their own income, correct? (Wouldn't this eliminate any tax implications from DASH? This is essentially mining.)

If the block rewards go to a fund and that fund pays a project owner then the fund owner may be required to report income and/or report income paid to the project owner, correct? (This would essentially, force a bunch of (current or future) tax paperwork on the fund owner we don't want.)
 
  • Like
Reactions: moli and Dunedoo

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,871
1,863
1,283
RE: the projects being estimated in fiat but being paid in DASH is only so that the amount of DASH at the time equals the fiat equivalent. Lets say that someone bids 1000 Euros to do a job, we grant him the job, but from the time the job is granted to the time the job is done, say DASH goes up 200% in price. Then we simply pay him the equivalent of 1000 Euros current exchange rate. That's all.

I don't know the answer to your question, Solarminer, but I hope someone on the team who is either a tax specialist or lawyer can answer.
 
  • Like
Reactions: Dunedoo

deusstultus

New Member
Dec 5, 2014
29
33
13
If the block rewards go directly to a project owner, the project owner has the obligation to report their own income, correct? (Wouldn't this eliminate any tax implications from DASH? This is essentially mining.)

If the block rewards go to a fund and that fund pays a project owner then the fund owner may be required to report income and/or report income paid to the project owner, correct? (This would essentially, force a bunch of (current or future) tax paperwork on the fund owner we don't want.)
IANAL, but It's a unique case, which always draws question. The miner creates the transaction and could have legal merit, the masternode receives funds and further executes services based on a relatively unspecified contract. Sure if this goes directly to a fund it's relatively easy to prove no ownership of the funds, but it's a gray area without definition. Likely to ever arise as a concern? Probably not, but if it does...? This was by far the weakest of my points, but I felt it worth mention. Per usual, I'm encouraging discussion and not driving decision points.
 

bhkien

Active Member
Mar 31, 2014
465
287
133
Canada
vietriches.com
Problem 3: From a technical perspective it's very difficult to make a system to enforce these payments, especially in a decentralized way.

Solution:

Instead of paying multiple addresses directly from the blockchain, I propose we make a "masternode escrow account". This will be a new type of account, that will require a quorum of masternodes to make transactions from. For example, it might require 30 random signatures from random masternodes, to make a transaction to pay for a specific proposal.

This type of masternode account means the masternode network can hold it's own money. It has many uses for us and will be extremely useful in the future for many different applications, e.g. it would be necessary for our decentralized web wallet idea.
Does it means that we need another blockchain running on masternodes?
 

Solarminer

Well-known Member
Apr 4, 2015
762
922
163
sorry but i do not see the connection between the Ripple fine and this fundraiser at all !

Edit:
And I do not think it is fair to throw this paranoia into the discussion !!!
This actually isn't off topic. It weird how the crypto world is so different than the fiat currency world. HSBC makes loads on laundering drug deals and gets a little fine. Charlie Shrem is sentenced to two years in prison for indirectly helping to send $1 million to Silk Road.

So the key to this article is, they should have had:
  • Filed suspicious activity reports submitted for transactions over 10K (or certain subjective amounts under this).
  • Obtained "know your customer" documentation
  • Enforced an anti-money-laundering protection program
Why? They should have known they were a money services business as part of the bank secrecy act.

The question of the day is, "Is this proposal putting the escrow account into the category of a money services business and adding additional requirements? Now, or potentially in the future?
 
  • Like
Reactions: Dunedoo and moli

deusstultus

New Member
Dec 5, 2014
29
33
13
Does it means that we need another blockchain running on masternodes?
Voting plus multisig scripting would be the sensible basis here, sidechains should never be encouraged. However while script-based transactions are fairly well established, they have not been implemented at this scale and introduce risk should involved masternodes not follow convention.
 
  • Like
Reactions: Dunedoo and bhkien

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
If the block rewards go directly to a project owner, the project owner has the obligation to report their own income, correct? (Wouldn't this eliminate any tax implications from DASH? This is essentially mining.)

If the block rewards go to a fund and that fund pays a project owner then the fund owner may be required to report income and/or report income paid to the project owner, correct? (This would essentially, force a bunch of (current or future) tax paperwork on the fund owner we don't want.)
I think the fund is like another PoS so we can say even though the coins are paid to the devs or whoever of the voted project, it's like they "mine" the coins, like MN owners "mine" their coins. If this is defined as such under the law, I'm guessing we don't have to worry about the govt going after us for handling money without being registered with FinCEN. The payees just have to pay their own taxes just like any other miners and investors if they have made a profit.
 
  • Like
Reactions: Dunedoo

eduffield

Core Developer
Mar 9, 2014
1,084
5,320
183
So does this mean the plans to remove the reference node are being postponed or is it now a permanent fixture?

Also I doubt it's worth spending a lot of time worrying about governmental aspects influences until we are a lot larger and publicly visible. As I am certain most legislators or bureaucrats don't even know this projects exist let alone have any plan of action regarding it. Hell it will take years for them to begin to understand, just us like with any new tech.
The reference node will be removed in v12 for sure, none of the logic above requires it (except for the first phase in v11).
 

Solarminer

Well-known Member
Apr 4, 2015
762
922
163
eduffield said:
Problem 3: From a technical perspective it's very difficult to make a system to enforce these payments, especially in a decentralized way.

Solution:

Instead of paying multiple addresses directly from the blockchain, I propose we make a "masternode escrow account". This will be a new type of account, that will require a quorum of masternodes to make transactions from. For example, it might require 30 random signatures from random masternodes, to make a transaction to pay for a specific proposal.

This type of masternode account means the masternode network can hold it's own money. It has many uses for us and will be extremely useful in the future for many different applications, e.g. it would be necessary for our decentralized web wallet idea.
Does it means that we need another blockchain running on masternodes?
Sign me up. A second masternode network profiting from the 10% donations.

Seriously, I think Evan was referring to fluctuations with DASH vs US$. I don't see fluctuations with DASH to US$ a big deal here. If the price goes up or down the project owner will need to either absorb it or apply for further funding. In a few years, I bet DASH will be more stable than the US$ anyway. Another way to do this would be to let the project get paid for a few extra weeks(assuming recurring payments from the block rewards directly). That way the payments stay the same, just the time changes.

I also see that the project payment could just be pulled from the masternode block rewards with 1 out of every 60 masternode payments for each %. This wouldn't require changing the current split % between MN and Miners. It would be like adding an additional 25-250 masternodes.
 

alex-ru

Grizzled Member
Dash Support Group
Jul 14, 2014
2,374
3,242
1,183
The idea is great, I know it, but the solution is almost there: We do not want it to be palliative. We want it to be good long term.
Let's open our ears and listen to all opinions... and only then decide/vote :)
I am also not absolutely happy about this voting and think some things may be done better way, but...
1. There are so many opinions and contradictory ideas - we could keep debating them for months... So more constructive is - to start with something, get first practical results and then correct system, than doing endless theoretical discussions.
2. For every decision - there are some logical-technical limitations, and many of them only developers are competent to estimate...
3. I realize proposed model as "release candidate (similar to initial early_2014_darksend)" that will be changed in future...

My general opinion on vote: it has to include announce - the exact way (and time?) MN ops may correct the proposed "model" in 2015... It will allow MN ops to feel more confident and stop being afraid of making "fatal mistake" by voting "yes".
 
Last edited by a moderator:

tungfa

Grizzled Member
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,902
6,737
1,283
My general opinion on vote: it has to include announce - the exact way (and time?) MN ops may correct the proposed "model" in 2015...
i see this totally being part of it
when suddenly all MN's keep voting 'nay' (and concerns are raised in the community)
no project will get approved and the Dev team will and has to listen to the community
and we will go into the next round of discussions and eventually changes of the original idea
 
  • Like
Reactions: Dunedoo and alex-ru

TaoOfSatoshi

Grizzled Member
Jul 15, 2014
2,840
2,648
1,183
Dash Nation
www.dashnation.com
i see this totally being part of it
when suddenly all MN's keep voting 'nay' (and concerns are raised in the community)
no project will get approved and the Dev team will and has to listen to the community
and we will go into the next round of discussions and eventually changes of the original idea
Yes, this is also what I've been saying. Do it, evaluate it, and change it if need be.