[ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency

[Ignition75]

Why you guy are so scared ? Little price drop huh ? Lets talk price right now.
What are your predictions ?
Le me tellyou mine :
Two weeks after RC5 one DRK is going to cost 0.045 BTCand rising !

I don't see how RC5 is going to drive the price up. Unless some big holders stop dumping their coins the bearish trend will continue.

RC5 will mean DarkSend+ is open source and then the marketing will commence... Or soon after that anyway...

Nobody trust close source . RC5 and the open source is going to be the start of the race !

I'm thinking about opening the source at release of RC5. I've actually been having various close friends of mine look at the source and no one sees anything seriously wrong with it besides some organizational issues (which I'm working on now). I believe we're ready to go.

That's great news 

[oblox]

Why you guy are so scared ? Little price drop huh ? Lets talk price right now.
What are your predictions ?
Le me tellyou mine :
Two weeks after RC5 one DRK is going to cost 0.045 BTCand rising !

I don't see how RC5 is going to drive the price up. Unless some big holders stop dumping their coins the bearish trend will continue.

RC5 will mean DarkSend+ is open source and then the marketing will commence... Or soon after that anyway...

Nobody trust close source . RC5 and the open source is going to be the start of the race !

I'm thinking about opening the source at release of RC5. I've actually been having various close friends of mine look at the source and no one sees anything seriously wrong with it besides some organizational issues (which I'm working on now). I believe we're ready to go.

Any further updates from Mr. Atlas on his peer review?

[eduffield]

Saw this yesterday in a local newspaper  

https://docs.google.com/document/d/143Uwls4ZZrN7pS7bWfjk03i90TWskjy8scNB2U0HOoo/edit

[splawik21]

I'm thinking about opening the source at release of RC5. I've actually been having various close friends of mine look at the source and no one sees anything seriously wrong with it besides some organizational issues (which I'm working on now). I believe we're ready to go.

Ohhh Evan
Every your post here is like blessing
Cool beer for you.

[safepalm]

Saw this yesterday in a local newspaper  

https://docs.google.com/document/d/143Uwls4ZZrN7pS7bWfjk03i90TWskjy8scNB2U0HOoo/edit

Great news!  Are there any concrete plans for the foundation?  Any course of action?

[thelonecrouton]

I don't understand why you people saying we will start marketing after RC5. Any reason we can't start it now?

None at all, go for it!

[safepalm]

I've been a long time lurker and I've recently set up a couple of masternodes.

On https://drk.mn/ I can see them as 'Active' but the port check status is 'Closed'.

Can someone tell me if this is OK or if I should be worried?  Normally the masternode should not appear as 'Active' if the port is really closed, I guess?

[oblox]

I've been a long time lurker and I've recently set up a couple of masternodes.

On https://drk.mn/ I can see them as 'Active' but the port check status is 'Closed'.

Can someone tell me if this is OK or if I should be worried?  Normally the masternode should not appear as 'Active' if the port is really closed, I guess?

When does it say it was last checked? How long have they been up? Did you get 1 when after grepping your ip?

[zenDevil]

I don't understand why you people saying we will start marketing after RC5. Any reason we can't start it now?

1) Who will trust close source ?
2) DRK will have only one chance to convince, better wait until at least know issues get fixed
3) By the way, RC4 still really sucks for the moment.

[safepalm]

I've been a long time lurker and I've recently set up a couple of masternodes.

On https://drk.mn/ I can see them as 'Active' but the port check status is 'Closed'.

Can someone tell me if this is OK or if I should be worried?  Normally the masternode should not appear as 'Active' if the port is really closed, I guess?

When does it say it was last checked? How long have they been up? Did you get 1 when after grepping your ip?

It was last checked about 30 minutes ago, the masternodes have been up 2 and 3 hours respectively (I restarted the first one because I thought I screwed up).  Both masternodes are listed with :1 behind the ip.

[BrainShutdown]

I've been a long time lurker and I've recently set up a couple of masternodes.

On https://drk.mn/ I can see them as 'Active' but the port check status is 'Closed'.

Can someone tell me if this is OK or if I should be worried?  Normally the masternode should not appear as 'Active' if the port is really closed, I guess?

When does it say it was last checked? How long have they been up? Did you get 1 when after grepping your ip?

It was last checked about 30 minutes ago, the masternodes have been up 2 and 3 hours respectively (I restarted the first one because I thought I screwed up).  Both masternodes are listed with :1 behind the ip.

The port 9999 must be open on the masternodes. Can you telnet the port and obtain a connection?

[Freckleg]

Why you guy are so scared ? Little price drop huh ? Lets talk price right now.
What are your predictions ?
Le me tellyou mine :
Two weeks after RC5 one DRK is going to cost 0.045 BTCand rising !

I don't see how RC5 is going to drive the price up. Unless some big holders stop dumping their coins the bearish trend will continue.

RC5 will mean DarkSend+ is open source and then the marketing will commence... Or soon after that anyway...

Nobody trust close source . RC5 and the open source is going to be the start of the race !

I'm thinking about opening the source at release of RC5. I've actually been having various close friends of mine look at the source and no one sees anything seriously wrong with it besides some organizational issues (which I'm working on now). I believe we're ready to go.

Bump

[KryptoFoo]

Saw this yesterday in a local newspaper  

https://docs.google.com/document/d/143Uwls4ZZrN7pS7bWfjk03i90TWskjy8scNB2U0HOoo/edit

Initial Board of directors membership:

1. Evan Duffield
2. Edward Moncada
3. Fernando Gutierrez Mosquera
4. Christopher Carlo Rimoldi
5. Harold Boo

I believe #3 is btc user fernando and #4 is eltito. What do we know about #2 and #5?

Also: is there a public charter, vision, mission statement?

[eduffield]

Saw this yesterday in a local newspaper  

https://docs.google.com/document/d/143Uwls4ZZrN7pS7bWfjk03i90TWskjy8scNB2U0HOoo/edit

Initial Board of directors membership:

1. Evan Duffield
2. Edward Moncada
3. Fernando Gutierrez Mosquera
4. Christopher Carlo Rimoldi
5. Harold Boo

I believe #3 is btc user fernando and #4 is eltito. What do we know about #2 and #5?

Also: is there a public charter, vision, mission statement?

Correct about Fernado and Eltito. Edward represents some of the largest Darkcoin investors and Harold is a long term Darkcoin supporter and attorney who helped setup the foundation. We've setup the foundation to equally represent all aspects of the coin (Development, Legal, Investment and Community). We'll be releasing much more detailed information with RC5

[baddw]

Sporkage is just putting the rules you mention into action. Same as if they were hardcoded in the first place.

Of course they had to be hardcoded in the first place for the spork to even work, but the fact that the software can be influenced by an external "switch" that can be turned on or off at any time is not in the spirit of cryptocurrencies.  I am fine with it for betas/RCs/development/whatever, but the final product should definitely not have any spork switches.

I don't believe enforcement was ever difficult to implement, I think the problems resulted from the payment/election code sometimes causing different nodes to believe different masternodes should be paid. So when enforcement was switched on (via hard fork), little forks started emerging because there wasn't consensus.

That is what I understand to have been happening; could've been something else though.

This is certainly believable, and I guess it would be a problem if a given miners/pools "chose" the same MNs over and over again, excluding other MNs. 1. However, it is better for them to be paying MNs than not at all.

Personally I've always thought the "election" process was convoluted and prone to error (given that not all MNs can necessarily always be seen by all nodes on the network) and that the coinbase transaction should simply pay the MNs who provably performed the mixing during that particular block.  Split it up among them proportionately.  The clients will choose which MNs to send to at random; or if they mess with the code to always favor certain MNs, that's fine too (although they will probably be losing some privacy if they choose to always use their own MN = shooting themselves in the foot = hopefully nobody is so stupid as to do this).  The MNs are paid for providing a service, and if they provide that service in a given block, then they should be paid in that block.  JM2C

1. I believe this should have been a fairly easy "enforcement" switch to code, but in reality wouldn't have done too much. I believe the cause of the forking to have been nodes thinking different MNs should be paid, and rejecting the blocks that paid, but didn't pay the "right" node. However, just making so 20% had to be split off or the block rejected would allow the miner to just pay themselves in a separate transaction.

I think you have an interesting idea in doing that PoSvc thing (which I believe "flare" has talked about at dct): you should be able to determine which masternode signed each denomination transaction included in the block.

It sounds very cool and elegant at first, but it too has vectors that must be considered. Nothing stops you from choosing a masternode; they just sit around waiting for inputs. So you could constantly denominate the smallest # of inputs (to minimize fees) using your own node, which would nearly guarantee its inclusion in every block for payment. This only wouldn't make sense if fees were higher than the payout.

Additionally, what happens if no denominate transaction occurs in a particular block? Is the mining node then able to keep the entire reward for himself? What then happens if he simply refused to include those transactions in his block (I'm not sure how you can force them to include transactions?).

Several other ideas are rolling around in my head, mostly in relation to masternodes somehow/sometimes having block minting authority. I need to think about it some more though.

Ok, good points.... keeping up a synchronized, agreed-upon list of MNs throughout the network is the real crux here.  Especially since it definitely needs to account for MNs dropping out of the network from time to time.  Which shouldn't really happen, but it will happen for various reasons.  So yeah, that idea definitely has some flaws that would be hard to work through.

How about this.  Each block, a group of MNs is "nominated" by the block hash.  The hash simply matches a few bits of the MN's public address... target this so that each block hash should "nominate" 5-10 MNs on average.  Then all of the nominated MNs will be required to create "ping" transactions and push them to the network within 2 blocks.  These transactions will be included in these next 2 blocks.  Take the hash of the 2nd block after the original "nomination" block, and use it to determine the winner (among the nominees who have correctly "pinged" back) of the MN prize that will be generated by the coinbase transaction in the next, 3rd block.  If for some reason a block hash doesn't match any MNs (or no MNs happen to "ping" in time -- which is equivalent in result), then there would be a fallback option such as awarding the prize to a different MN that wasn't chosen in the previous block, but was nominated and "pinged" back correctly.

This gets rid of the problem of having to keep a current, up-to-date list of all MNs throughout the network.  The MNs themselves are responsible for letting the network know that they are out there by the "ping" transactions, and they can be called upon at any time due to the random nature of the nomination process, so therefore they must be ready to quickly respond at any time.  If they miss a "ping" then they will be penalized by not being eligible for the reward the next time they are nominated.  All MN-payment-eligible addresses will have their public addresses in the blockchain immediately prior (1 or 2 blocks) to the block which pays them out, and the reward will be awarded to one of the nominees in a deterministic fashion, which eliminates confusion and rejection of blocks due to nodes not being aware of a particular MN on the network.

There might be some problems that crop up with this process due to orphan blocks.  Perhaps the ping-response-time should be set to 5 or even 10 blocks instead of 2.  But I have been chewing on this kind of idea for a while now, and I think it could work for the MNs.

Well as fate would have it, I didn't dream about this at all...

It seems to me that the distribution of masternode public keys is probably not very uniform, and therefore a (pseudo) random matching based on block hashes could result in rather uneven payments? It may be possible to mitigate this, though not 100% sure. Perhaps some additional variables in the matching algorithm could help. If it can be structured in a way to get a reasonably normal distribution, then it's actually rather elegant.
One other consideration is that it'd still be highly probable that producing an output not matching any MNs is possible. Do we just say "too bad" for those ineligible blocks?

Match on several bits along the length of the entire public address.  The address is a hash function.  Its output should be sufficiently random.

I addressed the "no match" problem above.  If there isn't a match, choose a winner among the non-winning addresses from the previous block.  If there was only one address in that block, then go back to the previous block, recursively until a block is found with multiple addresses, and choose one of the non-winning addresses from that block, using the same choosing algorithm.

I am thinking that this choosing algorithm might simply be an ordering.  Like say the block hash used to choose the winning address among the nominee addresses is A7Bg34xyz.  Take the first digit in this hash, the 7.  This means choose the 7th character in the nominee addresses.  Sort the nominee addresses by this 7th character (and carry over to the 8th character to settle ties).  Now that they are ordered, take the second digit in the hash, the 3.  This means choose the 3rd nominee address as the winner.  If there aren't 3 qualified nominees, choose the 2nd, or the 1st, etc.

The algorithm for nominating MNs could be similar, to provide for added randomness.  Take the same block hash, A7Bg34xyz.  Take the first digit in the hash, 7, and the next character after it, B.  This tells us that the 7th character in the address needs to be a 'B'.  Now go to the next digit in the hash, 3, and take the next character after it, 4.  This tells us that the 3rd character in the address needs to be a '4'.  So all MNs whose public addresses match the pattern xx4xxxBxxxxxxxx would be nominated by that block.  This algorithm could obviously be tweaked in many ways in order to generate the right number of MN addresses with each block.  Maybe the pattern match would need to be broadened to be any pattern of 4xxxB anywhere in the address.  Or only in the first 15 characters of the address.  Or the last 15 characters of the address.  Etc.  

There are a lot of variations to play with.  But it is hard for me to see a way for anybody to game this somehow by generating their address in order to be paid more or less often.  I guess if they had multiple MNs then they could generate the address of each so that there is no overlap with their other addresses, so they would never be nominated at the same time as the others.  Which would be ok.  If there was a lot of overlap then they could have multiple MNs nominated at once, which would increase their chances of winning the payment for a block in which they have multiple nominated MNs.  So it's hard for me to see a real winner there.... it seems to be equal.  Better chances of winning when nominated, versus being nominated more often.  Given that the process for both nomination and choosing the winner are essentially random as long as no single entity is controlling the mining, I don't see how you could argue that one of these options is definitely better than the other.

[coins101]

Saw this yesterday in a local newspaper  

https://docs.google.com/document/d/143Uwls4ZZrN7pS7bWfjk03i90TWskjy8scNB2U0HOoo/edit

Initial Board of directors membership:

1. Evan Duffield
2. Edward Moncada
3. Fernando Gutierrez Mosquera
4. Christopher Carlo Rimoldi
5. Harold Boo

I believe #3 is btc user fernando and #4 is eltito. What do we know about #2 and #5?

Also: is there a public charter, vision, mission statement?

Correct about Fernado and Eltito. Edward represents some of the largest Darkcoin investors and Harold is a long term Darkcoin supporter and attorney who helped setup the foundation. We've setup the foundation to equally represent all aspects of the coin (Development, Legal, Investment and Community). We'll be releasing much more detailed information with RC5

Its that time again, when we have a little giggle and pat our backs for hodling.

[coins101]

Does anyone know any examples of any Bitcoin accounts, exchanges or otherwise, being closed (other than Coinbase) because users have been using gaming sites?

Any banks been using block chain analysis?

Looking for some case studies for my summary:

https://bitcointalk.org/index.php?topic=761561.msg8585129#msg8585129

[drawingthesun]

Why you guy are so scared ? Little price drop huh ? Lets talk price right now.
What are your predictions ?
Le me tellyou mine :
Two weeks after RC5 one DRK is going to cost 0.045 BTCand rising !

I don't see how RC5 is going to drive the price up. Unless some big holders stop dumping their coins the bearish trend will continue.

RC5 will mean DarkSend+ is open source and then the marketing will commence... Or soon after that anyway...

Nobody trust close source . RC5 and the open source is going to be the start of the race !

I'm thinking about opening the source at release of RC5. I've actually been having various close friends of mine look at the source and no one sees anything seriously wrong with it besides some organizational issues (which I'm working on now). I believe we're ready to go.

I'm looking forward to reading the code, it has been a long wait.

[Jestah]

Saw this yesterday in a local newspaper  

https://docs.google.com/document/d/143Uwls4ZZrN7pS7bWfjk03i90TWskjy8scNB2U0HOoo/edit

Initial Board of directors membership:

1. Evan Duffield
2. Edward Moncada
3. Fernando Gutierrez Mosquera
4. Christopher Carlo Rimoldi
5. Harold Boo

I believe #3 is btc user fernando and #4 is eltito. What do we know about #2 and #5?

Also: is there a public charter, vision, mission statement?

Correct about Fernado and Eltito. Edward represents some of the largest Darkcoin investors and Harold is a long term Darkcoin supporter and attorney who helped setup the foundation. We've setup the foundation to equally represent all aspects of the coin (Development, Legal, Investment and Community). We'll be releasing much more detailed information with RC5

Its that time again, when we have a little giggle and pat our backs for hodling.

Someone please enlighten my noob brain......

Please can someone explain to me why this and open source is good news?   Isn't the purpose of the BTC foundation to enrich a select few?  Also, I expect a ton of copy/paste coins based on DRK to further dilute and confuse the masses.

[BrainShutdown]

Someone please enlighten my noob brain......

Please can someone explain to me why this and open source is good news?   Isn't the purpose of the BTC foundation to enrich a select few?  Also, I expect a ton of copy/paste coins based on DRK to further dilute and confuse the masses.

Open source is about tranparency and confidence.

BTC foundation I don't really know.

Confused masses need to learn how to take care of themselves