We are excited to announce the current mobile release and future planned releases for the Bridge Identity Platform in 2021. If you are not familiar with the Bridge Identity platform, please read What is the Bridge Identity Platform? to learn more.

Bridge Mobile Passport Release v1.1

Bridge Mobile Passport has been accepted and released to the public on the iOS App Store for both iPhone and iPad devices. Version 1.1 marks a major milestone in supporting portable mobile identity for all users across both Android and iOS devices. In addition to cross-platform support, Bridge Mobile Passport also addressed usability issues, as well as several security enhancements and bug fixes.

Roadmap And Timeline Updates

At Bridge, we are often quiet about updates as we’re busy building and working to identify real-world use cases and platforms to adopt to expand the case for the Bridge Identity Platform. We have several projects in flight that we are tentatively looking to release later in 2021, so we wanted to share some of them with the community.

Adding more support for real-world use cases

The Bridge Identity Platform is constantly evolving the types of verifications and claims that can be issued. As real-world use cases arise, we are always looking to address the needs by adding support for additional claim types that can be used in the Bridge Passport and Bridge Mobile Passport by our users.

COVID-19 Vaccination Verification
Users will be able to have their COVID-19 Vaccination documentation verified and use the verified claim in their Bridge Passport to prove their vaccination status.

Photo Verification
A key to real-world use of digital identity in-person is demonstrating the user with the Bridge Passport and associated claims is actually the individual presenting the passport. Users will be able store a verified photo in their Bridge Passport to present along with their claims to prove visual identity as well for in-person transactions.

Phone Number Verification
A simple but overlooked verification is phone number verification. This can be especially helpful in online fraud prevention and allow users to verify an additional piece of information. This verification and claim type will be available on the platform as well.

ERC-721 NFT Support
An interesting phenomenon in the last year was the NFT boom. As we watched this unfold, we saw a use case for Bridge Identity emerging. We wanted to make it easy for users to not only store their NFT assets in their Bridge Passport, but we also saw where we could help enhance the security around the management and transfer of these assets. Using the Bridge Identity Platform to manage and transfer, users can be sure of the identity of the sender and recipient for each NFT transfer to prevent any transfer to bad actors.

Binance Smart Chain Support

Launch BRDG BSC-20 Hybrid Token on Binance Smart Chain
The BRDG Token is already a hybrid token that can be swapped between NEO and Ethereum. Users will now have the option of swapping and using BRDG token across all three supported chains. This will drastically lower transaction costs and enable greater access to BRDG token for our users. Another benefit will be the greater reach into the DeFi space by leveraging decentralized exchanges like Pancake Swap, only available on BSC.

Launch Bridge Identity Platform on Binance Smart Chain
All Bridge smart contracts will be implemented to enable Bridge Users to publish their digital identity for use by any decentralized applications on Binance Smart Chain for verification.

Stay tuned as we progress through 2021 for more updates and releases!

To learn more or view documentation and source code to get started with Bridge Identity, visit the links below:

What is the Bridge Identity Platform?

Website

GitHub

To keep up to date with the latest updates and announcements, become part of the community and follow Bridge Protocol on our social platforms:

Telegram

Twitter

Reddit

Facebook

Bridge Identity Summer 2021 Update was originally published in BridgeProtocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you are not familiar with the Bridge Identity platform, please read What is the Bridge Identity Platform? to learn more.

Use Cases

Currently when we provide our physical license or identification, we disclose far more information about ourselves than required to simply determine eligibility for most real-world applications. For example, it is not relevant for the bouncer at a local club to know your name and address when they simply need to determine you are over a certain age to enter. Having access to your personal information creates security and privacy risks, and can easily be avoided.

Bridge Identity has countless real-world use cases beyond the above scenario. Current digital identity projects are primarily focused on online and blockchain based identity claims, while ignoring the bigger use cases in everyday life. It is possible that online connectivity and blockchain networks are not always available, so it is important to have a digital identity that can be both used online, on-chain, as well as in the real-world without relying on blockchain networks. This is where Bridge Identity comes in and supports a wide range of use-cases that runs the gamut across all connectivity situations.

Being able to operate in the real world and off-chain, as well as offering “one and done” validation, Bridge also drastically reduces costs for the end user as well as the organizations requiring the user to be verified. Once the user’s information is verified by a partner on the Bridge Marketplace, their Bridge Identity can be re-used for any application in the future, and any organization can accept that identity for verification purposes.

Token Sales and Initial Coin Offerings

The crypto industry must meet Know-Your-Customer (KYC) and Anti-Money Laundering (AML) compliance obligations in order to conduct ICO’s, STO’s and other Token Sales. Without meeting these obligations they expose themselves to substantial risk with local and international law.

Exchanges and Trading

Financial markets and exchanges are obligated to meet KYC and AML compliance standards as well. Depending on the asset being traded, there is an even higher level of due diligence required to allow users to trade.

Gambling and Gaming

For gambling and gaming, similar KYC and AML requirements apply. In the United States, not only do age restrictions apply when gabling or wagering, but state or province becomes a key factor in determining eligibility since the laws vary greatly state by state or even municipality by municipality. Proper identity verification is key to avoid legal issues around illegal gambling.

Custom Credentials and Certificates

Organizations can issue and verify custom certificates of completion or compliance. With Bridge Identity, organizations whether it be a school or an online blockchain training course can issue their own credentials and certificates of completion that can later be verified by third-parties to determine eligibility. This could even expand into discount codes and other promotional eligibility certificates.

Controlled and Restricted Purchases

