Topic: [ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency - page 887. (Read 9723733 times)

Just buy PASC and shut up! 

Damn you're the real deal! 

Another announcement of an announcement?

Totally legit.  No pump here.  Definitely not just another opportunity for Evan the Instaminer & Co. to dump onto a new generation of bagholders.

Massive crash?

Aw, evolution?

Well, as the anointed most "thoroughly brainwashed cult victim" (Nº 1 apparently ) I think I should at least have a say on this, which is that  - you're all wrong  

The only enforceable authority that the masternode voting has is over how to spend the block reward budget. Any other voting is basically an opinion poll of the holders, but as such it still serves a purpose because the three other stakeholder quadrants (miners, developers, merchants) all have it in their interests to carry mutually supportive sectors with them.

(For example, it's in holders interests that miners are attracted to the network, it's in merchants interests that developers give them a roadmap to future-proof their commitments, it's in miners and merchant's interests that holders don't dump and crash the value because things are going in a sh*t direction that they don't like etc). There is also some indirect enforceability in that voting can deny development funds to the currently endorsed core developer group to the extent that they are getting financed directly from the blockchain.

So the voting is what it is - everyone will draw their own significance from it. Voting couldn't enforce the blocksize change, but on the other hand consider what would have happened if if the vote had gone against and the devs had still implemented it and the miners accepted the upgrade. There would have been a public fissure in the stakeholding community that would be fairly categorical and visible. Markets would then price that discord accordingly.

Aeroplanes have something called a trim tab on their main directional control surfaces. It relieves the stress on the cables connecting the pilot's inputs with the elevators and rudder by replacing the mechanical pressure with aerodynamic force at source, thereby placing the entire aircraft back into a state of aerodynamic equilibrium for a given configuration of main-surface deflection (take-off / cruise / approach). However with everything else in balance, the trim tab can actually change the direction of the aircraft on its own.

Dash masternode voting is a "trim tab".

The main "control surfaces" are the 3 big stakeholder sectors - miners, developers and merchants (including exchanges) IMO, and the voting creates balance by adding two things:

 • supplying enforceable and final judgements on the allocation of budget assigned block rewards
 • providing directional stability in ambiguous situations with respect to the other 3 "stakeholder quadrants"

This one i dedicate to our trolls that have been with us through hardship and prosperity :



ETA : 10 days

My post is very much more clear than the misleading vote for 2mb, which was purported to be an actualizable, shovel-ready short-term goal, but turned out to be nothing but a feel good exercise in putting down and sneering at Dash's betters on the Bitcoin Core team.

What is the point of voting in favor of something Duffiled is going to do anyway?  That's called a 'rubber stamp' (IE not actual governance).

What is the point of voting for something if there's no way to make sure it gets done?  That's called 'symbolism over substance.'

It's very clear SolarMiner and many others were lied to by Evan and disenfranchised by the fraudulent 2mb vote, which served only to pump the price and enable Evan to dump more of his Instamine on bagholders eager to have 2mb blocks.

You're not very clear, my dear.

There are two non-exclusive possibilities here.

1. Dash's so-called "distributed governance" is just a system for conducting unenforceable and therefore meaningless symbolic straw polls (along with unaccountable grants of free money)

2. Evan lacks the technical chops to implement a maximum 2mb block size


Gee, I wonder how silly old SolarMiner got the mistaken impression that the 2mb vote was, you know, more than just a bullshit jacking off exercise in self-congratulation?

Can anyone provide evidence from the time of the vote that it was widely understood to be a mere resolution in support of a 2mb vaporware upgrade?

Solving the problems inherent to a 2mb max blocksize is much harder than simply voicing some nebulous intention for undertaking such an endeavor.

And yet, you consider 2mb 'as good as done' with no substance to back up the symbolism.

I know you aren't really knowledgeable about what happens in Bitcoin world, but please be aware that project has run into big problems (IE, a chain fork) due to nodes signaling support for upgrades they weren't actually ready for.

As an aside, it's pretty funny even Dash's 2nd most thoroughly brainwashed cult victim (right behind toknormal) doesn't believe Dash will actually be used for "at least another 3 years."

In 3 years, the crypto universe will be radically different, and if Dash doesn't start finding uses in the real world very soon it will be an almost forgotten footnote in history.

Don't be surprised, trolls know very well that this particular vote was not to be taken literally. They just play their moronic and/or paid game over and over.

https://www.dashcentral.org

I'm surprised anyone has taken the vote to increase Dash blocksize literally the real motivation was very obvious. Personally I didn't really like that proposal but I can see why it was done, there was an opportunity to contrast favourably against bitcoin and it was taken.

Charting Dash’s Evolution and Sprint Forward

http://news.coincap.io/2017/01/charting-dashs-evolution-and-sprint-forward/

When Evan put up that proposal, it's ONLY purpose was to show how fast Dash can get consensus.  We won't need extra space for at least another 3 years unless we are suddenly so successful, we're all wondering if we're having a wet dream.  We BARELY make a dent in any block. Why this issue should bother you, I can't understand!  I think it used to be that block size was needed to reserve space for entries.  I don't know if that's still the case.  But if you have each block with 1 MB of space, it grows quickly.  If you reserve 2 MB of space, the block size grows doubly fast. I heard block sizes are now flexible, but I'm not sure that's the case.  If not, then our 4X transaction space is already growing far faster than Bitcoin's and it's all empty space!  I hope that's not the case, and that we actually have flexible block sizes, but I believe that's why there is a block size, and we simply inherited it.

And I can see MooCow being correct, that having too much wiggle room with nothing in there might create attack vectors.  I don't know how exactly, but in programming, you want to keep things well fitted and efficient.

As far as transaction locks go, those usually clear up with the very next block.  But if that proves not to be enough, as Udjin said here, "Successfully locked inputs are kept in "lock list" for 1 hour i.e. 24 blocks on average which should be enough imo but I'm sure we can easily extend this if there is a need or some research saying that this is not enough."

That could be a good start but it's definitely not enough. With this change only network is going to fork in two during update once someone spams it with few thousands of txes overflowing 1mb, so you need more code: either define a starting block at some time in the future and apply if/then logic in block validation (assuming that everyone _must_ upgrade before this block, which is an old way of doing thing and we really should stop using it btw) or implement it via signaling/"supermajority rule".

As for proposal/block size limit/etc:
- this was a "poll proposal", imo it's clear from its text - there was no date set in stone in its text besides "before Evolution";
- historically 1MB limit was set in bitcoin as a temporary protection while network is in its early age and tokens are too cheap i.e. it's economically vulnerable to spam - I believe our network is still better to be protected that way;
- the point of the poll was "let's give Dash more room to grow on-chain when needed" - 1MB is clearly enough right now, so we are focused on other things which are critical for closest launch and following releases.

If you still feel like it should be coded _right now_ for whatever reason and you want to code it yourself - submit PR on github (preferably, not a hardcoded block height solution), we'll happily review and apply it when time comes, if you don't want to code it - we'll implemented it ourselves when needed. If you think it should be applied right now just "because reasons", you'd better find some arguments imo.

Well, Solarminer is kind of right about that one, to be fair.

Currently locks are kept for 1h / 24 blocks. This is more like a buffer for chain reorgs, not a mempool atm. A flooding attack could be mitigated say by changing "ix mempool" behavior to expire locks not 24 blocks from the entry block but from locked tx confirmation block for example.
...
..
.
I'll have a look

EDIT: fixed typos

Hey Moo.   There is more too it than just being impatient.  I think most people thought that proposal would happen quickly, not waiting 2 years for Evolution.  And if this was the only issue with Dash, it would be a pretty minor issue.

This is from the initial release post here:  https://www.dash.org/forum/threads/v0-11-1-instantx-release.3923/
Transaction locks are lost when restarting the client and only last for an hour
So if there are enough transactions that have fees higher than the InstantX fee, and blocks are kept full for an hour, the lock will be released and transaction unlocked.

Just to let you know that Dash market is just commencing a 1-hour chart correction for a while, so you can take a tea break if you need one. (Your bud here will make you a cup that's agreeable   ).

Normal services should commence in about 10-12 hours. (Woudn't want you overworked and needing to join him  ) ).

Isn't the elephant in the room Evan's inability to independently emulate the combined efforts of Bitcoin Core?

It's easy to press the fork button on Bitcoin (or was it from Litecoin that Xcoin was forked?) but much harder to keep up with the original project feature wise.

Evan used Gavinista FUD about RBF/CPFP as an excuse to avoid putting in that great feature, but (hilariously) the popular-on-reddit '2MB RITE MEOW' meme has now put him on the spot.

It doesn't help that tante and the other cheerleaders pumped him up to be the next Satoshi, and thus unmanaged expectations have grown completely out of control.


"The “premium” office costs $2,000 per month"

^^^That is the epitome of of "Marketing over Tech."

Solar, I don't mind you having an opinion, but I do take issue when you post assumptions as fact.


100% completely and utterly false. IX locks are mempool entries same as transactions.  They don't get flushed until the transaction gets written into a block, regardless of how many blocks that takes.

And, your disappointment is simply impatience.  The very last sentence of the proposal states:

If approved, a proper development, testing and deployment process would start before it reaches production. Let’s give Dash room to grow.

The process is already happening, there's just no need to implement it anytime soon.