Should Platform run on all nodes or should Platform run only on High Performance nodes ?

[DASHvestor]

Does 4K or 10K collateral really solve anything, if such 4K or 10K nodes use lame connections and barely (or don't) fulfill Platforms hardware requirements?
Whales owning dozens or even 100+ 1K MN would still be over-represented in such a 4K or 10K scenario. It hardly makes any sense.

First you have to define the optimum amount of Nodes in Platform, or dynamically calculate this figure.
Then Masternodes will have to COMPETE ON HARDWARE-RESOURCE-RELATED GROUNDS to obtain one of the available Platform slots.

Changing collateralization or introducing a super-collateralized node type will only cause confusion & discrimination and ultimately serve nothing.
We only need REGULAR 1K NODES with VOLUNTARY COMPETITION ON HARDWARE in order to reach the optimal amount of Platform nodes.

 

[xkcd]

I will be voting on the 10k option as it poses the best outcome for us from a poor set of alternatives.

Some people on this forum seem to think that the 4k and 10k solutions would be more centralised and I must admit I thought the same at first until I really thought about it. The reason why these options are not more centralised is precisely because the stake required is so high, at 10k there are few whales with enough Dash to be able to form a majority stake in Dash in order to control the Platform, so 10k is by far the safest and most decentralised option. As we go to smaller stakes, the risk becomes that a big whale could create enough nodes such that they control the network and do the bad things. This is most obviously in the 1k opt in model where MNOs choose to run Evo with 1k collaterals, if the network size were say 600 Evo 1k nodes, then our largest whale could wind up controlling a third of the network which is the threshold where they can start to mess with it.

One solution to this is to force all 1K MNs to run Evo, this keeps the network as a homogeneous blob, which the community desires, but has the following issues. Firstly, the severe burden of running evo on every MN means our effective ROI will plummet as we over pay for hosting fees, this will see attrition as the network shrinks to boost ROI. Secondly, there is an issue that a catastrophic evo fault could also halt the L1 payments chain, thirdly, the platform fees would be too high for regular people to bother with using it, thus turning platform into a still-born. Finally, the fact that Evo allows the storage of arbitrary binary data (could be CP or whatever), is a risk to MNOs that host their nodes in their own name, or connect to their VPS without first connecting to a VPN which was paid for anonymously... Well some people just might not want to run such a risky service, but with the 1K option they have no choice, this would likely result in some further attrition.

So, clearly this leaves the 4k and 10k options as the only viable options. Their benefits can be listed as follows, it's opt in, so entirely democratic, it protects the L1 payments chain from fault, it keeps the fees down on Evo which won't hinder adoption, it's more decentralised because a whale will find it harder to amass enough coins when the stake is so large to gain dominance in the network and by reducing the number of servers running Evo, the network's overall expenditure on hosting fees will be less, thus our ROI will not be impacted as it would be in the 1K option where everyone has to upgrade to far beefier VPS plans at their own cost.

 

[vazaki3]

Some people on this forum seem to think that the 4k and 10k solutions would be more centralised and I must admit I thought the same at first until I really thought about it. The reason why these options are not more centralised is precisely because the stake required is so high, at 10k there are few whales with enough Dash to be able to form a majority stake in Dash in order to control the Platform, so 10k is by far the safest and most decentralised option. As we go to smaller stakes, the risk becomes that a big whale could create enough nodes such that they control the network and do the bad things.

10k is not the most decentralized option. 1k is more decentralized than 10k. The one who has enough money in order to destroy the decentralization and control the Platform in the 1k solution, can do this more easily (or at worst at the same difficulty) in the 10k solution. If we consider the difficulty is the same, even then for the 1k solution we still have the hope that the network may be decentralized (and we can prove the level of decentralization by investigating individualities)

As long as there are a few people that can afford the 10k solution, the total staked collateral for the 10k solution will be less than the total staked collateral for the 1k solution. This makes the 1k solution a more decentralized solution, because the total stake for the 1k solution will be bigger than the 10k solution stake. So someone who want to control the network, can do it with less money in the 10k solution. Unless of course the total stake is arbitralily set identical for both 1k and 10k solutions. If the total stake is set identical for both 1k and 10k solutions, then this second argument does not apply.

This is most obviously in the 1k opt in model where MNOs choose to run Evo with 1k collaterals, if the network size were say 600 Evo 1k nodes, then our largest whale could wind up controlling a third of the network which is the threshold where they can start to mess with it.

When arguing, you mismatch the cases. You can compare (1k, 10k both mandatory). You can compare (1k, 10k both opt in). You can compare (1k opt in, 10k mandatory). You can finnaly compare (1k mandatory, 10k opt in). Each set of two elements requires a different analysis, and has different advantages and disadvantages. You cannot argue for the advantages of the (1k, 10k mandatory) set and then argue for the disadvantages of the (1k opt in, 10k opt in) set, and then come to a conclusion. This is a mismatch. You have to examine and compare each case, as a set of two elements.

Lets analyze.
(1k, 10k both mandatory). How can 10k be mandatory? We dont know the 10k whales, so we cannot force them to participate in the Platform. We may have a clue about them, but it is just a clue.
(1k, 10k both opt in). This is a possible scenario.
(1k opt in, 10k mandatory). Again, how can 10k be mandatory? We dont know the 10k whales, so we cannot force them to participate in the Platform.
(1k mandatory, 10k opt in). This is also a possible scenarion.

So the 10k solution is always opt in. And if we do not set a mandatory total collateral for the Platform to start, then the 10k solution may become tottaly centralized, because maybe we will have very few 10k whales that they will be interested.

 

[stan.distortion]

That's assuming shared masternodes actually arrive, should some unforeseen issue crop up that would result in a very small handful of whales receiving twice the block rewards of the entire treasury. Maybe that sounds far fetched, apparently trustless masternode shares are ready to go but after the failed promises so far it's what I'm expecting.

Maybe it's time to bring up another failed promise, when do we get sporks handled in a decentralised manner? I doubt DCG would hold the network to ransom but the spork activation keys give them that option in the event of any other development teams offering alternative approaches.

 

[xkcd]

Maybe it's time to bring up another failed promise, when do we get sporks handled in a decentralised manner? I doubt DCG would hold the network to ransom but the spork activation keys give them that option in the event of any other development teams offering alternative approaches.

Sporks are being slowly removed and DCG is working on code that will allow us to hard fork in the future without the need for the sporks, so they are working towards that goal, there's just so much other work to do and constraints on what can be done.

 

[xkcd]

Another factor I did not mention is that we need to think about how much value is to be secured in Platform. I did the calculation somewhere else, but the payment cycle on Platform is every 18 days and every MN gets paid at the same time, so just before payment Platform will hold almost 7k Dash in credits, after payments, MNOs will move that Dash off Platform and convert it to regular Dash, so by my estimates, maybe 10k Dash (equivalent) will held on Platform, but let's say MNOs get lazy, or Platform gets super popular and many people transfer Dash into credits and there is a float of about 50k Dash worth of credits, just how much of the Masternode network do we really need to protect that value? Surely not the entire 4000 strong network? So, doesn't it make sense to assign the job of securing Platform to just a few nodes and leave the rest of the network securing damn near 11 million Dash?

 

[krilen]

There is a great incentive to do a good job, if you use "proof of work", "proof of service" or "proof of usefull work" (and by the way, the forum thread that mentions PouW is deleted. why??????). So you can use the above argument, when arguing in favor for the proof of work/service.

The forum thread about Proof-of-Useful Work, which retains the key benefits of PoW while consuming energy in a more sustainable way, was somehow deleted. The administrator of the forum was unable to restore the post when I asked him to. At that time, I took a snapshot of the thread, which you can find here.

 

[virgile]

Another factor I did not mention is that we need to think about how much value is to be secured in Platform. I did the calculation somewhere else, but the payment cycle on Platform is every 18 days and every MN gets paid at the same time, so just before payment Platform will hold almost 7k Dash in credits, after payments, MNOs will move that Dash off Platform and convert it to regular Dash, so by my estimates, maybe 10k Dash (equivalent) will held on Platform, but let's say MNOs get lazy, or Platform gets super popular and many people transfer Dash into credits and there is a float of about 50k Dash worth of credits, just how much of the Masternode network do we really need to protect that value? Surely not the entire 4000 strong network? So, doesn't it make sense to assign the job of securing Platform to just a few nodes and leave the rest of the network securing damn near 11 million Dash?

Yes, it's something to keep in mind indeed that Platform is not made for payments, credits are just here to pay masternodes for the storage services, so without checking the values/calculations, i can certainly say that your estimates are logical.

 

[vazaki3]

The forum thread about Proof-of-Useful Work, which retains the key benefits of PoW while consuming energy in a more sustainable way, was somehow deleted. The administrator of the forum was unable to restore the post when I asked him to. At that time, I took a snapshot of the thread, which you can find here.

This is VERY serious. Who deleted the thread , and for what reason?

 

[peter]

Fun fact, some people actually told us they agreed with our design choice there, but they are too afraid to get the same negativity we do, so they stay silent.

Indeed, a mistake. Our positive feedback is dominated by a very negative minority.
It seems, that it needs to be spelled out in bold and all upper case: POSITIVE FEEDBACK.

With all the very good explanations from Sam, the 10k-HPMN solution seems to be the best choice for the first release. The DCG guys are smart and very patient. They listen to all feedback and try their best to evaluate other ideas. Delays are quite normal in such field of software development.

Again, keep up DCG! You DTRT!

Thanks for your efforts!
Peter

 

[virgile]

Indeed, a mistake. Our positive feedback is dominated by a very negative minority.
It seems, that it needs to be spelled out in bold and all upper case: POSITIVE FEEDBACK.

With all the very good explanations from Sam, the 10k-HPMN solution seems to be the best choice for the first release. The DCG guys are smart and very patient. They listen to all feedback and try their best to evaluate other ideas. Delays are quite normal in such field of software development.

Again, keep up DCG! You DTRT!

Thanks for your efforts!
Peter

Thank you, such comments are appreciated. Indeed positive feedback is important as well. We are but a tool of the network and if the network only points out when things go wrong, we cannot know when things go right.

what does DTRT?

 

[QuantumExplorer]

Do the right thing?

 

[qwizzie]

Indeed, a mistake. Our positive feedback is dominated by a very negative minority.

Looking at the different people that commented so far in this 18 pages long thread .. i would say there is a very negative majority, not a very negative minority.
Only a few people seem to support 4k or 10K so far....

xkcd thread does not seem to trigger much supportive responses either : https://www.dash.org/forum/threads/...gh-performance-masternodes.53394/#post-232576

It would be interesting to observe what the actual voting response will be, once the DCG decision proposals hit the Dash network and masternode owners need to vote on them.

 

[virgile]

Looking at the different people that commented so far in this 18 pages long thread .. i would say there is a very negative majority, not a very negative minority.
Only a few people seem to support 4k or 10K so far....

xkcd thread does not seem to trigger much supportive responses either : https://www.dash.org/forum/threads/...gh-performance-masternodes.53394/#post-232576

It would be interesting what the actual voting response will be, once the DCG decision proposals hit the Dash network.

It's the same handful persons commenting negatively in both threads though. We let the 3-4 of you voice your negative feedback for almost 18 pages, Let them voice their positive feedback for a comment or two, aren't you a proponent of free speech?

 

[qwizzie]

It's the same handful persons commenting negatively in both threads though. We let the 3-4 of you voice your negative feedback for almost 18 pages, Let them voice their positive feedback for a comment or two, aren't you a proponent of free speech?

Nobody is restricting anybody from making comments, either in favor for or against the decision proposals. xkcd even created his own thread for it.
But to say that just 3-4 people voice negative feedback for almost 18 pages is just plain wrong. A lot more people provided negative feedback.

Maybe you should read those earlier pages before you entered into this discussion thread ?

 

[virgile]

Nobody is restricting anybody from making comments, either in favor for or against the decision proposals. xkcd even created his own thread for it.
But to say that just 3-4 people voice negative feedback for almost 18 pages is just plain wrong. A lot more people provided negative feedback.

Maybe you should read those earlier pages before you entered into this discussion thread ?

I went over 5 pages in a few minutes, it was indeed only you few. And a person making a lighthearted joke and two persons being neutral. But yeah, i don't know why we are discussing that. Point is if you are the majority you don't need to point that out usually...

 

[stan.distortion]

The forum thread about Proof-of-Useful Work, which retains the key benefits of PoW while consuming energy in a more sustainable way, was somehow deleted. The administrator of the forum was unable to restore the post when I asked him to. At that time, I took a snapshot of the thread, which you can find here.

WTF? How many other technical discussions have been somehow deleted from this forum?

 

[qwizzie]

I went over 5 pages in a few minutes, it was indeed only you few. And a person making a lighthearted joke and two persons being neutral. But yeah, i don't know why we are discussing that. Point is if you are the majority you don't need to point that out usually...

Page 1 :

Semarge
vazaki3
dashfriend
kot
splawik21
GrandMasterDash
GNULinuxGuy
Macrochip
Me

All leaving negative feedback to the 4K HPM & 10K HPM ... and thats just page 1

 

[virgile]

Page 1 :

Semarge
vazaki3
dashfriend
kot
splawik21
GrandMasterDash
GNULinuxGuy
Macrochip
Me

All leaving negative feedback... and thats just page 1

We both know that feedback before any discussion even happened isn't really telling is it not? If you scroll back far enough you will also find negative feedback from xqc probably, i know he was against the idea of not enforcing platform on all nodes at first, and then he came back a few days later agreeing. That said, not very constructive, topic closed on my part.

 

[qwizzie]

We both know that feedback before any discussion even happened isn't really telling is it not?

It is telling to me, specially after those same people expressed their negative feedback a number of times during this 18 page thread.
If you want to ignore that, that is fine.

Of course people can change their opinion about this topic, specially after learning of the shortcomings / benefits of each solution.
But looking at the people that participated in this thread and commented so far, i would still say a majority left just negative feedback.

 

[peter]

Looking at the different people that commented so far in this 18 pages long thread .. i would say there is a very negative majority, not a very negative minority.

This is just your interpretation. And actually a quite negative interpretation.
You cannot know it. You don't know the number of Dash users, of forum users, of MNOs, and you don't know neither the number of silent persons in each of these 3 groups.

But you know the facts: there are about 4 or 5 overly loud voices in the group of forum users, and there are about 600 MN-votes acknowledging the work of DCG.

My interpretation is quite different: I guess, that there is a vast majority in all 3 groups, acknowledging the work of DCG, and keeping silent here, because they don't see any need to express their acknowledgment.

 

[qwizzie]

This is just your interpretation. And actually a quite negative interpretation.
You cannot know it. You don't know the number of Dash users, of forum users, of MNOs, and you don't know neither the number of silent persons in each of these 3 groups.

let me requote myself :

Of course people can change their opinion about this topic, specially after learning of the shortcomings / benefits of each solution.
But looking at the people that participated in this thread and commented so far, i would still say a majority left just negative feedback.

If this thread is considered pre-proposal feedback on the upcoming DCG decision proposals, it could be handy for DCG to take that into consideration as well.

 

[vazaki3]

.... there are about 600 MN-votes acknowledging the work of DCG.

598 MN-votes (approximately 76 individuals) acknowledge the work of DCG, but not necessarily the work of DashPlatform.

If DCG really wants to discover the truth, then they should split their next DCG-COMP-JAN-MAR23 into DASHPAY-COMP-JAN-MAR23 and DASHPLATFORM-COMP-JAN-MAR23 .

But I am afraid they will not, because truth hurts.

 

[krilen]

This is VERY serious. Who deleted the thread , and for what reason?

WTF? How many other technical discussions have been somehow deleted from this forum?

I don't know. Maybe the spam filter, because at the same time I was also banned from posting. The administrator promptly restored my privilege to post when I contacted him, but could not restore the thread. It is somewhat surprising that a spam filter can retroactively delete a thread.

 

[TheNetworkIsBiggerThanYou]

my problem, conceptually, with the 10k HPMN plan is that is seems to be designed reactively based on the existing constraints of the network (in particular, having a couple big whales). This doesn't feel right to me. Supposing that my feeling is just a feeling and not an accurate measure of the appropriateness of the plan, and assuming it is structurally sound in set up, there is one more thing that would need to be guaranteed to me, and I suppose to the rest of the network. That the HPMNs cannot censor the platform content. There is a lot of hyperbolic talk going on about broken promises, changed vision, etc. But truly if we allow censorship baked into the design and structure we have failed the mandate.

Let me define censorship first - When MNOs, or any other entities, are able to remove content from platform, or if they are able to manipulate the fees associated with specific data so as to prohibit their practical use.

So my questions are;
1.) Is there a mechanism in theory or practice, currently developed, to censor content from platform?
2.) What sort of guarantee is there that platform cannot be censored? What would that guarantee look like?