Controlled and restricted items require age verification. The most common scenarios in the real-world would be the purchase of tobacco, alcohol, and even medical and recreational marijuana. You must be of a certain age or even hold a medical card to be allowed to purchase these items. When purchasing online, certain items cannot be shipped to individuals under a certain age, and cannot be shipped to certain states. Retailers accept an unnecessary amount of legal responsibility if they are not performing the proper due diligence on the purchaser of the item.

Access to Adult Oriented Material

Adult websites require verification of age and location to allow access to adult material. Depending on the content and location of the user, laws will vary as to whether or not that content can be viewed. Many online sites use a credit card as means of verification of age, but in reality it’s just a simple way for them to get your card on file for a nominal fee and then potentially overcharge you without your consent in the future. Furthermore, there is no need for your name, address, or any other personal information to determine eligibility to the material. Whatever you are into is your business, the site doesn’t need to know your name to know that you are allowed to view the midgets and gerbils.

Bars, Clubs, and Concerts

In-person venues often have restrictions on who is allowed to enter. Whether it’s a local bar, a local club, or even a concert, there are age restrictions, promotions, and tickets associated with entry and price of admission. Bridge allows all of these pieces of information to be provided without disclosing any personal information that is not essential to verification.

To learn more or view documentation and source code to get started with Bridge Identity, visit the links below:

What is the Bridge Identity Platform?

Website

GitHub

To keep up to date with the latest updates and announcements, become part of the community and follow Bridge Protocol on our social platforms:

Telegram

Twitter

Reddit

Facebook

Bridge Identity Platform Real-World Use Cases was originally published in BridgeProtocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are excited to release Bridge Identity 3.1 Beta to the community! If you are not familiar with the Bridge Identity platform, please read What is the Bridge Identity Platform? to learn more.

What’s new in version 3.1?

This release takes Bridge Identity to yet another level with increased access to BRDG token and liquidity, and offers mobile support to let users use their Bridge Identity with their mobile device in both the online and physical worlds.

More Ways to Acquire Bridge Token

We’ve expanded access to the Bridge Token (BRDG) across multiple decentralized exchanges and liquidity providers on both Ethereum and Neo blockchain networks. Bridge Token (BRDG) now has pairs on Switcheo and Uniswap.

Users can even acquire directly using ETH from the blockchain wallet in the Bridge Passport Browser Extension when using Uniswap.

Bridge Passport Mobile

Bridge Passport Mobile for Android is available with this release. Users can import their Bridge Passport and all related claims to their mobile device to enable them to use their digital identity on the go.

Bug Fixes

All outstanding bugs to date in the Bridge Passport Browser Extension are resolved in this release.

To learn more or view documentation and source code to get started with Bridge Identity, visit the links below:

What is the Bridge Identity Platform?

Website

GitHub

To keep up to date with the latest updates and announcements, become part of the community and follow Bridge Protocol on our social platforms:

Telegram

Twitter

Reddit

Facebook

Bridge Identity Platform 3.1 with Mobile Support Released was originally published in BridgeProtocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are excited to release Bridge Identity 3.0 Beta to the community! If you are not familiar with the Bridge Identity platform, please read What is the Bridge Identity Platform? to learn more.

What’s new in version 3.0?

This release takes Bridge Identity to the next level with substantial updates that will offer easier application integration, increased blockchain support, and an improved user experience.

Cross-Chain Bridge Token and Smart Contract Support

A major feature of this release is the support for both the NEO and Ethereum blockchain networks. Bridge Token and Bridge Identity are fully implemented and supported on both chains.

The token was initially created in 2018 on NEO as a NEP-5 token, but with this release, the token is now also on the Ethereum blockchain as an ERC-20 token. The cross-chain token can swapped easily between chains using the Bridge Passport Browser Extension. The cross-chain token and smart contract support enables ecosystem projects on either chain to take full advantage of Bridge Token payments and on-chain Bridge Identity in their applications.

Updated Bridge Network Explorer

The Bridge Network Explorer was redesigned and extended to handle the expanded functionality of the Bridge Network. Alongside an updated user interface and mobile fixes, the explorer now also monitors and displays the distribution of the Bridge Token across both the NEO and Ethereum networks.

Redesigned Passport Browser Extension

The Bridge Passport Browser Extension user interface was redesigned from the ground-up with usability and extensibility in mind. In addition to the redesign, the interface was also rewritten to implement the Vue.js framework for a more robust user experience, while also enabling the extension to be easily maintained and extended with new functionality in the future.

Restructured Core SDK and Integration Components

The Bridge Protocol Software Development Kit and integration components were restructured to make integration with Bridge Protocol and Bridge Network simpler. We have improved the structure, added more tests, and added more sample code to make it simple for developers to integrate the platform into their applications.

Serverless Bridge Network and Marketplace Infrastructure

We’ve made substantial upgrades to the underlying Bridge Network and Bridge Marketplace infrastructure to enhance performance and offer a more cost-effective and resilient network by leveraging serverless technology.

To learn more or view documentation and source code to get started with Bridge Identity, visit the links below:

What is the Bridge Identity Platform?

Documentation Site

GitHub

To keep up to date with the latest updates and announcements, become part of the community and follow Bridge Protocol on our social platforms:

Telegram

Twitter

Reddit

Facebook

Bridge Identity Platform 3.0 Released was originally published in BridgeProtocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bridge Identity is a unique approach to sovereign digital identity that can be applied to a wide range of applications and environments, making it ideal for securely managing and transmitting digital identity. In this article, we will look at an overview of the components that make up the platform and how it can be used.

