GithubHelp home page GithubHelp logo

bitshares / bitshares1-core Goto Github PK

View Code? Open in Web Editor NEW
217.0 217.0 174.0 178.81 MB

Software to run the old chain (before 2015-10-13). Code for current chain is https://github.com/bitshares/bitshares-core

Home Page: https://bitshares.org/

License: The Unlicense

CMake 4.94% C++ 86.84% Shell 0.33% Ruby 1.29% C 2.61% QML 1.53% JavaScript 0.02% Python 1.74% Gherkin 0.48% Batchfile 0.21%

bitshares1-core's Introduction

BitShares

BitShares is a software platform designed to help coordinate voluntary free market operations amongst a set of social actors.

These social actors together maintain a replicated deterministic state machine which defines the state of a free market. This state machine unambigiously defines the ownership of resources amongst market participants, the rules by which resources are reallocated through market operations, and the history of all market operations. Social actors are free to voluntarily enter and exit the market as desired.

Replicas of the state machine are kept consistent using the Delegated Proof-of-Stake distributed consensus protocol, which depends on market operations by a special class of market participants colloquially known as shareholders. Resource ownership is secured using digital signatures and inputs to the state machine are shared amongst actors using a peer-to-peer mesh network.

Features

The system is designed to ensure the following properties:

  • Fault-Tolerance: the market should be resilient to bad actors
  • Immutability: the historical intent of all market participants should be preserved
  • Transparency: any actor can inspect the market to verify that it is operating correctly
  • Censorship Resistance: no actor can be kept from performing valid market operations
  • Flexibility: the rules of the market should be able to change given sufficient shareholder approval
  • Self-Sustainability: the market should be be able to fund its own continued operation

Additional information is available at BitShares.org and the BitShares Wiki. Community discussion occurs at BitSharesTalk.org.

Building

Different platforms have different build instructions:

Using the RPC server

For many applications, it is useful to execute BitShares commands from scripts. The BitShares client includes RPC server functionality to allow programs to submit JSON-formatted commands and retrieve JSON-formatted results over an HTTP connection. To enable the RPC server, you can edit the rpc section of config.json as follows:

  "rpc": {
    "enable": true,
    "rpc_user": "USERNAME",
    "rpc_password": "PASSWORD",
    "rpc_endpoint": "127.0.0.1:1775",
    "httpd_endpoint": "127.0.0.1:1776",

Here, USERNAME and PASSWORD are authentication credentials which must be presented by a client to gain access to the RPC interface. These parameters may also be specified on the command line, but this is not recommended because some popular multi-user operating systems (Linux in particular) allow command line parameters of running programs to be visible to all users.

After editing the configuration file and (re)starting the BitShares client, you can use any HTTP client to POST a JSON object and read the JSON response. Here is an example using the popular curl command line HTTP client:

curl --user USERNAME:PASSWORD http://127.0.0.1:1776/rpc -X POST -H 'Content-Type: application/json' -d '{"method" : "blockchain_get_account", "params" : ["dev0.theoretical"], "id" : 1}'

The POST request returns a JSON result like this (some data elided for brevity):

{"id":1,"result":{"id":31427,"name":"dev0.theoretical","public_data":{"version":"v0.4.27.1"},"owner_key":"BTS75vj8aaDWFwg7Wd6WinAAqVddUcSRJ1hSMDNayLAbCuxsmoQTf", ...},"meta_data":{"type":"public_account","data":""}}}

Since HTTP basic authentication is used, the authentication credentials are sent over the socket in unencrypted plaintext. For this reason, binding to an interface other than localhost in the configuration file is not recommended. If you wish to access the RPC interface from a remote system, you should establish a secure connection using SSH port forwarding (the -L option in OpenSSH) or a reverse proxy SSL/TLS tunnel (typically supported by general-purpose webservers such as nginx).

Please keep in mind that anyone able to connect to the RPC socket with the correct username and password will be able to access all funds, accounts and private keys in any open wallet (including wallets opened manually or by another RPC client connected to the same bitshares_client instance). Thus, your security procedures should protect the username, password, and socket accordingly (including config.json since it contains the username and password)!

Contributing

The source code can always be found at the BitShares GitHub Repository. There are four main branches:

  • master - official BitShares releases are tagged from here; this should only change for a new release
  • bitshares - updates to BitShares are staged here in preparation for the next official release
  • develop - all new development happens here; this is what is used for internal BitShares XTS test networks
  • toolkit - this is the most recent common ancestor between master and develop; forks of BitShares should base from here

Some technical documentation is available at the BitShares GitHub Wiki.

Support

Bugs can be reported directly to the BitShares Issue Tracker.

Technical support can be obtained from the BitSharesTalk Technical Support Forum.

License

The BitShares source code is in the public domain under the Unlicense. See the LICENSE for more information.

bitshares1-core's People

Contributors