I'm extremely tired of Dash entities promising one thing and then pivoting. We've seen it most blatantly with the DIF where they promised to put all funding to a vote and then once they became entrenched they changed their mind on that promise. Somehow these things are viewed as acceptable. Censorship resistance is a non-negotiable. It is literally the only fucking reason Dash platform is interesting. Not the speed, or low cost, or usernames. The world needs an independent tool that dash is offering. It is unique and special. Marginalized and threatened groups need to know they can rely on the dash network otherwise they will not build on it, and who can blame them.

Censorship needs to happen at the application layer, not the protocol level. It is the app developers who are ultimately responsible for moderation of content. In the analogous centralized network, ISPs are responsible for moving child porn off their servers because they *can* remove the porn. They are not decentralized. There should be no option for blocking content by HPMNs. If a reasonable application developer who is not a totally gross deviant, does't want child porn in his application he needs to filter out that garbage. There is a myriad way of doing this filtering and the Dash DAO and DCG can be leaders in making it easy to do so.

In the future, when dash gets under heat for misusage of storage it is up the DAO and the developers to go after the offending parties by again offering application filtering tools, or through even hiring investigators to hunt down the identities of the deviants. With the treasury funding system we have the tool to do this.

If we can be assured beyond a doubt that Dash is being built to maintain, and ideally improve, its censorship resistance then I personally can accept, what my layman's perspective seems to be a suboptimal dash platform setup.

 

