Dev Null

Special device files
/dev/full
/dev/null
/dev/random
and /dev/urandom
/dev/zero

In some operating systems, the null device is a device file that discards all data written to it but reports that the write operation succeeded. This device is called /dev/null on Unix and Unix-like systems, NUL: or NUL on DOS and CP/M, nul on newer Windows systems (internally \Device\Null on Windows NT), NIL: on Amiga operating systems, and the NL: on OpenVMS. In Windows Powershell, the equivalent is $null. It provides no data to any process that reads from it, yielding EOF immediately. In IBM DOS/360, OS/360 (MFT, MVT), OS/390 and z/OS operating systems, such files would be assigned in JCL to DD DUMMY.

In programmer jargon, especially Unix jargon, it may also be called the bit bucket or black hole.

The null device is typically used for disposing of unwanted output streams of a process, or as a convenient empty file for input streams. This is usually done by redirection.

The /dev/null device is a special file, not a directory, so one cannot move a whole file or directory into it with the Unix mv command. The rm command is the proper way to delete files in Unix.

some command > /dev/null 2>&1

STDIN is represented by 0, STDOUT by 1, and STDERR by 2.

/dev/null is the bit-bucket: the place where you dump anything you don’t need.

By default:

stdin  ==> fd 0
stdout ==> fd 1
stderr ==> fd 2

In the script, you use > /dev/null causing:

stdin  ==> fd 0
stdout ==> /dev/null
stderr ==> fd 2

And then 2>&1 causing:

stdin  ==> fd 0
stdout ==> /dev/null
stderr ==> stdout

Reference: https://en.wikipedia.org/wiki/Null_device
https://unix.stackexchange.com/questions/119648/redirecting-to-dev-null

Install/Uninstall packages in Ubuntu from tar.gz

Unzip the tar.gz by using the compression/decompression program in your system.

The steps to make and build:

./configure 
make
make install
//Remove package
Make unistall

To remove the package make install is used. Sometimes if the unistall step is not mentioned in the make file, the removal of the installed package would get difficult and can even lead to a broken system.

To prevent this, instead of installing the package using make install, we can use the checkinstall utility available in the ubuntu repo. It cretaed a .deb package for the program. This .deb package can be easily removed using any package manager like apt, synaptic, dpkg, aptitude.

sudo apt install checkinstall
sudo checkinstall

 

Example to remove package after installing it through checkinstall.



**********************************************************************

 Done. The new package has been installed and saved to

 /home/ajinkyawavare/Downloads/scid_vs_pc-4.19/scid-vs-pc_4.19-1_amd64.deb

 You can remove it from your system anytime using: 

      dpkg -r scid-vs-pc

**********************************************************************

Chess Engine Rating And Chess Games Db

Chess Engine Rating

ELO Rating

The Elo rating system is a method for calculating the relative skill levels of players in zero-sum games such as chess. It is named after its creator Arpad Elo, a Hungarian-American physics professor.

The Elo system was originally invented as an improved chess rating system over the previously used Harkness system, but is also used as a rating system for multiplayer competition in a number of video games, association football, American football, basketball,Major League Baseball, table tennis, Scrabble, board games such as Diplomacy and other games.

The difference in the ratings between two players serves as a predictor of the outcome of a match. Two players with equal ratings who play against each other are expected to score an equal number of wins. A player whose rating is 100 points greater than their opponent’s is expected to score 64%; if the difference is 200 points, then the expected score for the stronger player is 76%.

A player’s Elo rating is represented by a number which increases or decreases depending on the outcome of games between rated players. After every game, the winning player takes points from the losing one. The difference between the ratings of the winner and loser determines the total number of points gained or lost after a game. In a series of games between a high-rated player and a low-rated player, the high-rated player is expected to score more wins. If the high-rated player wins, then only a few rating points will be taken from the low-rated player. However, if the lower rated player scores an upset win, many rating points will be transferred. The lower rated player will also gain a few points from the higher rated player in the event of a draw. This means that this rating system is self-correcting. A player whose rating is too low should, in the long run, do better than the rating system predicts, and thus gain rating points until the rating reflects their true playing strength.

Strengths of modern day chess engines:

The rating and stats of the chess engines can be found at

http://www.computerchess.org.uk/ccrl/4040/

Stockfish, an open source chess engine has been on the top for quite some time.

Chess Games Database

Chess games are ususally saved in the pgn format. A huge collection of chess games can be found on the internet.

Starters for Games Database:

1) PGNMentor