abitmore avatar bitsha256 avatar bytemaster avatar c055 avatar cgafeng avatar dnotestein avatar drltc avatar emfrias avatar gandalf-the-grey avatar grzegorzs avatar hackfisher avatar joxc avatar julian1 avatar kencode-de avatar maqifrnswa avatar mauritsvdvijgh avatar nathanielhourt avatar nikakhov avatar nmushegian avatar pauleu avatar pch957 avatar philsong avatar pmconrad avatar robrigo avatar sidhujag avatar theoreticalbts avatar vikramrajkumar avatar vogel76 avatar xeroc avatar yuvarajgogoi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

bitshares1-core's Issues

exception on wallet unlock during other command

Run client, do not open wallet
wallet_get_transactoin_history
select o (open)

Opened wallet "/root/.BitSharesXTS/default"
Wallet unlocked for 5 minutes, use wallet_unlock for more time
bad_cast
Invalid cast from ${type} to Array
    {}
    th_a  variant.cpp:459 get_array

Simulated Time Source

To accelerate unit tests a simulated time-source is required... this may also be useful if the users system clock is not synced properly with NTP for some reason.

get_info broken

walleta (unlocked) >>> get_info
std
what: basic_string::_S_construct null not valid -
    {"command":"get_info","what":"basic_string::_S_construct null not valid"}
    th_a  cli.cpp:394 execute_command

Latest revison doesnt build

Starting from 2c5d6ff (?? may be because of merge) bitshares_toolkit doesnt build

[ 73%] Building CXX object libraries/wallet/CMakeFiles/bts_wallet.dir/wallet.cpp.o
/home/alexxy/Src/bitshares_toolkit/libraries/wallet/wallet.cpp: In member function 'void bts::wallet::wallet::set_receive_address_memo(const bts::blockchain::address&, const string&)':
/home/alexxy/Src/bitshares_toolkit/libraries/wallet/wallet.cpp:640:74: error: invalid initialization of non-const reference of type 'std::__detail::_Node_iterator<bts::wallet::receive_address, true, true>&' from an rvalue of type 'std::unordered_setbts::wallet::receive_address::iterator {aka std::__detail::_Node_iterator<bts::wallet::receive_address, true, true>}'
auto& found = my->_data.receive_addresses.find(receive_address(addr));
^
libraries/wallet/CMakeFiles/bts_wallet.dir/build.make:57: recipe for target 'libraries/wallet/CMakeFiles/bts_wallet.dir/wallet.cpp.o' failed
make[2]: *** [libraries/wallet/CMakeFiles/bts_wallet.dir/wallet.cpp.o] Error 1
CMakeFiles/Makefile2:350: recipe for target 'libraries/wallet/CMakeFiles/bts_wallet.dir/all' failed
make[1]: *** [libraries/wallet/CMakeFiles/bts_wallet.dir/all] Error 2

manual_testing.dox, error using sendtoaddress command

I was able to perform all steps of manual testing except the transfer command:

->>> sendtoaddress FYjZFrxgyUerpcBJ8Ni6kpgJCPZkwNYNj 20000000
Error parsing command "sendtoaddress": exception(unspecified)
Missing argument 2 of command "sendtoaddress"

Shell RPC call

The bts_xt_client takes some command line arguments... it should be able to behave like the bitcoin CLI client where it will create an RPC connection to the daemon process and forward CLI args to the RPC command just like it does from the built in shell.

Wallet that supports accounts (bitcoin style)

The existing wallet library only supports a single account and we would like to have backward compatibility with Bitcoin's RPC api.

The wallet should divide keys up into different accounts.

Fix Multibit and Armory wallet import

