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

[Ignition75]

We need a PR person as well as a Kristov Atlas available to hire.

Earlier this week I was conducting a bit of a mining experiment with flare.  At one point we controlled nearly 5% of the network hashrate.

Anyway, I digress.  I think there needs to be a fund where people can donate a few duff to ultimately buy in the expertise that we might be missing as a community.  One idea I had was a CPU miner that only mines when your computer is idle but x% of mined blocks goes to the skill recruitment fund.  

People could either donate DRK if they have some to spare or just run an executable on their computer.

What do people think about this?  I reckon if enough of the community used their idle CPU cycles to mine from a dedicated NOMP instance then quite a hashrate could build up.  Obviously there is nothing stopping people from pointing their GPUs at it now and again.

Not only would it be good for the PR and Comms of Darkcoin, it'd be healthy for the network too!

Yes I saw you connecting and disconnecting from DarkcoinTalkPool, watching your hash rate with great envy.  I'm downsizing my humble 500 Mh/s and selling most of the hardware off for masternodes, how do you keep a farm that size running without haemorrhaging money?

Purely from an interested bystander point of view can I have some farm details, size, photo's would be awesome.  I'll show you mine if you show me yours 

[1715411121]

1715411121

[1715411121]

1715411121

[1715411121]

1715411121

[1715411121]

1715411121

[1715411121]

1715411121

[Ignition75]

crazy day in crypto, litecoin just lost 2nd place!

You mean regarding price of 1 unit?

There are coins like 42Coin who have even higher prices per unit than btc, so price per unit is not really relevant.

i was refering to the marketcap but for some reason Ripple doesent count.
I dont know anything about ripple so i cannot really comment.

I stand corrected, i apologise

Go kneel in the corner and say 10 Hail Mary's and 10 Our Father's 

[TsuyokuNaritai]

 

****** PLEASE UPDATE TO v9.13.13 (Stable) OR 10.13.13 (RC) *******

This should fix everything Kristov found except for a possible DOS issue that will have to be fixed later, including the privacy issue. So we should be solid for Monday now.

- Bounds checking in a few places where it was lacking
- Output list in transactions lacked random seeding
- masternode constants for communication are much easier to read now

Everything should still work (Nothing structural was changed), but it would be great it we could anonymize some funds to double check before going live on Monday

Stable Binaries
http://www.darkcoin.io/downloads/master-rc5/darkcoin-qt
http://www.darkcoin.io/downloads/master-rc5/darkcoind

RC5 Binaries
http://www.darkcoin.io/downloads/rc5/darkcoin-qt
http://www.darkcoin.io/downloads/rc5/darkcoind

https://darkcointalk.org/threads/rc5-testing.2245/page-46#post-21395

(Testnet only!)

[defunctec]

****** PLEASE UPDATE TO v9.13.13 (Stable) OR 10.13.13 (RC) *******

This should fix everything Kristov found except for a possible DOS issue that will have to be fixed later, including the privacy issue. So we should be solid for Monday now.

- Bounds checking in a few places where it was lacking
- Output list in transactions lacked random seeding
- masternode constants for communication are much easier to read now

Everything should still work (Nothing structural was changed), but it would be great it we could anonymize some funds to double check before going live on Monday

Stable Binaries
http://www.darkcoin.io/downloads/master-rc5/darkcoin-qt
http://www.darkcoin.io/downloads/master-rc5/darkcoind

RC5 Binaries
http://www.darkcoin.io/downloads/rc5/darkcoin-qt
http://www.darkcoin.io/downloads/rc5/darkcoind

https://darkcointalk.org/threads/rc5-testing.2245/page-46#post-21395

(Testnet only!)

wow, so quick!

[Ignition75]

Well that sucks..

"I have identified a few privacy-related issues in the code. For the time being, I recommend that users pause use of Darksend+ for privacy purposes, or bolster them with other blockchain privacy tactics as part of a privacy-in-depth strategy, until the issues can be fixed; these issues were reported to the Darkcoin dev team on 2014/09/18, and acknowledged by email by the dev team on the same day. All will be fully disclosed by 2014/10/18 as part of “responsible disclosure” practices. I expect that they will be addressed sooner than 2014/10/18; if corrected Release Candidate binaries are made available before then, I will disclose the issues at that point. For the time being, I’m reserving the following IDs for the issues so that their status can be tracked:"