[virgile]

my problem, conceptually, with the 10k HPMN plan is that is seems to be designed reactively based on the existing constraints of the network (in particular, having a couple big whales). This doesn't feel right to me. Supposing that my feeling is just a feeling and not an accurate measure of the appropriateness of the plan, and assuming it is structurally sound in set up, there is one more thing that would need to be guaranteed to me, and I suppose to the rest of the network. That the HPMNs cannot censor the platform content. There is a lot of hyperbolic talk going on about broken promises, changed vision, etc. But truly if we allow censorship baked into the design and structure we have failed the mandate.

Let me define censorship first - When MNOs, or any other entities, are able to remove content from platform, or if they are able to manipulate the fees associated with specific data so as to prohibit their practical use.

So my questions are;
1.) Is there a mechanism in theory or practice, currently developed, to censor content from platform?
2.) What sort of guarantee is there that platform cannot be censored? What would that guarantee look like?

I'm extremely tired of Dash entities promising one thing and then pivoting. We've seen it most blatantly with the DIF where they promised to put all funding to a vote and then once they became entrenched they changed their mind on that promise. Somehow these things are viewed as acceptable. Censorship resistance is a non-negotiable. It is literally the only fucking reason Dash platform is interesting. Not the speed, or low cost, or usernames. The world needs an independent tool that dash is offering. It is unique and special. Marginalized and threatened groups need to know they can rely on the dash network otherwise they will not build on it, and who can blame them.