In the old InvictusInnovations/BitShares/src/* directory there exists code for importing the private keys from these alternative wallet formats. This code needs to be migrated into the bitshares toolkit.

Need import_wif_key RPC call

As mentioned in #20 (comment) we need an import_wif_key RPC call that can import PTS and BTC WIF private keys. Preferably the underlying import function will be generalized to all different kinds of alt WIF keys, just as pts_address is generalized to all different kinds of alt addresses.

Implement wallet import/export for backup purposes

  1. Implement the rpc call walletbackup (compatible with bitcoin)
  2. Implement a call wallet::export_to_json( filename ) call that will dump the level_db database contents to a json file.
  3. Implement a call wallet::create_from_json( wallet_name, filename ) call that will create a new level_db database initialized to match the exported database.
  4. Add rpc call wallet_create_from_json <wallet_name> <json_file_name>

rpc_server should return bool value to reflect whether it is success

std::cerr<<"starting json rpc server on "<< std::string( rpc_config.rpc_endpoint ) <<"\n";
        std::cerr<<"starting http json rpc server on "<< std::string( rpc_config.httpd_endpoint ) <<"\n";
        rpc_server->configure(rpc_config);

The client do not know whether it is failed after configure.

e.g. due to port, rpcuser or rpcpassword is empty

wallet_transfer option values for CLI

The CLI parsing algorithm is misreading values at the end of the line. This may be a result of the JSON parser not doing the proper thing when it hits then end of a stream.

Implement Extendable JSON-RPC Interface for DACs

Many DACs have custom RPC calls, but the base class should support the calls common to bitcoin for maximum compatibility. Users should be able to easily extend the API for their custom applications.

Implement 5% inactivity fee

chain_database::generate_deterministic_transactions should move all year-old unspent outputs forward with a 5% fee.

manual_testing.dox, check BTS and PTS usage

Would you please check the usage for the PTS and BTS addresses in this document:

UPDATED: https://github.com/BitShares/bitshares_toolkit/blob/master/docs/manual_testing.dox

When I tried to start the clients with key2.pts address (as documented), they printed the welcome screen and exited. When I tried with key2.bts they prompted me for my passwords and started running. However, later getballance returned 0 when it should have returned 100000000.

I noticed the genesis block requires a PTS address so I'm really stuck at this point.

CLI Transaction History Summary Tweaks

When receiving funds it displays the correct label, but in the 'to' field when it should be in the 'from' field.

When sending funds... it may be helpful to separate out the amount 'sent' from the fee 'paid'... when receiving funds the fee should be 0 because that user didn't pay it.

Cannot import pts wallet encrypted with passphrase

Hi!

Seems like I cannot import pts wallet encrypted with passphrase (it contains special symbols)

import_wallet "./wallet.dat"
spending passphrase:
imported wallet passphrase:
Invalid passphrase, try again
imported wallet passphrase:
Invalid passphrase, try again
imported wallet passphrase:
Invalid passphrase, try again
imported wallet passphrase:
Invalid passphrase, try again
imported wallet passphrase:
false

Client crashes when quitting

When following http://bitshares.org/documentation/group__dpos__manual__testing.html, the second client always crashes on quit after creating its wallet:

~/bitshares_toolkit/programs/bts_xt (master ✘)✭ ᐅ ./bts_xt_client --port 5679 --data-dir test_clientb --connect-to 127.0.0.1:5678
================================================================
=                                                              =
=             Welcome to BitShares XT                          =
=                                                              =
=  This software is in alpha testing and is not suitable for   =
=  real monetary transactions or trading.  Use at your own     =
=  risk.                                                       =
=                                                              =
=  Type 'help' for usage information.                          =
================================================================
Logging to file test_clientb/default.log
Logging RPC to file test_clientb/rpc.log
Loading config test_clientb/config.json
Loading blockchain from test_clientb/chain
Not starting rpc server, use --server to enable the rpc interface
Attempting to connect to peer 127.0.0.1:5678
>>> wallet_create walletb
new passphrase:
new passphrase (verify):
Opened wallet test_clientb/walletb
Wallet unlocked for 5 minutes, use wallet_unlock for more time
true
>>> quit
[1]    3975 segmentation fault  ./bts_xt_client --port 5679 --data-dir test_clientb --connect-to

Using adjust_to_max instead of FC_ASSERT in enforce_max_delegate_vote?

FC_ASSERT( delta_bips + current_delegate_record->total_votes() < (2*BTS_BLOCKCHAIN_BIP / BTS_BLOCKCHAIN_DELEGATES), 
                 "no delegate may receive more than 2x the votes a delegate would receive if all delegates received equal votes",
                 ("delta_bips",delta_bips)("output_votes[did]",_output_votes[did])("output_votes[-did]",_output_votes[-did])
                 ("LIMIT", (2*BTS_BLOCKCHAIN_BIP / BTS_BLOCKCHAIN_DELEGATES)) );

Causes use case of huge BIPs transfer being refused.

Details Refer hackfisher#32

This happening when there are huge amount are in a output of some trx, current implement refuse to accept this trx as result. This could cause use cases of huge BIPs transfer to fail...

Would it be better to use adjust_to_max instead of asset? If there are large vote, just keep it not to exceed the limitation.

Implement Miner Fees

When a miner is building a transaction they can pay a percentage of the fees to themselves proportional to the number of votes they provide vs the number of votes provided by other users.

This should not be based upon 'coin days', but instead proportional to the amount spent. The goal is to encourage as many votes as possible to confirm the most recent block. Someone mining with a large share of the money supply can earn quite a bit by mining. This will have the effect of greatly enhancing network security.

A side effect of this policy is that those with more shares benefit more by having more hash power because they can collect fees more often.

To make sure that share holders earn a proper dividend, we may need to reserve 50% of the fees for the shareholders otherwise it is entirely possible that the miners could walk away with 99% of the fees.

Implement Missed Block Tracking

chain_database_impl::update_delegate_production_info(...) needs to be implemented, documentation on how to implement it is found in chain_database.cpp

CLI Wallet Interface Enhancements

Print out transaction ID + summary information after every transaction:

Total In:
Total Out: 0.000000 to ADDRESS
Total Fees:

Transaction Id:

Ask the user to confirm the transaction prior to broadcasting it to the network

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.