Topic: [ANN][CRW] CROWN (SHA256) | Platform | Governance | Systemnodes | Masternodes | - page 14. (Read 316951 times)

https://medium.com/crownplatform/crown-platform-nft-framework-18d88f9db76



Crown Platform NFT Framework

Non-fungible Tokens on the Crown Core

Since the beginning of the Crown Platform evolution, we wanted to build a public blockchain solution that will enable simple and fast integration with a modern distributed ledger technology. Back in August 2017, the foundational ideas of how the platform should look like were laid down. Since then, we’ve been working hard to realize these ideas and transform them into a tangible form. The general platform overview that is available here explains the main concepts of the Crown Platform. Today we are going to concentrate on the part that evolved to become the Non-Fungible Token Framework or NFT Framework. In the platform overview that part has a name — Registry Subsystem. If you’re not familiar with the term NFT, feel free to read a quick overview here. In simple words, when a token is non-fungible it means it’s not interchangeable, it has unique properties and one asset is not equal to another asset in the same set, as it is with the fungible tokens. They are mostly monetary and interchangeable.
After some experiments with development, we changed terminology and the API interface a bit. So it now aligns with the notion of NFTs that became popular with the rise of Ethereum, ERC-721 smart contract standard and success of the Cryptokitties game. We believe it will be easier for developers to understand the workflow and start using Crown Platform in their applications if we adopt the same abstract concepts that exist on the market. In general, we all need the same technical language which is platform-agnostic to effectively communicate about blockchain software development.

Crown NFT vs Ethereum ERC-721 NFT

The conceptual difference between Ethereum NFTs and Crown NFTs is that in the first case the development process is more code-oriented or smart contracts based. It means that the most part of the business logic is deployed and executed on the EVM. However, in Crown we use the data-oriented approach and the Crown Platform API as a gateway for the integration of your web or any other application with a blockchain solution. There are pros and cons to both approaches. The smart contract approach gives you the flexibility to run arbitrary code on-chain and customize your business-logic in a smart contract, and in many cases, it’s exactly what you need. But sometimes you need a blockchain solution that you can quickly integrate with your existing or developing application using the API. You don’t need to deal with the smart contracts languages and time-consuming development. You need to get clear on the data model for your non-fungible tokens set and how it fits into your architecture. So eventually, you have business-logic running off-chain on your back-end which interacts with the on-chain solution that you integrate using the Crown Platform API. Plus, you don’t have to deal with potential bugs that might be introduced with a smart contract code and are irreversible.

Design Your Blockchain Solution

When you work on an NFT solution based on Ethereum, you need to write Solidity code that implements standard smart contract interface:

/// @title ERC-721 Non-Fungible Token Standard
interface ERC721 /* is ERC165 */
{
Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);
event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);
function balanceOf(address _owner) external view returns (uint256); function ownerOf(uint256 _tokenId) external view returns (address); function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
function approve(address _approved, uint256 _tokenId) external payable;
function setApprovalForAll(address _operator, bool _approved) external;
function getApproved(uint256 _tokenId) external view returns (address);
function isApprovedForAll(address _owner, address _operator) external view returns (bool);
}


The implementation will encapsulate the logic of your NFT blockchain solution. The analog of the smart contract implementation on Crown is an NFT protocol registration. You need to define the set of rules for your non-fungible token solution. First, you need to set a protocol symbol or protocol ID, it should be a string that contains only symbols from the set: .abcdefghijklmnopqrstuvwxyz12345 with the length between 3 and 12 characters. It might be something like: “doc”, “docproof”, “prf”, “ckt” or “cryptoknight”, “lux” etc. This string is used as a unique identifier of the protocol in the system. Also, you can set up a long protocol name that will be more meaningful and can contain up to 24 arbitrary symbols, for example: “Documents”, “Documents Proof”, “Proofs”, “Cryptoknights Game”, “Luxury Goods” etc. As an engineer, you also need to define the metadata mimetype, its schema and whether it will be embedded in the NFT or just contain a link to an IPFS or another resource with the metadata. Usually, it should be an “application/json” format, and the metadata field should contain a link to the JSON file. Embedding metadata directly into the blockchain record only makes sense if it’s shorter than a URL. If the metadata field contains many symbols, the NFT transaction fee will grow exponentially (not implemented yet). You will also need to define some other rules for your protocol that will customize the behavior of your application. Some of the fields of the protocol are:

/// NF token protocol unique symbol/identifier, can be an a    abbreviated name describing this NF token type
    /// Represented as a base32 string, can only contain characters: .abcdefghijklmnopqrstuvwxyz12345
    /// Minimum length 3 symbols, maximum length 12 symbols
    uint64_t tokenProtocolId;
    /// Full name for this NF token type/protocol
    /// Minimum length 3 symbols, maximum length 24
    std::string tokenProtocolName;
    /// URI to schema (json/xml/binary) describing metadata format
    std::string tokenMetadataSchemaUri;
    /// MIME type describing metadata content type
    std::string tokenMetadataMimeType;
    /// Defines if metadata is embedded or contains a URI
    /// It's recommended to use embedded metadata only if it's shorter than URI
    bool isMetadataEmbedded;
    /// Owner of the NF token protocol
    CKeyID tokenProtocolOwnerId;

Note: the protocol registration is not necessary for the upcoming testnet release 0.13.9 (pre-release before 0.14.0), you can start NFTs registration with arbitrary protocol symbol to test your solution.

NF Token Registration and API interface

So now comes the fun part. As an engineer, you will be interacting with the Crown Platform API interface to issue new NFTs, query different information about them for your users, etc. I am going to provide you a couple of examples of how you can use the API through the wallet command line interface and a small code example.