Censorship needs to happen at the application layer, not the protocol level. It is the app developers who are ultimately responsible for moderation of content. In the analogous centralized network, ISPs are responsible for moving child porn off their servers because they *can* remove the porn. They are not decentralized. There should be no option for blocking content by HPMNs. If a reasonable application developer who is not a totally gross deviant, does't want child porn in his application he needs to filter out that garbage. There is a myriad way of doing this filtering and the Dash DAO and DCG can be leaders in making it easy to do so.

In the future, when dash gets under heat for misusage of storage it is up the DAO and the developers to go after the offending parties by again offering application filtering tools, or through even hiring investigators to hunt down the identities of the deviants. With the treasury funding system we have the tool to do this.

If we can be assured beyond a doubt that Dash is being built to maintain, and ideally improve, its censorship resistance then I personally can accept, what my layman's perspective seems to be a suboptimal dash platform setup.

We'll adress that in the incoming FAQ, but basically the tldr is: if you look at node distribution among owners, 4/10K is better with bonus point if you have shares. If you care about the amount of nodes, well that's a parameter to set. You surely have in mind other projects which have lots of nodes and are "decentralized" but really owned by like 2-3 entities... Ownership distribution is very important to avoid censorship.

 

[stan.distortion]

...
I think the biggest issue here is a base level of distrust so when we propose anything there are some that immediately distrust it. There doesn't seem to be much ways to mend this situation unless those that are distrustful explain what would make them trust DCG again.