https://www.pgnmentor.com/files.html

It has huge collection of games. It has segregated games by players, openings, midgames, endgames etc.

2) Kingbase

http://www.kingbase-chess.net/

Millbase for scid has been discontinued. The successor to this is kingbase. It has over 2.2+ million games. The contents are also updated on a monthly basis.

3) Rebel

http://www.top-5000.nl/pgn.htm

4) GorgoBase

http://gorgonian.weebly.com/pgn.html

Reference:
https://en.wikipedia.org/wiki/Elo_rating_system

Chess Engines

Protocols

1) Xboard

XBoard is a graphical chessboard for the X Window System. It is developed and maintained as free software by the GNU project. WinBoard is a port of XBoard to run natively on Microsoft Windows.

Originally developed by Tim Mann, these programs are compatible with various chess engines that support the Chess Engine Communication Protocol such as GNU Chess.It also supports Internet Chess Servers, e-mail chess, and the playing of saved games.

XBoard/WinBoard remain updated, and the Chess Engine Communication Protocol has been extended to meet the needs of modern engines (which have features such as hash tables, multi-processing and end-game tables, which could not be controlled through the old protocol).

Tim Mann’s website: http://tim-mann.org/engines.html

2) UCI

A Universal Chess Interface (UCI) is an open communication protocol that enables chess engines to communicate with user interfaces.
In November 2000, the UCI protocol was released. Designed by Rudolf Huber and Stefan Meyer-Kahlen, the author of Shredder, UCI rivals the older “Chess Engine Communication Protocol” introduced with XBoard/WinBoard. Both protocols have been free to use without license fees.

In 2002, Chessbase, the chess software company which markets Fritz, began to support UCI, which had previously been supported by only a few interfaces and engines.

As of 2007, well over 100 engines are known to directly support UCI.

Stockfish

Stockfish is a free and open-source UCI chess engine, available for various desktop and mobile platforms. It is developed by Marco Costalba, Joona Kiiski, Gary Linscott and Tord Romstad, with many contributions from a community of open-source developers.

Stockfish is consistently ranked first or near the top of most chess-engine rating lists and is the strongest open-source chess engine in the world.It won the unofficial world computer chess championships in season 6 (2014), season 9 (2016), season 11 (2018) and season 12 (2018). It finished runner-up in season 5 (2013), season 7 (2014) and season 8 (2015). Stockfish is derived from Glaurung, an open-source engine by Romstad.

Stockfish Repo: https://github.com/official-stockfish/Stockfish

Installing In Ubuntu
A comprehensive list of all the buntu chess packages has been prepared by ubuntu dev.
Package list: https://packages.ubuntu.com/bionic/games-chess

sudo apt-get install pychess scid eboard phalanx gnuchess gnuchess-book stockfish polyglot fruit glaurung hoichess phalanx polyglot pychess scid toga2 xboard sjeng fairymax crafty

Interfaces: pychess scid eboard gnuchess

GNU Chess provides a simple yet powerful interface. It also supports addition of multiple chess engines to it.

gnuchess --version
gnuchess --help
info gnuchess

SCID

Shane’s Chess Information Database (Scid) is an open source UNIX, Windows, Linux, and Mac application for viewing and maintaining huge databases of chess games. It has features comparable to popular commercial chess software. Scid is written in Tcl/Tk and C++.

Scid has undergone several stages of development. Firstly by Shane Hudson, and then Pascal Georges.

Every toolkit provides mechanism to add the installed chess engines. Add the engines from the preferences in the toolkit. The installed chess engine can be used in the analysis of the game as well as act the brains of the opponent in a Human Vs Computer match.

SCID development has stopped in 2016.

Setting up SCID: https://ilikewhenit.works/blog/7

A newer toolkit called SCID VS PC is now available.

SCID vs PC

Remove scid package if installed from the apt install command mentioned above

Download the package from official site: http://scidvspc.sourceforge.net/

Installing the package making use of the steps mentioned in the documentation

Running Scid Vs PC

nohup scid &

Tutorial for installation:
http://www.linuxx.eu/2012/11/scid-vs-pc-installation-guide-ubuntu.html

The tcl tk libraries 8.6 version is already installed in Ubuntu bionic. Therefore, shouldn’t be a problem as mentioned above.

Database and saved games:
https://www.youtube.com/watch?v=NG2yRGlL1iU

It gives a brief idea about how to save games and open games from pgn files

 

