Behind Satoshi Nakamoto’s creation of Bitcoin lies a simple, core belief: that financial transactions in a digital world can be peer-to-peer. To that end, certain projects have looked to extend blockchain technology to a variety of services including content curation, digital advertising/marketing, and social media/content platforms. Gifto is tackling all three of these areas with its digital gift service. Using Gifto, consumers will be able to pay creators for their content with virtual gifts, which can be bought and exchanged for Gifto tokens on the service’s platform. Though all this may sound silly, it actually offers a peer-driven solution to the inequitable revenue sharing model that digital advertising creates. If you’re still not convinced, keep reading – we go over the specifics in detail below.
Say Hello to Gifto
Simply put, Gifto is a decentralized protocol built on Ethereum that allows users to exchange virtual gifts through digital/social media platforms.
It’s the brainchild of CEO Andy Tian and his company, Asia Innovation Group. A former employee of Google, Andy ran Google’s mobile development in China, introducing Android to Chinese markets. Afterward, he went on to found a number of startups, the latest of which is AIG.
In essence, Tian positions Gifto as an improvement on the virtual gift-giving mechanism of Uplive, AIG’s flagship product. Launched in 2016, Uplive is a live streaming service that allows users to broadcast or watch real-time videos on their smartphones. In China alone, live streaming was a roughly US$5 billion industry in 2017.
And Uplive has played its part in this budding virtual sector. It’s currently available in over 100 countries, with an active user base of more than 20 million individuals. According to the South China Morning Post, Uplive was recording US$5-10 million in revenue per month going into 2017. Users don’t have to pay for the service, so where does this revenue come from, you might ask?
Virtual gifts. No, I’m not kidding. With Uplive, viewers can reward content creators with virtual gifts that they purchase on the streaming service’s marketplace. The platform processes upwards of 25 million virtual gifts a month, and these gifts’ values range anywhere from US$0.30 to US$148. Some broadcasters even report monthly earnings of US$50,000 for their live video streams.
That’s some serious dosh, and Tian wants to take this concept and put it on Ethereum’s blockchain with Gifto.
You might be asking yourself why anyone would pay money for a virtual gift, or how this could drive a US$5 billion industry. Well, people are willing to pay US$100,000 for eBits, so clearly the internet is full of niches that people can (and will) fill.
But on a more serious note, virtual gifts actually solve a problem in the digital advertising space. Consumers have grown used to sponsored ads on YouTube and Facebook that generate revenue per views, and they likely don’t think twice about these nuisances (especially if they have ad blockers enabled). Well, YouTubers don’t actually see much of that profit at all, as the majority of revenue goes straight to YouTube or the digital advertising firms that publish the ads.
Virtual gifts eschew this model entirely and place purchasing power back into the hands of individuals. Consumers can reward content they like with virtual gifts, and broadcasters can profit from these gifts by selling them back through Uplive. Disregard the fact that these virtual gifts are glorified emojis with a price tag – that’s beside the point. They’re the vehicle by which consumers and producers can drive and fund their own entertainment economy, without sacrificing the lion’s share of their revenue to a third party entity.
But Why Gifto?
Gifto takes Uplive’s virtual gift model to the blockchain, making the process more secure, transparent, and adaptable. Tian wants to use Ethereum-powered smart contracts to streamline the virtual gifting process.
“By integrating these contracts into the virtual gift itself, a transaction could automatically be executed, allowing for the instant delivery of revenue share to gift creators and producers,” Tian believes.
This will allow broadcasters to accumulate profits directly from viewers, rather than having to go through Uplive, a process that can take up to 30 days according to Tian. Moreover, by using Gifto tokens (GTO), there won’t be any need to process the dozens of fiat currencies that Uplive currently accepts to support the virtual gift marketplace. By using only GTO for purchases, users won’t have to juggle a handful of international currencies, and blockchain-based smart contracts will nullify the risks of fraud and canceled transactions that Uplive has experienced with credit card payments in the past.
Finally, Tian envisions a future where Gifto can be integrated with multiple social media/entertainment applications.
“The Gifto protocol will be available to any content creator on virtually any platform, including YouTube, Facebook and Instagram,” he said. “For the first time ever, content creators on these platforms won’t be constrained to the advertising-only model that generates very little revenue for the creators without millions of followers. Now, anyone will be able to accept virtual gifts through the Gifto platform and generate meaningful income from their content, directly from their fanbase.”
This means that, in the future, consumers will be able to award content creators in virtual gifts on a variety of networks. Creators can then sell these gifts on the Gifto platform’s marketplace in exchange for GTO, which they can then liquidate for fiat if they so choose. Additionally, virtual gift designers can list their creations on the marketplace at their own price.
A Concluding Take
So when you add up the logistics of Gifto’s model, you have content creators, consumers, and curators all fueling the digital entertainment/media industry using this platform. In effect, this ecosystem will ensure a more equitable payout to content producers for their services, cutting out the middlemen that the digital advertising model has created. Consumers can direct funds to their favorite producers, allowing them to contribute to their success in ways that current models don’t allow.
Even if you think the concept of virtual gifts is silly, value is in the eye of the beholder (just look at CryptoKitties). Looking at the bigger picture, Gifto is providing solutions that can help democratize the arguably broken revenue model that drives digital media. If Gifto ends up integrating with networks outside of Uplive, who knows? You might be tipping that crypto-trader you follow on Twitter in a digital Lamborghini one day for their investment advice.
SONM – Supercomputer Organized by Mining – is one of three main projects competing for a piece of the pie of the distributed cloud computing market, iExec and Golem being the other two. When the team released their MVP it was still unclear what features are exactly available and what the Minimum Viable Product is capable of doing. In this article I will walk through building and utilizing the MVP and will showcase what it is capable of.
Before we get started I would like to give big thanks to Alexander Sigaev from the SONM beta-test telegram, without him this tutorial probably wouldn’t have come along, he provided great support and answers to my questions. If you feel stuck in any way make sure to visit SONM’s beta test telegram linked below as the admins are very helpful.
Without further ado let’s get right to it. We will use an Ubuntu 16.04 digital ocean droplet to run the MVP. I used the $20 / month one but even the cheapest option will do. We will be using Putty to connect to our droplet and set everything up. Let’s begin:
Step 1: Login to your droplet
This should be self explanatory, simply type in the IP of your droplet from digitalocean, set the new password, and you should be all set.
Step 2: update the droplet and download some basic tools (unzip, nginx, docker)
We will need unzip in order to extract our downloaded files and we will need nginx for our SONM wallet. We will also need docker as it is an integral part of SONM and is needed to run tasks. Last but not least, the opencl library is needed for the miner. Run the following commands:
$ sudo apt-get update && apt-get upgrade
$ sudo apt-get install nginx unzip docker.io
$ sudo apt install ocl-icd-opencl-dev
Verify that your nginx installation is working by navigating to http://droplet_ip_address. You should see the default nginx page.
You should see the following directories: cli, hub, node, worker.
From here on, this tutorial will mimic the guides on the official SONM website which you can find here, and here.
Step 4: Set up an ethereum account and get some tokens from the Rinkeby Ethereum testnet
Navigate to the cli folder inside our sonm mvp and run the sonm cli.
$ cd ~/sonm_v0.3.0_linux64/cli
$ ./sonmcli_linux64 login
Since you do not have a keystore file, it will ask you to create one. Set a password for it and the keystore will be automatically generated, you should see your eth address as a response.
Cli also creates a .sonm folder in the home directory, which is where it stores the keystore file that was just created.
For simplicity’s sake I shared the contents of my keystore file, but you should never do that.
Now that we have an eth address we need to fund it with some testnet eth. Specifically we need the Rinkeby testned coins and the easiest way to get some is by using the below dispenser. Simply send a tweet with your eth address, copy paste the tweet url to their website and they will automatically fund it:
Requesting faucet funds into 0x40A1b4FCDF4AFc182c0b63820fBa3789D17414ab on the #Rinkeby#Ethereum test network.
— The Merkle (@themerklenews) eBits
To make sure you have testnet eth on the rinkeby chain, check etherscan. Make sure you go to rinkbey etherscan subdomain: https://rinkeby.etherscan.io/ Type in your address and you should see some ether. If you see your account funded proceed to the next step.
Step 5: Set up your SONM wallet
Now that we have the keystore file we can go back to our web based wallet and add an account. This will help us keep track of our Ether and SNMT tokens.
In order to import a new account you will need a keystore file. Open a text editor on your main machine and copy paste the contents of the file inside ~/.sonm/keystore. Then import that file into the web based wallet.
The password needs to match the same password you used when you ran the sonm cli and generated your eth address. In our case we used the password “123”. After all is done you should see the following page and the eth address should match the one generated earlier.
As you can see we have 3 Ether but no SNMT, we need to fix that. Go back to the terminal and navigate to the cli folder. Use the following command to get more tokens:
$ ./sonmcli_linux64 get
It should return the following:
Navigate back to our SONM wallet and you should see that you now have 100 SNMT and a bit less Ether:
Now that we have both ether and SNMT we are ready to configure the MVP.
Step 6: Configuring and running the Node
We are going to start with the node. A SONM client node interacts with the marketplace, it handles automatic processes such as setting bids, matching deals, and running tasks. The node is the first part that should be configured.
Navigate to the node folder and open the node.yaml file (the configuration file).
$ cd ~/sonm_v0.3.0_linux64/node
$ vim node.yaml
The only fields you need to edit are key_store and pass_phrase, which are under the ethereum block.
Since the default key_store value is /home/sonm/keys, let’s just create the same directory path and put our keystore file in there.
NOTE: Keep in mind the name of your keystore file will be different.
Go back to the node folder and edit the node.yaml file once again, for the pass_phrase field just edit in the password you used to create your eth wallet, in our case “123”
Node that our node.yaml file is correctly configured, start up the node.
If everything goes right you should see the below output:
Step 7: Configuring and running the CLI
Next we are going to configure the CLI. Make sure to leave the node running, start up a new instance of putty, log into the droplet once more, and navigate to the cli folder:
Similar to the previous step we are going to edit the cli.yaml file and add in our passphrase (123). The key_store value stays the same as we have already made the correct path to the keystore file.
Slight change in this step is we are going to move the cli.yaml file to our hidden sonm directory that was created for us the first time we rean sonmcli. Assuming you are in the ~/sonm_v0.3.0_linux64/cli directory:
$ cp cli.yaml ~/.sonm/
$ rm cli.yaml
Finally, test the command line interface by typing in the login command:
$ ./sonmcli_linux64 login
The response should be the following:
While we are here, we are also going to set an allowance cap for the client to pay for resources:
We are done with the cli for now. At this point you should have 2 putty instances running, one of them should be running the node, and the other is the one we are working with. Start up yet another instance of putty because this time we will be editing the hub.
Step 8: Configuring the Hub
Setting up the hub node is very similar to the previous two. Simply navigate to the hub directory and edit the hub.yaml file.
$ cd ~/sonm_v0.3.0_linux64/hub
$ vim hub.yaml
Edit in the pass_phrase and save the file.
Start the hub:
If everything goes well you should get the following response:
Leave the hub running. As of now you should have 3 terminals open. The node, the hub, and the cli.
Step 9: Configuring the Worker
Open a new putty instance and navigate to the worker directory. Same as in the previous steps, edit the worker.yaml file.
$ cd ~/sonm_v0.3.0_linux64/worker
$ vim worker.yaml
Modify the endpoint value. Where it shows <HubEthAddr> replace it with the ethereum address you first generated and funded. Also don’t forget to edit the pass_phrase towards the bottom of the file.
Save the file and run the worker.
If you get the following response you are on the right track:
You are now done setting up the MVP. You should have the hub, the node, and the worker running.
To verify you have a worker running use the cli to get a list of workers.
$ cd ~/sonm_v0.3.0_linux64/cli
$ ./sonmcli_linux64 hub worker list
If you have a worker available it should be showing as Idle.
Interacting with the market
At this point you are officially done with the setting up and configuration part of the SONM MVP. We will not show you how to interact with the market.
The way SONM works, is you can place a BID and an ASK order just like on an exchange. The bid order is a request for a certain amount of computer resources, and it has a price associated with it in the form of SNMT. An ask order comes from the supplier’s side and offers a certain amount of resources for a price.
The consumer’s node will automatically execute any bid and ask orders if the price and the resources match as long as both the supplier’s and the client’s hubs are online.
Let’s create a market bid order. First, we need to create a file specifying the resource requirements. Create a file called bid_slot.yaml in the cli directory.
If you keep refreshing with the market processing command, eventually you will see the contract will change from processing to dealing to done. Congratulations, you just purchase 1 hour of 512mb ram, 1gb storage, 100mb network traffic and a cpu core. You can now view the accepted deal ID under the deals command.
$ ./sonmcli_linx64 deals list
To assign tasks to these rented resources, we need another configuration file. Call this one task.yaml
# image name to start, requriedname: nginx:latestresources:
# number of CPU cores required by task, required paramCPU: 1# amount of memory required by task, required param# You may use Kb, Mb and Gb suffixesRAM: 20Mb
Save it in the cli folder.
Run the task by assigning it to the contract by the deal ID, in my case it was 1146.
$ ./sonmcli_linux64 tasks start 1146 task.yaml
It should return the following:
You can test it by going to the first endpoint. 22.214.171.124:32768 shows the nginx welcome page.
We are currently using our own resources but through the SONM platform. If there is nobody else on the testnet it is unlikely your bid orders will execute. For this example I’ve set up two droplets so we can try using another supplier’s resources.
I’ve created an ask order on the second droplet for the price of 14. We can check for active orders using the market search command
We set the limit to the amount of orders to view to a high number so we can see all the ask orders with our parameters, at the time of writing there were only 268 orders on the market. Since we set the price of 14, you should see the order in the list.
To become the consumer for the order we need to create a bid order. We will also specify the other node’s hub eth address so the orders can be matched up manually instead of waiting for the locator to match them.
In return you should see the deal start executing and dealing. Once the deal is done you can verify the supplier and consumer addresses are different using the deals list command.
Here we can see the deal ID is 1147, it has the price of 14 and the consumer and supplier’s addresses are different. At this point we have successfully rented another node’s resources for an hour, and now we are ready to run some tasks.
In the previous example we ran a simple nginx server, this time we will try to run a wordpress application. Edit the taks.yaml file and change the image name to wordpress:latest.
Save the file, we are now ready to start the task on our 1 hour rented deal.
$ ./sonmcli_linux64 tasks start 1147 task.yaml
If we navigate to one of the endpoints we will see the wordpress welcome page. Go through the set up and fill in the fields for the database that we set up.
What you will notice, is the endpoint’s IP address belongs to the supplier and not the consumer. This clearly shows that we are rendering the page using our supplier’s resources.
This is it for the first part of the tutorial. In the second part I will go over another use case for the SONM MVP. If you have any questions make sure to ask them and I will do my best to get back to you.
Depending on what you want to achieve with your mining rigs you have many options to choose from. In this article I will explain the different ways to mine bitcoins with your GPU mining rigs.
If you are wondering whether you should mine using GPUs or ASICs please refer to THIS ARTICLE for an explanation. In this post I will assume that you have built a working GPU mining rig and know how to the process of mining works.
The first idea to look at when configuring your mining rig is whether you want stable return, or make a bet and have a chance for a larger return in the near future. Depending on the route you go there are different mining techniques for that. Depending on what route you choose you will have different options regarding the mining pools and the mining algorithm that you should choose.
If you are going to go with a stable return then you must immediately convert all your coins that you mined to fiat in order to ensure the stability. That limits you as a miner to mine coins that are already on exchanges. However, the other way to approach mining is similar to gambling. you can go to cryptocointalk and check out the releases for new coins, choose a coin that you believe will enter on an exchange and one that will have some sort of future and mine away. The difficulty will be low and once the coin goes on an exchange (hopefully) you will be able to dump it and make crazy profits.
If you want to go with a more stable return, there are many ways to do that. One of the ways is to mine the Scrypt algorithm on a multipool mining pool. Scrypt is the standard algorithm that most GPU miners use and has quite a lot of hashing power devoted to it. The only problem with Scrypt is that there are ASICs coming out for it. ASIC stands for Application Specific Integrated Circuit. ASICS are cheaper, consume less power, and have way more hashing power then GPUs. As a result, when Scrypt ASICs come out then those miners who still mine Scrypt using their GPUS will take a huge hit in profits. You see the more hashing power a blockchain gets the higher the difficulty rises, so unless you can keep buying more GPUs to match the ASICS there is no point mining an algorithm that already has ASICS for it.
Take for example Bitcoin. The only way to profitably mine bitcoin is to buy a Bitcoin miner. Miners like Antminer or Terraminer are all ASICS which are designed only to mine bitcoin. Mining bitcoin with GPUs or CPUs is obsolete because of the ASICS that overpower the other components. Similarly, if you want to continue making profit with you GPU mining rig you must switch to an algorithm which does not have an ASIC developed for it, and hopefully an algorithm which will never have an ASIC developed for it. Guess what? There is an algorithm like that, and it is called Scrypt-N.
Scrypt-N is an algorithm which modifies itself every couple of years, as a result developing ASICs for it will render useless after a year of mining and it takes way longer than a year to develop a functioning ASIC.
I currently mine vertcoins which use the Scrypt-N algorithm. I believe that Vertcoins are the next litecoin and will dominate the crypto market as the number 3 coin. This is not an article about promoting vertcoin but the only thing I want to say about vertcoin is that unlike other alt coins it has its own miner (vertminer) and as a result it looks very promising. Keep in mind there are other coins based on the Scrypt-N algorithm which are not vertcoin, you could possible mine a newly launched Scrypt-N coin if you believe it will have future and increase in value.
Back to the first idea that I was talking about. Do you want a small stable return or do you want to take a risk and invest and hope that the bitcoin market will go up along with the altcoin market? If you want a stable return then once you configure your miner you need to make sure to turn your profits from coins to fiat. If you are willing to take a bet you can either mine a newly launched coin that is not on an exchange, or go ahead and mine an established coin like vertcoin, which might go up in price someday.
If you need help configuring any mining software please feel free to post in the comments and I will write you a detailed tutorial on how to set it up.
Coinpunk is a bitcoin wallet platform. It is open source and is available for free, you can see the repository HERE
In the docs section there are available tutorials on how to install coinpunk on OSX and Ubuntu. However there isn’t one on how to install coinpunk on Centos. While Ubuntu and Centos are both linux distros the installation procedure must be modified. In this tutorial I will try to walk you through how to install coinpunk on Centos.
The first thing you must do on CentOS 6.5 is install bitcoind. For coinpunk you must use/install a specific version of bitcoind which can be found here:
now we will untar the tarball and start installing dependencies.
tar -zxf watchonly.tar.gz
You can find a tutorial on how to install the necessary dependencies HERE I will briefly walk through how to do that. If you don’t already have it you will need to install git.
yum install git-core
first we update yum and make sure your original deps are up to date:
We will need to install some dependencies from source so lets get to it, create a working directory and start compiling
Berkeley DB 4.8.30
tar zxvf db-4.8.30.tar.gz
../dist/configure --prefix=/home/bitcoind/bitcoind/deps --enable-cxx
make && make install
tar zxvf openssl-1.0.1g.tar.gz
./config --prefix=/home/bitcoind/bitcoind/deps --openssldir=/home/bitcoind/bitcoind/deps/openssl -fPIC shared
make && make install
wget http://sourceforge.net/projects/boost/files/boost/1.55.0/boost_1_55_0.tar.bz2/download -O boost_1_55_0.tar.bz2
tar jxvf boost_1_55_0.tar.bz2
./b2 --prefix=/home/bitcoind/bitcoind/deps link=static runtime-link=static install
Next we need to compile bitcoind. Navigate to the bitcoin-watch directory and run
If you get an error that looks something like this:
c:/deps/boost_1_52_0/boost/thread/detail/thread_group.hpp:74: undefined reference to `boost::thread::join()'
obj/bitcoinrpc.o: In function `thread<boost::_bi::bind_t<unsigned int, boost::_mfi::mf0<unsigned int, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::asio::io_service*> > > >':
Then you will need to link the boost directory where the libraries are installed. Here is how you would run your compile commands:
./configure --with-boost-libdir=/usr/lib/ --without-qt
If everything compiles then we will now configure the bitcoin.conf file
This will make sure that bitcoind starts up in the testnet so you can test functionality. I would let bitcoind run overnight not on the testnet and synchronize with the blockchain before continuing but it is up to you.
If you get an error or still having problems compiling check out this OTHER tutorial on how to install bitcoind on CentOS 5.5 just remember that you need a specific version of bitcoind for coinpunk so when following the instructions download the right version. Still all of the commands are the same.
Once you have bitcoind up and running and the blockchain updated lets start installing coinpunk.
First we need to clone the repository and then install the nodejs dependancies:
git clone https://github.com/kyledrake/coinpunk.git
Now we will setup the config files. Navigate to ~/coinpunk and add the config files from the templates.
cp config.template.json config.json
go ahead and do the same to the config template in ~/coinpunk/public
cp config.template.json config.json
Now we will edit the config files to connect to bitcoind. The ports are 18332 for testnet and 8332 for prodcution.
Since we will be first launching coinpunk on the tesnet then keep the line network:testnet, otherwise if you will compile for production change it from testnet to prod.
Now navigate back to the coinpunk folder in ~/coinpunk and fire it up
Hopefully coinpunk starts, you might get the following error:
Error: listen EADDRINUSE
at errnoException (net.js:904:11)
at Server._listen2 (net.js:1042:14)
at listen (net.js:1064:10)
at Server.listen (net.js:1138:5)
at b (domain.js:183:18)
at Domain.run (domain.js:123:23)
at Object.<anonymous> (/root/coinpunk/start.js:31:8)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
This means that the port is already in use by another program. If that is the case then you must kill whatever process is using that port or choose a different port. bitcoind is most likely the process using it so go ahead and check with:
lsof -i :18332
if you received the EADDRINUSE error then a process should show up. kill it by using it pid
kill [put your process id here]
Now go ahead and try again to start coinpunk.
The way to check if coinpunk is successfully installed is navigating to:
So for example since my domain name is www.coiniv.com then I would navigate to http://coiniv.com:18332
If you are using chrome it should give you a warning about the ssl certificate and how its not trusted click proceed and you should see this:
coinpunk on the testnet
This is it, now you are hosting a wallet on the network just like blockchain or coinbase. Thanks to the existing tutorials provided by coinpunk.com which can be found HERE
If any of you are facing issues feel free to post a comment and I will help you get it resolved.