http://blog.anonymousbitcoinbook.com/2014/09/darkcoin-code-review-results/

I'll have everything he found fixed by Monday.

Outstanding Evan!

[eduffield]

I thought it might be useful reading:

r/Bitcoin comment:

So if 10 malicious master nodes became chosen one round, they can suddenly allow double spending for their agents around the network? It seems like this isn't avoiding a sybil, it is implementing one.

eduffield:

Maybe the paper needs to be reworded on this point because you're missing the general idea. Masternode consensus is a event, like a block event that will reverse conflicting transactions with the same inputs on the network. It will modify the memory pool. The Bitcoin network waits for a block, Darkcoin will be able to do it TX by TX. So double spends become impossible.

[Propulsion]

Can anyone put some criticism to this?

https://www.reddit.com/r/CryptoCurrency/comments/2gvl87/darkcoin_eureka_moment_instant_confirmed/

[Propulsion]

I thought it might be useful reading:

r/Bitcoin comment:

So if 10 malicious master nodes became chosen one round, they can suddenly allow double spending for their agents around the network? It seems like this isn't avoiding a sybil, it is implementing one.

eduffield:

Maybe the paper needs to be reworded on this point because you're missing the general idea. Masternode consensus is a event, like a block event that will reverse conflicting transactions with the same inputs on the network. It will modify the memory pool. The Bitcoin waits for a block, Darkcoin will be able to do it TX by TX. So double spends become impossible.

It's just astonishing it wasn't downvoted to oblivion on the Bitcoin subreddit. Just to have a somewhat civil discussion about the technology is a huge win.

[Ignition75]

From the Instant(Tx) Whitepaper:

5.2 Transaction Lock Compatibility Mode

To enable backwards compatibility with all existing software (exchanges, pools, etc), clients will
default to showing 24 hours of confirmations of transactions that have been successfully locked.
This will provide all services using Darkcoin to benefit from instant transactions without having to
implement anything specific.

If a client needs the daemon to function in the old way, there will be a flag to disable this mode.

Good thinking 

[coins101]

Can anyone put some criticism to this?

https://www.reddit.com/r/CryptoCurrency/comments/2gvl87/darkcoin_eureka_moment_instant_confirmed/

At some point, you have to admit that that which must not be spoken, it being spoken about by others.



edit

MasterJoin

 

[eduffield]

From the Instant(Tx) Whitepaper:

5.2 Transaction Lock Compatibility Mode

To enable backwards compatibility with all existing software (exchanges, pools, etc), clients will
default to showing 24 hours of confirmations of transactions that have been successfully locked.
This will provide all services using Darkcoin to benefit from instant transactions without having to
implement anything specific.

If a client needs the daemon to function in the old way, there will be a flag to disable this mode.

Good thinking  

This section might need some work too.

Current raw blockchain (no other transactions)
(60m / 2.5m confirmation time) * 156KB per block * days in a year) / mb /gb
((60/2.5)*158*365)/1024/1024

1.31GB per year

Even without anything... the blockchain grows pretty fast. In 5 years we're looking at 5-15GB depending on the transaction volume.

((60/20)*158*365)/1024/1024

0.16GB per year

That means that we can save over a gig a year by increasing the confirmation time. The idea is we want less bloat and faster transactions, so we should be able to get both without sacrificing anything.

[Propulsion]

Can anyone put some criticism to this?

https://www.reddit.com/r/CryptoCurrency/comments/2gvl87/darkcoin_eureka_moment_instant_confirmed/

At some point, you have to admit that that which must not be spoken, it being spoken about by others.

That's when I stopped replying.

[drkwarrior]