All the NFT framework APIs start with the nftoken command. The subcommands list is: register(issue)|list|get|getbytxid|totalsupply|balanceof|ownerof.
In order to register/issue a new NFT instance you need to call the corresponding remote procedure:

nftoken register/issue "nfTokenProtocol" "tokenId" "tokenOwnerAddr" "tokenMetadataAdminAddr" "metadata"

Creates and sends a new non-fungible token transaction.

Arguments:

1. "nfTokenProtocol"           (string, required) A non-fungible token protocol symbol to use in the token creation. The protocol name must be valid and registered previously.
2. "nfTokenId"                 (string, required) The token id in hex. The token id must be unique in the token type space.
"3."nfTokenOwnerAddr"         (string, required) The token owner key, can be used in any operations with the token. The private key belonging to this address may be or may be not known in your wallet.
4. "nfTokenMetadataAdminAddr"  (string, optional, default = \"0\"). The metadata token administration key, can be used to modify token metadata. The private key does not have to be known by your wallet. Can be set to 0.
5. "nfTokenMetadata"           (string, optional) metadata describing the token. It may contain text or binary in hex/base64.

Let’s imagine we are building a crypto collectibles game — CryptoKnights. It’s a game where you can own digital assets that represent unique knights. Every other instance has different properties based on the DNA generation algorithm. Just like with Ethereum Cryptokitties game. Let’s say the protocol symbol will be “ckt”. In order to register an instance of a CryptoKnight, you have to run a command like this one:

nftoken issue ckt 2772eeb3a5486f773ad7e47413424356da55db94c7f8e0528fcba5079ddeb8ed CRWJKC453SVnczLQD6opqJVMuHDqNWwaJAgV CRWD4W7PauajWooq8vmtzaxNzEEED5yL3FdZ “https://ipfs.io/ipfs/QmPiYzMQbSPxsKC2b6CHEUHWfqFHjX9bHSu6YVpiopzvTx"

As a result you will get a transaction ID: ce1444b48cdd83761afa79f3089d2d433a417ea3a6eb2cfc403dc0bf4e7f48c6. To uniquely identify an NFT you can use the combination of the protocol ID and the token ID. Or transaction hash.

As an architect of your application, you have to choose a strategy of generating NF token IDs. The restriction is pretty simple — it must be unique in the space of your protocol. It can be a hash of a document that uniquely identifies your tokens, it also can be a simple counter, unique seed, etc. In the example above I calculate SHA-256 hash of the DNA uniquely identifying a new CryptoKnight instance.

After the transaction is mature enough, the NFT is considered registered and can be used as an existing digital asset. The link to the metadata can look something like this:
{
  “name”: “Percival”,
  “description”: “A knight of the Round Table”,
  “image”: “https://percival-image.link”
}

Now you can query data from the blockchain to process and display it in your application. In order to get a single instance of an NFT you can simply use the get API:

nftoken get ckt 2772eeb3a5486f773ad7e47413424356da55db94c7f8e0528fcba5079ddeb8ed

As a result, you will have a JSON document that looks something like this:

{
“blockHash” : “000001b031c4832eb185b05475bb37a6d320b6a531a48cc1cdf9300760e84388”,
“registrationTxHash” : “ce1444b48cdd83761afa79f3089d2d433a417ea3a6eb2cfc403dc0bf4e7f48c6”,
“height” : 5197,
“timestamp” : 1561019190,
“nftProtocolId” : “ckt”,
“nftId” : “2772eeb3a5486f773ad7e47413424356da55db94c7f8e0528fcba5079ddeb8ed”,
“nftOwnerKeyId” : “CRWJKC453SVnczLQD6opqJVMuHDqNWwaJAgV”,
“metadataAdminKeyId” : “CRWD4W7PauajWooq8vmtzaxNzEEED5yL3FdZ”,
“metadata” : “https://ipfs.io/ipfs/QmPiYzMQbSPxsKC2b6CHEUHWfqFHjX9bHSu6YVpiopzvTx“
}

You can also request the information about the NFT instance using the transaction ID:

nftoken getbytxid ce1444b48cdd83761afa79f3089d2d433a417ea3a6eb2cfc403dc0bf4e7f48c6

Keep in mind that it means using different abstraction level, so it’s recommended to use the token ID to address NFTs. In this case, you interact on a level of your application business-logic.

To query multiple instances you will use the nftoken list API. This command is pretty flexible so you can request and process all existing NFTs, or only those belonging to a specific protocol or belonging to a specific owner or both. You also can set up the requesting blockchain height and amount of records. All of this will give you the flexibility to adapt requests to your needs. For example, to request all CryptoKnights tokens you will write:
nftoken list ckt or to get all the instances belonging to the owner of the address CRWJKC453SVnczLQD6opqJVMuHDqNWwaJAgV your command will look like this:

nftoken list * CRWJKC453SVnczLQD6opqJVMuHDqNWwaJAgV

Other API documentation details are available using the help command of your node instance and will be available in the project wiki soon. You can also request additional information using the APIs:

nftoken totalsupply ckt
nftoken balanceof CRWJKC453SVnczLQD6opqJVMuHDqNWwaJAgV
nftoken ownerof ckt 2772eeb3a5486f773ad7e47413424356da55db94c7f8e0528fcba5079ddeb8ed

Code Example

This code example is a fragment of a simple application that receives a file as an input and registers an NFT with a unique hash of that file as a token ID, proving the existence and ownership of the underlying data.

int main()
{
    CURL * curl = curl_easy_init();
    curl_slist * headers = nullptr;
    Nft newNft;
if (curl != nullptr)
   {
        std::string getNewAddr(R"({"jsonrpc": "1.0", "id": "nftest", "method": "getnewaddress", "params": [] })");
        headers = curl_slist_append(headers, R"("content-type: text/plain;")");
        curl_easy_setopt(curl, CURLOPT_HTTPHEADER, headers);
        curl_easy_setopt(curl, CURLOPT_URL, "http://127.0.0.1:43001/");
        curl_easy_setopt(curl, CURLOPT_POSTFIELDSIZE, getNewAddr.size());
        curl_easy_setopt(curl, CURLOPT_POSTFIELDS, getNewAddr.c_str());
        curl_easy_setopt(curl, CURLOPT_USERPWD, "crownrpc:bogus");
        curl_easy_setopt(curl, CURLOPT_USE_SSL, CURLUSESSL_TRY);
        // Gen owner address
        curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, GetNewAddressFunc);
        curl_easy_setopt(curl, CURLOPT_WRITEDATA, &newNft.OwnerAddress);
        curl_easy_perform(curl);
        // Gen admin address
        curl_easy_setopt(curl, CURLOPT_WRITEDATA, &newNft.AdminAddress);
        curl_easy_perform(curl);
        // Register new NFT
        rapidjson::Document nfTokenRegDoc;
        nfTokenRegDoc.SetObject();
        nfTokenRegDoc.AddMember("jsonrpc", "1.0", nfTokenRegDoc.GetAllocator());
        nfTokenRegDoc.AddMember("id", "nftest", nfTokenRegDoc.GetAllocator());
        nfTokenRegDoc.AddMember("method", "nftoken", nfTokenRegDoc.GetAllocator());
        rapidjson::Value params(rapidjson::kArrayType);
        params.PushBack(rapidjson::Value("register").Move(), nfTokenRegDoc.GetAllocator());
        params.PushBack(rapidjson::Value("doc").Move(), nfTokenRegDoc.GetAllocator());
        params.PushBack(rapidjson::Value(rapidjson::StringRef(newNft.TokenId.c_str())).Move(), nfTokenRegDoc.GetAllocator());
        params.PushBack(rapidjson::Value(rapidjson::StringRef(newNft.OwnerAddress.c_str())).Move(), nfTokenRegDoc.GetAllocator());
        params.PushBack(rapidjson::Value(rapidjson::StringRef(newNft.AdminAddress.c_str())).Move(), nfTokenRegDoc.GetAllocator());
params.PushBack(rapidjson::Value(rapidjson::StringRef(newNft.Metadata.c_str())).Move(), nfTokenRegDoc.GetAllocator());
        nfTokenRegDoc.AddMember("params", params, nfTokenRegDoc.GetAllocator());
        rapidjson::StringBuffer buffer;
        rapidjson::Writer writer(buffer);
        nfTokenRegDoc.Accept(writer);
        std::string nftRegJsonStr = buffer.GetString();
        curl_easy_setopt(curl, CURLOPT_POSTFIELDSIZE, nftRegJsonStr.size());
        curl_easy_setopt(curl, CURLOPT_POSTFIELDS, nftRegJsonStr.c_str());
        curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, NfTokenRegFunc);
        curl_easy_setopt(curl, CURLOPT_WRITEDATA, &newNft);
        curl_easy_perform(curl);
    }
    return 0;
}

