eosio / eos

An open source smart contract platform

EOSIO - The Most Powerful Infrastructure for Decentralized Applications

Welcome to the EOSIO source code repository! This software enables businesses to rapidly build and deploy high-performance and high-security blockchain-based applications.

Some of the groundbreaking features of EOSIO include:

1. Free Rate Limited Transactions
2. Low Latency Block confirmation (0.5 seconds)
3. Low-overhead Byzantine Fault Tolerant Finality
4. Designed for optional high-overhead, low-latency BFT finality
5. Smart contract platform powered by WebAssembly
6. Designed for Sparse Header Light Client Validation
7. Scheduled Recurring Transactions
8. Time Delay Security
9. Hierarchical Role Based Permissions
10. Support for Biometric Hardware Secured Keys (e.g. Apple Secure Enclave)
11. Designed for Parallel Execution of Context Free Validation Logic
12. Designed for Inter Blockchain Communication

Disclaimer

Block.one is neither launching nor operating any initial public blockchains based upon the EOSIO software. This release refers only to version 1.0 of our open source software. We caution those who wish to use blockchains built on EOSIO to carefully vet the companies and organizations launching blockchains based on EOSIO before disclosing any private keys to their derivative software.

Official Testnet

testnet.eos.io

Supported Operating Systems

EOSIO currently supports the following operating systems:

1. Amazon Linux 2
2. CentOS 7
3. CentOS 7.x
4. CentOS 8
5. Ubuntu 16.04
6. Ubuntu 18.04
7. Ubuntu 20.04
8. MacOS 10.14 (Mojave)
9. MacOS 10.15 (Catalina)

---

Note: It may be possible to install EOSIO on other Unix-based operating systems. This is not officially supported, though.

---

Software Installation

If you are new to EOSIO, it is recommended that you install the EOSIO Prebuilt Binaries, then proceed to the Getting Started Guide. If you are an advanced developer, a block producer, or no binaries are available for your platform, you may need to Build EOSIO from source.

---

Note: If you used our scripts to build/install EOSIO, please run the Uninstall Script before using our prebuilt binary packages.

---

Prebuilt Binaries

Prebuilt EOSIO software packages are available for the operating systems below. Find and follow the instructions for your OS:

Mac OS X:

Mac OS X Brew Install

brew tap eosio/eosio
brew install eosio

Note: On MacOS 10.15 (Catalina), there is a chance to face the linking error below which prevents successful installation of EOSIO:

Reinstalling 1 broken dependent from source:
eosio/eosio/eosio

The following Homebrew commands will resolve this issue:

brew link eosio

Mac OS X Brew Uninstall

brew remove eosio

Ubuntu Linux:

Ubuntu 20.04 Package Install

wget https://github.com/eosio/eos/releases/download/v2.1.0/eosio_2.1.0-1-ubuntu-20.04_amd64.deb
sudo apt install ./eosio_2.1.0-1-ubuntu-20.04_amd64.deb

Ubuntu 18.04 Package Install

wget https://github.com/eosio/eos/releases/download/v2.1.0/eosio_2.1.0-1-ubuntu-18.04_amd64.deb
sudo apt install ./eosio_2.1.0-1-ubuntu-18.04_amd64.deb

Ubuntu 16.04 Package Install

wget https://github.com/eosio/eos/releases/download/v2.1.0/eosio_2.1.0-1-ubuntu-16.04_amd64.deb
sudo apt install ./eosio_2.1.0-1-ubuntu-16.04_amd64.deb

Ubuntu Package Uninstall

sudo apt remove eosio

RPM-based (CentOS, Amazon Linux, etc.):

RPM Package Install CentOS 7

wget https://github.com/eosio/eos/releases/download/v2.1.0/eosio-2.1.0-1.el7.x86_64.rpm
sudo yum install ./eosio-2.1.0-1.el7.x86_64.rpm

RPM Package Install CentOS 8

wget https://github.com/eosio/eos/releases/download/v2.1.0/eosio-2.1.0-1.el8.x86_64.rpm
sudo yum install ./eosio-2.1.0-1.el8.x86_64.rpm

RPM Package Uninstall

sudo yum remove eosio

Uninstall Script

To uninstall the EOSIO built/installed binaries and dependencies, run:

./scripts/eosio_uninstall.sh

Documentation

1. Nodeos
   • Usage
   • Replays
   • Chain API Reference
   • Troubleshooting
2. Cleos
3. Keosd

Resources

1. Website
2. Blog
3. Developer Portal
4. StackExchange for Q&A
5. Community Telegram Group
6. Developer Telegram Group
7. White Paper
8. Roadmap

Getting Started

Instructions detailing the process of getting the software, building it, running a simple test network that produces blocks, account creation and uploading a sample contract to the blockchain can be found in the Getting Started Guide.

Contributing

Contributing Guide

Code of Conduct

License

EOSIO is released under the open source MIT license and is offered “AS IS” without warranty of any kind, express or implied. Any security provided by the EOSIO software depends in part on how it is used, configured, and deployed. EOSIO is built upon many third-party libraries such as WABT (Apache License) and WAVM (BSD 3-clause) which are also provided “AS IS” without warranty of any kind. Without limiting the generality of the foregoing, Block.one makes no representation or guarantee that EOSIO or any third-party libraries will perform as intended or will be free of errors, bugs or faulty code. Both may fail in large or small ways that could completely or partially limit functionality or compromise computer systems. If you use or implement EOSIO, you do so at your own risk. In no event will Block.one be liable to any party for any damages whatsoever, even if it had been advised of the possibility of damage.

Important

See LICENSE for copyright and license terms.

All repositories and other materials are provided subject to the terms of this IMPORTANT notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources, and forward-looking statements. By accessing any of our repositories and other materials, you accept and agree to the terms of the notice.

eos's Issues

Is Eos More potential than Ethereum?

I follow Block chaining technique, but my research on it is initial. So, does anyone know whether eos is better than eth?