there is no point in going to btc reddit etc. you will get shot down no matter what, its kinda like when a troll of any coin comes here to tell us about their new coins new features. what do we do to them..do we listen, do we debate, do we give a f***,lol no.  
i say its best we just concentrate on what drk is good at ...bein annon and getting adoption on places like open baazar and any other digital industry that requires privacy but doesnt have it (online casinos,porn,sr2 etc ) once we have a entry into these markets ( jus like btc did )we must prove it works there first. then we can then focus on the big guns..paypal,overtstock,dell,expedia, they will probly come themselfs by this point.

[_evolution_]

Darkcoin will gradually begin to sober down all BTC holders and eventually will replace it. The real question is not if but when. However these BTC holders are still in their usual hypnotic state (depicted for clarity):



 

[drkwarrior]

as for instant transactions the two parties that will appreciate most them is..day traders who need to move coins quickly and exchanges will prob add  drk/alt pairing just like bittex and polo did for bc.

[salmion]

as for instant transactions the two parties that will appreciate most them is..day traders who need to move coins quickly and exchanges will prob add  drk/alt pairing just like bittex and polo did for bc.

Um the denominations would go faster too no?

Adoptionadoptionadoption.

Yeah traders will love it. But it'll also be super cool buying something. Both for buyer and seller.

Send. Done.

[luigi1111]

From the Instant(Tx) Whitepaper:

5.2 Transaction Lock Compatibility Mode

To enable backwards compatibility with all existing software (exchanges, pools, etc), clients will
default to showing 24 hours of confirmations of transactions that have been successfully locked.
This will provide all services using Darkcoin to benefit from instant transactions without having to
implement anything specific.

If a client needs the daemon to function in the old way, there will be a flag to disable this mode.

Good thinking  

This section might need some work too.

Current raw blockchain (no other transactions)
(60m / 2.5m confirmation time) * 156KB per block * days in a year) / mb /gb
((60/2.5)*158*365)/1024/1024

1.31GB per year

Even without anything... the blockchain grows pretty fast. In 5 years we're looking at 5-15GB depending on the transaction volume.

((60/20)*158*365)/1024/1024

0.16GB per year

That means that we can save over a gig a year by increasing the confirmation time. The idea is we want less bloat and faster transactions, so we should be able to get both without sacrificing anything.

Am I missing something? Why aren't hours/day included in the calculations? Shouldn't it be like:
(60m / 2.5m confirmation time) * 156(158?)KB per block * hours in a day * days in a year) / MB / GB
((60/2.5)*158*24*365)/1024/1024 = ~31.68 GB?

And second calculation:
((60/20)*158*24*365)/1024/1024 = ~3.96 GB?

Thus, the move would save 31.68 - 3.96 = 27.72 GB / year?

Edit: but that's not right, DRK's blockchain isn't nearly that big now...

Edit2: As pointed out below, each block uses space measured in mere bytes, not KB.

[naxin]

From the Instant(Tx) Whitepaper:

5.2 Transaction Lock Compatibility Mode

To enable backwards compatibility with all existing software (exchanges, pools, etc), clients will
default to showing 24 hours of confirmations of transactions that have been successfully locked.
This will provide all services using Darkcoin to benefit from instant transactions without having to
implement anything specific.

If a client needs the daemon to function in the old way, there will be a flag to disable this mode.

Good thinking  

This section might need some work too.

Current raw blockchain (no other transactions)
(60m / 2.5m confirmation time) * 156KB per block * days in a year) / mb /gb
((60/2.5)*158*365)/1024/1024

1.31GB per year

Even without anything... the blockchain grows pretty fast. In 5 years we're looking at 5-15GB depending on the transaction volume.

((60/20)*158*365)/1024/1024

0.16GB per year

That means that we can save over a gig a year by increasing the confirmation time. The idea is we want less bloat and faster transactions, so we should be able to get both without sacrificing anything.

Am I missing something? Why aren't hours/day included in the calculations? Shouldn't it be like:
(60m / 2.5m confirmation time) * 156(158?)KB per block * hours in a day * days in a year) / MB / GB
((60/2.5)*158*24*365)/1024/1024 = ~31.68 GB?