In the example above we generate two new Crown addresses and then make a call to register a new NFT within the “doc” protocol space. And that’s it. You now have a non-fungible token instance registered on the Crown blockchain. We use a local node here for registration on a sandbox blockchain. (Note: the information of how to set up and use Crown sandboxes will be available soon). It’s really up to you what language or library to use for the development. In the near future, I will update the Crown Bitcore library to support NFTs out of the box, so it’s easier for web developers to integrate Crown blockchain solution in their applications.

Thank you for your attention. Stay tuned for the upcoming 0.14 Emerald testnet release this week and more technical documentation on the wiki.

Join discord and tag defuctec, the author of this article. thank you sir

Can we hope for a new listing on Binance? What did they justify anyway?

https://medium.com/crownplatform/big-tech-censorship-antitrust-and-why-the-crown-platform-matters-881b872a36d4


Big tech censorship, antitrust and why the Crown Platform matters.

Crown contributor defunctec’s take on platforms vs publishers.

For years we have witnessed a slow creep of big tech control over the industry and control over content via their platforms which has now lead to Department of Justice probes.
Are these “platforms” publishers or platforms is the question of the day.
A great example of a publisher is news outlets where they pay journalists or reporters to write about X with the editors being responsible for what the author has written and published, while a platform is an open system in which virtually anyone can contribute anything. Of course, the platform has a duty to filter illegal content from its platform but apart from that anything goes.
The issue seems to be that these platforms are acting as publishers by not only banning illegal content but also controversial speech that either they don’t like or have been pressured by outside forces to remove.
 
Do platforms have the right to remove non-illegal but controversial content and still be classed as a platform? Who owns your content, you or the platform?
 
A good argument for Facebook not owning your content can be found here.
Facebook says the user owns their content but then why are they removing non-illegal but controversial speech from their platform? They’re taking responsibility for the curation of content other than illegal, making the argument of being a publisher very serious. If you do own your content, they’re only responsible for the removal of illegal content, not yours.
They can do this legally if they’re a publisher, but they masquerade as platforms and benefit from the lack of legal repercussions from acting as a publisher.

Antitrust suits are also on the horizon in America with Google, Apple and social media platforms all being looked into for breaches of laws relating to anti-competitive behaviour.

So why does blockchain matter?

Projects like Ethereum offer great utility for individuals and business to build or integrate already existing services to use blockchain tech, but with this utility comes great legal risk.

