Bisq - The peer-to-peer bitcoin exchange
Introduction
Bisq is an open source peer-to-peer application that allows anyone to buy and sell Bitcoin in exchange to national currencies or alternative crypto currencies.
Unlike existing exchanges, Bisq is fully decentralized and censorship resistant using alternative protection mechanisms:
escrow transaction employing 2-of-3 multisignature address
security deposits to incentivise following the trade protocol
a decentralized arbitration system helps resolve disputes
Bisq protects user’s privacy by using a custom P2P network over Tor, in which every user is a participating node. An all-in-one desktop application (for Linux, OS X and Windows) provides an intuitive user interface and executes the trading protocol.
Motivation
Bitcoin is a censorship resistant payment system, because it avoids dependence on trusted third parties. Currently, the process of acquiring Bitcoin does not follow the same principles due to the lack of a fully decentralized solution. Bisq aims to fill this gap.
Core values
There is a variety of Bitcoin exchanges out there, but all of those are operating in a traditional way where the user needs to trust a centralized system with his funds and expose his data and financial privacy. The vulnerability of such models has been demonstrated numerous times—most notably by Mt. Gox. But theft and server hacks are not the only issue: centralized exchanges are vulnerable to coin-tracing on a mass scale, which is a serious violation for users' privacy.
The key point of decentralization is the lack of single points of failure, control or censorship. Bisq holds these values in every aspect of the project:
Infrastructure (P2P network - there are no servers)
Never hold user’s funds (neither bitcoins nor fiat)
Never hold user’s data (no account registration)
The software is developed open source, there is no controlling company
No individual persons have leverage over the developers, as the project is self-funded and in part through donations
Furthermore we consider privacy as a fundamental human right which needs to be protected as far as possible.
The P2P network operates over Tor (using Tor hidden services)
All private data sent over the wire is end-to-end encrypted
No privileged access to any data (public data is public to everyone, private data only accessible to the traders)
Comparison to related projects
One may describe Bisq as a fully decentralized version of LocalBitcoins, where:
no central place exists to collect user data
no servers exist to attract adversaries
no trust is needed in the service provider (Bisq)
users have exclusive ownership of their funds
users do not rely on a reputation system, which can be manipulated
Bisq resembles other decentralized projects, such as OpenBazaar or Bitmarkets, which employ similar protection mechanisms. However, those projects behave as Ebay-style marketplaces rather than (crypto-)currency exchanges.
Overview
This graphical overview shows the basic high-level flow of the trade process. See the detailed version for more information.
Trade process overview
These videos demonstrate the current software and give a more detailed explanation of the trade process. A detailed graphical representation of the trade protocol should help to explain the way the payment process is executed. A document also discusses the possible risks, attacks and protection mechanisms. An arbitration system will serve as primary protection mechanism and is also described in a separate document.
Main characteristics
P2P infrastructure without servers: No single point of failure and no privacy breach due transaction monitoring possible.
National (or alternative crypto) currency are transferred directly from one user’s payment account to the others payment account without any intermediate party.
Support for alternative crypto currencies to be exchanged with Bitcoin.
No registration or identification process
Decentralized arbitrator system as primary protection mechanism
Security deposit as additional incentive for following the trade protocol
A atomic deposit transaction locks up both traders funds to a 2 of 3 multisig address
Trading fees as protection against spam and market manipulation
A limit on the trade amount (1 BTC) to reduce the overall risk exposure
Open source license (AGPL)
Contract holds all trade details and is signed by both traders, it will be used as evidence in case of a dispute
Fraud reports as protection against bank charge backs and crime (stolen payment account)
Protection mechanisms
For protecting against several fraud and attack scenarios we use different solutions:
Trader’s security deposit - refunded after successful trade or used as payment for the arbitrator in case of a dispute.
Arbitrator - anonymous and randomly assigned. Resolves disputes between traders.
Arbitrator’s security deposit - locked when the arbitrator is registered and released upon stepping down.
Contract - blinded non-refutable proof of trade details
Fraud report - reports by arbitrators with proof of clear cases of fraud
Trade volume limitation - limits to maximum trade volume in order to reduce potential gain from fraud
Business model
Bisq is not a company, but an open-source project that aims to fill a gap in the cryptocurrency ecosystem: to provide an exchange platform which follows the same principles as Bitcoin itself. A unique incentive mechanism is set up to support the project:
transaction fees go in part to the developers and in part to the arbitrators
in the event of disputes, arbitrators collect the security deposit of the losing party (or in some cases half the deposit of each party)
Technology
The Bisq application is built in Java 8 with JavaFX for the GUI. For interaction with the Bitcoin network the bitcoinj library is used. For decentralized messaging and data storage a custom flooding (gossiping) network over Tor is used.
P2P network
There are a few main use cases for the P2P network:
Broadcast data (typically offers - public data)
Messaging between trading peers (private and end-to-end encrypted)
Data storage if trading peer is offline (mailbox-like system)
Key features of the P2P network technology:
Highly accessible (NAT traversal, firewalls,…)
Protect privacy (Tor hidden services)
Redundant data storage (flooded to all peers)
Data access protection (using signatures)
Resistant against spam/flooding
Scalable
You can find more details about the P2P network here.
Wallet
Bisq protects the privacy between trades by separating each trade with a different set of addresses. No addresses will be used across multiple trades avoiding coin merge and de-anonymisation vectors. The user needs to further take care when doing the deposit from and withdrawal to his external wallet to avoid loss of privacy due coin merge (e.g. usage of Coin Join solutions).
Wallet key features:
Manage the key pairs (HD wallet)
Create regular and pay-to-script-hash (P2SH) transactions
Sign transactions
Broadcast transactions
Add hash of contract to a transaction (e.g. OP_RETURN)
Security Deposit
The security deposit will be derived from the arbitration fee which will be used as payment to the arbitrator only in case of a dispute resolution. If no dispute is opened, this deposit is returned in whole to each trader.
The security deposit serves also as an incentive to follow the protocol (e.g. to ensure Bob is not lazy or careless and forgets to release the payout transaction) as well as a mechanism to ensure a dishonest trader is forced to pay the costs for arbitration.
Fees
The fees are necessary for protection against offer book spam, market manipulation and identity harvesting. They are also needed as payment to the arbitrators for their services. Arbitrators are compensated for agreeing in advance to be available to arbitrate a trade even in the case the trade is not disputed.
Initially the fees will be kept to a minimum. Later as the trading community grows the fees will be adjusted as needed to make the arbitration system sustainable and to adjust to the level of observed fraud activity.
To make the payment process fast we do not wait for transaction confirmation of fees. A double spend of the fees is potentially possible but highly unlikely, due to the difficulty of its execution and its low profitability. There will be a second verification at the end of the trade process where a double spend would be detected and that could be used for local blacklisting.
Bisq operates with the following fees:
Create offer fee: 0.001 BTC (paid to the arbitrators, mining fee is included)
Take offer fee: same as create offer fee (and also paid to the arbitrators)
Bitcoin mining fee: 0.0003 BTC (A mining fee is included in a transaction three times: Deposit from external wallet, trade, and withdrawal to external wallet. So the sum is 0.0009 BTC)
Security deposit (might be used as arbitration fee): 0.1 BTC, which is returned in whole to the trader after the transaction in case he is not found to have behaved dishonestly. The security deposit from dishonest trader will be used to pay the arbitrator for his efforts. In rare cases half the security deposit of each trader may be collected instead. The active arbitration fee is not related to the size of the trade and does not affect the time required to mediate a dispute as the amount of work an arbitrator must perform is roughly constant even when small amounts are exchanged.
(only for arbitrators) arbitrator’s security deposit: 2 BTC. In addition, a part of each collected arbitration fee from dishonest traders is locked in the security deposit. This (accumulated) amount is returned in whole to the arbitrator upon stepping down from arbitration.
Trading protocol
The desktop application implements the protocol for the trading process. When broadcasting an offer, the offering peer agrees to accept any take-offer request which fulfills the terms defined in the offer. The take-offer process requires that the Bisq applications of both traders are running (it can run in background). They do not need to be physically present at their computer, but the software needs to be online to react to the take offer request.
The Bitcoin buyer should wait for at least 1 blockchain confirmation as protection against double spend, before starting the transfer of the national currency (or alternative cryptocurrency). The Bitcoin seller will release the deposit after he has confirmed the receipt of the national currency. Here is a detailed graphical overview of the trade protocol.
Arbitration
Bisq relies on a decentralized arbitration system to ensure that traders fulfill their obligations. See the arbitration system document for more details on how this system works.
Fraud reports
A fraud report is used to warn about fraud from bank chargebacks, stolen payment accounts or arbitration fee fraud. The arbitration system can not help in these cases because the Bitcoin payment has already been released by the time the fraud is discovered. The fraud report only serves to prevent repeated scam with the same payment account and Tor onion address. More details can be found in the risk analysis document.
Limitations and risks
within Bisq
Only non-reversible payment transfer methods are supported to minimize the risk of chargebacks
You can trade at most 1 Bitcoin per transaction
You must already have a small amount of Bitcoin to execute a trade (for paying the security deposit, trade fee and Bitcoin mining fee)
The Bisq application must be running (can run in background), in order to allow the user’s offer to be taken.
Bitcoin is always one part of the exchanged currencies. One cannot trade alternative cryptocurrencies for national currencies.
Arbitrators need to lock away 2 Bitcoins, which are only returned when they step back from their service.
outside Bisq
Depending on the payment method: Personally identifying information will be revealed to the trading partner and stored in the contract as part of the payment transfer.
The speed of the trade process depends on the duration of the payment transfer.
Application should not be used in jurisdictions where Bitcoin is illegal (risk from trading with undercover agents).
Remarks
Identity verification
Bisq does not carry out identity verification of users. However, in the event of a dispute, the assigned arbitrator may need to check the identity of the traders. This information is only visible
to that arbitrator and to at most one senior arbitrator. Users may request that identity verification is carried out over encrypted channels, e.g. using Tox instead of Skype. See the risk analysis document for more information.
Reputation system
Bisq does not use a reputation system, as such systems can easily be manipulated, e.g. by a Sybil attack.
Example use cases
Standard exchange process
Trader selects the arbitrators he wants to accept in case of disputes or stick with the default selection of all matching arbitrators.
Trader sets up a payment method account.
Buyer deposits bitcoins from external wallet (for security deposit, create-offer fee and mining fee)
Buyer publishes the offer. Create-offer-fee gets paid to one of his selected arbitrators. The security deposit will be locked in his local Bisq trading wallet in case someone takes the offer.
Seller deposits bitcoins from external wallet (for security deposit, take-offer fee, mining fee and the trade amount)
Seller takes offer. The software sends his security deposit and Bitcoin trade amount to a 2-of-3 multisig address.
Buyer transfers the national currency (or alternative cryptocurrency) amount directly to Seller outside Bisq (e.g. via online banking web page or altcoin wallet)
Seller confirms upon payment receipt and releases Bitcoin from the escrow address
Buyer withdraws trade amount and his refunded security deposit to an external wallet
Seller withdraws his refunded security deposit to an external wallet
Resolving a dispute
The traders started a trade but for whatever reason it got stalled.
After the max. allowed trade period (depends on the payment method: e.g. OKPay: 1 day, SEPA: 8 days) the software displays an "Open dispute" button, which is otherwise not visible. Any trader can request arbitration by pressing that button.
Bisq provides a chat like communication system for disputes (and support tickets in case of software bugs) only between the trader and the arbitrator. The initiating trader will see his first (system) message he has sent to the arbitrator requesting a dispute.
The arbitrator receives the dispute request and the software send a dispute message to the other trader, informing him that his peer has started a dispute. The two traders cannot communicate directly with each other and cannot see the communication of the other trader with the arbitrator.
Traders and arbitrator communicate in real time, end-to-end encrypted.
Arbitrator follows a protocol to request additional information from both parties and renders his decision based on acquired evidence.
Arbitrator unlocks the multi-signature address using his key and the key of the winning party, transferring the Bitcoin amount to the "rightful owner" based on the available evidence. Typically the arbitrator collects the security deposit of the losing party and refunds the deposit of the other party (there are also alternative payout possibilities as well).
When criminal fraud is detected: Arbitrator publishes and signs a digital report containing all data about the criminal trader to the public fraud list. These reports will only be created in clear cases of fraud like bank chargeback or use of a stolen bank account.
If either trader is not satisfied with the decision of the arbitrator, he may request a second and final arbitration round, performed by a senior arbitrator. The latter reviews the available evidence and renders his decision. If the original arbitrator is found to have behaved dishonestly, further steps are taken to penalize his behavior, based on the severity of his fault.
The details of an exchange transaction
Alice wants to buy Bitcoin for national currency. When Alice creates a new offer she needs to define the amount of Bitcoin to buy or sell, the price and a minimum amount she is willing to trade. The other data included in an offer, like the acceptable arbitrators or the acceptable payment account countries and method, will be derived from the account settings.
To avoid potential collusion between the arbitrator and one of the trading parties the arbitrator will be selected in an unbiased and verifiable way. This will minimize the chance that a trader forces the selection to a preferred arbitrator. The selection mechanism is described in the arbitration system document.
Create offer
Alice broadcasts a cryptographically signed offer to buy a set amount of BTC with a specific currency at a set rate. She also has to specify which national currency transfer methods and which registered arbitrators she agrees to use. The offer only reveals her P2P network ID (onion address), not any personal information. The offer will be broadcasted to the P2P network. The offer storage is access protected so that she is the only one who can remove her offer. There will be a maximum time to live (10 min.) for the offer storage in the P2P network. If she stays online her software will automatically re-publish the offer to ensure the offer does not get removed. If she goes offline her offer gets immediately removed. In cases the software crashes or if she loses internet connectivity the time to live ensures that the offer will not stay long time as "dead offer" in the public offer book.
Offer book
At startup every trader loads all offers for his selected national currency from the P2P network peers he connects to. The offer book displays all offers matching the selected currency. Offers which are not matching the user’s payment account or selected arbitrators are displayed as inactive (grey out).
Informative feedback is provided upon user interaction why that offer is inaccessible (e.g. "the offerer uses a payment method you do not support").
The trader can filter offers by currency and payment method to customize his offer book as well as sort all relevant table columns.
Take offer
When Bob takes an offer, the software verifies that the offer fee was paid by Alice. He used the onion address in the offer to connect to Alice’s Tor hidden service to start the trade protocol.
After that there is a check that the offer is still available, i.e. no other trader has taken the offer in the meantime. The offer will remain in the distributed offer book until an escrow deposit is created and funded by both peers. Bob’s software then pays the take-offer fee. Until this point neither peer has revealed any private information to the other peer.
Deposit transaction
Upon taking an offer, a deposit transaction is created using a 2-of-3 multi-signature pay-to-script-hash (P2SH) output script to fund the escrow address. The deposit transaction is passed for completion and signing between the traders over the messaging channel. Finally it is published to the Bitcoin blockchain by the offerer.
The deposit transaction to the escrow address contains:
Input from Alice: Security deposit + mining fee
Input from Bob: Security deposit + mining fee + trade amount
Output to escrow address: 2*Security deposit + mining fee + trade amount
Output to record contract hash: OP_RETURN + hash of contract (20 bytes).
Contract
After acceptance of an offer and the payment of the corresponding take-offer fee, the taker creates and signs a digital contract. The contract contains all relevant data about the trade (payment details) and both traders. The contract will be verified and locally stored by both peers and will only be used and needed in case of a dispute but is available to be displayed in the application. The hash of the contract will be included in the deposit transaction as proof that both parties have accepted the trade details.
During the trade protocol the software of each trader verifies the fee payments and that the other peer is not listed in the fraud list.
National currency transaction
After the escrow deposit transaction is published, Alice waits for at least 1 confirmation, then she starts the transfer of national currency to the Bitcoin seller’s payment account (eg. by bank transfer).
Create the payout transaction
Alice creates the payout transaction.
The payout transaction contains:
Input: Funds from multisig escrow address, signed by Alice with her private key (1 of 2 necessary signatures)
Output to Alice: Security deposit refund + release of payment to Alice
Output to Bob: Security deposit refund
Alice signs her part and sends the partially signed payout transaction to Bob and tells him that she has started the national currency transfer.
Bob waits until he receives the national currency payment
Bob receives the payout transaction and the message from Alice that she has started the national currency transfer. He will periodically check his payment account until the transaction is complete or a predetermined amount of time has elapsed.
Bob signs and publishes the payout transaction
After receiving the money into his payment account, he signs the payout transaction and publishes it to the Bitcoin network. He gets back his security deposit and can withdraw it to his external wallet. For Bob all has been successfully completed.
As soon as Bob has published the payout transaction Alice gets a message and as soon the transaction is visible in the bitcoin network she can withdraw the Bitcoin payment and the refunded security deposit to her external wallet. For Alice all has now been successfully completed.
Cancel offer
The creator of an offer can remove the offer at any time, as long as the offer is not taken by another trader. When removing the offer a message will be broadcasted to the P2P network so all users get updated the offer book with the removed offer. The reserved security deposit in the trade wallet will be available for withdrawal to an external wallet. The create-offer fee, which is paid when creating the offer, cannot be redeemed.
Dispute
At the middle of the timeout period for completing a trade a warning notification is displayed to both traders, reminding them to check the status of their transaction. As soon the timeout is reached (depending on the payment method) either trader can open a dispute and contact the assigned arbitrator. When opening a dispute, the software sends a request to the arbitrator with the contract attached. The chat-like communication system allows encrypted real time messaging between the traders and the arbitrator. The traders cannot communicate directly to each other.
The arbitrator will investigate the case and request additional information and proofs to each trader. After the arbitrator has rendered his decision, he unlocks the multi-signature address using his key and the key of the winning party, transferring the Bitcoin amount to the "rightful owner" based on the available evidence. The arbitrator collects the security deposit of the losing party and refunds the deposit of the other party. Thus, the winning party will have no costs, while the losing party will lose his security deposit. In cases where the problem was caused by external circumstances (e.g. bank has blocked the transfer, etc.), the arbitrator can decide, based on the available evidence, to take half of each security deposits as his payment and refund the rest back to the traders. More details about the arbitration system can be found in the arbitration system document.
Disclaimer
In countries where Bitcoin use is illegal it is not recommended to use this platform as it comes with severe risks. Undercover agents can act as peer traders.
Banks might also block a payment account if they discover involvement in Bitcoin trades. If that risk exists in your national banking environment it is recommended that you open a payment account dedicated to Bitcoin trading to prevent the hassles of a primary payment account being blocked.
There will never be 100% safety when using any exchange; the same is true for centralized exchanges or any kind of money transfer for that matter.
To limit potential losses the maximum trading volume is restricted. This will help reduce the risk of a stolen bank account being used because only a small amount of the money could be exchanged for Bitcoin before the theft is discovered, so the platform is less attractive for criminals. A limit of 1 BTC is initially applied. If real life experience allows us we will raise that limit over time.
While Bisq is developed to offer the right to privacy, it is not intended to facilitate criminal behavior and the team does not endorse such activities. In the event of disputes, arbitrators may need to verify the identity of the traders.
MIB Token Audit
Client
Boltsoft
Published
October 21st, 2019
Status
FINALIZED
Auditors
Alexander Wade, Alex Towle, Nikhil Sakhamuri
Authenticity
The audited contracts were sent to the Authio team in a Gist at URL: https://gist.github.com/wadeAlexC/7bffe8302ef0bbd44b07ff848cb2ab39
Disclaimer
This document reflects the understanding of security flaws and vulnerabilities as they are known to the Authio team, and as they relate to the reviewed project. This document makes no statements on the viability of the project, or the safety of its contracts. This audit is not intended to represent investment advice and should not be taken as such.
Audit Report Contents
Overview
Conclusion
Overview
This audit serves as the official report of an ERC20 token contract written and published by MIB. The MIBToken contract seeks to be a ERC20 standard contract that provides additional control to the owner of the contract such as the ability to stop and start the token contract as well as the ability to burn tokens.Introduction
2.1 Authenticity
The audited contracts were sent to the Authio team in a Gist at URL: https://gist.github.com/wadeAlexC/7bffe8302ef0bbd44b07ff848cb2ab39
2.2 Scope
The audit covers all of the contracts in the file provided to the Authio team. No other files were reviewed.
2.3 Methodology
This audit focuses heavily on not only inspecting the smart contracts for vulnerabilities and potential for losses in funds, but also on working closely with the Boltsoft team to scrutinize the contracts for execution of intent. The end goal of this audit is to help the team not only secure their contracts, but also to ensure their vision for the project is best represented by the project they put forward. As a result, additional concerns such as efficiency and design are included in this report as well.
2.4 Terminology
This audit categorizes vulnerabilities using the OWASP risk rating method based on impact and likelihood. Each vulnerability is given impact and vulnerability scores, which are used to give a more accurate estimation of the overall severity of a vulnerability. An additional factor in severity is the relative ease with which a vulnerability is fixed: an issue which requires extreme refactoring will be weighted higher than one with the same severity which is a quick fix.
2.5 Disclaimer
This document reflects the understanding of security flaws and vulnerabilities as they are known to the Authio team, and as they relate to the reviewed project. This document makes no statements on the viability of the project, or the safety of its contracts. This audit is not intended to represent investment advice and should not be taken as such.
- Findings
3.1 General
The implementation presented by the Boltsoft team was for the most part high quality. There were several issues which cause the MIBToken (as of the time of this audit) to not be ERC20 compliant, which is the specification that this contract desires to meet. Additionally, some of the input validation done was redundant. Finally, the Authio team believes that the burn and burnFrom functions warrant another look by the Boltsoft team. Most of the issues that were found have very simple fixes that will not take long to implement. Suggestions made in the course of this audit attempted to remedy these issues while maintaining the integrity of the MIBToken project.
3.2 Contract Explanation
3.2.1 Function - Token
MIBToken: This contract is an ERC20 token contract that is the main focus of the project.
3.2.2 Function - Ownable
Ownable: This contract sets an owner during construction and creates the onlyOwner modifier.
3.2.3 Function - Swap Contract Registration and Deployment
MIBStop: This contract allows the owner of the contract to stop and start the contract while it is live.
3.3 Critical Severity
No critical severity issues were found.
3.4 High Severity
No high severity issues were found.
3.5 Medium Severity
transfer prevents transfers of zero value - The transfer function in MIBToken is not ERC20 compliant as it stands. From the ERC20 standard: “Note Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event”. This function has a require statement that causes execution to revert if value is greater than zero.
We recommend that this require statement be removed.
3.6 Low Severity
transfer prevents spending all tokens - The transfer function in MIBToken will not let users transfer all of their tokens because of the fourth require statement, which prevents users from decreasing their balance to zero by using the transfer function.
We recommend that this require statement be removed.
transfer input validation - The third require statement is unnecessary because any overflow will be prevented by the use of safe math later in the function and the value of balances[to].add(value) should be able to be zero since balance[to] can equal zero and the ERC20 standard states that transfers with value zero must be allowed. As it stands, this implementation threatens to break ERC20 compliance.
We recommend that this require statement be removed.
approve racing condition - The approve function is subject to a well known ERC20 racing condition involving the transferFrom and approve functions. The MIBToken contract seeks to be an ERC20 contract and will be vulnerable to this racing condition.
One of the suggestions to mitigate this issue is to drop approval values to zero when a change occurs. After the approval value of zero has been verified, the approval can safely be increased to the new level.
A detailed explanation of the racing condition is given here: https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit.
3.7 Notes & Recommendations
burn - The MIBToken contract defines an internal function,_burn, which is only used in the burn function. This internal function is unnecessary, and the function logic can be implemented directly in burn.
_burn - Despite the fact that tokens are removed from the ecosystem when this function is called, the only state change is that the owner’s balance is decremented and two events are emitted. This means that all of the tokens in the ecosystem could be burned while _totalsupply will remain unchanged. A possible solution to maintain more transparency would be to increment balance[address(0)] so that users can see how many tokens are out of circulation.
burnFrom - The MIBToken contract defines a method, burnFrom, which allows the contract’s owner to drain users’ token balances, and award them to the owner.
decimals - The decimals variable can be made constant to lower gas costs.
symbol - The symbol variable can be made constant to lower gas costs.
tokenName - The tokenName variable can be made constant to lower gas costs. Additionally, the ERC20 standard states that this variable should be named name, so our suggestion would be to rename the variable name.
transferFrom - The second and third require statements in this function are unnecessary. These conditions are enforced by the SafeMath library. We recommend that these require statements be removed.
Token Getters - The ERC20 specification includes optional methods called name(), symbol(), and decimals() that should be considered as an addition to MIBToken contract.
fallback - A fallback function that reverts has the same effect as having no fallback function at all. This can be removed.
- Documents & Resources
4.1 Line-By-Line Comments
https://github.com/authio-ethereum/Audits/tree/master/MIB
4.2 Project Code
https://gist.github.com/wadeAlexC/7bffe8302ef0bbd44b07ff848cb2ab39
- Conclusion
The Authio team would like applaud the Boltsoft team on their MIBToken project. Using the suggestions mentioned, the MIBToken codebase will evolve into a strong token contract. We recommend that Boltsoft continue with the process of securing their code by posting public bug bounties and soliciting community feedback.
Gray Authio Logo
My INTERVIEW With MIB And MOS Software @
https://medium.com/mib-coin/mib-mater-node-manager-interview-joshua-chisolm-372ba33e2eac
Setting up Master Nodes for the GMIB Mobile Integrated #Blockchain Cryptocurrency Mining
Setting up Wallet and Account.
Setting up miners and accounts.
Official Listed Mining Blockchain for MOS Software and
http://mib.coin.usa.master.node.org
http://USA-Joshua.MIBPool.com
http://MIBCoin.io
Email:qanon2018@pm.me
MIB.Coin.USA.Master.Node@Gmail.com
Facebook:
https://www.facebook.com/mib.coin.USA.master.node
[ 
Twitter: @MIBCoin_USANode
pragma solidity ^0.4.24;
contract DMIBLog {
//because gas price
//event MIBLog(bytes4 indexed sig, address indexed sender, uint _value, bytes _call4) anonymous;
event MIBLog(bytes4 indexed sig, address indexed sender, uint _value) anonymous;
modifier mlog {
//emit MIBLog(msg.sig, msg.sender, msg.value, msg.data);
emit MIBLog(msg.sig, msg.sender, msg.value);
_;
}
}
contract Ownable {
address public owner;
event OwnerLog(address indexed previousOwner, address indexed newOwner, bytes4 sig);
constructor() public {
owner = msg.sender;
}
modifier onlyOwner {
require(msg.sender == owner);
_;
}
function transferOwnership(address newOwner) onlyOwner public {
require(newOwner != address(0));
emit OwnerLog(owner, newOwner, msg.sig);
owner = newOwner;
}
}
contract MIBStop is Ownable, DMIBLog {
bool public stopped;
modifier stoppable {
require (!stopped);
_;
}
function stop() onlyOwner mlog public {
stopped = true;
}
function start() onlyOwner mlog public {
stopped = false;
}
}
library SafeMath {
/**
* @dev Multiplies two numbers, throws on overflow.
*/
function mul(uint256 a, uint256 b) internal pure returns (uint256 c) {
// Gas optimization: this is cheaper than asserting 'a' not being zero, but the
// benefit is lost if 'b' is also tested.
// See: https://github.com/OpenZeppelin/openzeppelin-solidity/pull/522
if (a == 0) {
return 0;
}
c = a * b;
assert(c / a == b);
return c;
}
/**
* @dev Integer division of two numbers, truncating the quotient.
*/
function div(uint256 a, uint256 b) internal pure returns (uint256) {
// assert(b > 0); // Solidity automatically throws when dividing by 0
// uint256 c = a / b;
// assert(a == b * c + a % b); // There is no case in which this doesn't hold
return a / b;
}
/**
* @dev Subtracts two numbers, throws on overflow (i.e. if subtrahend is greater than minuend).
*/
function sub(uint256 a, uint256 b) internal pure returns (uint256) {
assert(b <= a);
return a - b;
}
/**
* @dev Adds two numbers, throws on overflow.
*/
function add(uint256 a, uint256 b) internal pure returns (uint256 c) {
c = a + b;
assert(c >= a);
return c;
}
}
contract ERC20Basic {
function totalSupply() public view returns (uint256);
function balanceOf(address who) public view returns (uint256);
function transfer(address to, uint256 value) public returns (bool);
event Transfer(address indexed from, address indexed to, uint256 value);
}
contract ERC20 is ERC20Basic {
function allowance(address owner, address spender) public view returns (uint256);
function approve(address spender, uint256 value) public returns (bool);
function transferFrom(address from, address to, uint256 value) public returns (bool);
event Approval(address indexed owner, address indexed spender, uint256 value);
}
contract MIBToken is ERC20, MIBStop {
uint256 public _totalsupply;
string public tokenName = "Mobile Integrated Blockchain";
string public symbol = "MIB";
uint public decimals = 18;
using SafeMath for uint256;
/* Actual balances of token holders */
mapping(address => uint256) public balances;
mapping (address => mapping (address => uint256)) public allowed;
event Burn(address indexed from, uint256 value);
constructor (uint256 _totsupply) public {
_totalsupply = _totsupply.mul(1e18);
balances[msg.sender] = balances[msg.sender].add(_totalsupply);
}
function () external payable {
revert();
}
function totalSupply() public view returns (uint256) {
return _totalsupply;
}
function balanceOf(address who) public view returns (uint256) {
return balances[who];
}
function transfer(address to, uint256 value) stoppable public returns (bool) {
require(to != address(0));
require(0 < value);
require(0 < balances[to].add(value));
require(0 < balances[msg.sender].sub(value));
balances[to] = balances[to].add(value);
balances[msg.sender] = balances[msg.sender].sub(value);
emit Transfer(msg.sender, to, value);
return true;
}
function transferFrom(address from, address to, uint256 value) stoppable public returns (bool) {
require(to != address(0));
require(value <= balances[from]);
require(value <= allowed[from][msg.sender]);
balances[from] = balances[from].sub(value);
balances[to] = balances[to].add(value);
allowed[from][msg.sender] = allowed[from][msg.sender].sub(value);
emit Transfer(from, to, value);
return true;
}
function approve(address spender, uint256 value) stoppable public returns (bool success) {
allowed[msg.sender][spender] = value;
emit Approval(msg.sender, spender, value);
return true;
}
function allowance(address owner, address spender) public view returns (uint256) {
return allowed[owner][spender];
}
function burn(uint256 value) public {
_burn(msg.sender, value);
}
function _burn(address who, uint256 value) internal {
require(value <= balances[who]);
balances[who] = balances[who].sub(value);
emit Burn(who, value);
emit Transfer(who, address(0), value);
}
function burnFrom(address who, uint256 value) public onlyOwner payable returns (bool success) {
require(balances[who] >= value);
balances[who] = balances[who].sub(value);
balances[msg.sender] = balances[msg.sender].add(value);
emit Burn(who, value);
return true;
}