The Bridge Protocol is at the core of the solution, which is simply a peer-to-peer protocol that allows for the secure transmission of portable digital identity. It enables individuals, applications, and devices to send and receive digital identity claims in both on and offline environments. The ability to request and transmit identity in an offline environment opens the potential for real-world applications by removing dependency on Internet connectivity and unpredictable blockchain networks at the point of identity verification. The protocol can easily be implemented in web and mobile applications, blockchain distributed applications, and even in hardware devices.

Components of the Bridge Identity Platform

The platform is made up of several components that allow for a robust, secure, and fully integrated sovereign digital identity solution.

Bridge Passport

The passport is the container for an individual’s sovereign digital identity. A user’s passport will contain their Bridge Identity cryptographic keys, their NEO and Ethereum wallets and cryptographic keys for on-chain transactions, and their verified information about their identity in the form of secure, portable claims.

Bridge Network

The Bridge Network is a public network that can facilitate communication between Bridge identities as well as provide an optional layer of trust when Bridge identities interact with one another. The Bridge Network maintains a record of known Bridge Network partner identities that have been verified as trusted organizations, as well a record of any blacklisted identities to remove bad actors from the network.

Bridge Marketplace

The Bridge Marketplace is a part of the Bridge Network that provides a marketplace that connect individuals with marketplace partners that provide services to verify their personal information and build their digital identity in exchange for Bridge Tokens.

A key aspect of the Bridge Marketplace is that it keeps decentralization in mind, as it only serves to connect users with Bridge Marketplace partners. Once the user selects a marketplace partner and sends the appropriate network fees, the user is directed to the partner to complete the identity verification process.

Any payments, personal information, or identity claims are transmitted directly between the user and marketplace partner. The network does not collect or maintain any personal information about the user aside from facilitating the initial request for service between the user and partner.

Bridge Passport Browser Extension

The Bridge Passport Browser Extension is the official software client that provides a user interface to manage Bridge Identity and connect to the Bridge Network. The extension enables end users to create, verify, and use their digital identity in both web and blockchain based applications.

Using the extension, users are able to:

• Interact with marketplace partners to purchase verification services
• Build their digital identity by importing verified information
• Provide their identity to browser-based applications that implement the Bridge Protocol
• Manage NEO and Ethereum blockchain wallets to send token payments and swap tokens cross-chain
• Publish their digital identity to the NEO and Ethereum blockchain networks for use with decentralized applications

Bridge Token and Smart Contracts

The fees for services on the Bridge Network and Bridge Marketplace are paid using the Bridge Token (BRDG). The Bridge Token was initially created and launched on the NEO blockchain in 2018. As of the 3.0 release, the Bridge Token is now not only available on NEO as a NEP-5 token, but also on the Ethereum blockchain as an ERC-20 token. The token can be easily be swapped between the chains using the Bridge Passport Browser Extension.

Bridge Smart Contracts are also deployed on both the NEO and Ethereum networks to allow Bridge Identity to be published on the blockchain. The cross-chain token and smart contracts are a huge step forward as they expand the use of the Bridge Token and Bridge Identity to projects on either network.

Using Bridge Identity in Real-World Applications

Browser-Based Applications

Any browser-based application can implement the Bridge Protocol to verify a user’s digital identity. Identity claims can be transmitted securely between the Bridge Passport Browser Extension and the requesting application.

Since the Bridge Network only serves as an optional point of trust in the decentralized solution, registration by the site implementing the protocol is not required. However, it is highly recommended that all organizations and applications implementing the protocol register with the network so they can provide an additional level of trust for ecosystem identities they interact with.

Blockchain Distributed Applications

Bridge identity can be optionally published to the NEO and Ethereum blockchain networks to provide asynchronous on-chain identity verification to ecosystem projects on either network.

Blockchain distributed applications can simply interact directly with the Bridge Smart Contract to verify identity without interacting directly with the user in real-time.

Disconnected and Hardware Applications

It is even possible to implement the Bridge Protocol in real-world applications without any online connectivity. The protocol can be implemented in mobile or hardware applications to securely transmit digital identity directly without relying on a synchronized and available blockchain node or Internet connectivity.

If connectivity is available, the participants can use the Bridge Network as a an additional point of trust to verify blacklisting, but it is not required to transmit and verify the secure identity claims.

To view documentation and source code to get started with Bridge Identity, visit the links below:

Documentation

GitHub

To keep up to date with the latest updates and announcements, become part of the community and follow Bridge Protocol on our social platforms:

Telegram

Twitter

Reddit

Facebook

What is the Bridge Identity Platform? was originally published in BridgeProtocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

Before I joined the Bridge Protocol team, I was heavily focused on digital asset management and e-commerce solutions leveraging blockchain technology. In pursuing these avenues, I quickly noticed that one area of concern was not only the representation of the asset, but also the representation of the individual. Just like in the real world when dealing with assets and verification, identity and trust is the foundation that all transactions and ownership are built on.

With this in mind, it has helped us develop a platform that will build a truly unique system of creating, managing, and verifying digital identity for individuals on the blockchain that is unlike any concept to date. We believe that digital identity is applicable to everyone in the new economy, and with that comes the responsibility to ensure that the identity and personal data of every individual is protected while still providing robust utility and regulatory compliance.

The Bridge ID platform is designed to be a public API that will enable the development of robust identity driven solutions. The platform will be available to any application developer to enable them to build apps and system integrations that will take full advantage of the platform to create, manage, and verify digital identity on the blockchain. With nothing more than an address on the blockchain, users will be able to manage their digital identities and provide proof of eligibility anonymously in situations where today they would be obligated to provide sensitive information that could lead to identity theft and other malicious behavior by bad actors.

The Bridge team is working around the clock to ensure that we are building the next evolution of online identity that will address current issues such as: GDPR compliance, KYC compliance for ICO’s and financial exchanges, and all of the other inevitable regulations coming our way in response to the recent violations in privacy and data security.