For example, an illegal organisation could use Ethereum and it’s token generation tools (ERC tokens) to fund operations around the world. The Ethereum developers are basically powerless to stop this group from using Ethereum’s tools unless they take drastic action which would jeopardise the trust aspect of the project. Even if mass consensus was reached to remove such a group then the fact that the Ethereum team intervened will erode trust in the decentralised ideal.

Crypto tech will always be used maliciously. We cannot completely stop this but we can create a system that helps filter out illegal content.
Ethereum will one day face this scenario, with an “illegal” operation using its tools for bad intentions.

When this day comes the Ethereum community will have to decide if this type of structure is the one they would like to continue to support or move on to a more regulated space. We must also consider governments actually banning the use of such platforms that allow illegal content to be hosted and distributed on the platform.

Crown Platform

The Crown development team and community are building a new system in which illegal actors’ access to the platform can be revoked… But not by the development team.

ID Verifiers

A unique and privileged position to hold within the Crown community, it comes with great responsibility. A verifier would need to create a special proposal via Crown’s proposal (governance) system. Once the proposal gathers enough Yes votes to pass the proposer gains access to a part of the Crown Platform no one else has. The verifier can now hash identity documents and provide requesters of verification with a “Unique Verification Hash” (UVH). A UVH can be used by individuals or corporations to provide proof they are who they say they are.

Systemnodes

Will provide computational power to users of the Crown Platform and can also be used independently alongside any website/server/business. A Systemnode doesn’t need a UVH to operate in the legacy sense but to use Crown Platform services a UVH will be needed.
 
A Systemnode can provide a toolkit of API requests from the network such as NFT generation, account registration etc..

So who keeps what in check?

The Crown community vote on ID verifiers which in turn provide UVHs to the Crown community. This is a relationship between a verifier and the community. If the verifier becomes a bad actor (e.g., Person A obtains UVH, Person A uses Crown Platform to host illegal content), the Crown community can notify the verifier that illegal content is being hosted using a UVH they provided, the verifier can now act appropriately. If the verifier doesn’t act the Crown community can vote down the verifier, removing all content related to the verifier.
 
It sounds harsh but it’s a requirement to remain legally compliant as a global network (within reason.)
 
Person B who successfully completed his verification and now possess a UVH can now host a Systemnode or become part of the computational pool.

Why the Crown Platform matters
 
This is the perfect time for a blockchain backed platform like the Crown Platform to emerge as an alternative technology and new way of managing large platforms such as the “App store”, social media, etc. where the distinction between publisher and platform is grey.
 
The Crown Platform is purely a platform and not a publisher. ID verifiers must not pick and choose the content they prefer but rather accept the user’s freedom to do anything within the law of the UVH holder’s land. Any content hosted on the platform is hosted by verified users and if the content is illegal in his country, his Identity could be used against him since his UVH is known to the ID verifier. It’s well within the user’s interest to remain within legal compliance within his jurisdiction.
 
Users (UVH holders) also have the choice to choose more than one ID verifier to provide them with a valid UVH in case the Crown community ever vote down a verifier and their privilege is revoked.
 
If a verifier acts like a publisher and revokes UVHs because of some personal spat, for example, it’s the Crown community’s (Voters) responsibility to act. On the other hand, if an ID is found to be fraudulent or the user acts illegally it becomes the verifier’s responsibility to revoke the UVH. Again, if the verifier doesn’t act they become susceptible to No votes and ultimately removal from the platform.
 
This isn’t a platform of curation nor subjective, moral or ethical standards rather a legally compliant framework you can choose to use or not to use.
 
“Fall of big tech”
 
If big tech platforms are found to be publishers and violate or have violated antitrust laws there will be a huge vacuum ready to be filled with new tech and new ideas. Large corporations that have a firm grip on the tech industry could actually be broken down similar to how Standard Oil was broken into 34 individual companies.
 
Yes, speculation… But all this should be considered when building such a platform as we don’t want to make the same mistakes.

Summary
 
Legal action against big tech platforms is looming. Platform or publisher? Do they own the content you provide and can they restrict your content if it’s legal? Are they violating antitrust laws by snuffing out competition? The Department of Justice will provide more information about this soon.
It’s safe to say that censorship of speech which is a right in the USA, for example, is curation, making the argument that these platforms act as publishers carry some weight.
 
The Crown Platform and its community do not curate non-illegal content. Users are free to act within the laws of their jurisdiction.
ID verifiers provide users with UVHs allowing them to join the computational pool or access tools directly via a Systemnode. Verifiers have the responsibility of revoking users’ UVHs if found to be acting illegally, not curating content depending on how they feel that day.
 
Systemnodes can be used alongside a website, for example, to offer their users/customers blockchain related services.
 
Overall the Crown Platform is attempting to build an open compliant network that will function legally within as much of the globe and possible, providing non-fungible token creation to start, with further development leading to fungible tokens, account registration, ID verification, verifier voting, time stamping, transactions. All the tools that will enable the Crown Platform to be a vibrant open legal ecosystem.

usaly when "superblock" are made they make the price rise, not on CRW tho... down hill since ur failed Mn system in affect... should of ketp it pow.... but then ya wouldnt get all the free coins from doing STUFF ALL...
lol at the bot accounts trying to hype aswelll...
Crw vote payout should stop till u show some kind or price inc and returns for holders..... not LEACH users that hold since start...

I'm willing to admit what you say but 3h of confirmation 100 or 150 confirmation for CROWN on = 2h or 3h30 MN exemple it's much very  toooooooo long even for POS example CLOAK or VIOG or ExSolution coins 5 confirmation and everyone is happy.

How can the mass adopt if we have to wait X confirmation with 107 years?

Very well, I have been following the development of the project with great interest for some time now. The predominance of development over marketing and attention to technical innovations makes it in my opinion one of the most promising projects for the future, especially in the masternodes space where there are really few projects that look far ahead. I think also it is one of the projects with one of the healthiest and most motivated community in the whole crypto space.