And second calculation:
((60/20)*158*24*365)/1024/1024 = ~3.96 GB?

Thus, the move would save 31.68 - 3.96 = 27.72 GB / year?

60 minutes / 2.5 minutes/block * 158 bytes per block (w/o txs) * 24 hours * 365 days / 1024 (bytes/kilobyte)/(1024 kb/megabytes) = 31 megabytes not 31 gigabytes!

[luigi1111]

From the Instant(Tx) Whitepaper:

5.2 Transaction Lock Compatibility Mode

To enable backwards compatibility with all existing software (exchanges, pools, etc), clients will
default to showing 24 hours of confirmations of transactions that have been successfully locked.
This will provide all services using Darkcoin to benefit from instant transactions without having to
implement anything specific.

If a client needs the daemon to function in the old way, there will be a flag to disable this mode.

Good thinking  

This section might need some work too.

Current raw blockchain (no other transactions)
(60m / 2.5m confirmation time) * 156KB per block * days in a year) / mb /gb
((60/2.5)*158*365)/1024/1024

1.31GB per year

Even without anything... the blockchain grows pretty fast. In 5 years we're looking at 5-15GB depending on the transaction volume.

((60/20)*158*365)/1024/1024

0.16GB per year

That means that we can save over a gig a year by increasing the confirmation time. The idea is we want less bloat and faster transactions, so we should be able to get both without sacrificing anything.

Am I missing something? Why aren't hours/day included in the calculations? Shouldn't it be like:
(60m / 2.5m confirmation time) * 156(158?)KB per block * hours in a day * days in a year) / MB / GB
((60/2.5)*158*24*365)/1024/1024 = ~31.68 GB?

And second calculation:
((60/20)*158*24*365)/1024/1024 = ~3.96 GB?

Thus, the move would save 31.68 - 3.96 = 27.72 GB / year?

60 minutes / 2.5 minutes/block * 158 bytes per block (w/o txs) * 24 hours * 365 days / 1024 (bytes/kilobyte)/(1024 kb/megabytes) = 31 megabytes not 31 gigabytes!

There we go, thanks. I knew something wasn't right with that math, as it wasn't matching up with reality in the slightest, haha.

My whole appdata folder at present is only around 400 MB, with almost 139,000 blocks under its belt (2/3rds of a year's worth).

Anyway, looks like the move would only save around ~28MB / year.

[eduffield]

From the Instant(Tx) Whitepaper:

5.2 Transaction Lock Compatibility Mode

To enable backwards compatibility with all existing software (exchanges, pools, etc), clients will
default to showing 24 hours of confirmations of transactions that have been successfully locked.
This will provide all services using Darkcoin to benefit from instant transactions without having to
implement anything specific.

If a client needs the daemon to function in the old way, there will be a flag to disable this mode.

Good thinking  

This section might need some work too.

Current raw blockchain (no other transactions)
(60m / 2.5m confirmation time) * 156KB per block * days in a year) / mb /gb
((60/2.5)*158*365)/1024/1024

1.31GB per year

Even without anything... the blockchain grows pretty fast. In 5 years we're looking at 5-15GB depending on the transaction volume.

((60/20)*158*365)/1024/1024

0.16GB per year

That means that we can save over a gig a year by increasing the confirmation time. The idea is we want less bloat and faster transactions, so we should be able to get both without sacrificing anything.

Am I missing something? Why aren't hours/day included in the calculations? Shouldn't it be like:
(60m / 2.5m confirmation time) * 156(158?)KB per block * hours in a day * days in a year) / MB / GB
((60/2.5)*158*24*365)/1024/1024 = ~31.68 GB?

And second calculation:
((60/20)*158*24*365)/1024/1024 = ~3.96 GB?

Thus, the move would save 31.68 - 3.96 = 27.72 GB / year?

60 minutes / 2.5 minutes/block * 158 bytes per block (w/o txs) * 24 hours * 365 days / 1024 (bytes/kilobyte)/(1024 kb/megabytes) = 31 megabytes not 31 gigabytes!

Ah, yeah. Long day! Thanks