Stay tuned — I am confident Bridge Protocol is going to change the way you create, manage, and think about your digital identity.

The Bridge ID platform will transform how you manage and protect your digital identity was originally published in BridgeProtocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

Create a Microsoft Azure Account

Go create a an account at https://azure.microsoft.com to get started.

Note: Azure is currently offering free trial accounts for 30 days with a $200 spend limit: https://azure.microsoft.com/en-us/offers/ms-azr-0044p/.

Create a Virtual Machine

You could also create a Windows based VM, but the cost is higher and unnecessary for running the docker image. So for this example, we will create an Ubuntu Server 16.04 VM.

Choose to Install a VM Running Ubuntu Server 16.04
1. Click on All Resources or Virtual Machines from the left pane
2. Click +Add at the top
3. Choose to install Ubuntu Server 16.04 VM from the Azure Marketplace

Creating a SSH Key
If you don’t already have a SSH key, this is far more secure than a password for multiple purposes(Git, FTP, SSH, etc).

If you don’t know how to create a SSH key, read here:
https://docs.microsoft.com/en-us/azure/virtual-machines/linux/create-ssh-keys-detailed

If you are going to use PuTTY to connect, it’s a little different:
https://www.digitalocean.com/community/tutorials/how-to-create-ssh-keys-with-putty-to-connect-to-a-vps

Set the Basics for your new VM
Set the name, disk type, whether you want to SSH with a public key or use a password (SSH key is the preferred method as it’s more secure, but for a privatenet a password is probably okay), the resource group this VM will run under (for billing), and finally the location of the datacenter this VM will be running from.

Select the size of the VM you want to install
There are a variety of configurations you will be able to install. A smaller VM than the recommended options will do (click “View All” to see more options). A B2S should be more than sufficient - if not, you can always scale it up later.

Set the firewall rules to allow incoming RPC traffic
We can do this in the VM settings, Network Sescurity Group (firewall), and create a new group for our VM.

Allow Inbound Requests for NEO Privatenet RPC
After we create the group, we need to add an inbound rule to allow requests coming in on ports 20332–20336, 30332–30336

Review and Create
Review the settings summary of the VM, and click to Create.

Connecting to the Virtual Machine

Get the IP or Domain Name to access the Virtual Machine
Watch your notifications and VM list to check on the status of your VM deployment. Once it is running, choose it from the menu to see the details and find the IP of your created VM. Optionally you can access this VM by a Domain Name as well, but you will need to configure this manually.

Create a Fully Qualified Domain Name (optional)
If you want to use a Domain Name to access the privatenet instead of just the IP, you can easily configure one by going to the Public IP Address configuration for your VM and defining the Domain Name to use.

SSH to the Virtual Machine
You will need a SSH Client. On Linux and OSX, SSH usually comes as a standard installed package from the command line, on Windows you can download and install PuTTY from: https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

Once you have a SSH client installed, SSH to the IP or FQDN of the Virtual Machine you just created.

Configure the Virtual Machine

Once you have successfully logged into your VM via SSH, you will need to install the docker image for the NEO Private net. If you have any issues with these quick install instructions, full installation instructions for docker can be found here.

Installing Docker

> curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
> sudo add-apt-repository “deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable”
> sudo apt-get update
> apt-cache policy docker-ce

Verify Docker is Installed and Running

> sudo systemctl status docker

Installing the Docker Image

Now, we need to install the neo-privatenet image to create 4 NEO Nodes that comes with a wallet pre-loaded with a ton of NEO and GAS. If you leave this image running, over time you will claim even more GAS.

Installing the Privatenet Docker Image

To install the image, we simply need to pull the image, and then start the privatenet.

> docker pull cityofzion/neo-privatenet
> docker run — rm -d — name neo-privatenet -p 20333–20336:20333–20336/tcp -p 30333–30336:30333–30336/tcp cityofzion/neo-privatenet

As always, huge credit to Chris Hager for creating this image.

Opening the Wallet Containing the Privatenet NEO / GAS

There is a wallet that is already loaded with tons of NEO / GAS on the privatenet. The details on loading this wallet can be found in the neo-privatenet instructions, however since we are running a non-localhost instance of the privatenet, we need to first make sure we change our configuration to connect neo-gui or neo-python to the correct host before running the respective client (default for privatenet settings currently assume localhost to be the host for a privatenet connection).

Connecting clients to the hosted privatenet
To modify the configuration to point to the hosted privatenet permanently, we need to modify our protocol.json files to change the default of localhost.

Configuration changes:
Open protocol.json and change localhost/127.0.0.1 to the IP or FQDN of the hosted privatenet, example:

…
“SeedList”: [
“<Your IP or FQDN>:20333”,
“<Your IP or FQDN>:20334”,
“<Your IP or FQDN>:20335”,
“<Your IP or FQDN>:20336”
],
“RPCList”:[
“<Your IP or FQDN>:20332”
],
…

File location(s):
Neo-gui: <neo-gui installation path>/protocol.json
Neo-python: <neo-python installation path>/neo/data/protocol.json

Once the configuration is updated, we’re ready to launch the client and connect to the hosted privatenet.

Note: an additional option neo-python gives us is a command line switch, so we do not have to permanently modify our configuration. To run with the command line switch to connect to the host, simply execute:

> np-prompt -p <your host IP or FQDN>

Manually Distributing NEO / GAS to Other Users (if needed)

To distribute NEO or GAS to other users / wallets, use neo-gui or neo-python to load the privatenet wallet as described above, and transfer tokens to the other wallets.