Attention masternode owners

It’s time to vote!

Being a masternode owner isn’t just about earning a passive income. With great rewards comes great responsibility. Masternode owners are responsible for enacting the Crown Decentralised Governance Proposal system which decides the future direction of the Crown project, and allocates funds from the superblock to the current proposals.

If you need a reminder of what the CDGP system is about please take a look at the governance section of the Crown website, and familiarise yourself with the superblock calendar and the voting system.

TL;DR
It is crucially important that you exercise your duty to vote in the monthly superblock “election”.
The next superblock is at block 2,419,200 which is estimated to occur at about 07:20 UTC on 17 June 2019. However, voting closes 2880 blocks (about 2 days) before that but your masternode must remain online until the actual superblock for your vote(s) to count.
Please go and vote now!

Why?
Last month, in superblock 2,376,000 the submitted proposals asked for a combined total amount of Crown which exceeded the available funds. The proposal with the largest ask received the smallest number of votes and consequently, although it passed, it did not get funded. This put continued platform development in jeopardy. Also, fewer than 20% of the enabled masternodes actually voted.
That’s right, the majority of masternode owners abdicated their responsibility and left it up to a minority of a subset of the Crown community to decide how the project should progress and which proposals to fund.

This month, for superblock 2,419,200 the submitted proposals again ask for a combined total amount of Crown which exceeds the superblock maximum of 54,000 CRW. It is possible that there will be some additional proposals submitted for this superblock which will further increase the competition for the limited funds available. Almost inevitably that means some proposals will fail to be funded, even if they pass (a proposal passes when the number of Yes votes exceeds the number of No votes by at least 10% of the number of enabled masternodes).
At the time of writing, only about 30% of masternodes have voted in this superblock.
We need all masternode owners to carefully review the submitted proposals and vote according to their interpretation of the best interests of the project.

Each proposal contains a link to a detailed description of what it entails, how much funding is sought, who is asking for it and doing the work, and the benefits it will bring. Please take the time to review all the proposals and to consider (among other things)

- the total available budget
- the individual amounts requested
- the other proposals amounts requested
- the priorities of the project
- the impact of each proposal on those priorities if it is funded and if it isn’t funded
- just passing may not be sufficient for a proposal to be funded

Hint: it would be a really good thing if the development and infrastructure proposals passed!

Where to find the proposals?
You can see a pretty colour overview of the active proposals at crowncentral.net:

An enhanced proposal view but you can’t vote directly here
You can also see the submitted proposals directly in your QT wallet in the Voting tab of the Masternodes page:

The voting tab in the QT wallet
Most importantly, you can also vote for them here. But before voting, please take time to click on the URL for each proposal to read the details. Some of the descriptions can be found in the Crown forum:

Proposal descriptions in the Crown forum
but proposal owners can put the description anywhere (Google docs is another popular location).
The description should include essentials like who is making the proposal, how much they’re asking and what the community gets in return. There should also be contact details so if you have any questions about the proposal you can contact the proposer and seek clarification or offer comments and feedback.

Questions and comments are positively encouraged because they increase participation and help build the community. If you vote No on a proposal it would be really helpful to the proposer if you let them know why you voted that way. You can ask questions and leave comments in the #proposals channel in Discord.

How to vote

Each proposal includes instructions on how to cast your vote. There are two cryptic looking lines of the form

How To Vote YES: mnbudget vote-many 3c67369ab31786ab1bff83c3634a71eb3b9b8983260d1f97c0e664bc741cdb4f yes
How To Vote NO: mnbudget vote-many 3c67369ab31786ab1bff83c3634a71eb3b9b8983260d1f97c0e664bc741cdb4f no

which are what you need to know if you’re going to vote using the command line interface or the debug console of the QT wallet. You can also vote directly from the Voting tab in the QT GUI. Whichever method you’re going to use, your wallet must be unlocked before you can vote.
To vote using the QT GUI, click on a proposal to highlight it and then click the appropriate vote-many button. The wallet will respond with a confirmation request window:

After voting you should get a result window similar to:

Due to a bug in the QT wallet, votes don’t always register on the first attempt. If you don’t get a result window like this, you need to vote again.
Important. You can vote more than once for any proposal but only your last vote before the voting window closes counts. So you can change your mind on a proposal if you want to.

Remember: this superblock is over-full. It is probable that not every proposal which passes will get funded. If passing proposals don’t get funded there is a possibility that some superblock funds will remain unallocated and be wasted (as happened last month). One of your responsibilities as a masternode owner is to ensure funds are allocated in the best interests of the project. You may want to change one or more of your votes to make that happen.

Please vote as soon as possible.
Please also check again before the voting window closes (around 07:20 UTC on 15 June) because circumstances could have changed and you may want to vote again.

So far only about 30% of masternodes have voted. Let’s see if we can double that number over this coming weekend.

https://medium.com/crownplatform/attention-masternode-owners-4c15040f285

Development update June 2019

Onwards and upwards


Our developers, Artem and Ashot have been hard at work since the last development update.

Version 0.13.4.0 was released a week later than we had hoped but was worth the wait. Everyone who has updated is experiencing improved stability, lower resource consumption and fast syncing. The network node count has recovered from its dip and there are currently around 1000 masternodes and 1500 systemnodes online. The systemnode count is still much lower than it traditionally has been because the depressed price makes them unprofitable (in fiat terms) on many hosting platforms at present. However, canny community members know the systemnode ROI is higher than the masternode ROI, take a long term view and keep running those nodes.

Trezor

