That is interesting. No one that I know of has bothered to make a wallet for BSD let alone a gui wallet. Watching.

It's just nonsense: *BSD are variants of "Unix" as is linux, openstep (os X), etc.

At very least Decred will enter into a mutually beneficial symbiotic relationship with Bitcoin. That's the goal. Improvements in one will feed into the other (where possible). Development has a lot more freedom in Decred because it's new, so there's room for innovative ideas and experimentation. Hopefully a foundation can be built where it can be kept that way - that's the other goal.


There's already been some press coverage. There will be some more next week, but as you can imagine, it's an uphill battle. A lot of people in the Bitcoin camp see anything alternative as an attack or a threat. That's not what this is about at all - it's not about competing, but about growing in parallel. Maybe that's just spin on "competition", but you get what's meant by the ideal.

Make sure you guys are signed up for airdrop on the site. Going to sound like a broken record, but the project will benefit from as diverse a group of people as possible.

^^^ Looking forward to reading the answer (not the made up word part, but other).

Also, since it looks like more than one person is using the Decred user account, could post authors sign their name at the end even if it's just their first name?

Funding:
There are basically three models we've seen in most free and open-source projects that want to remain sustainable (continue development over time). In these, funding comes from:

• Donation-type efforts, or hoping for goodwill
• Some type of initial offering, or selling influence to insiders
• Some external party, or selling influence to outsiders

Nobody here will tell you Decred is going to fix your world. Anyone who tells you that is a false prophet. What we can tell you, unequivocally, is that Decred is a project that will attempt to introduce a fourth option to counter the corruptive influence of funding we've seen destroy a lot of good ideas that started in an earnest way. By writing funding into a consensus rule, Decred attempts to put power back in the hands of its users. Some people will stop reading here and say it's a terrible idea. Others will come along on the journey and see where it goes. The fact remains, if the network dislikes the direction development takes, they now have a direct voice to communicate that - stop mining and staking and the funding stops. That's the fourth option.

All the other options we've seen are suboptimal. Donation-type efforts are limited in scale. Selling air to you saying it'll be worth something "if you just trust us" is sick. And finally, Decred won't accept a situation where it's owned by a handful of corporations astroturfing the community and manufacturing consent in its name. By putting funding into the hands of users, Decred attempts a representative democratic model where nobody owns it. Decred isn't for sale - and you can't inquire within about sale. And if anyone messes with that in the future, scream from the hilltops and burn the whole damn thing to the ground - it's our duty as a community.

btcsuite:
btcsuite has been funded by a single guy, relatively unknown, who is crazy about freedom. There's no selling and no venture capital. There have been attempts to buy influence, and they have been chased away. Bear in mind btcsuite is the backbone of a great number of Bitcoin businesses and organisations now. There isn't a number because many close off their code - so we don't know. You may be interested to know that Ethereum's most popular client (geth) is based on btcd, for example. The point is btcsuite is high quality software written in public view over years. That is what you will see from Decred from a development perspective - you need not look further than btcsuite's history.

That type of situation is obviously quite unique. A single source of philanthropic funding is both rare and a problem for a project like Decred. It's been sustained fine for a project like btcsuite, but Decred intends to build a multi-stakeholder development environment where anyone can come contribute and be rewarded for their work fairly when it becomes part of the codebase. 100% of funding goes to the benefit of Decred's development - in full view of the public. So funding isn't going to go to btcsuite as a separate project unless that code clearly and directly benefits Decred, goes into its codebase, and is part of a Decred feature. It's clear now how that can be confusing - what we mean is actual code contributions accepted into Decred's codebase will go to btcsuite too if it's applicable. Similarly, Decred gets free contribution from btcsuite where applicable. So the symbiotic relationship between the two is based on code, not funding, aside from the fact Decred gets free code from btcsuite's ongoing work. The word applicable is used because they're different systems and Bitcoin is more constrictive on what it can accept - chances of a hybrid PoW/PoS change are 0.

As for Decred, the community is beholden only to itself. If someone (person or organisation) wants to build a feature put up as a development proposal, and there's sufficient support from the community, it can built by that party, reviewed, merged, and becomes part of Decred's codebase. c0, for example, is a competent development stakeholder interested in continuing work on Decred, so it'll be doing work for Decred as a team. They don't own it, and anyone can be a development stakeholder if they are good - that's the meritocratic element of the system.

I'm posting most of the responses at the moment. The current process is to consult with all the devs and non-devs working on the project and construct responses together for the "decred" account. However, it isn't always possible to construct individual responses since the devs are focusing on developing and testing (understandable at this point in time). I distil what's being said and run back and forth. Once it's mainnet time people will have more time to engage publicly and directly - I suspect most devs prefer technical talk around their work. I don't mind, since we'd all rather have what we're talking about than just talk about it.

The other reason for using the "decred" account is nobody wants a cult of personality, so we'd rather construct responses together. Also remember we're custodians to get it live, it's not ours. So "we" can't speak for Decred, we can only put forward information and see if there are objections or support. Anyone here has as valid an opinion as anyone else. Maybe that's not always practical, but it's worth keeping in mind when interacting from any position. A key thing to get up is a platform where we can have discourse and vote on a range of matters and then perhaps move it to another formal layer for voting (blockchain) and integration into Decred, that would be worthwhile. Experimenting with the platform for discourse/informal voting next week too.

Hi I found out today about how CLAM devs are doing their voting. Is this similar to or exactly your process/code?

https://bt.irlbtc.com/view/623147.msg13098673#msg13098673

Will we be doing it in similar way?

Also, We are using 5 min block time, how did you reach that number? Here is a talk by Dave Hudson, where he explains his research. Please do watch it. The slides are not visible in the video but there is link to all slides in description.

https://www.youtube.com/watch?v=9aBKLmJ2ebM

He talks particularly about block times starting at 50:55 (https://youtu.be/9aBKLmJ2ebM?t=50m55s). He says that blocktimes can be reduced as network speeds improve. Is it possible that like block subsidy we can also program either blocksize or blocktime to change so that scalability/tx per second is built in to the code rather than left to be solved later. Obviously we would need some kind of data or extrapolation about adoption rate, n/w speed increases etc to do that. I think if this can be done, it will make scalability not an issue left to consensus but based on how n/w evolves & hard forks will be required only to adjust the graphs based on new data. This is also an area where we can involve Dave Hudson to run some statistical models or do it ourselves if someone can do it.

Interesting - how did you come to this conclusion? Decred doesn't have any connection to Dash. Dash is based on C/C++ codebase, whereas Decred is based on a Go (golang) codebase. One thing Decred would like to avoid is what happened during Dash's launch. It needs to be taken as a lesson to try and learn from. Another good reason to get many people involved in airdrop.

it's premined. guess they mine for themselve since some months.