Continuous Growing Merkel of All Block IDs

In order to support the efficient generation of merkle proofs and validation thereof, it is useful to have a merkle tree comprising all blocks. This tree can be calculated on an incremental basis by tracking the leading edge of the tree.

We can adapt this code from Steemit (after 4/18/2017)
steemit/steem@a2b2d8e#diff-f947dc99291f1eb724e650d3dd4b9b53

When calculating the Merkle Tree of the transactions inside a block, we should add one extra leaf at the end which points to the ROOT of the GLOBAL HEADER MERKEL TREE.

We can then follow the hashes from the head block to any transaction like so...

HEAD BLOCK HEADER -> TRX_MROOT-> RIGHT MOST BRANCH OF TRX_MROOT -> PRIOR GLOBAL HEADER MERKLE ROOT -> BRANCH_TO_ANY_BLOCK_ID -> TRX_MROOT -> BRANCH_TO_ANY_TRX

Generally, a light client will be able to track recent block headers of any chain to validate new transactions but for validating OLD transactions it should be possible to generate a slightly larger proof without requiring all nodes to keep all block headers.

Proposed API JSON response format

Success

{"status": "success", "data": { ... }}

Error

Instead of:

echo '{"block_num_or_id": 9999}' | curl http://127.0.0.1:8888/v1/chain/get_block -d @-
unknown block

Return valid JSON:

Example 1

echo '{"block_num_or_id": 9999}' | curl http://127.0.0.1:8888/v1/chain/get_block -d @-
{"status": "error", "message": "unknown block"}

Example 2

If a per-field error is desirable, this is another format:

echo '{"block_num_or_id": 9999}' | curl http://127.0.0.1:8888/v1/chain/get_block -d @-
{"status": "fail", "data": {"block_num_or_id": "unknown block"}}

From: https://stackoverflow.com/questions/12806386/standard-json-api-response-format
See JSend: http://labs.omniti.com/labs/jsend#Sohowsitwork

Cannot use from US?

I'm quite interested in the project,code and wondering if I can even use if I'm located in the US? I'm unable to participate from eos site. Is this true that I can't connect or utilize if in the US?... or does this even apply?

I was even interested in investing but not if we're unable to use.

starting testnet: consider using the --genesis-timestamp

Starting a testnet I get:

Your genesis seems to have an old timestamp
Please consider using the --genesis-timestamp option to give your genesis a recent timestamp

Where should I set --genesis-timestamp?

Transactions should Explicitly Declare Required Authority Level

In BitShares and Steem the required authority is implicitly defined by the operation type and data contained within. Under EOS this is no longer the case, message types are dynamic and defined at run time.

The goal is to facilitate validating that a transaction has all required signatures for the declared authority without having to know how to read internals of messages.

struct transaction {
    ... header....
    vector<message> messages;
}

struct permission {
    account_id               account   
    permission_id_type permission; // owner, active, or custom...
}

struct signed_transaction : public transaction {
     vector<signature>   signatures;
     vector<permission> required_authority;
}

The blockchain can verify that the given signatures provide the required authority without having to execute scripts.

Before applying a message to a contract, the blockchain can look up the permission level required for the SENDER / TO pair and verify that the permission is in the required_authority set of the transaction.

Implement producer-median-voted blockchain configuration options

As specified in the Community Contract Spec, in the Producer Configurable Properties section, the producers will vote on various parameters for the blockchain, and the median of their votes will be used by the chain.

Implement this system.

could not gain write access to the shared memory file

Hi! I've caught the error wich related with rights i think. But i can't understand how to solve. Please help!

graphene@d657759b57d5:/eos$ eosd --config=./data-dir/config.ini
1540149ms thread-0   chain_plugin.cpp:60           plugin_initialize    ] initializing chain plugin
1540149ms thread-0   net_plugin.cpp:514            plugin_initialize    ] Initialize net plugin
1540149ms thread-0   net_plugin.cpp:520            plugin_initialize    ] configured net to listen on 127.0.0.1:9876
1540150ms thread-0   main.cpp:29                   main                 ] /eos/libraries/chainbase/src/chainbase.cpp(102): Throw in function chainbase::database::database(const bfs::path &, chainbase::database::open_flags, uint64_t)
Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
std::exception::what: could not gain write access to the shared memory file

Fix Merkle Root Calculation

Implement Last Irreversible Block, et al

Currently the blockchain doesn't properly implement the construct of the last irreversible block. The last irreversible block (LIB) is the most recent block which has been acknowledged by 2/3 of the witnesses, where a block b is "acknowledged" by a witness w if w either produced b, or w produced some other block for which b is a direct or indirect parent.

• Calculate the LIB, and track it in dynamic_global_property_object
• Only write irreversible blocks to disk
• Rewind the blockchain to the LIB when opening the database

Update Message structure to include "code" field

Under the existing architecture it is assumed that the "code" and the "data" both belong to a single contract; however, this architecture will greatly limit ability for applications to communicate and execute in parallel. A currency contract would be limited to single threaded performance because it owns the entire balance table.

We would like to introduce the concept that the code for @Currency could operate on the data for @user, but would be restricted to modifying a segment of @user's data managed by @Currency. It would be able to read any other state stored by other contracts in @user's data.

We can achieve this by adding a "code" field to each message. The current behavior can be mirrored by setting the "code' field and the "recipient" field to the same value; however, with the addition of this field new contracts could be constructed such that "code" and "recipient" are different.

The API exposed for reading and writing data would take an extra argument specifying the "code context".

Building latest Web Assemble changes

After adding the llvm dependency in Docker/Dockerfile (RUN pacman ... llvm) the build progresses nicely.

UNTIL

error: no member named 'parseDecimalF64' in namespace 'std'

/usr/sbin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/stdlib.h:75:12: error: no member named 'parseDecimalF64' in namespace 'std'
using std::strtod;
      ~~~~~^

So, is this really true? Is Mac's version of clang really going around masquerading as g++?

