Muhammad Bilal Arif furusiyya

Keybase proof

I hereby claim:

I am geek96 on github.
I am geek96 (https://keybase.io/geek96) on keybase.
I have a public key whose fingerprint is 58E3 7E8C 7401 723B FE4A 4E31 F0DF 9354 CB39 8BAC

To claim this, I am signing this object:

Bitcoin

Ethereum

Update Yellow Paper: https://ethereum.github.io/yellowpaper/paper.pdf
https://media.consensys.net/time-sure-does-fly-ed4518792679
Ethereum Wiki consist of 159 pages: https://github.com/ethereum/wiki/wiki
Ethereum Improvement Proposals: https://github.com/ethereum/EIPs
https://forum.ethereum.org

The purpose of this document is to make recommendations on how to browse in a privacy and security conscious manner. This information is compiled from a number of sources, which are referenced throughout the document, as well as my own experiences with the described technologies.

I welcome contributions and comments on the information contained. Please see the How to Contribute section for information on contributing your own knowledge.

Merged Pull Requests

1- Connection Timeout Added

Issues Resolved: #72, #59
Description Glutton support number of services (protocol handlers) so each service mean number of connection on that service. So It crash after some time with error: [user.tcp] accept tcp [::]:5000: accept4: too many open files, and this error was due to the allowance of limited number of open file descriptors by the operating system. There was no deadline set for opened connections so most of the connections never get closed. In result, the number of opened connections gradually cross the maximum open file descriptors limit and cause panic. So I added connection timeout = 72 second, number of opened connection will never reach the open file descriptor limit. Another reason was Freki; Glutton useses freki as a networking core so frek

Write contracts
Study zeppelin in depth and then learn to test for this: logic bugs, failed sends, recursive calls, overflow, poison data, exposed functions, exposed secrets, dust spam, replay attack, miner vulnerabilities, malicious creator, off-chain safety, cross-chain attacks, tx-origin problems, stack depth exhaustion, etc.
http://hackthiscontract.io/dashboard?address=ggg
https://medium.com/@rtaylor30/how-i-snatched-your-153-037-eth-after-a-bad-tinder-date-d1d84422a50b

Specifications of a contract

A flat pricing with ETH: USD - $0.02 per token (50 tokens to 1 USD)
Coin rate should be $0.02 (can just use the live feed from www.oraclize.it or similar)
Token supply: 1 billion, selling 150 million e.g. $3M cap.
Token: 8 decimals
Multisig wallet for the proceeds, as per gnosis (as that doesn't seem to have had any issues vs. parity)
Ensure tokens are reserved and allocated by a certain date when they unlock to subscribers
No ETH cap: Anyone can buy as many tokens as they like until all tokens are sold
Sale ends when 150m tokens (out of 1bn) allocated to contract run out or a certain date is reached
Ideally the smart contract should verify in etherscan and fit into the token tracker

	0x00 0 STOP
	0x01 3 ADD
	0x02 5 MUL
	0x03 3 SUB
	0x04 5 DIV
	0x05 5 SDIV
	0x06 5 MOD
	0x07 5 SMOD
	0x08 8 ADDMOD
	0x09 8 MULMOD

	#!/bin/bash
	docker rmi $(docker images \| grep "^<none>" \| awk "{print $3}");
	docker rm $(docker ps -a -q)