The final pre-reqs for Trezor integration have been completed:
Bitcore-Crown and the associated Crownsight explorer
the pull-requests to Trezor-firmware for the prefix change and explorer links
We now have to wait for Trezor to push a new firmware release. These happen roughly every 3 months and the last was in March so we’re hoping it will happen this month.

NFT framework

Artem is still concentrating on development of the non-fungible token (NFT) framework. He has completed coding of most of the APIs (get, getbytxid, totalsupply, balanceof, ownerof) and has a couple more still in progress. He’ll be working on the documentation soon and we’re hopeful for a testnet release on 20 June 2019.

Codebase refresh

Ashot evaluated the best Bitcoin codebase to migrate to and has settled on v0.17. This is going to be a complex and time-consuming process. He basically has to take all the changes over the last four years which made Crown Crown, and re-apply them to a clean Bitcoin base. A very rough guestimate for how long this might take is 3–6 months.

Astute readers might wonder why we chose Bitcoin v0.17 rather than v0.18 since the amount of effort is about the same. The reason is account support. Accounts are the flaky wallet code for partitioning wallet funds into separate chunks. Some centralised exchanges are known to rely on this functionality. In Bitcoin v0.17 the functionality is deprecated but still present. In Bitcoin v0.18 it is removed completely. Switching to the v0.18 codebase without prior agreement from exchanges could cause us problems.

The new codebase will bring security, speed and stability enhancements. It will also make it easier to keep up to date with critical Bitcoin changes and ease maintenance into the future.

https://medium.com/crownplatform/development-update-june-2019-a1086c5d3aa0

That's exactly what it is! I couldn't have described it better

I see that the fintech sector is exploding with new and innovative products and services. Since it covers monetary transactions in the fields of credit, payments, insurance and trading, most of which are processed in end-to-end processing (STP) mode, regulatory compliance is a must. Promoting innovation without the overhead costs of over-regulation and consumer protection requires a balanced approach, for which regulators in many countries have adopted a "regulatory sandbox" approach and allows authorised companies to test their innovative products, services, business models and delivery mechanisms in the real market, with real consumers, on a trial basis. It helps reduce time-to-market at low cost, improves access to capital and ensures compliance with compliance requirements. These regulatory sandboxes allow direct communication between fintech developers, companies and regulators, while mitigating the risks of unintended negative consequences, such as security breaches. It is nice to see that CRW meets these criteria.

I have analyzed your project, it is realistic and seems to be performing well. Can you confirm when the next division of annual percentages will take place in 2020 or 2021?

The Crown tech lead Artem is nearly finished with his long awaited work on the #NFT (Non-fungible Token) framework.
A technical document will be released in June, followed by the release of the code into testnet. Crown is now one step closer to the Emerald release milestone!

Recommended CROWN update v0.13.4.0

We are pleased to announce the release of Crown v0.13.4.0. This is a recommended update.


Although you can continue to run v0.13.2, unless you have already taken steps to mitigate the increased RAM and CPU usage, you almost certainly will hit problems further down the line. We recommend everyone update at their earliest convenience.

v0.13.4.0 is a recommended update for all users

What does it include?

It was originally planned to include three fixes but actually includes four and some enhancements:

The long awaited fix to the v0.13 sync problem.
Following the v0.13 update, a number of users experienced very severe performance problems with syncing the blockchain. A number of workarounds were published, which successfully circumvented the problem for most of those users. Others continued to experience unacceptably slow syncing. Ashot and presstab have worked hard to identify and resolve the issue.
With the new update, everyone with a part-way decent internet connection should be able to complete a full sync in less than 4 hours.

Incorrect display of rewards on the wallet summary screen.
Rewards were showing as mature (available to spend and stake) before they actually were.
Fresh masternode and systemnode rewards, and staking rewards now show as “Immature” in the wallet summary screen until they receive the required 100 confirmations.

Address labels.
Ashot has worked his magic in the wallet and old labels display correctly with no intervention from the user.

CPU and memory usage.
It became apparent during development that there was a bigger and more pressing problem than any of the preceding three. Nodes and wallets were using much more RAM and CPU than in v0.12.5.3. Depending on the hardware they were running on, nodes could exhaust the available RAM and crash themselves or even the VPS after a couple of days. Painstaking research showed the increase to be related to code hardening against one of the PoS attack vectors. Presstab reworked the code so that it still provides the same protection but at much lower resource cost.

Installer enhancements.
While waiting for the code fixes in v0.13.4 a number of workarounds for the sync and resource usage were deployed. Although they should no longer be required it was thought beneficial to provide easy access to them through the installation/update script. So the script now includes options to add the watchdog script to a new or existing node, to sync a node or wallet using the bootstrap, and to install a pipeline build.

I’m sold, how do I upgrade?
As always, the new release is a drop-in replacement. Essentially, make a backup of your wallet.dat, shutdown your wallet and node(s), replace the executables and restart. The details vary from platform to platform and environment.

Hosted node
If you use a hosted masternode/systemnode service they should take care of the node update for you. Since this is not a mandatory update you might need to ask them, but given the resource savings to be made by upgrading it’s likely they’ll be way ahead of you! You can update your node(s) before or after your wallet; the order is unimportant.

QT wallet
Restart the wallet and it should prompt you to download the update.

Self hosted node (linux) or a wallet
If you are already using the watchdog script you should disable it before upgrading (otherwise it could restart the node at an inopportune moment). See below.
If you’re not interested in the watchdog and bootstrap simply use the one-liner to update a masternode or systemnode. Log on to your server and run
sudo apt-get install curl -y && curl -s https://raw.githubusercontent.com/Crowndev/crowncoin/master/scripts/crown-server-install.sh | bash -s

