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

Holy cows, fake buy wall?

I don't know what you mean by fake....If people want to sell at that price it will be filled!  Unless it gets pulled I suppose...

Is there something I don't get?

I don't know what you mean by fake....If people want to sell at that price it will be filled!  Unless it gets pulled I suppose...

Is there something I don't get?

Holy cows, fake buy wall?

LOL !!!!!

91k buy wall-e @ bitfinex @ 0,007btc
Otoh is that ALL you?!?!?!

WOW   Walls moved to 70...and what such of volume!  

Now that the network has updated to version 11 and is stable, I thought it might be a good idea to lay out what the next we have in store for the next release and future plans. We’ll be leveraging our larger development team and working on a few projects at once to enable to a few new exciting features at once.

Enforcement
Network fragmentation has been corrected on the network and we’ve enabled enforcement. Those not paying the correct node after today will simply be rejected by the network.

InstantX
A couple months ago I open sourced the design so that I could work with researchers on perfecting it. However, it’s not presently done and the code is a simple prototype of what I intended. I would recommend other crypto-currencies from not using it until we’ve had a chance to thoroughly test and refine the logic, otherwise grave damage could be done to your network.
We’ll begin finishing development on instantX immediately and work on the stability of the system. This will be done over the next few weeks on testnet and will be a completely open public testing phase.

Masternode Changes / Improvements
As an upgrade to the masternode system, we’re going to be moving to a token-based system, where you’ll only be required to gain access to your cold wallet every few months. When starting a masternode, one will simply execute the “masternode generate-token” command, which will sign the key and generate a tokenized string to put into the masternode.conf. Using this signature masternodes can be restarted multiple times, even with protocol version updates.

The pinging system (dseep) is going to be replaced with a “challege request” system, which will be done in a completely decentralized way. Other masternodes on the network will be elected each block to check on their peers by initiating a “challenge request”, if a masternode fails multiple of these in a row by failing to respond it will be removed from the list.

As be move forward into the future, static IPv4 IPs will continue to get more scarce. In the next release we will begin to allow non-static IPs to be used as long as the client is reachable and can answer challenge requests.

Beyond version 11.1 (will not be in the InstantX release)

Masternode Blinding
Recently a paper by 3 researches at Saarland University came out describing a new technique, while there are some serious problems with the approach they take, the concept of blinding the users they use is novel. In CoinShuffle, each output is sent to the next peer in a circle, one at a time. The new peer adds an output, shuffles and then sends the list again. We can do this and actually improve upon it.

To implement blinding, each user would connect to one completely random masternode and say "Send masternode X this output/value for mix N" and pass a single output. That output would be passed to the leading masternode. It would take access to all masternodes used to know who did what, which is as solid as M rounds mathematically (M = number of outputs). This is great because all users can submit all inputs at once. So it's super fast compared to CoinShuffle and even more secure.

Decentralization of the masternode payment system
Currently, there is a node that signs a message for each block and says which masternode should be paid for that specific block. As many of our users know, the centralized reference node was a temporary solution to the problem of enforcing masternode payments. Miners use this when creating the block to ensure they comply, if a miner tries to cheat the system, the block will be rejected by the network. This is a great solution temporarily, but isn’t decentralized enough.

To explain the new completely decentralized strategy, first we have to explain exactly how masternodes work. When a masternode starts, it relays a message called the “masternode election entry”. This puts the masternode into a list on all clients on the network and allows them to be used by all of the clients on the network. Every few minutes, these masternodes ping the network saying they’re still alive and allowing them to earn interest payments.

To decentralize this system, we propose a new system we’ll call “Masternode mining”. This simply means that when miners receive a new “masternode election entry” and solve a block, they will append the masternode to the block. Each block can contain up to 10 masternode list changes. So by following the normal progression of the blockchain, you will be able to compile a list of all known masternodes. This system is also highly resistant to attack and the same list can be compiled by any client on the network.

For example:
Block 1: Add mn1, mn2, mn3
Block 2: Add mn4, mn5
Block 3: Remove mn2  //mn2 fell off the network
-- currently the masternode list contains mn1, mn3, mn4, mn5
Block 4: Add mn6, mn7
Block 5: Add mn2  //mn2 came back

-- example attack: --
Block 6: Remove mn1, mn2, mn3, mn4, mn5, mn6  //miner owns masternode 7, wants control of the network
Block 7: Add mn1, mn2, mn3, mn4, mn5, mn6