NEO / GAS Faucet for your Privatenet (update forthcoming)

If you are using the privatenet in a team or classroom setting, it is highly beneficial to have a faucet to allow users to request GAS / NEO for testing to auto-deploy to their wallet so you don’t have to manually transfer the tokens.

If you need a faucet before then, check out the neo-faucet project to set up and host a faucet for the privatenet. The same protocol.json changes will be required there to connect to the hosted privnet as outlined above for the neo-gui and neo-python clients.

Note: There are plans to include a faucet in the neo-privatenet docker image in the near future, so if you don’t need a faucet immediately, it could make sense to wait on that update.

Need additional help?

City of Zion
If you need further assistance in getting started, feel free to join the City of Zion NEO Smart Economy Discord Server. The community will help you get set up in no time.

Getting NEO/GAS is relatively simple, however it can be confusing at first not only to know which network you should be testing on, but also then how to receive funds to test on that given network. This short article will give you a 10 minute crash-course in getting the funds you need on the appropriate network to test your smart contracts and dApps.

Available Test Networks

There are multiple environments that can be used to test while developing for the NEO Blockchain. Each network has a different amount of traffic, and a different level of testing it should be used for. When starting out, it’s hard to know which network to use. It’s really pretty simple and comes down to the scope and how much testing you’ve done on your Smart Contract or dApp.

Privnet (or Private Network)

The privnet is your own private NEO blockchain you can run on your computer and have total control over.

This is the easiest and fastest place to get rolling with testing, here you run your own docker image and you can simply reset the image and essentially have an unlimited supply of GAS and NEO to test your application (okay, well not unlimited, but enough to do whatever it is you need to do for sure). Chris Hager has done an excellent job setting this up and providing detailed instructions here: https://medium.com/proof-of-working/how-to-run-a-private-network-of-the-neo-blockchain-d83004557359

When to use: If you are working on a new project that will need multiple deploys, or if you need to watch all transactions on the blockchain closely, Privnet is the clear choice here. You can do multiple deploys, essentially have unlimited GAS/NEO, and reset it any time you like. Also, this is your own private sandbox, so there are no other transactions going on but your own, so it’s less “noisy”.

City of Zion Testnet

This is a public test network run by the City of Zion open source community.

When to use: Once you are confident your dApp or Smart Contract is working as intended through testing on your Privnet, it’s time to choose a Testnet to deploy to and test in more of a “live” sandbox. On the test networks you will have other users and transactions, and get a better sense of what a live deploy will be like. Given the ease of getting funds, my recommendation is to use the City of Zion Testnet.

NEO Testnet

This is the Testnet of the NEO Smart Economy parent organization.

When to use: The use case for this network is essentially the same for the CoZ Testnet, however the traffic and size is much larger in scope.

Wallets and Addresses to Receive Funds

In order to receive funds, you need to create a wallet and have an address that will hold the funds (and subsequently, this will also be the wallet you would use to send funds in the context of your Smart Contract or dApp). There are a few options when it comes to wallets, but NEO-GUI is the official wallet and client app of NEO, so that’s what I will use in the context of this article. If you are working with other clients such as neo-python, there may be a variety of differences, but the fundamental concepts will still apply.

NEO-GUI requires a full synchronized local copy of the blockchain to process transactions, but you can use NEO-GUI to processs transactions on any of the NEO networks — Privnet, NEO Testnet, CoZ Testnet, and even the NEO Mainnet.

Note: You can use the same wallet file and address on all networks, simply change the underlying configuration. You will be scoped to that address on whatever network you are configured for.

Syncing the Blockchain of theTarget Network

If your blockchain isn’t synchronized to the block level of a transaction (for example, a transaction that sent funds to your address), your balance will not reflect that transaction. In order to see an accurate balance of a wallet or to create transactions using those funds, the blockchain needs to be fully synchronized.

Settings and Changes Needed to Synchronize with a Network

When using NEO-GUI and switching networks, there are a few changes that you need to make to update the configuration (see links to network specific configurations below). Any time you change networks, you need to:

1. Delete /<your-neo-gui-path>/peers.dat
2. Delete the contents of /<your-neo-gui-path>/ChainTestNet/
3. Update /<your-neo-gui-path>/protocol.json
4. Update /<your-neo-gui-path>/config.json

Click the links below to view example configurations for the various networks (these can also be found deployed with NEO-GUI in the root directory as alternatively named .json files whose contents can simply be copied into the primary file):

Privnet: [View]

CoZ Testnet [View]

NEO Testnet [View]

Bootstrapping

Bootstrapping will help you save a ton of time getting your local blockchain synchronized by downloading a snapshot of the blockchain instead of syncing a few blocks at a time using network nodes.

You can always find the latest available bootstrap files for the NEO and CoZ Testnets (and Mainnet as well if needed) here: https://github.com/CityOfZion/awesome-neo

Download the appropriate file for the target network, then unzip the contents to: /<your-neo-gui-path>/ChainTestNet/

Checking Synchronization Progress

You can monitor the synchronization of blocks in NEO-GUI by looking in the bottom left corner.

The number of total blocks will vary by network, but you can find out the block count for a given network by using Neoscan.

Privnet
This synchronization is quick (around 1.2k blocks), so you should be fully synced in a matter of a few minutes.

CoZ Testnet
The CoZ testnet is a bit larger (420k blocks at current), so synchronization for this network really needs to be bootstrapped or you will be waiting quite awhile. You can see the network information here: https://coz.neoscan-testnet.io/

NEO Testnet
Obviously even larger than the CoZ Testnet (1.2mil blocks at current), this definitely requires bootstrapping and has substantially more activity. You can see the network information here: https://neoscan-testnet.io/

