DASH governance system
Dash's governance is way way way more fair and decentralized than BTC, which is controlled by only a handful of centralized miners in china.
Nope. Dash does not have a governance system. Governance implies that you can force a change. The only thing the budget system can do is pay out a project that is submitted.
Proof: Budget passed to increase block size to 2MB. Result is still 1MB blocksize. Of course, this proposal is used over an over to say Dash can increase the blocksize in 24 hours....um. right....1 year and still no change.
The only ones that can control changes are those with access to github. And even then, the code needs to be created and tested before it can be approved.
Charlie was spot on with the "Marketing over Tech".
To get you started on that blocksize increase, here is a start.
https://github.com/dashpay/dash/blob/master/src/primitives/block.h/** The maximum allowed size for a serialized block, in bytes (network rule) */
static const unsigned int MAX_BLOCK_SIZE = 1000000;
change to
static const unsigned int MAX_BLOCK_SIZE = 2000000;
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.
Solar, I don't mind you having an opinion, but I do take issue when you post assumptions as fact.
If blocks do get full, InstantX transactions will start to be unlocked.
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.
...
...
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 hourSo 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.
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
With this new major exchange coming on board and stress testing instantx/instantsend is it now time to implement the 2MB blocks?