https://stackoverflow.com/questions/25322489/error-no-member-named-stod-in-namespace-std

fc::variant deserialization fails for boost::multiprecision::number<T>

Ubuntu 16.04.2 LTS
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
boost 1.60.0

UInt16 val16(150);
fc::variant v;
fc::to_variant(val16, v);

UInt16 tmp;
fc::from_variant(v, tmp);
BOOST_CHECK_EQUAL( val16, tmp );

The above test fails when using decltype(n)

template<typename T> void from_variant( const variant& v, boost::multiprecision::number<T>& n ) {
      n = decltype(n)(v.get_string());
}

Fixed using the type explicitly

template<typename T> void from_variant( const variant& v, boost::multiprecision::number<T>& n ) {
      n = boost::multiprecision::number<T>(v.get_string());
}

chain_controller::validate_tapos() fails because deserialization of refBlockNum and refBlockPrefix is wrong

Word list: Words.cpp

I assume words.cpp is for a mnemonic seed:
https://github.com/EOSIO/eos/blob/master/libraries/utilities/words.cpp

Please consider using the word list from the the bip 0039 spec. We get other language translations as they become available. The dictionaries are created with the following in mind:

https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#wordlist

Bip 0039 provides a way to create the seed with a hidden checksum. I have used http://npmjs.com bip39 package to create my seeds. The checksum is compatible with other existing wallets including Ethereum wallets like MyEtherWallet.

There are a few other use cases when creating and re-entering mnemonic seeds that I plan to support:

https://www.npmjs.com/package/bip39-seeder

Authority Check Recursion Depth Limit Check

AuthorityChecker::satisfied() has a #warning TODO that is spamming output because it is in header. Moving that TODO to a this issue.

Please move ROADMAP.md to EOSIO/Documentation

In order to make translation easier using https://crowdin.com/project/eos-docs please move ROADMAP.md to EOSIO/Documentation repository.

make error!!

[ 86%] Building CXX object plugins/producer_plugin/CMakeFiles/producer_plugin.dir/producer_plugin.cpp.o In file included from /home/ubuntu/eos/plugins/chain_plugin/include/eos/chain_plugin/chain_plugin.hpp:3:0, from /home/ubuntu/eos/plugins/producer_plugin/include/eos/producer_plugin/producer_plugin.hpp:26, from /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:24: /home/ubuntu/eos/libraries/chain/include/eos/chain/chain_controller.hpp:122:2: warning: #warning QUESTION Should we be setting o.base_scope here? [-Wcpp] #warning QUESTION Should we be setting o.base_scope here? ^ /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp: In member function ?𻱶irtual void eos::producer_plugin::set_program_options(boost::program_options::options_description&, boost::program_options::options_description&?𼀺 /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:101:38: error: reference to ?𻱢po?𼀠is ambiguous ("enable-stale-production", bpo::bool_switch()->notifier([this](bool e){my->_production_enabled = e;}), " ^ /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:41:39: note: candidates are: namespace bpo = boost::boost::program_options; namespace bpo = boost::program_options; ^ In file included from /home/ubuntu/eos/plugins/chain_plugin/include/eos/chain_plugin/chain_plugin.hpp:2:0, from /home/ubuntu/eos/plugins/producer_plugin/include/eos/producer_plugin/producer_plugin.hpp:26, from /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:24: /home/ubuntu/eos/libraries/appbase/include/appbase/application.hpp:8:42: note: namespace appbase::bpo = boost::boost::program_options; namespace bpo = boost::program_options; ^ /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:102:37: error: reference to ?𻱢po?𼀠is ambiguous ("required-participation", bpo::bool_switch()->notifier([this](int e){my->_required_producer_participatio ^ /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:41:39: note: candidates are: namespace bpo = boost::boost::program_options; namespace bpo = boost::program_options; ^ In file included from /home/ubuntu/eos/plugins/chain_plugin/include/eos/chain_plugin/chain_plugin.hpp:2:0, from /home/ubuntu/eos/plugins/producer_plugin/include/eos/producer_plugin/producer_plugin.hpp:26, from /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:24: /home/ubuntu/eos/libraries/appbase/include/appbase/application.hpp:8:42: note: namespace appbase::bpo = boost::boost::program_options; namespace bpo = boost::program_options; ^ /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:103:28: error: reference to ?𻱢po?𼀠is ambiguous ("producer-id,w", bpo::value<vector<string>>()->composing()->multitoken(), ^ /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:41:39: note: candidates are: namespace bpo = boost::boost::program_options; namespace bpo = boost::program_options; ^ In file included from /home/ubuntu/eos/plugins/chain_plugin/include/eos/chain_plugin/chain_plugin.hpp:2:0, from /home/ubuntu/eos/plugins/producer_plugin/include/eos/producer_plugin/producer_plugin.hpp:26, from /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:24: /home/ubuntu/eos/libraries/appbase/include/appbase/application.hpp:8:42: note: namespace appbase::bpo = boost::boost::program_options; namespace bpo = boost::program_options; ^ /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:103:52: error: expected primary-expression before ?.?𼀠token ("producer-id,w", bpo::value<vector<string>>()->composing()->multitoken(), ^ /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:103:55: error: expected primary-expression before ?.?𼀠token ("producer-id,w", bpo::value<vector<string>>()->composing()->multitoken(), ^ /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:105:26: error: reference to ?𻱢po?𼀠is ambiguous ("private-key", bpo::value<vector<string>>()->composing()->multitoken()->default_value({fc::json::to_stri ^ /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:41:39: note: candidates are: namespace bpo = boost::boost::program_options; namespace bpo = boost::program_options; ^ In file included from /home/ubuntu/eos/plugins/chain_plugin/include/eos/chain_plugin/chain_plugin.hpp:2:0, from /home/ubuntu/eos/plugins/producer_plugin/include/eos/producer_plugin/producer_plugin.hpp:26, from /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:24: /home/ubuntu/eos/libraries/appbase/include/appbase/application.hpp:8:42: note: namespace appbase::bpo = boost::boost::program_options; namespace bpo = boost::program_options; ^ /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:105:50: error: expected primary-expression before ?.?𼀠token ("private-key", bpo::value<vector<string>>()->composing()->multitoken()->default_value({fc::json::to_stri ^ /home/ubuntu/eos/plugins/producer_plugin/producer_plugin.cpp:105:53: error: expected primary-expression before ?.?𼀠token ("private-key", bpo::value<vector<string>>()->composing()->multitoken()->default_value({fc::json::to_stri ^ plugins/producer_plugin/CMakeFiles/producer_plugin.dir/build.make:62: recipe for target 'plugins/producer_plugin/CMakeFiles/producer_plugin.dir/producer_plugin.cpp.o' failed make[2]: *** [plugins/producer_plugin/CMakeFiles/producer_plugin.dir/producer_plugin.cpp.o] Error 1 CMakeFiles/Makefile2:1337: recipe for target 'plugins/producer_plugin/CMakeFiles/producer_plugin.dir/all' failed make[1]: *** [plugins/producer_plugin/CMakeFiles/producer_plugin.dir/all] Error 2 Makefile:127: recipe for target 'all' failed

