Topic: [ANN][DCR] Decred - Community Governance | Bitcoin Devs | Lightning Network - page 546. (Read 1201332 times)

Thank you for the good wishes. The project has certainly tried to explain the logic transparently and in detail - hence the long ANN OP post. If anything is unclear, people should ask so explanatory improvements can be made for new visitors and future community members.

Thanks to decreed January is going to be a highly interesting month, I simply would recomend to devs to try to make a clean and  absolutelly transparent explanation of the use of the premine, all we know this can  damage the coin if is not well done, i wish you good luck with this nice project

Hi Gladimor, thanks for letting people know about the ticker. It's duly noted. Obviously no one had an idea DeltaCredits operated under DCR when that ticker was decided on. Contentious issues are dealt with as a community, which in Decred's case is discourse and voting on a separate platform. This will be addressed in that way.

You need to remember that a ticker isn't the biggest concern right now as development continues and time is being spent on helping people who are trying to learn about the project. So it's being said with respect that everyone is aware of the matter and it will be addressed. Doesn't mean the outcome is necessarily a change, however, but there is due process to follow. You can also see the difficulty in tickers crossing over each other when most tickers are three letters. It's really important that the thread sticks on topic and not derail because of an issue like that when it's being taken into consideration.

A ticker is a manner of distinguishing various assets from one another in a unique manner. On the stock exchange, do you see two equities with the same ticker symbol? No.

No, it isn't unjust. I'm one of the greatest Deltacredits investors and I tell you that it isn't unethical. Your name is Adam, and many people have the same name ; is it also unjust?

I wish the Decred team the best of luck with the experiment but I do think it was a mistake  to take the three letter code being used by another group of people in the crypto community (assuming what's here is accurate). It can't be that hard to come up with an original three letter code.


It's not too late to change it

I saw this thread some time ago but wasn't sure if i would qualify for the airdrop as i'm just learning about the coding and development part.
I do however have some skills in marketing and security testing of websites. I signed up and used my "forum profile" as the URL as this is where i handle most stuff i do.

DeltaCredits is far from dead. We have major things coming in the near future, and as the lead developer, I can personally state that DeltaCredits is quite active. Don't let the activity of the ANN thread fool you.

Stealing a ticker from a currency that was launched earlier is not only unethical, but is unjust.

As far as I know, none of us were familiar with delta credit prior to it being mentioned in this thread.  Other people in the thread (not decred devs) told us that it was a dead coin and that we did not need to change the ticker.

So we haven't really made any statement about delta credit since we have no particular info there.  Obviously we don't want to change if we don't have to, but also don't want to step on another project for no reason.  So I don't think the ticker issue is settled at the moment (we need to look into the status of delta credit a bit more and want to know what the community thinks (since this is not meant to be a dictatorship or oligarchy)).

No pool at beginning but only solo mining,since they will not release getblocktemplate.
It's correct?

I really hope this coin doesn't attempt merge mining.
I'd prefer if the miners for this coin actually cared about the coin and weren't just receiving dumpcoins while they mine on a chain that they like.

Following up this thread to see any update on Decred

Please show the exact post where someone belonging to Decred project told they consider Delta Credit to be 'dead' coin and refused to change the ticker. I read this thread and did not notice such statement from the Decred officials. Decred developers seem to be smart guys with legit project and I would not expect them to make such aggressive moves and unnecessarily create enemies for their young project.

Would appreciate a clear statement on this topic from the Decred developers.

also if im not mistaken, the speed of 8-round blake256 contributes to faster wallet, when verifying transactions and loading blocks. for example on first install of wallet, bootstrapping/downloading the blockchain loads much faster. especially important for cellphone wallets and raspi nodes. I really wish it could have been (maybe still could be?) geared for merged mined, it increases network security for all the coins, while also mitigating risk for miners since you are mining multiple coins at once, so if one fails, atleast you still got the others.

History about SHA3 and Blake-256:
14 rounds was only pushed in final stage sha3 comp as the fear was it was too fast and wanted to win votes from judges to become sha3 but as we know they ended up choosing the next secure hash based on sponge function so others basically got ignored!

Original Blake-256/Blake-32 was 10 rounds and was tested as such so should have 2²⁵⁶ security

you will see with the successor of Blake-256 > Blake2s they reduce the rounds back to 10 anything more is overkill and the whole blake hash design is slightly overkill to start with anyways!  

no need to waste compute as it is always going to be there on every platform and may force in some places to spend time/effort doing optimizations when you could start more optimized by factoring the reasons why your hash algo is what it is, tune-able number of rounds is very powerful feature not to be ignored before you start things like root hashes/checksum

so you can look at it like this:

1. ignore and carry on not looking into why you can have 10/8 rounds (huge headache when you find you cant change after)
2. use the 10 round spec and have minimum 2²⁵⁶ security and hash is in big endian so will fit with BTC code
3. use the 8 rounds and have minimum 2²⁰⁰ security (tested so known minimum security with best attack no guess work!)
4. use blake2s or blake2sp and have minimum 2²⁵⁶ security, performance is slightly worse for blake2s vs 8rnd blake-256, blake2 is also little endian so if you wanted to go full on you could remove the big endian conversion and just do everything in little endian as most software does

why did I tweak blake-256 to 8 rounds simple for the wallet you would want a design goal of at least 2¹²⁸ you could do with 2¹⁶⁰ and I thought 2¹⁹² would give enough margin that other flaws in wallet would be of more worry! this seems to have been proven correct so far and the margin on 8 rounds was better than my original estimation @2²⁰⁰  

before anyone starts saying oh but 8 round is only available in c/c++ this is just not true if you care to see my github you will find versions for php/python/java/c/c#/go/opencl

and specifically these may be of interest to the Decred dev/devs

8 round blake-256 in golang
https://github.com/BlueDragon747/blake256
 
8 round blake-256 checksum tool in golang
https://github.com/BlueDragon747/blakesum

shame about auxpow and merge mining but might be ott in go at this time so much needs to match for it to be valid and with your described pos/pow hybrid it would make far more work for dev/devs, hope that everyone can take some notes about blake-256 it is a good algo but the 14 version is fubar was made only to please judges during final of sha3 which it did not win nor was most of the testing done on 14 rounds!

efficiency is important it helps all nodes even if not mining for as long as you use the algorithm, quicker and higher throughput will lead to quicker propagation time though the nodes on the network if you can save 20-40% off the bat from just understanding the why is blake-256 x rounds and do we really need more security margin than we can use at cost of wasting compute and taking more time?  

As we've stated elsewhere the current developers are mostly drawn from the btcsuite devs so there is a lot of back and forth which should be good for that project as well.

I'm one of the devs and it is possible some of the others have introduced themselves here (but it is a long thread so I can't be sure).  If not, I know we've all chimed in on the irc channel.

https://twitter.com/traderminer/status/681492873737547781

The dev subsidy travels through the blockchain to DHG and from DHG back through the blockchain to development parties. It's transparent. This is also summarized and accounted for in a traditional way by public financial statements. If it changes and becomes less transparent, people need to rise up and turn against Decred.

10% means that we are going to have a forever sell pressure of 10%?

I mean: You will receive 10% of each block payed in decreed. You need fund,so what you do? Sell your 10% over buywall and create sell pressure, or hold decreed for years assuming you know that price will rise year after year?

Most of all, who will held those 10%?
We need a physical person or a trusted escrow, NOT something like decreed society or somoene's anonymous.

We need to know who held those 10%. How? To be trasparent,use a trusted escrow on forum and NOT someone's inside your organization.