Reference:
https://en.wikipedia.org/wiki/XBoard
https://en.wikipedia.org/wiki/Universal_Chess_Interface
https://en.wikipedia.org/wiki/Stockfish_(chess)
https://en.wikipedia.org/wiki/Shane%27s_Chess_Information_Database

 

MultiChain Web Demo

Follow the steps listed down in the Github repository for the same.

Github Repo: https://github.com/MultiChain/multichain-web-demo

Setting up in Local:

Starting the web server

$ cd ~/public_html
$ php -S localhost:8000

The terminal will show:

PHP 7.2.7-0ubuntu0.18.04.2 Development Server started at Thu Aug 2 17:46:31 2018
Listening on http://localhost:8000
Document root is /home/ajinkyawavare/Documents/BlockChain/MultiChain/multichain-web-demo
Press Ctrl-C to quit.
[Thu Aug 2 17:46:46 2018] 127.0.0.1:45556 [200]: /?chain=default
[Thu Aug 2 17:46:47 2018] 127.0.0.1:45574 [200]: /bootstrap.min.css
[Thu Aug 2 17:46:47 2018] 127.0.0.1:45576 [200]: /styles.css
[Thu Aug 2 17:48:43 2018] 127.0.0.1:45588 [200]: /?chain=default&page=permissions
[Thu Aug 2 17:48:43 2018] 127.0.0.1:45602 [200]: /bootstrap.min.css
[Thu Aug 2 17:48:43 2018] 127.0.0.1:45604 [200]: /styles.css

Accessing Explorer from localhost:

Accessing Explorer installed on the remote server:
Make sure that you update the network and security settings in the aws.
Also take a note of the change in the host accessible in the chain1.conf file here.
You need to install php and php curl for the web page to get served.
Also nginx or apache htt-server needs to be installed in your machine.

MultiChain Explorer

Follow the steps listed down in the Github repository for the same.

Setting up in Local:

Accessing Explorer from localhost


Accessing Explorer installed on the remote server:
Make sure that you update the network and security settings in the aws.
Also take a note of the change in the host accessible in the chain1.conf file here.

 

Github Repo: https://github.com/MultiChain/multichain-explorer

 

MultiChain Mining

In MultiChain, block creators must prove their identity by signing blocks

Block signatures

Block signatures are embedded inside the OP_RETURN metadata of the coinbase transaction, using a regular bitcoin-style signature format. The payload signed by the block creator is the full block header, with the following modifications:

  • The merkle_root is recalculated based on the txid of the coinbase transaction with the OP_RETURN removed. This prevents a dependency loop from block signature → coinbase txid → merkle root → block header → block signature.
  • The nonce field is set to 0. This avoids having to recalculate the signature for every attempt at finding a block hash to match the target difficulty. However it does lead to some malleability in that a user without mine permissions could generate a block with the same content as a valid block, but with a different nonce. Seeing as the nonce serves no purpose other than to randomize the block’s content for its hash, this should not be a source of concern.

In the case of a permissioned MultiChain blockchain, consensus is based on block signatures and a customizable round-robin consensus scheme, rather than proof-of-work as in bitcoin.

On the first server, run:

grant 15ZLxwAQU4XFrLVs2hwQz1NXW9DmudRMcyx2ZV mine

(Even though the permission is called mine note that there is no real “mining” taking place, in the sense of proof-of-work.) On the second server, check that two permitted block validators are listed:

listpermissions mine

Run this on both servers to maximize the degree of validator randomness:

setruntimeparam miningturnover 1

Now wait for a couple of minutes, so that a few blocks are added. (This assumes you left the block time on the default of 15 seconds.) On either server, check the creators of the last few blocks:

listblocks -10

The address of the validator of each block is in the miner field of each element of the response.

Snippet:
RR Mining

Node-1 Terminal | Node-2 Terminal

 

Reference: https://www.multichain.com/developers/mining-block-signatures/
https://www.multichain.com/getting-started/

MultiChain Streams

MultiChain streams enable a blockchain to be used as a general purpose append-only database, with the blockchain providing timestamping, notarization and immutability. A MultiChain blockchain can contain any number of streams, where the data published in every stream is stored by every node. If a node chooses to subscribe to a stream, it will index that stream’s contents to enable efficient retrieval in various ways.

Each stream is an ordered list of items, in which each item has the following characteristics:

  • One or more publishers who have digitally signed that item.
  • A key between 0 and 256 bytes in length.
  • Some data, which can reach many megabytes in size.
  • Information about the item’s transaction and block, including its txid, blockhash, blocktime, and so on.