In this case a majority of mining power is required to control the masternode list. If a miner has enough computing power to alter the masternode list, they will also have enough power to double spend with a 51% attack. Therefore this is the safest solution to decentralizing the payment.

You can use coin control to select inputs to send so that you don't break any of your MNs.

Sorry, misread your post - no you can't activate DS to mix coins in your Masternode wallet. If you denominate and mix the 1000DRK vins you'll break your MNs.

Now that the network has updated to version 11 and is stable, I thought it might be a good idea to lay out what the next we have in store for the next release and future plans. We’ll be leveraging our larger development team and working on a few projects at once to enable to a few new exciting features at once.

Enforcement

Network fragmentation has been corrected on the network and we’ve enabled enforcement. Those not paying the correct node after today will simply be rejected by the network.

InstantX

A couple months ago I open sourced the design so that I could work with researchers on perfecting it. However, it’s not presently done and the code is a simple prototype of what I intended. I would recommend other crypto-currencies from not using it until we’ve had a chance to thoroughly test and refine the logic, otherwise grave damage could be done to your network.

We’ll begin finishing development on instantX immediately and work on the stability of the system. This will be done over the next few weeks on testnet and will be a completely open public testing phase.

Masternode Changes / Improvements

As an upgrade to the masternode system, we’re going to be moving to a token-based system, where you’ll only be required to gain access to your cold wallet every few months. When starting a masternode, one will simply execute the “masternode generate-token” command, which will sign the key and generate a tokenized string to put into the masternode.conf. Using this signature masternodes can be restarted multiple times, even with protocol version updates.

The pinging system (dseep) is going to be replaced with a “challege request” system, which will be done in a completely decentralized way. Other masternodes on the network will be elected each block to check on their peers by initiating a “challenge request”, if a masternode fails multiple of these in a row by failing to respond it will be removed from the list.

As be move forward into the future, static IPv4 IPs will continue to get more scarce. In the next release we will begin to allow non-static IPs to be used as long as the client is reachable and can answer challenge requests.

Beyond version 11.1 (will not be in the InstantX release)

Masternode Blinding

Recently a paper by 3 researches at Saarland University came out describing a new technique, while there are some serious problems with the approach they take, the concept of blinding the users they use is novel. In CoinShuffle, each output is sent to the next peer in a circle, one at a time. The new peer adds an output, shuffles and then sends the list again. We can do this and actually improve upon it.

To implement blinding, each user would connect to one completely random masternode and say "Send masternode X this output/value for mix N" and pass a single output. That output would be passed to the leading masternode. It would take access to all masternodes used to know who did what, which is as solid as M rounds mathematically (M = number of outputs). This is great because all users can submit all inputs at once. So it's super fast compared to CoinShuffle and even more secure.

Decentralization of the masternode payment system

Currently, there is a node that signs a message for each block and says which masternode should be paid for that specific block. As many of our users know, the centralized reference node was a temporary solution to the problem of enforcing masternode payments. Miners use this when creating the block to ensure they comply, if a miner tries to cheat the system, the block will be rejected by the network. This is a great solution temporarily, but isn’t decentralized enough.

To explain the new completely decentralized strategy, first we have to explain exactly how masternodes work. When a masternode starts, it relays a message called the “masternode election entry”. This puts the masternode into a list on all clients on the network and allows them to be used by all of the clients on the network. Every few minutes, these masternodes ping the network saying they’re still alive and allowing them to earn interest payments.

To decentralize this system, we propose a new system we’ll call “Masternode mining”. This simply means that when miners receive a new “masternode election entry” and solve a block, they will append the masternode to the block. Each block can contain up to 10 masternode list changes. So by following the normal progression of the blockchain, you will be able to compile a list of all known masternodes. This system is also highly resistant to attack and the same list can be compiled by any client on the network.

For example:

Block 1: Add mn1, mn2, mn3
Block 2: Add mn4, mn5
Block 3: Remove mn2  //mn2 fell off the network

-- currently the masternode list contains mn1, mn3, mn4, mn5

Block 4: Add mn6, mn7
Block 5: Add mn2  //mn2 came back

-- example attack: --

Block 6: Remove mn1, mn2, mn3, mn4, mn5, mn6  //miner owns masternode 7, wants control of the network
Block 7: Add mn1, mn2, mn3, mn4, mn5, mn6

In this case a majority of mining power is required to control the masternode list. If a miner has enough computing power to alter the masternode list, they will also have enough power to double spend with a 51% attack. Therefore this is the safest solution to decentralizing the payment.

Wow, this thread seems to be purely about masternodes

Any reason for this?