If the network votes and prefers the "everyone runs Platform solution" then we will go with that one. I will pray that I was wrong if we go in that direction. Once again I do not understand why people are unhappy with DCG asking the network what they prefer to do? Isn't that how our governance should work?

Trust in DCG is deep into the red, you've definitely been pushing it back up but it's so far into the negative that DCG would be better liquidated and reformed imho. I'd say this issue is the straw that broke the camels back, the real issue was finding out we'd been hoodwinked with endless promises of "it's getting there!" and you where only handed that can of worms, you're not getting the blame for causing it.

That's where a good chunk of the anger is coming from imo, but certainly not all of it. You want to implement an optimisation method that goes against (for me) the whole point of crypto, decentralised and uncensorable. A few high performance nodes is how things work in the corporate world, it's centralised and censorable. Every additional node should add to the overall performance of the network, every other optimisation path leads to greater centralisation.

 

[rion]

THEN WHAT MAKES YOU AFRAID OF A REGULAR 1K MN WITH VOLUNTARY ADHERENCE TO PLATFORM (and an INITIAL LIMIT to the number of nodes) ????

Its the most natural, non-coercive and sensible way of starting Platform...
Perhaps somebody else will give us the chance to vote on it.

Agreed. I'm planning to submit an alternative proposal that's very similar to what you described; the only caveat is that it would be coupled with timelocking the 1,000 DASH stake, for various reasons that I will expound upon if I formalize the proposal.