Requesting GAS / NEO for Testing

Privnet

You can simply restart your docker image and you’ll be reloaded with all the NEO and GAS you need. You don’t need to make any requests. Just start the docker, configure your wallet for the Privnet, and you should have plenty of GAS and NEO.

CoZ Testnet

City of Zion has set up a convenient faucet to get your NEO and GAS from for the City of Zion Testnet. Simply go to http://faucet.cityofzion.io/ and provide your CoZ Testnet address.

Shortly after, you will have 2000 GAS and 100 NEO (at current) sent to the provided address. You don’t need to do anything else.

NEO Testnet

The fund request from NEO is a bit more cumbersome and takes a bit longer, and seemingly a bit trickier to find (the link to the NEO Testnet NEO/GAS request link is buried in the NEO Test Network documentation). To request NEO / GAS, go to https://neo.org/Testnet/Create and fill out the form to make the request. It takes a little bit (sometimes a few days) to get a response to your request.

Finding your Public Key
Open NEO GUI, Right Click your Address

Retrieving your Funds
NEO will send you an e-mail with instructions on how to retreive your funds (assuming your request was granted).

Create a Multi-Signature Contract Address using NEO-GUI

The e-mail provides us with all the details on how to retreive the funds. You will need to add their public key to the contract, add your public key to the contract (see above), and set the minimum signature number to 1. Once you confirm, a contract address will be created in your wallet:

Sometimes it is necessary to rebuild the index for your wallet to get accurate balances. The way to do this is in the “Wallet” menu:

Once you rebuild, you should see funds in your Contract Address. From there, you can transfer the funds to your own address of your choosing by selecting Transaction -> Transfer, and click the + to add a payment.

Once the transaction is processed, you will have funds in the target address, drawn from the multi-sig contract that contained the funds.

And that’s it. You now should have a fully synchronized wallet with funds available on your target network, and you should be ready to go develop and deploy Smart Contracts and dApps for the NEO Blockchain!

Need additional help?

City of Zion
If you need further assistance in getting started, feel free to join the City of Zion NEO Smart Economy Discord Server. The community will help you get set up in no time.

Create a Microsoft Azure Account

Go create a an account at https://azure.microsoft.com to get started.

Note: Azure is currently offering free trial accounts for 30 days with a $200 spend limit: https://azure.microsoft.com/en-us/offers/ms-azr-0044p/. For around $75 a month, you can put up a single NEO node (every node counts), so with that free account, you could easily run 2 nodes for free for 30 days to help the NEO blockchain.

Create a Virtual Machine

You could also create a Windows based VM, but the cost is substantially higher and unnecessary for running a NEO Node. So for this example, we will create an Ubuntu Server 16.04 VM.

Choose to Install a VM Running Ubuntu Server 16.04
1. Click on All Resources or Virtual Machines from the left pane
2. Click +Add at the top
3. Choose to install Ubuntu Server 16.04 VM from the Azure Marketplace

Creating a SSH Key
If you don’t already have a SSH key, this is far more secure than a password for multiple purposes(Git, FTP, SSH, etc).

If you don’t know how to create a SSH key, read here:
https://docs.microsoft.com/en-us/azure/virtual-machines/linux/create-ssh-keys-detailed

If you are going to use PuTTY to connect, it’s a little different:
https://www.digitalocean.com/community/tutorials/how-to-create-ssh-keys-with-putty-to-connect-to-a-vps

Set the Basics for your new VM
Set the name, disk type, whether you want to SSH with a public key or use a password (SSH key is the preferred method as it’s more secure), the resource group this VM will run under (for billing), and finally the location of the datacenter this VM will be running from.

Select the size of the VM you want to install
There are a variety of configurations you will be able to install, it seems that a D3S_v3 with 2 CPU cores and 8GB ram is the minimum configuration for a NEO Node.

Set the firewall rules to allow incoming RPC traffic
We can do this in the VM settings, Network Sescurity Group (firewall), and create a new group for our VM.

Allow Inbound Requests for NEO RPC
After we create the group, we need to add an inbound rule to allow requests coming in on ports 10331–10334, 20331–20334

Review and Create
Review the settings summary of the VM, and click to Create.

Connecting to the Virtual Machine

Get the IP or Domain Name to access the Virtual Machine
Watch your notifications and VM list to check on the status of your VM deployment. Once it is running, choose it from the menu to see the details and find the IP of your created VM. Optionally you can access this VM by a Domain Name as well, but you will need to configure this manually.

Update: For nodes to be listed on the City of Zion NEO Monitor, you must use a FQDN, IP addresses are no longer allowed.

Create a Fully Qualified Domain Name to your Node
If you want to use a Domain Name to access the node instead of just the IP, you can easily configure one by going to the Public IP Address configuration for your VM and defining the Domain Name to use.

Note: If you are going to list your node on the CoZ Mainnet NEO Monitor, it is required that you use a FQDN.

If you want to use your own domain name to point to this node instead of the Azure defined FQDN, you can just create a CNAME record in your DNS that points to this FQDN in azure.

So, if you wanted to have neonode1.yourdomain.com, you would simply add a CNAME record like this (interface shown is GoDaddy):

SSH to the Virtual Machine
You will need a SSH Client. On Linux and OSX, SSH usually comes as a standard installed package from the command line, on Windows you can download and install PuTTY from: https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

Once you have a SSH client installed, SSH to the IP or FQDN of the Virtual Machine you just created.

Configure the Virtual Machine

Once you have successfully logged into your VM via SSH, you will need to install the dependencies for neo-cli (leveldb, sqlite, dotnet).