Like native assets, MultiChain streams can be referred to in any of three ways:

  • An optional stream name, chosen at the time of stream creation. If used, the name must be unique on a blockchain, between both assets and streams. Stream names are stored as UTF-8 encoded strings up to 32 bytes in size and are case insensitive.
  • A createtxid, containing the txid of the transaction in which the stream was created.
  • A streamref which encodes the block number and byte offset of the stream creation transaction, along with the first two bytes of its txid.

If root-stream-name in the blockchain parameters is a non-empty string, it defines a stream which is created with the blockchain and can be written to immediately. The root stream’s createtxid is the txid of the coinbase of the genesis block, and its streamref is 0-0-0.

Create a stream, which can be used for general data storage and retrieval. On the first server:

create stream stream1 false

The false means the stream can only be written to by those with explicit permissions. Let’s see its permissions:

listpermissions stream1.*

So for now, only the first server has the ability to write to the stream, as well as administrate it. Let’s publish something to it, with key key1:

publish stream1 key1 73747265616d2064617461

The txid of the stream item is returned. Now let’s see that the stream is visible on another node. On the second server:

liststreams

(The root stream was in the blockchain by default.) Now we want the second server to subscribe to the stream, then view its contents:

subscribe stream1
liststreamitems stream1

Now we want the second server to be allowed to publish to the stream. On the first server:

grant 15ZLxwAQU4XFrLVs2hwQz1NXW9DmudRMcyx2ZV send
grant 15ZLxwAQU4XFrLVs2hwQz1NXW9DmudRMcyx2ZV stream1.write

Note that the address needs both general send permissions for the blockchain, as well as permission to write to this specific stream. Now let’s publish a couple of items on the second server:

publish stream1 key1 736f6d65206f746865722064617461
publish stream1 key2 53747265616d732052756c6521

Now let’s query the stream’s contents in many different ways. Back on the first server:

subscribe stream1
liststreamitems stream1 (should show 3 items)
liststreamkeys stream1 (2 keys)
liststreamkeyitems stream1 key1 (2 items with this key)
liststreampublishers stream1 (2 publishers)
liststreampublisheritems stream1 15ZLxwAQU4XFrLVs2hwQz1NXW9DmudRMcyx2ZV

Snippets:

Streams -1 (node 1 and node 2)

Streams – 2

Reference: https://www.multichain.com/developers/data-streams/
https://www.multichain.com/getting-started/

 

MultiChain Native Assets

MultiChain allows the creation & tracking of assets at the network level.

A use of  Blockchain to have defined limited native assets & let peers or nodes transact them among each other in an atomic or non-atomic manner. Anything can be defined as an asset.

Using native assets:

MultiChain allows the creation and tracking of assets at the network level

Assets in MultiChain

MultiChain supports assets natively at the blockchain level. The identifiers and quantities of assets are encoded within each transaction output, alongside the quantity of the blockchain’s native currency (which may be zero if it is not being used). Every MultiChain node tracks and verifies the quantity of assets in transactions, just as it is does with the native currency. Specifically, it checks that the total quantities of all assets in a transaction’s outputs are exactly matched by the total in its inputs. MultiChain allows each transaction output can contain any number of different assets.

In MultiChain, assets can be referred to in any of three ways:

  • An optional asset name, chosen at the time of issuance. If used, the name must be unique on a blockchain, between both assets and streams. Asset names are stored as UTF-8 encoded strings up to 32 bytes in size and are case insensitive.
  • An issuetxid, containing the txid of the transaction in which the asset was issued.
  • An assetref which encodes the block number and byte offset of the issuance transaction, along with the first two bytes of its txid.Common Commands:
    
    listpermissions issue (Check whether you have the permission to issue or not)
    issue 16bNJqp4d8JX3uL7UYr5hACWLnK2LU4f2Ep9FD aj007 100000 0.000001 (Address which has the permission to issue. Here aj007 is the asset issued. This has precison till 6 as specified in the last param)
    listassets (list the assets on the chain)
    gettotalbalances (get the total balance on the server)
    send 15ZLxwAQU4XFrLVs2hwQz1NXW9DmudRMcyx2ZV aj007 5000 (send the assets to the given address on node - 2)
    listwallettransactions (get the total transactions which have occured in the given wallet)
    
    sendwithdata 15ZLxwAQU4XFrLVs2hwQz1NXW9DmudRMcyx2ZV '{"aj007":500}' data (Sending metadata in transaction)


    Reference: https://www.multichain.com/developers/native-assets/