If you refer to numbers on the 1K solution that Rion proposes: it simply could/would lead to very heavy centralization on platform, which we wish to avoid, so we won't stay silent at an obvious issue which could hurt the project.

That post was preliminary. I've refined it a bit since then, but it's still the same general idea. Thanks for spending some time explaining your modeling. I wouldn't propose something I think has an "obvious issue". The potential to "hurt the project" exists in every scenario at this point, so that's not saying much.

So, so far among the more serious solutions that have been fleshed out, there was:

-all nodes (old design) -> secure for whales takeover, but if there is a catastrophic failure on Platform, it impacts DASH as a whole. And this, you cannot go around, by definition they all run platform so if platform has a bug... yeah. There is nothing to think about here. It's like asking a filled doughnut: that isn't a doughnut anymore, that's another pastry.

-1k nodes + limit the number of nodes (by rion) -> whale takover chances are way too high

-4k/10k nodes (us) -> no glaring security issue

Whale takeover chances in my model are not high. I'll share it with everyone when I have some more time to present it properly.

Some people on this forum seem to think that the 4k and 10k solutions would be more centralised and I must admit I thought the same at first until I really thought about it. The reason why these options are not more centralised is precisely because the stake required is so high, at 10k there are few whales with enough Dash to be able to form a majority stake in Dash in order to control the Platform, so 10k is by far the safest and most decentralised option. As we go to smaller stakes, the risk becomes that a big whale could create enough nodes such that they control the network and do the bad things. This is most obviously in the 1k opt in model where MNOs choose to run Evo with 1k collaterals, if the network size were say 600 Evo 1k nodes, then our largest whale could wind up controlling a third of the network which is the threshold where they can start to mess with it.

The 10k option is relatively secure because, like you say, most MNOs can't participate at that level. Unfortunately that's the same reason it's very risky to the project in various other ways. We need to find a way to launch securely without introducing problems associated with increasing collateral requirements. I think timelocks solves this. Binance isn't going to launch 270 platform nodes if they require a timelock, and Binance is the main risk.

Under timelocks what's more likely?
A) all the large whales convert every single one of their nodes into platform nodes, immediately, or
B) various dedicated small MNOs convert, and some large whales convert a small portion of their nodes.
I think B is more likely (with timelocks), and that's exactly what we want. Not everyone will love this, but I think more will find it acceptable than the alternatives.