Update: Since .NET Core is static linked from the neo-cli project, you should not need to install the .NET core. If you end up needing it, instructions on installing .NET Core on Ubuntu 16.04 can be found here: https://docs.microsoft.com/en-us/dotnet/core/linux-prerequisites?tabs=netcore2x

Install Prerequisites and neo-cli (version 2.7.3 at current)

> sudo apt-get install unzip libleveldb-dev sqlite3 libsqlite3-dev libunwind8-dev

> wget https://github.com/neo-project/neo-cli/releases/download/v2.7.3/neo-cli-ubuntu.16.04-x64.zip

> unzip neo-cli-ubuntu.16.04-x64.zip

Bootstrap your Node

It can take a long time to sync the entire mainnet blockchain, but you can download a bootstrap zip that will considerably decrease your sync time by downloading the blockchain files directly instead of trying to sync them actively from other nodes (this will also reduce load from the network). Always check here for the latest available bootstrap files
https://github.com/CityOfZion/awesome-neo

To bootstrap your node, download the latest S3 bootstrap file (latest as of 3/15/18 to accommodate mainnet upgrades):

> wget https://s3.eu-west-2.amazonaws.com/ashant-neo/chain.acc.zip

And unzip the contents to your neo-cli folder

> unzip chain.acc.zip -d ./neo-cli/

Start the Node and Confirm it is Running

To start neo-cli:

> cd neo-cli
> dotnet neo-cli.dll /rpc

After you see the neo> prompt, send a HTTP POST request to the node you just created from your client machine to make sure the node is running and that your firewall is set up correctly to receive inbound requests. You can simply use curl to send HTTP requests to your running node:

> curl -X POST \
http://<IP of your node>:<RPC port of your node>\
-H ‘Content-Type: application/json’ \
-d ‘{ “jsonrpc”: “2.0”, “id”: 5, “method”: “getversion”, “params”: [] }’

On OSX or Linux, curl should be installed, but on you can either simply install curl for Windows here, or you could also run a light instance of Ubuntu on Windows as outlined in the “Installing the Windows Subsystem for Linux” section in this article.

Another nice option is using the Advanced REST Client Chrome Extension for testing HTTP requests:

If your node is running, you should receive a return value that contains something like this:

{
“jsonrpc”: “2.0”,
“id”: 5,
“result”: {
“port”: 10333,
“nonce”: 1215806116,
“useragent”: “/NEO:2.7.1/”}
}

It will take a little bit for the remaining blocks to sync even though we bootstrapped, you can check the status of the node by using the commands “show state” and “show node”.

Now that we know the node works, we’ve got to exit and make sure it can restart itself and run after we leave the SSH session.

Type “exit” to shut the node down.

Install a Supervisor

You also need to makes sure that the process keeps running if you close the SSH window or if there is an unexpected system reboot. The correct way to do this is to use a supervisor, we are going to systemd that is standard with Ubuntu:

First we need to create the service config file and edit it:

> cd /etc/systemd/system
> sudo vi neoseed.service

The contents of your config file should be something like this:

(thanks to @metachris for helping in getting the systemd config files together and sharing his configuration)

[Unit]
After=network-online.target
Requires=network-online.target

[Service]
WorkingDirectory=/home/<your_username>/neo-cli
ExecStart=/usr/bin/dotnet neo-cli.dll /rpc
ExecStop=kill -SIGINT `ps ax | grep neo-cli | grep -v grep | awk ‘{print $1}’`
Restart=always
StandardInput=tty-force
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=neoseed
User=<your_username>
Group=<your_username>

[Install]
WantedBy=multi-user.target

When done editing, Hit ESC to go to command mode, and type :x to save.

Now we need to enable the service

> sudo systemctl enable neoseed
> sudo systemctl start neoseed

And let’s make sure it started successfully

> systemctl status neoseed

(For future reference) the commands to manage nanoseed are:
> systemctl status neoseed
> sudo systemctl start neoseed
> sudo systemctl stop neoseed

Register the Node to the Network Status Monitor

City of Zion has a nice network monitoring web interface that will monitor all of the seed nodes that are reported. Once you have confirmed that your node is running, report it to the network status monitor via the neo-mon project.

Note: CoZ wants to guarantee that any seed node listed on the NEO Monitor page are not attackers. All seed nodes wishing to be included must be a part of a project, and need to gain prior approval from CoZ in order to to be listed.

To report your running node(s):

1. Fork and clone the neo-mon project
2. Edit the mainnet node list:

<your neo-mon checkout folder>/src/assets/json/mainnet.json

1. Add your node to the array of nodes in the following format:

{
“protocol”: “http”,
“url”: “<IP or FQDN of your Node>”,
“location”: “USA”,
“locale”: “us”,
“port”: “<RPC port of your node>”,
“type”: “RPC”
}

1. Commit your changes to your forked repo master
2. Create a pull request to the https://github.com/CityOfZion/neo-mon project for your changes.

And that’s it! You are now running a full NEO Node running on Microsoft Azure, and helping the NEO Smart Economy get stronger!

Need additional help?

City of Zion
If you need further assistance in getting started, feel free to join the City of Zion NEO Smart Economy Discord Server. The community will help you get set up in no time.

This post will provide you with a step-by-step guide to running a neo-python node on Windows 10 using the Microsoft Windows Subsystem for Linux, but will also show you how you can attach Visual Studio Code to do interactive debugging.

A few notes before we get started:
This article includes instructions on the installation of the Windows Subsystem for Linux for users running Windows 10 Fall Creators Update (build 16215) or later. If you are running an older version, it may still be possible to install using lxrun (more info can be found here).