Change Account Name & Message Types

Account Name Design

All accounts require a globally unique identifier, for ease of development and use it is best if these account names are human readable. For performance it is best if these account names are 64 bit integers.

By using base32 encoding we can support account names up to 12 characters long consisting of the characters: [a-z12345.]

We will consider the . to be a namespace separator and all trailing (unused) characters shall also be '.'.

Converting Strings

An account name can be converted to or from strings as follows:

"dan"          <=> "dan........."
"dan.larimer"  <=> "dan.larimer."

Is 12 characters enough?

The average username length for twitter accounts created in 2012 is 11 characters. The most popular length for domain names traded on the market place was 8 characters.

UI Benefits of Short Names

User interfaces must be designed to handle the full range of name lengths, if they can assume that a name will be at most 12 characters long it will enable more interface uses.

Longer Names

If users would like to register a longer name, potentially using UTF8 characters, then a separate naming contract can be used and user interfaces can opt to lookup / display the longer name.

Rationalle

A simple currency transfer message consists of 5 account names: sender, receiver, notifier, to, and from. If serialized as 32 byte integers this would require 160 bytes, if serialized as length-encoded strings this would take 5*(1+average account length) bytes, if we assume "average account length" is greater than 10 characters then this will take over 55 bytes.

The current design encodes account names as length-encoded strings which means that smart contracts need to parse these strings (often resulting in copying to properly padded memory) and that the database indices need to maintain 32 bytes (fixed length). This results in both CPU and MEMORY being waisted packing and unpacking types while complicating the code in order to provide the benefit of 32 character human readable account names.

The compromise approach retains human readable names for the underlying identifier while allowing users to map to unique long-form names. It also allows account names long enough to support the average twitter username.

Message Types

We can use the same rationale for message types, namely that for performance reasons a 64 bit integer is ideal but for developer purposes a human readable string is preferred. This will allow developers to assign message types with names up to 12 characters long.

Replace operations with messages

Message type looks something like this:

/**
 * A message has a header that defines who sent it and
 * who will be processing it.  The message content is a binary blob whose
 * type is determined by 'type', which is dynamic and defined by
 * the scripting language.
 */
struct message {
  account        sender;
  account        to;
  vector<acct>   cc;
  message_type   type;
  vector<byte>   data;
};

account is a string typedef for now, will become a fixed-length string in the future.
message_type is a string typedef.

Should we require all scopes to be used?

A transaction specifies the scopes that it must access, these scopes in turn impact when it can be scheduled. If a transaction specifies a scope that is not used then it represents unnecessary locking.

On the other hand, it may not be possible to know if a scope will be accessed at the time the transaction is generated.

When it comes to billing a contract we should count CPU time as execution time * scopes.size()^2

Please add Dockerfile

Example: https://github.com/steemit/steem/blob/master/Dockerfile

Adopt block_log from Steem

Adopt Steem's block_log, found here, which should fix some potential corruption issues in the storage of blocks.

This will replace the current block_database storage mechanism.

appbase @ 024ec0d not properly linked in master

Unable to clone current master.

From commit f83884c

1 addition & 1 deletion libraries/appbase
Submodule appbase updated from 028da3 to 024ec0

However, https://github.com/eosio/appbase/tree/024ec0da9931700f25a89e8d80e02f555fe1310a is 404

Unable to build docker image

Tried to docker build on OSX Sierra with Docker CE 17.06.0-ce-mac18. The build failed on