Running platform should be accessible to all MNOs who believe in the project. Timelocks allow for that in a way that 4x/10x collateral increases don't. Keeping the 1,000 DASH requirement should be a design constraint.

One more thing: Everyone should keep in mind that not all DCG devs/staff feel the same as Sam. I know of at least one dev who doesn't think that launching with 1,000 DASH collateral is a big risk.

 

[virgile]

Agreed. I'm planning to submit an alternative proposal that's very similar to what you described; the only caveat is that it would be coupled with timelocking the 1,000 DASH stake, for various reasons that I will expound upon if I formalize the proposal.


That post was preliminary. I've refined it a bit since then, but it's still the same general idea. Thanks for spending some time explaining your modeling. I wouldn't propose something I think has an "obvious issue". The potential to "hurt the project" exists in every scenario at this point, so that's not saying much.


Whale takeover chances in my model are not high. I'll share it with everyone when I have some more time to present it properly.


The 10k option is relatively secure because, like you say, most MNOs can't participate at that level. Unfortunately that's the same reason it's very risky to the project in various other ways. We need to find a way to launch securely without introducing problems associated with increasing collateral requirements. I think timelocks solves this. Binance isn't going to launch 270 platform nodes if they require a timelock, and Binance is the main risk.

Under timelocks what's more likely?
A) all the large whales convert every single one of their nodes into platform nodes, immediately, or
B) various dedicated small MNOs convert, and some large whales convert a small portion of their nodes.
I think B is more likely (with timelocks), and that's exactly what we want. Not everyone will love this, but I think more will find it acceptable than the alternatives.

Running platform should be accessible to all MNOs who believe in the project. Timelocks allow for that in a way that 4x/10x collateral increases don't. Keeping the 1,000 DASH requirement should be a design constraint.

One more thing: Everyone should keep in mind that not all DCG devs/staff feel the same as Sam. I know of at least one dev who doesn't think that launching with 1,000 DASH collateral is a big risk.

Just a heads up. If your idea still relies on timelock + 1K collaterals + a hard limit on the number of nodes, i will have to staunchly disagree and give my advice to the community wide and large, as this in fact is insecure. Not to mention the "lack of collateral differenciation" related issues. It will be quite confrontational so i'd rather say it beforehands, i hope it will not impact our working relations in your eyes. It won't for me, but the network goes above the rest though.

As of your other statements... eh... I will wait for you to actually present your idea somewhere to refute what i think is wrong.

 

[QuantumExplorer]

So my questions are;
1.) Is there a mechanism in theory or practice, currently developed, to censor content from platform?
2.) What sort of guarantee is there that platform cannot be censored? What would that guarantee look like?

This is not the topic for this thread. I have a feeling when I respond we will go offtopic. I'll respond very succinctly here. If though you want to continue the conversation about it I would suggest making a new thread dedicated to the topic.

We need to start by having a common understanding of what censorship means. According to the dictionary it is defined as to "examine officially and suppress unacceptable parts of it." According to that definition at launch there will be no censorship. Why? Because we are limiting sizes on Dash Platform to things really very small in order to push this problem to a future release. There is no examination of content so there is no censorship, but the goal of suppression of undesirable content is somewhat achieved.

Second we need to understand what the goal is... Platform should not be used as a marketplace for contract killings, terrorism and child pornography (and other things at this level). If anyone thinks it should, then there's nothing I'm willing to debate. However I think most people when talking about censorship are thinking more about people censoring online free speech. I think many here are rational enough to see the difference between someone who wants to participate in child abuse and someone who criticises the government.

Thoughts have been put into place on how to deal with these issues. The conceptual way of how we can deal with this problem is that we create 3 piles of types of content. The first is content that everyone must host, the second is content that everyone can host, and the third is content that no one can host.

Until we have the type of PoSe that we defined in other posts (that has never been done in blockchain) the feature presented here is not possible.

So we are all aligned, our roadmap is that we will first be building smart contracts, and then PoSe. At that point platform will have much easier ways to vote specific to decisions like this. We will ask the network to vote on the types of content it wants to put in each category, it may well vote that all data must be available in every category. However if that is the case I think many would resign including myself. Once that is done we will have a release for this feature while increasing the size of "blobs" of data in platform.