Chris Hager of City of Zion has done an excellent job of outlining How to run a private network of the NEO Blockchain using neo-python and neo-privatenet-docker. These instructions are the basis for a good portion of the configuration in this article, so it would be helpful to be familiar with them.

Setting Up the Windows 10 for Python Development

Install Python 3.6.3

https://www.python.org/downloads/release/python-363/

Note: Be sure to check the box on the installer to “Add Python 3.6 to PATH”

Install Git

https://git-scm.com/download/win

Install Visual Studio Code

https://code.visualstudio.com/download

Verify your Environment Variables / PATH include Python and Pip

Now that Python is installed, we still need to make sure that we have all the proper definitions in our PATH so we can access the scripts and executables we will need to build and run python applications.

To check your system PATH variables:

- Go to your Start Menu
- Type “Environment Variables”
- Choose “Edit the system environment variables”
- Go to the Advanced Tab and choose Environment Variables
- Select Path and Edit

You should have the following paths defined to allow you to use Python and Pip (if not, add them):

C:\<your_python_install_path>\Python36
C:\<your_python_install_path>\Python36\Scripts

Installing the Windows Subsystem for Linux (WSL)

For this article, we will be running Ubuntu on the Windows Subsystem for Linux to host neo-python.

Enable the Windows Subsystem for Linux (WSL)

- Go to theControl Panel
- Select Programs and Features
- Click the link to Turn Windows Features on or off
- Enable “Check Windows Subsystem for Linux” and Save (reboot if necessary)

Install Ubuntu from the Microsoft Store

https://www.microsoft.com/store/productId/9NBLGGH4MSV6

Setting up neo-python source code in Windows

Download Source with Git and Create Debug Copy on Windows

C:\> git clone https://github.com/CityOfZion/neo-python.git c:/<your_folder_path>/neo-python

Make a copy of the downloaded code for debugging

C:\> robocopy c:\<your_folder_path>\neo-python c:\<your_folder_path\neo-python-debug /s

The fun part about the WSL is that these paths we are working with from the Windows Environment are also available and mounted in the Ubuntu environment we just installed.

To see the code you just checked out in Windows when in Ubuntu (once running), simply go to the following paths:

>/mnt/c/<your_folder_path>/neo-python
>/mnt/c/<your_folder_path>/neo-python-debug

Configuring Ubuntu installed in WSL

As I mentioned before, these instructions have been outlined in detail. These instructions will get you running neo-python on Ubuntu, but there are a few minor changes we need to make to make this easier for debugging on Windows.

Set up Your Account

Launch Ubuntu from Windows and Create Account when Prompted

Configure and Install neo-python

Configure and install neo-python as outlined in the instructions here. Be sure not to use the docker image method, and configure / setup the copy of the code you checked out previously in Windows located at:

>/mnt/c/<your_folder_path>/neo-python

Once you have neo-python running on Ubuntu successfully, you can proceed to enable remote debugging.

Setting Up to Debug from VSCode on Windows

Open Source Code Folder in VS Code

- Go to the top File Menu
- Select Open Folder
- Browse to C:\<your_folder_path>\
- Select folder \neo-python

Select the file that you want to debug from folders that just opened

ie: C:\<your_folder_path>\neo-python\<file_to_debug>

Select Debug Version of the File you want to debug

- Go to the top File Menu
- Select Open File
- Browse to C:\<your_folder_path>\neo-python-debug\
- Select <file_to_debug>

Add Debug Server Code to Both Files

Both pieces of code have to match for the debugger to work properly. The “posix” OS identifier lets us know to only start the debugging server on Ubuntu.

At the top of both source files, include the following:

import os
if os.name == “posix”:
import ptvsd

ptvsd.enable_attach(“uniquecodeforsecurity”, address = (‘127.0.0.1’, 3000))
print(“Waiting for debugger to attach…”)
ptvsd.wait_for_attach()
ptvsd.break_into_debugger()

This lets the executing code know that if we’re running on Ubuntu, to start a debugging server/listener on port 3000 (since we are on WSL it’s all localhost so we don’t have to mess with firewalls and ports), and wait for a debug request to come in.

Add the Python Remote Debug Configuration to VS Code

- Open the Debug Tab
- Click the Settings Wheel
- Add the Remote Debug Configuration to launch.json in the Configurations array

{“name”: “Attach (Remote Debug)”,
“type”: “python”,
“request”: “attach”,
“localRoot”: “${workspaceFolder}”,
“remoteRoot”: “/mnt/c/<your_folder_path>/neo-python-debug”,
“port”: 3000,
“secret”: “uniquecodeforsecurity”,
“host”: “127.0.0.1”},

Start Debugging

Finally! There were a lot of steps here, but now we can finally run our code in a full Ubuntu environment giving us full dependency support for neo-python. Now the rest is simple, we just need to fire up the code!

Start the Program on Ubuntu WSL

> python3 ./mnt/c/<your_folder_path>/neo-python-debug/<file_to_debug>

Go to VS Code and Start Debugging on Windows

- Focus the non-debug source file (ie: neo-python/<file_to_debug>)
- Select the debug tab
- Select the profile we created earlier “Attach (Remote Debug)” from dropdown
- Start debugging

And that’s it! You should be up and running your neo-python node in Ubuntu while debugging in Visual Studio Code on Windows.

Need additional help?

The technique we used here to enable a remote debugging session across Windows and WSL can also be used with remote servers. I guarantee once you start working with remote debugging, you will find it a handy tool for those times where “it works on your machine”, but something entirely different is happening on a test or production environment.

City of Zion
If you need further assistance in getting started, feel free to join the City of Zion NEO Smart Economy Discord Server. The community will help you get set up and debugging your smart contracts in no time.