[ 95%] Linking CXX executable chain_test
CMakeFiles/chain_test.dir/tests/simplecoin.cpp.o: In function `onInit':
/eos/tests/tests/simplecoin.cpp:(.text+0xf): undefined reference to `name_to_int64'
CMakeFiles/chain_test.dir/tests/simplecoin.cpp.o: In function `apply_simplecoin_transfer':
/eos/tests/tests/simplecoin.cpp:(.text+0xce): undefined reference to `assert'
CMakeFiles/chain_test.dir/tests/simplecoin.cpp.o: In function `void store<long long, Balance>(long long const&, Balance const&)':
/eos/tests/tests/simplecoin.cpp:(.text._Z5storeIx7BalanceEvRKT_RKT0_[_Z5storeIx7BalanceEvRKT_RKT0_]+0x2d): undefined reference to `store'
CMakeFiles/chain_test.dir/tests/simplecoin.cpp.o: In function `void readMessage<Transfer>(Transfer&)':
/eos/tests/tests/simplecoin.cpp:(.text._Z11readMessageI8TransferEvRT_[_Z11readMessageI8TransferEvRT_]+0x16): undefined reference to `readMessage'
CMakeFiles/chain_test.dir/tests/simplecoin.cpp.o: In function `int load<long long, Balance>(long long const&, Balance&)':
/eos/tests/tests/simplecoin.cpp:(.text._Z4loadIx7BalanceEiRKT_RT0_[_Z4loadIx7BalanceEiRKT_RT0_]+0x2d): undefined reference to `load'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
tests/CMakeFiles/chain_test.dir/build.make:350: recipe for target 'tests/chain_test' failed
make[2]: *** [tests/chain_test] Error 1
CMakeFiles/Makefile2:2152: recipe for target 'tests/CMakeFiles/chain_test.dir/all' failed
make[1]: *** [tests/CMakeFiles/chain_test.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

Inspection of the docker images showed the following tools were used.

g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
clang version 4.0.1-svn305187-1~exp1 (branches/release_40)

Thoughts to get the build to work that I can verify?

Implement transaction cycles/threads

Define types and behavior around the new blockchain evaluation parallelism designs using transaction cycles and threads.

Each block contains one or more cycles. Each cycle contains one or more threads. Each thread contains several transactions. All threads in a cycle may be executed in parallel. If some transactions A and B both affect an account U, then A and B may be included in the same cycle if and only if they are also in the same thread (which guarantees a particular ordering). A and B may not be in separate threads of the same cycle. They may be in distinct cycles.

Each thread contains one or more input transactions, and zero or more output transactions. Output transactions (aka generated_transactions) are created when a transaction executes a smart contract, and that smart contract outputs a transaction to run. When an input transaction on thread T generates an output transaction O, O becomes an output transaction on T. O may then subsequently become an input transaction in a future cycle, even within the same block, but not within the same cycle.

Output transactions are assigned 32-bit serial number IDs at the end of each cycle. To include an output transaction from a previous cycle as an input transaction in a current cycle, reference its ID. No longer the case; see comment below

Could not find a package configuration file provided by "LLVM"

Got this error trying to build in OSX

$ cmake .
-- Using custom FindBoost.cmake
-- Boost version: 1.64.0
-- Found the following Boost libraries:
--   thread
--   date_time
--   system
--   filesystem
--   program_options
--   signals
--   serialization
--   chrono
--   unit_test_framework
--   context
--   locale
-- Using custom FindBoost.cmake
-- Boost version: 1.64.0
-- Found the following Boost libraries:
--   coroutine
-- Configuring Eos on OS X
-- Setting up SECP256K1 root and include vars to /usr/local, /usr/local/include
-- Configuring fc to build on Unix/Apple
-- Setting up OpenSSL root and include vars to /usr/local/opt/openssl/, /usr/local/opt/openssl//include
-- Found Secp256k1: /usr/local/lib/libsecp256k1.a
-- zlib found
-- bzip2 found
-- Using custom FindBoost.cmake
-- Boost version: 1.64.0
-- Found the following Boost libraries:
--   thread
--   date_time
--   system
--   filesystem
--   chrono
--   unit_test_framework
--   locale
-- Configuring ChainBase on OS X
CMake Error at libraries/wasm-jit/Source/Runtime/CMakeLists.txt:26 (find_package):
  Could not find a package configuration file provided by "LLVM" (requested
  version 4.0) with any of the following names:

    LLVMConfig.cmake
    llvm-config.cmake

  Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set
  "LLVM_DIR" to a directory containing one of the above files.  If "LLVM"
  provides a separate development package or SDK, be sure it has been
  installed.


-- Configuring incomplete, errors occurred!

where is the autoreconf

│➜ secp256k1-zkp git:(secp256k1-zkp) ./autogen.sh
│./autogen.sh: 3: ./autogen.sh: autoreconf: not found

deterministic_randomness test failures

Build environtment:

• Debian Jessie x64
• Cmake 3.8.2
• Clang 4.0.1-svn305187-1~exp1

Build commands and logs:
/home/give/src/cmake-3.8.2/bin/cmake -DCMAKE_CXX_COMPILER=/usr/bin/clang++-4.0 -DCMAKE_C_COMPILER=/usr/bin/clang-4.0 -DBOOST_ROOT=/opt/boost160/ -DCMAKE_BUILD_TYPE=Release ..

-- The C compiler identification is Clang 4.0.1
-- The CXX compiler identification is Clang 4.0.1
-- Check for working C compiler: /usr/bin/clang-4.0
-- Check for working C compiler: /usr/bin/clang-4.0 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/clang++-4.0
-- Check for working CXX compiler: /usr/bin/clang++-4.0 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using custom FindBoost.cmake
-- Boost version: 1.60.0
-- Found the following Boost libraries:
--   thread
--   date_time
--   system
--   filesystem
--   program_options
--   signals
--   serialization
--   chrono
--   unit_test_framework
--   context
--   locale
-- Using custom FindBoost.cmake
-- Boost version: 1.60.0
-- Found the following Boost libraries:
--   coroutine
-- Configuring Eos on Linux
-- Setting up SECP256K1 root and include vars to /usr/local, /usr/local/include
-- Configuring fc to build on Unix/Apple
-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libcrypto.a (found version "1.0.1t")
-- Found Secp256k1: /usr/local/lib/libsecp256k1.a
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.8")
-- zlib found
-- Found BZip2: /usr/lib/x86_64-linux-gnu/libbz2.so (found version "1.0.6")
-- Looking for BZ2_bzCompressInit
-- Looking for BZ2_bzCompressInit - found
-- bzip2 found
-- Using custom FindBoost.cmake
-- Boost version: 1.60.0
-- Found the following Boost libraries:
--   thread
--   date_time
--   system
--   filesystem
--   chrono
--   unit_test_framework
--   locale
-- Configuring ChainBase on Linux
CMake Warning (dev) at libraries/wrenbase/CMakeLists.txt:11 (add_executable):
  Policy CMP0037 is not set: Target names should not be reserved and should
  match a validity pattern.  Run "cmake --help-policy CMP0037" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  The target name "test" is reserved or not valid for certain CMake features,
  such as generator expressions, and may result in undefined behavior.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- egenesis: /home/give/eos/genesis.json
-- embed_genesis_args: -t/home/give/eos/libraries/egenesis/egenesis_brief.cpp.tmpl---/home/give/eos/build/libraries/egenesis/egenesis_brief.cpp-t/home/give/eos/libraries/egenesis/egenesis_full.cpp.tmpl---/home/give/eos/build/libraries/egenesis/egenesis_full.cpp--genesis-json/home/give/eos/genesis.json
-- Using custom FindBoost.cmake
-- Boost version: 1.60.0
-- Found the following Boost libraries:
--   thread
--   date_time
--   system
--   filesystem
--   chrono
--   program_options
--   unit_test_framework
--   locale
-- Configuring ChainBase on Linux
-- Found gperftools; compiling steemd with TCMalloc
-- Found gperftools; compiling tests with TCMalloc
-- Configuring done
-- Generating done
-- Build files have been written to: /home/give/eos/build

./chain_test -t misc_tests/deterministic_randomness Log:

give@debian:~/eos/build/tests$ ./chain_test -t misc_tests/deterministic_randomness
Random number generator seeded to 1497988907
EOS_TESTING_GENESIS_TIMESTAMP is 1431700005
Running 1 test case...
/home/give/eos/tests/tests/misc_tests.cpp(52): error: in "misc_tests/deterministic_randomness": check fc::json::to_string(words) == fc::json::to_string(vector<string>{"potters","hal9000","memorizes","infamy","invests","estimated"}) has failed [["infamy","hal9000","invests","estimated","memorizes","potters"] != ["potters","hal9000","memorizes","infamy","invests","estimated"]]
/home/give/eos/tests/tests/misc_tests.cpp(55): error: in "misc_tests/deterministic_randomness": check fc::json::to_string(words) == fc::json::to_string(vector<string>{"memorizes","hal9000","infamy","invests","estimated","potters"}) has failed [["infamy","hal9000","memorizes","estimated","potters","invests"] != ["memorizes","hal9000","infamy","invests","estimated","potters"]]

*** 2 failures are detected (1 failure is expected) in the test module "Master Test Suite"

Chain API

Implement the beginnings of the chain API, accessible through the http_plugin

Unit Tests Recursively call Push Block

We get the following call stack:

push_block(b)
   ...
     with_write_lock 
        apply_block(b)
           ... 
           applied_block(b) /// emit...
               ... network code handler
                   push_block(b)
                      with_write_lock  (timeout)

This results in warnings / slowdowns but shouldn't break anything.

I have added a work around that will exit push_block if head_block is the block being pushed.

To actually solve this we need the simulated network to be async, but if it is async then we need to build in a "sleep" during which network events can "propagate".

Atomically create and use account?

At present, it is impossible to create an account, and then use that account in the same transaction. If the newly created account is referenced as sender, recipient, or notification receiver on any message in the transaction, the transaction will fail because the account doesn't exist when the transaction is being validated.

Furthermore, if the new account is needed to sign the transaction (a perfectly viable option, since the creator of the transaction may know the new account's keys), this is also a problem due to the need to list the new account, by name, in the provided_authorizations for the transaction. The database checks the provided_authorizations and signatures prior to evaluating the transaction, thus the new account and its keys will not be known to the database in time.

At this point, I think our options for dealing with this are:

• Fix it -- perform account existence checks on a per-message basis rather than a per-transaction basis, and somehow defer signature checking for provided_authorizations accounts that don't exist yet until the accounts do exist
• Ignore it -- forbid a transaction from using an account which it created

Are there any other options? Is it important that we support atomically creating and using an account?

Remove maintenance interval

We won't be having the constructs of a blockchain maintenance period or a maintenance interval. Remove these from the code.

gcc-5 not support, please add to the markdown.

TaPoS fails after block 65535

The block summaries used for TaPoS wrap back to 0 after reaching 65535. Currently, this is breaking, and all transactions fail to validate after block 65535.

Advanced Permission Hierarchy

Advanced Permission Infrastructure
EOS operates on the basis of pre-authenticated messages, but there is still a concept that all actions require a certain permission. Permissions are organized hierarchically. For example, in Steem an account has an owner, active, and posting permission. Owner can do everything, active can do everything exchange change owner, and posting can only make posts and vote.
Each permission in turn is defined as a dynamic, threshold multisig of the following authority structure:

Authority
   ThresholdWeight
   map< key, weight >
   map<  pair<AccountName,PermissionName>, weight >

Each account can define its own permission hierarchy using an number of named permissions each of which has a parent permission and an authority. This is a generalization of the system defined by Steem.

Contract Permission Hierarchy

Each contract can define its own permission hierarchy. By default there is a “Contract” level a per-message permission. But contracts can also group messages into an arbitrary permission hierarchy.
For Example:

ExchangeContract
   TradeAuthority
       CreateOrderMessage
       CancelOrderMessage
   WithdrawAuthority
       WithdrawMessage

A message is dispatched with a permission level of the sender which is evaluated by looking up the Authority structure on the sender and then recursively checking for signatures to verify the account has the authority.

Then we traverse the contract’s message authority tree from leaf permission on up.

ExchangeContract.WithdrawMessage->ExchangeContract.WithdrawAuthority-
>ExchangeContract->SenderActive->SenderOwner

For each level it checks the SenderAccount to see if it has an Authority specified for that level, if the sender has the authority specified, then checks to see if it was the authority on the message. If not it checks any parent-authority specified by the sender on up to active. If no match is found, then it goes to the next level up on the exchange permission tree.

Implement Native Contracts

Implement the Native Contracts in C++

• System Contract
  • Create Account (name, owner authority, active authority)
  • Update Permission (account, permissionname, parent, authority)
  • Update Script (account, new script)
• Eos Contract
  • Transfer (to, amount, memo)
  • TransferToLocked (to, amount)
• Staked Balance Contract
  • Create Producer (owner name, signing key)
  • Update Producer (account, signingkey)
  • Producer Vote Update (account, producer, does_approve)
  • Register As Foundation (account)
  • Foundation Vote Update (account, foundation, does_approve)
  • StartUnlockEOS (account, amount)
  • ClaimUnlockedEOS (account, amount)

Port to AppBase

Adopt AppBase and use it to replace the entire app infrastructure.

Transfer example .. Unit test typo?

Is this a typo?

trx.messages[0].recipients = {"inita", config::EosContractName}

This value is not used then re-assigned before the transaction push:

trx.messages[0].recipients = {"inita", "initb"};

misc_tests/deterministic_randomness is failing

/Users/dlarimer/eos/tests/tests/misc_tests.cpp:52: error: in "misc_tests/deterministic_randomness": check fc::json::to_string(words) == fc::json::to_string(vector{"potters","hal9000","memorizes","infamy","invests","estimated"}) has failed [["infamy","memorizes","invests","potters","hal9000","estimated"] != ["potters","hal9000","memorizes","infamy","invests","estimated"]]
/Users/dlarimer/eos/tests/tests/misc_tests.cpp:55: error: in "misc_tests/deterministic_randomness": check fc::json::to_string(words) == fc::json::to_string(vector{"memorizes","hal9000","infamy","invests","estimated","potters"}) has failed [["potters","memorizes","infamy","hal9000","invests","estimated"] != ["memorizes","hal9000","infamy","invests","estimated","potters"]]

Exporting JSON structures

Can I get a program that will write the blockchain operations to standard out?

Here is the original format and operations that I'm parsing to create the serializer:

https://github.com/eosjs/json/blob/master/schema/operations.json

Building error. Linking CXX executable chainbase_test

Hi,

I have met compilation problem. Enviroment: ubuntu 16.04.2, Boost 1.64, OpenSSL, LLVM 4.0, secp256k1, cmake 3.8.0, clang 4.0, clang++ 4.0

[30%] Linking CXX executable chainbase_test
CMakeFiles/chainbase_test.dir/test.cpp.o: In function open_and_create::test_method()': /home/bitshares/eos/libraries/chainbase/test/test.cpp:(.text+0x76c): undefined reference to boost::test_tools::tt_detail::report_assertion(boost::test_tools::assertion_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...)'
/home/bitshares/eos/libraries/chainbase/test/test.cpp:(.text+0x99d): undefined reference to boost::test_tools::tt_detail::report_assertion(boost::test_tools::assertion_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring<char const>, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...)' /home/bitshares/eos/libraries/chainbase/test/test.cpp:(.text+0xbf8): undefined reference to boost::test_tools::tt_detail::report_assertion(boost::test_tools::assertion_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...)'
/home/bitshares/eos/libraries/chainbase/test/test.cpp:(.text+0xe55): undefined reference to boost::test_tools::tt_detail::report_assertion(boost::test_tools::assertion_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring<char const>, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...)' /home/bitshares/eos/libraries/chainbase/test/test.cpp:(.text+0x11c3): undefined reference to boost::test_tools::tt_detail::report_assertion(boost::test_tools::assertion_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...)'
CMakeFiles/chainbase_test.dir/test.cpp.o:/home/bitshares/eos/libraries/chainbase/test/test.cpp:(.text+0x29a0): more undefined references to boost::test_tools::tt_detail::report_assertion(boost::test_tools::assertion_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring<char const>, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...)' follow CMakeFiles/chainbase_test.dir/test.cpp.o: In function __cxx_global_var_init.11':
/home/bitshares/eos/libraries/chainbase/test/test.cpp:(.text.startup+0x1c0): undefined reference to boost::unit_test::ut_detail::auto_test_unit_registrar::auto_test_unit_registrar(boost::unit_test::test_case*, boost::unit_test::decorator::collector&, unsigned long)' CMakeFiles/chainbase_test.dir/test.cpp.o: In function boost::unit_test::make_test_case(boost::function<void ()> const&, boost::unit_test::basic_cstring, boost::unit_test::basic_cstring, unsigned long)':
/home/bitshares/eos/libraries/chainbase/test/test.cpp:(.text._ZN5boost9unit_test14make_test_caseERKNS_8functionIFvvEEENS0_13basic_cstringIKcEES8_m[_ZN5boost9unit_test14make_test_caseERKNS_8functionIFvvEEENS0_13basic_cstringIKcEES8_m]+0xae): undefined reference to boost::unit_test::test_case::test_case(boost::unit_test::basic_cstring<char const>, boost::unit_test::basic_cstring<char const>, unsigned long, boost::function<void ()> const&)' CMakeFiles/chainbase_test.dir/test.cpp.o: In function bool boost::test_tools::tt_detail::check_frwd<boost::test_tools::tt_detail::equal_impl_frwd, int, int>(boost::test_tools::tt_detail::equal_impl_frwd, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, int const&, char const*, int const&, char const*)':
/home/bitshares/eos/libraries/chainbase/test/test.cpp:(.text.ZN5boost10test_tools9tt_detail10check_frwdINS1_15equal_impl_frwdEiiEEbT_RKNS_9unit_test12lazy_ostreamENS5_13basic_cstringIKcEEmNS1_10tool_levelENS1_10check_typeERKT0_PSA_RKT1_SH[ZN5boost10test_tools9tt_detail10check_frwdINS1_15equal_impl_frwdEiiEEbT_RKNS_9unit_test12lazy_ostreamENS5_13basic_cstringIKcEEmNS1_10tool_levelENS1_10check_typeERKT0_PSA_RKT1_SH]+0x1ce): undefined reference to `boost::test_tools::tt_detail::report_assertion(boost::test_tools::assertion_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...)'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
libraries/chainbase/test/CMakeFiles/chainbase_test.dir/build.make:103: ошибка выполнения рецепта для цели «libraries/chainbase/test/chainbase_test»
make[2]: *** [libraries/chainbase/test/chainbase_test] Ошибка 1
CMakeFiles/Makefile2:239: ошибка выполнения рецепта для цели «libraries/chainbase/test/CMakeFiles/chainbase_test.dir/all»
make[1]: *** [libraries/chainbase/test/CMakeFiles/chainbase_test.dir/all] Ошибка 2
Makefile:129: ошибка выполнения рецепта для цели «all»
make: *** [all] Ошибка 2

Latest checkout is not producing blocks..

After a new build, I wiped all but my data-dir/config.ini file which still contains enable-stale-production = true and the 11 producer-id entries per the README.

No producers configured! Please add producer IDs and private keys to configuration.

The ini file has not changed..

Failing test: block_tests/create_script

Failing test needs to be fixed. Most relevant output:

1150634ms thread-0   wasm_interface.cpp:173        assertnonei32i32     ] message: no existing balance 
1150635ms thread-0   block_tests.cpp:928           test_method          ] 10 assert_exception: Assert Exception
test: assertion failed: no existing balance
    {"s":"no existing balance","ptr":8608}
    thread-0  wasm_interface.cpp:174 assertnonei32i32

    {}
    thread-0  wasm_interface.cpp:298 vm_apply

    {}
    thread-0  wasm_interface.cpp:333 apply

    {"context.msg":{"sender":"simplecoin","recipient":"simplecoin","notify":["init1"],"type":"Transfer","data":"0a73696d706c65636f696e05696e697431020000000000000008454f53000000000568656c6c6f"}}
    thread-0  chain_controller.cpp:651 apply_message

    {"trx":{"refBlockNum":"12","refBlockPrefix":"1091583988","expiration":"2015-05-15T14:29:01","messages":[{"sender":"simplecoin","recipient":"simplecoin","notify":["init1"],"type":"Transfer","data":"0a73696d706c65636f696e05696e697431020000000000000008454f53000000000568656c6c6f"}],"authorization":[],"signatures":[],"authorizations":[]}}
    thread-0  chain_controller.cpp:670 _apply_transaction

    {"trx":{"refBlockNum":"12","refBlockPrefix":"1091583988","expiration":"2015-05-15T14:29:01","messages":[{"sender":"simplecoin","recipient":"simplecoin","notify":["init1"],"type":"Transfer","data":"0a73696d706c65636f696e05696e697431020000000000000008454f53000000000568656c6c6f"}],"authorization":[],"signatures":[],"authorizations":[]}}
    thread-0  chain_controller.cpp:268 push_transaction
unknown location(0): fatal error: in "block_tests/create_script": unknown type
../../tests/tests/block_tests.cpp(120): last checkpoint: "create_script" entry.

API Theory

Implement new API machinery. Progress for this has already begun (ref #12) but there's a lot of improvement to be done.

There are three plugin types involved in API exposure:

• The plugin that defines the APIs and provides fc::api handles for them (i.e. chain_plugin)
• A plugin to configure exposure and handle API permissions (i.e. chain_api_plugin)
• Plugins that expose APIs to the outside world (i.e. http_plugin)

For example, chain_plugin exposes a RO and RW APIs. They are exposed as publicly-accessible fc::api objects. chain_api_plugin gathers up these APIs and wires them up with http_plugin. chain_api_plugin implements any necessary permissions/authentication mechanisms, so chain_plugin simply implements the API without caring about permissions, chain_api_plugin implements the permissions and determines which APIs get exposed where, and API exposure plugins like http_plugin make the API accessible to the outside world without concerning themselves with permissions.

See error during Docker build

When building using docker seeing the below issue. using Docker version 17.06.0-ce, build 02c1d87
on Ubuntu 16.04

See also "/tmp/eos/build/CMakeFiles/CMakeOutput.log".
The command '/bin/sh -c cd /tmp && git clone https://github.com/EOSIO/eos.git --recursive && cd eos && mkdir build && cd build && cmake -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_STANDARD=14 -DCMAKE_INSTALL_PREFIX=/opt/eos ../ && make -j$(nproc) && make install && rm -rf /tmp/eos*' returned a non-zero code: 1

Implement block producer scheduling

How are block producers to be scheduled? Via rounds? What happens if all blocks are missed for more than one round? Does the round simply repeat?

Of course all of these questions have been answered before in BTS and Steem, but since none of the EOS producer scheduling code is written yet, I figure we should take a moment to make sure we know exactly how we want this to work, factoring in all the lessons from past experience.

Fix unit tests

Unit tests are broken right now (thanks, @bytemaster ;) ) so those need fixing.

PLEase help - EOS ICO

Hi , I have sent some ETH on Metamask but am not sure the interface generated an EOS Key for me.. is it possible to check?
The ETH is sent to the contract address according to the effective price , your ETH, Your EOS table

thank you for the guidance

CMake on the mac

When building with Makefiles on OSX, the secp256k1 header is not found. This is because the default installation location, /usr/local, is not part of the compiler's built-in include paths. After discussing with Nathan I've enhanced the CMakeList.txt for libraries/fc to pick up $SECP256K1_ROOT_DIR if present or default to /usr/local.

I'll supply a pull request shortly.

Autonomously executing smart contracts

One of the limitations of Ethereum contracts is that they need to be called (and paid for) manually, each time the user wants to do anything.

This greatly limits dapps in their scope of functionality.

Are there any plans for mechanisms in EOS that would allow for:
a.) smart contracts execution being scheduled programmatically
b.) smart contracts having the ability to perform pre-authorized transactions, based on agreed upon specification

Example 1:
Vests power-down on Steem is illustrating the desired autonomous ability of a decentralized application. The user will get their Steem credited to their account, every week, without a need do anything beyond initiating the hard-coded contract.

Example 2:
Credit Card subscriptions are a popular mean of payments in the legacy world. It would be very burdensome for merchants to try and re-commit their clients to re-purchase. Additional friction is created on the buyer side, as they have to allocate their time and energy to a tedious process of paying their bills.
Perhaps a smart contract mimicking the subscriptions pattern would be an important addition for dapps.