All environments
The network protocol version has not changed so it isn’t necessary to issue start-alias commands for masternodes or systemnodes if you have already upgraded to v0.13.2.0

What about the watchdog and bootstrap thingies?
The installation/update script has new options which could still be useful in certain circumstances. If you want to take advantage of them, we recommend you download the latest version of the script and run it directly (doing so gives you the most flexibility, but if that sounds too complicated see below).

Download the installer
You can use curl or wget. The following example uses curl. Put the installer somewhere in your path (/usr/local/bin is recommended) and make sure it is executable.
sudo curl -o /usr/local/bin/crown-server-install.sh https://raw.githubusercontent.com/Crowndev/crowncoin/master/scripts/crown-server-install.sh
sudo chmod +x /usr/local/bin/crown-server-install.sh

watchdog
The watchdog as originally published ran every 15 minutes and did two things:
Check if crownd is running, start if it is isn’t.
Check free memory and restart crownd if it is “too low”.
If you are already using the watchdog it won’t do any harm to continue running it after the upgrade, but you should disable the cron entry for the duration of the upgrade. Use the command
crontab -e and comment out the watchdog entry by putting a hash sign (#) at the start of the line. Uncomment the line (by removing the hash sign) after upgrading.

The watchdog could still be useful after the upgrade. It is very unlikely you would need the memory checking. However, making sure your node is running every 15 minutes isn’t a bad thing (but don’t use the watchdog in conjunction with systemd or any other automatic process starter/monitoring system).

The installer has a new option, -w followed by a number 1 or 2 which corresponds exactly with the two actions described above. If you want to add the watchdog to an existing instance at the same time as upgrading then the command to use is
crown-server-install.sh -w 1
or, if you want to use the free memory checking as well
crown-server-install.sh -w 2

bootstrap
Syncing performance in the v0.13.4 update is vastly improved. Pretty much everyone should be able to sync a new node across the network, from scratch, in less than four hours. With a good internet connection, we saw several such syncs complete in less than two hours during testing.
There may still be times when syncing with the bootstrap is useful so the installer now has the option to use it. Most VPSs have a good internet connection but your local connection may not be as fast or reliable. We anticipate some wallet installations might benefit from syncing with the bootstrap, which can be done using the -b option. For example
crown-server-install.sh -c -b

The -c option indicates this is a new wallet installation (-w is already used for the watchdog). This example will ensure your system is updated, download the release package and the latest bootstrap, create swap space if you don’t have any, write a new crown.conf, update your firewall, install the release package, unzip the bootstrap into the datadir and start the daemon.

wait, there’s more!
Unless told otherwise the installer will fetch the latest release package from our Github mirror. There may be times when you want to use some other version, specifically a test version from a Gitlab pipeline build. A number of community members helped test this version before release and we’re grateful for their assistance. If you’d like to get involved and help with testing in future please get in touch via the #contributor-general channel in Discord.

Use the -j option to specify a pipeline build to install or update to. For example
crown-server-install.sh -j 6114

The installer has a number of other options. They are mostly additive although there are some mutually exclusive combinations (for instance you can’t specify both -m for a masternode and -s for a systemnode in a single invocation). You could combine all the options we’ve seen so far here, like
crown-server-install.sh -j 6114 -c -b -w 1
to install a pipeline build as a wallet, sync with the bootstrap and enable the watchdog (level 1).

We plan to publish another article soon describing the installer in more detail.

Wrapping up
Thank you to everyone who has upgraded to v0.13.2 for your patience while we dealt with the glitches and performance issues. We recommend you update at your earliest convenience.
There are still a number of v0.12.5.x nodes and wallets which have not upgraded. Although the node count is down about 20% the network hasn’t really missed them but they have been missing out on both node rewards and staking rewards. We hope these fixes will encourage their owners to upgrade those nodes and rejoin the network.

If you have any questions or issues with the upgrade or want to know more or even just chat about Crown, please contact us in Discord or Telegram.

https://medium.com/crownplatform/recommended-update-v0-13-4-0-6791cb0599a8

Key aspects

1. We just transited from a BTC mergemined PoW to a crypto industry first all-node-staking PoS protocol demonstrating our community strength / will to innovate during a bear market and making our stakeholder structure decentralized in a true way.
https://medium.com/crownplatform/crown-masternode-and-sytemnode-proof-of-stake-consensus-system-mnpos-e6780ef534b3

2. We have a clear vision for Crown: a blockchian-as-a-service model, where anybody who wants to work with blockchain is invited to build their ideas: ranging from registering any physical or digital asset using NFTs, build/host an applicaiton, transact value, or create any use case imaginable on the Crown chain. Leaving the future of blockchain tech on natural, community-driven forces rather than pushing one usecase and telling people how it should be used.
https://medium.com/crownplatform/crown-blockchain-platform-overview-f1aff7d341a8

3. Our next development goal is the release of NFT's which will enable the registration of any asset on the Crown Blockchain, our solution is nearly already (in private testnet of our tech lead Artem), you can watch the QA with our tech Lead Artem here:
https://medium.com/crownplatform/artem-ashot-dev-q-a-99c27ab64c84

4. We are a community driven platform of approximately 5k users mostly from the western part of the world with largest communities coming from the US, UK, Netherlands, Germany, Czech Republic, Spain, Korea, Brazil, Italy, Australia and New Zealand. There is no centralized team, but rather a decentralized model of contributors, our communication channels are open and transparent. Our community meets in person 3 to 4 times a year since December 2016 when we met for the first time in London.
https://medium.com/crownplatform/crown-coinfestuk-2019-april-4th-5th-6th-2019-d5210bca6a05
https://medium.com/crownplatform/malta-blockchain-summit-review-8d9108ba41e7
https://medium.com/crownplatform/crown-meeting-culminates-with-use-case-focused-community-meetup-at-the-blockchainhotel-in-essen-c496f08df715
https://medium.com/crownplatform/crown-miami-meetup-recap-6a154fa2342d
https://bitcointalksearch.org/topic/m.24536634
https://bitcointalksearch.org/topic/m.21189347
https://bitcointalksearch.org/topic/m.18823814
https://bitcointalksearch.org/topic/m.17094738


5. We have a decentralized governance proposal system, which enables the development of Crown to be independent and self-sustainable
https://crown.tech/governance/
https://medium.com/crownplatform/decentralized-governance-readjustment-f8c119c632f4

6. Our blockchain is powered by over 2k of nodes - masternodes and systemnodes: the community is fully in charge of the future of the blockchain
https://medium.com/crownplatform/crown-mn-and-sn-rates-of-roi-f317247c208


7. Our development repositories are open to the public
https://medium.com/crownplatform/crown-core-team-goes-public-with-repositories-and-workflow-3b5fcc5278b0


8. Our blockchain was fairly launched in October 2014 during the pre-ICO times in a fully transparent way
https://bitcointalksearch.org/topic/anncrw-crown-sha256-platform-governance-systemnodes-masternodes-815487

9. We are not an anonymous platform, our identities are faces are known to the world.
https://crown.tech/about/

10. We are currently listed on 4 quality exchanges, we have not paid them to list us, that is our philosophy.
https://bittrex.com/Market/Index?MarketName=BTC-CRW
https://upbit.com/exchange?code=CRIX.UPBIT.BTC-CRW
https://wallet.crypto-bridge.org/market/BRIDGE.CRW_BRIDGE.BTC
https://www.litebit.eu/en/buy/crown

11. You can see a summary of the Crown blockchain in this presentation
https://medium.com/crownplatform/crown-platform-a3c1ad774bff

12. We were selected as one of the few blockchain and featured on a US based TV show Success Files hosted by Rob Lowe
https://medium.com/crownplatform/crown-platform-featured-on-success-files-presented-by-rob-lowe-4a5be9bd3308

13. You can see what we represent in this short video
https://www.youtube.com/watch?v=fI_zjKxzVaA

Dear crown community!
I read the intro on https://crown.tech/learn-more-about-crown and I didn't find any special stuff.
Could someone tell me as easy as possible about crown progress with links please?
P.S. I know another similar platform - shiftnrg but they already have working dapps, but haven't masternodes unfortunately.
Cheer!

Awesome video interview with Jose aka Crownfan from CrownPlatform during the Coinfest UK event in Manchester in April 2019

https://vimeo.com/334693605


Few words also on the Interview at CoinFest:

- Crown is a network for decentralised money and applications. We are working on further decentralised registries to leverage all the potentials of Bitcoin Core and combine them with frameworks that are typical of other chains such as Ethereum  / EOS.

- Crown is not only unique for trying to reach these technical goals, it is also unique in the way we organise to reach them. In this sense, the way is also our goal. We can only leverage the technology we are building if we also use it and integrate it in our own lifes. Devs fx do this as they live from the value they generate for Crown by building on it. So do many other dozens of contributors who accept CRW, who design new use cases or who have social relations on and through the chain.

- We always need to ask ourselves how the technology we are building and using impacts and changes our social and cultural ecosystems.

- The Crown governance system is one of the few working examples. It is not in the custody of anyone and depends on the totality of MN votes.

- We now have over 2000 mining nodes who can produce blocks without the need for centralised pools or middlemen.

- More important milestones are coming up.

- this Interview was just a side gig. The NFT presentation video will be up shortly. Its more informative and longer. Looking forward to it.

Indeed the performance is correct and ever-increasing, we have tested the stability, conclusive result

Crown Platform Development update for May 2019 is here

First off, an apology: we aren’t able to release v0.13.4 by 6 May. Although the current release candidate solves the slow sync problem, fixes the display of immature rewards, fixes the address labels problem, and (added bonus) reduces the memory requirement, it has proved to be a bit unstable. It will be released as soon as the instability is resolved.

Now that MN-PoS is operational we are looking forward to the next developments in the evolution of the Crown platform. In order of arrival, and scale, they are:

Trezor integration
NFT framework
Codebase update


Trezor integration
This is an exciting development which brings the security of a hardware wallet to Crown users and offers the possibility in future to start masternodes and systemnodes without requiring a full desktop wallet.

It involves several components, some of which are completed and others which are nearly complete. The completed components are the new address prefixes in Crown v0.13 (“Jade”) and update of the Electrum-Crown wallet to understand the new address format. Changes to Bitcore to understand the new address formats are in progress and could be ready within two weeks. Bitcore will provide an Insight explorer which allows access to information in the Crown blockchain. The final component is the actual Trezor integration. Our target release date is June 2019.

NFT framework
This will extend the use-cases for the Crown platform and allow users to develop their own applications. Non-fungible tokens can be used in myriad ways. The initial framework version is expected in the “Emerald” release and will provide registration and timestamping facilities. One of the most basic applications of NFTs is recording proof-of-existence and we already have people interested in developing more complex applications. To facilitate this we aim to provide developer documentation ahead of the release, expected in testnet by July 2019.
Further development of the NFT framework will be guided by user feedback on the initial release.

Codebase update
Crown is based on Bitcoin core v0.10 and v0.11. In computing and crypto terms this is ancient. Bitcoin v0.18 was released on 2 May 2019.
Updating the codebase is a major undertaking with the principal benefit of making future maintenance easier. It will also enhance security and provide access to additional features. There is no estimated completion date yet but the project will take several months.

https://medium.com/crownplatform/development-update-may-2019-a53cc2c7eb55