So I replay the kylin blocks from scratch using config:

/opt/eosio/bin/nodeos --hard-replay --replay-blockchain --disable-replay-opts plugin = eosio::state_history_plugin state-history-dir = "state-history" trace-history = true chain-state-history = true state-history-endpoint = 0.0.0.0:9090 [and a few other options that have been there for a long time]

sometime after block 19406900 (not sure exact number), the software goes an infinite loop:

Nov 22 15:37:56 peer1 nodeos[28294]: warn 2018-11-22T15:37:56.654 thread-0 controller.cpp:244 emit ] 3110000 plugin_exception: Plugin exception Nov 22 15:37:56 peer1 nodeos[28294]: missing trace for transaction 6139bd32da0c523116efcbb2e8536787f68e2b9da364e40792598ea7e64f5815 Nov 22 15:37:56 peer1 nodeos[28294]: {"id":"6139bd32da0c523116efcbb2e8536787f68e2b9da364e40792598ea7e64f5815"} Nov 22 15:37:56 peer1 nodeos[28294]: thread-0 state_history_plugin.cpp:385 store_traces Nov 22 15:37:56 peer1 nodeos[28294]: warn 2018-11-22T15:37:56.659 thread-0 controller.cpp:244 emit ] 3110000 plugin_exception: Plugin exception Nov 22 15:37:56 peer1 nodeos[28294]: missed a block in trace_history.log Nov 22 15:37:56 peer1 nodeos[28294]: {"name":"trace_history"} Nov 22 15:37:56 peer1 nodeos[28294]: thread-0 state_history_log.hpp:84 write_entry Nov 22 15:37:56 peer1 nodeos[28294]: warn 2018-11-22T15:37:56.661 thread-0 controller.cpp:244 emit ] 3110000 plugin_exception: Plugin exception Nov 22 15:37:56 peer1 nodeos[28294]: missed a block in trace_history.log Nov 22 15:37:56 peer1 nodeos[28294]: {"name":"trace_history"} Nov 22 15:37:56 peer1 nodeos[28294]: thread-0 state_history_log.hpp:84 write_entry Nov 22 15:37:56 peer1 nodeos[28294]: warn 2018-11-22T15:37:56.662 thread-0 controller.cpp:244 emit ] 3110000 plugin_exception: Plugin exception Nov 22 15:37:56 peer1 nodeos[28294]: missed a block in trace_history.log Nov 22 15:37:56 peer1 nodeos[28294]: {"name":"trace_history"} Nov 22 15:37:56 peer1 nodeos[28294]: thread-0 state_history_log.hpp:84 write_entry Nov 22 15:37:56 peer1 nodeos[28294]: warn 2018-11-22T15:37:56.669 thread-0 controller.cpp:244 emit ] 3110000 plugin_exception: Plugin exception Nov 22 15:37:56 peer1 nodeos[28294]: missed a block in trace_history.log Nov 22 15:37:56 peer1 nodeos[28294]: {"name":"trace_history"} Nov 22 15:37:56 peer1 nodeos[28294]: thread-0 state_history_log.hpp:84 write_entry Nov 22 15:37:56 peer1 nodeos[28294]: warn 2018-11-22T15:37:56.670 thread-0 controller.cpp:244 emit ] 3110000 plugin_exception: Plugin exception Nov 22 15:37:56 peer1 nodeos[28294]: missed a block in trace_history.log Nov 22 15:37:56 peer1 nodeos[28294]: {"name":"trace_history"} Nov 22 15:37:56 peer1 nodeos[28294]: thread-0 state_history_log.hpp:84 write_entry Nov 22 15:37:56 peer1 nodeos[28294]: warn 2018-11-22T15:37:56.678 thread-0 controller.cpp:244 emit ] 3110000 plugin_exception: Plugin exception Nov 22 15:37:56 peer1 nodeos[28294]: missed a block in trace_history.log Nov 22 15:37:56 peer1 nodeos[28294]: {"name":"trace_history"} Nov 22 15:37:56 peer1 nodeos[28294]: thread-0 state_history_log.hpp:84 write_entry Nov 22 15:37:56 peer1 nodeos[28294]: warn 2018-11-22T15:37:56.681 thread-0 controller.cpp:244 emit ] 3110000 plugin_exception: Plugin exception Nov 22 15:37:56 peer1 nodeos[28294]: missed a block in trace_history.log etc...

If one of the goals of EOS is to be able to very large platforms (e.g. social network), then how can 4kb * 0.015 EOS RAM cost per account be within the desirable tolerances?

0.5-1.0 USD per account simply can't work if your target is to create tens or hundreds of million user accounts for your dApp!

Am I missing something, e.g. is there any way for a dApp creator to somehow reclaim RAM costs for dormant or inactive user accounts that it has created?

Resolves #3030

The mongo db plugin has been updated to work with 1.1 release.

It is recommended that a large --abi-serializer-max-time-ms value be passed into the nodeos running the mongo_db_plugin as the default abi serializer time limit may not be large enough to serialize large blocks.

It will create the following collections:

• accounts - created on accepted transaction -- Currently limited to just name and ABI if contract on account

• actions - created on accepted transaction -- action_num - the # of the action in its transaction -- trx_id -- account -- name -- authorization --- actor --- permission -- data -- hex_data

• block_states - created on accepted block -- block_num -- block_id -- block_header_state -- validated -- in_current_chain

• blocks - created on accepted block -- block_num -- block_id -- irreversible - updated to true on irreversible block -- block

• transaction_traces - created on applied transaction -- transaction_trace

• transactions - created on accepted transaction -- trx_id -- irreversible - updated to true on irreversible block -- transaction_header -- signing_keys -- actions -- context_free_actions -- transaction_extensions -- signatures -- context_free_data

Currently EOSIO prohibits the creation of new account names that are less than 12 characters long and/or contain a ".". The purpose of this restriction is to discourage name squatting. That said, it is desirable to enable shorter names for usability and because they are a marketable commodity.

It is also desirable for organizations to have the ability to create a "trusted" namespace where everyone can trust an account suffix like ".edu" or ".com". Shorter suffix enable longer names pre-suffix and therefore have a larger namespace and are more valuable.

The most economically efficient and fair method to allocate shorter names and/or namespaces is to sell the names at market price. To get the most value for the premium names they should not be sold all at once, but over time.

Proposal

1. Only account name "com" can register new accounts xyz.com
2. At most one new "premium name" (those that don't contain a ".") will be sold per day and it will be the name with the highest bid.

Bidding on Names

bidname( account_name bidder, account_name desired, asset bid )

If 'bid' is greater than the highest bidder then bidder becomes the pending winner of the desired name. Each bid must be 10% higher than any existing bid. The existing bidder will receive a refund of their bid when they are outbid. This encourages parties to bid high enough that they don't get outbid in the first place and discourages parties from going back-and-forth fighting for the name. It also discourages "squatting" on names hoping no one comes along to outbid them.

Every 24 hours the name with the highest bid is closed. Once closed the "winner" can use the newaccount action to register the account. At this point the memory allocated for the bid is released back to the bidder.

Easy options for masses

The vast majority of users will not want to participate in the daily name auctions because it is a slow and highly competitive process. Instead name-registrars will bid on the good names and then create accounts for their users as "sub-names". Large DAPPs will probably want to reserve their own branded namespace and set their own policy on premium names.

Non-Revokable

Once account xyz.com has been created by .com it cannot be deleted and the owner of xyz.com can potentially transfer control over that account to anyone. If companies wish to retain control over all accounts with ".com" in the suffix then they will need to set the "owner" permission accordingly.

Auction Proceeds

The proceeds from the auction are placed into the system savings account along with other unallocated inflation and RAM trading fees.

FAQ

1. All names can be bid on at any time, but only the name with the highest bid closes each day. Order of names being sold will be "most valuable first".

2. Future worker proposals could allocate the proceeds from the name sales.

3. 12 character limit applies to the full name including the ".suffix"

Change Description

The state history plugin gives external processes a way to track chain state (tables), transaction history, and blocks. External processes could store this data into a database (e.g. https://github.com/EOSIO/fill-postgresql ), transform the data to meet app needs (e.g. a https://github.com/EOSIO/demux-js action handler), or index the data and provide an end-user api (e.g. a /v1/history replacement).

The plugin stores:

• Chain DB table changes (per block) (enable with --chain-state-history)
• Transaction traces (per block) (enable with --trace-history)

The plugin allows clients to fetch via block index:

• Blocks from the block log
• Chain DB table changes (per block) (enable with --chain-state-history)
• Transaction traces (per block) (enable with --trace-history)

The plugin stores its data in files which can move between machines. BPs could provide these files along with snapshots, reducing the need for new nodes to replay.

The plugin provides a streaming websocket interface. To reduce the load on nodeos, the interface uses a serialized binary format instead of JSON and the plugin does minimal processing to handle requests. However, since this interface provides a high data volume and has no abuse mitigations, we don't recommend publicly exposing its port.

Hello Team,

I am trying to connect to HTTP/RPC API and do basic queries like get accounts, get balance in my UI and I am always getting a 404 error.

Here is the error:

{"code":404,"message":"Not Found","error":{"code":0,"name":"exception","what":"unspecified","details":[{"message":"Unknown Endpoint","file":"http_plugin.cpp","line_number":203,"method":"handle_http_request"}]}}

I have configured nodeos to work on port 8888 and cleos on 8889 and I have followed multiple resources to get it right but I cannot do so.

Any help would be appreciated.

I have attached the config files of nodeos and cleos.

Config files.zip

This paper describes an improvement on the DPOS (Delegated Proof of Stake) algorithm that makes stronger guarantees that a network of nodes following the DPOS 3.0 protocol will not fall out of consensus. We define falling out of consensus as two nodes concluding that two different blocks are irreversible.

Background

Proof of work blockchains, such as Bitcoin, define consensus using the “longest-chain” rule. Using this rule no block is ever considered irreversible confirmed. At any time someone could produce a longer chain built off of an older block and the node would switch. From this we can conclude that Bitcoin only offers a high-probability of irreversibility based upon the economic cost of attempting to change forks.

BitShares introduced Delegated Proof of Stake. Under this algorithm stakeholders elect block producers. Block producers are pseudo-randomly shuffled and assigned absolute time slots during which they may either producer a block or not. The blockchain with the most producers building on it will grow in length faster than a blockchain with fewer producers. Given two chains growing at different speeds, the faster one will eventually become the longest chain. Therefore, the original Delegated Proof of Stake algorithm offers similar guarantees to Bitcoin, namely that as blocks are added to a chain it is increasingly unlikely for another chain to be produced that reverses reverses a block.

The nature of the DPOS scheduling algorithm communicates a lot of information to an observer. For example, an observer can detect that they are likely on a minority chain based upon the frequency of missed blocks. With 21 producers a node can accurately detect they may be on a minority fork after just 2 consecutive missed blocks (6 seconds). This allows users to be warned when the network is unstable and to wait longer for confirmation. Likewise, if no producers have missed a block in 21 blocks that follow your transaction you can assume with certainty that your block will not be reversed. Rare loss of Consensus (DPOS 2.0)

In DPOS 2.0 we introduced the concept of the last irreversible block. This is the most recent block which 2/3+1 of block producers have built off of. The theory is that if 2/3+1 of producers have built on a chain that confirmed a block then it is likely impossible for there to be any other fork.

That said, enterprising folks have constructed contrived scenarios where a network split divides the network into two chains. Normally this would simply cause one or both chains to halt the advancement of the last irreversible block until one or the other is reconnected with 2/3+1 of the producers. In this normal behavior everything is fine and all nodes will converge on the one-true-chain once connectivity is returned. That said, there is a race condition whereby two-subsets simultaneously switch forks resulting in both forks reaching 2/3+1 on a different block. When this happens nodes on the two sides of a fork are unable to synchronize because neither will unwind beyond the last irreversible block. Manual intervention is required.

Under this situation one or both forks will cease advancing irreversibility depending upon which whether either of the forks managed to end up with 2/3+1 of producers. The minority chain may still grow at 1/2 the speed but nodes waiting for irreversibility would no longer accept any transactions on the minority chain as finalized.

This failure mode produces a single-block which some services may experience loss if it was reversed. By our estimates, the probability of this happening is much less than the probability of a Bitcoin block with 6 confirmations being reversed. This bears out in real-world testing of both BitShares and Steem which have operated for over 3 years without this situation being observed.

DPOS 3.0 + BFT

With EOSIO we are introducing inter-blockchain communication (IBC) which allows one chain to efficiently prove to another chain that a transaction is final. Finality is critical for IBC because once one blockchain accepts a message from another it is not easy nor desirable to reverse both chains to correct the mistake.

Imagine for a moment that a blockchain was attempting to accept a Bitcoin deposit. A user submits all bitcoin blockheaders plus 6 block headers built on top of the block he references. Based upon this proof the blockchain takes irreversible actions. Now imagine that the Bitcoin forks and undoes those 6 blocks? It is not possible for this blockchain to reverse and reject the previously accepted Bitcoin transaction. Such an incident would require manual intervention and/or a hardfork. Such a hardfork/intervention would ripple through all chains that are connected. This is not a viable option.

To enable secure and reliable IBC under all non-byzantine situations DPOS 3.0 + BFT introduces a small change to how the Last Irreversible Block (LIB) is calculated. With this change we can prove that it is impossible for two nodes to come to different conclusions regarding the LIB without at least 1/3 of the block producing nodes being intentionally malicious. Furthermore, we can prove malicious behavior of even a single node.

The core idea behind DPOS is that each produced-block is a vote for all prior blocks. With this model once 2/3+ producers have built upon a particular block it has 2/3+ votes. This sounds good in theory except that it is possible for non-byzantine block producers to produce blocks on different forks at different times. When they produce these blocks they end up casting indirect conflicting votes for the block numbers that appear on each chain.

Suppose a network with producers A, B, and C has an issue that causes two block producers to lose communication for a short period of time such that producer A produces block N at time T and producer B produces block N at time T+1. Now suppose producer C breaks the tie by building block N+1 at time T+2 on top of B’s block N with time T+1. After this happens and A learns of C’s block N+1, A will switch to the longer fork. Next time A produces a block he will indirectly confirm B’s block N which conflicts with A’s previously produced block N.

Under the DPOS 2.0 rules, A’s block N would have votes from A, B, and C and therefore become irreversible due to (2/3+1) confirmation. Under DPOS 3.0 we require A to disclose that he previously confirmed an alternative block N. Due to this disclosure the network will not count A’s block as having voted for B’s block N. This leaves B’s block N with only 2 votes which is not enough to achieve irreversibility.

Under DPOS 3.0 B’s block N will never achieve direct irreversibility because it requires votes from A, B, and C to have 2/3+1 and A cast a vote on an alternative block N. Instead, block N+1 will become irreversible once A producers N+2 and B produces N+3. This would give block N+1 the 3 votes necessary to reach 2/3+1. Once C’s block N+1 is irreversible, B’s block N is deemed irreversible as well.

To implement this algorithm each block producer includes the highest block number (H) they have previously confirmed on any fork in the block header. When block N is applied only blocks in the range [H+1, N] receive votes toward irreversibility.

Any producer who signs a block with an overlapping range is deemed byzantine and will generate cryptographic proof of misbehavior.

With this information we can now generate a simple proof that for any given block height to achieve 2/3+1 votes for two different blocks at the same height that at least 1/3 of the producers must sign conflicting ranges. This would happen if there was an honest network split where two good groups of size 1/3 create two alternatives and a bad group with 1/3 signs on both forks. In practice, a network with good connectivity requires 2/3+1 to be malicious to create two different blocks deemed irreversible.

Under this these rules there are now two ways for producers to sign byzantine statements:

1. Sign two blocks with the same block number directly or indirectly
2. Sign two blocks with the same block time Honest nodes running the default software will never do these things. Therefore, it is possible to trivially punish all bad actors even for failed attempts.

Credits

The solution to this problem was discovered collaboratively by Bart, Arhag, and myself along with some other members of the B1 team.

We have been struggling with nodeos since the beginning, we can't find any way to have a systemd service or even a bash script that would automate or at least start and stop nodeos automatically.

Most of the time when nodeos is stopped to be updated or simply in an attempt to make a backup it stops responding and the next time it is started we allways get a dirty db, we always worked around this by copying or replying or even syncing the whole chain, but now we are nearing 18M blocks and it takes days to resync.

Today I was planning on updating all nodes to v1.3.0 and I have already screwed up 4 nodes, and I am afraid to update the rest!

systemd config:

[Unit]
Description=EOS daemon
After=syslog.target network.target

[Service]
User=eosio
Group=eosio
WorkingDirectory=~

#Type=simple
Restart=on-failure
ExecStart=/usr/local/eosio/bin/nodeos 
TimeoutStopSec=600s
TimeoutStartSec=15s
StartLimitInterval=600s
StartLimitBurst=5
PrivateTmp=true
PrivateDevices=true
ProtectSystem=full

[Install]
WantedBy=multi-user.target

Hi all, I just updated the last version, and got this issues when i tried to create an account as below. Anyone have this issues?

$ cleos create account eosio eosio.token EOS7m4Q5HRiLPK8a1q3pX1DMLd8VehTdRfuabv9f3FoX6wG51bAjU
Error 3090003: provided keys, permissions, and delays do not satisfy declared authorizations
Ensure that you have the related private keys inside your wallet and your wallet is unlocked.

The wallet already imported a private key and unlocked.

$ cleos wallet keys
[
  "EOS7m4Q5HRiLPK8a1q3pX1DMLd8VehTdRfuabv9f3FoX6wG51bAjU"
]

$ cleos wallet unlock --password PW5Jw5iTrqs8u1eMDY7EzU7ujkrmDQmxc6yKg1W67TtxaAn5cz21S
Unlocked: default

2018-08-22T04:25:32.647 thread-0   producer_plugin.cpp:309       on_incoming_block    ] 3030001 unlinkable_block_exception: Unlinkable block
unlinkable block
    {"id":"00bd1da28feb56b0d31c56383e230767315d10ec5f4dc0a9a328395596e8438b","previous":"00bd1da1591315791655cbf100df9ffd89064172219efb654e93b20875dc9128"}
    thread-0  fork_database.cpp:151 add
rethrow
    {}
    thread-0  controller.cpp:1036 push_block

running more than 10 days, but yesterday occur this error and sync stop

I've got a node setup and I'm trying to use the get_account endpoint to fetch balances (not my own) but I can't seem to find account names. Wallet names are visible on the blockchain but not account names? If account names are not available publicly and I should be using a different endpoint, which one should I be using?

Thank you

Hi im trying to do this:

//create a new wallet 1)cleos wallet create -n claudia -f claudia_wallet_password.pwd

//create new keys 2)cleos create key --file claudia.txt

//save those keys Private key: 5JPWCTptoxdrhX3WTLxsQgeKH1EDFSyRKWjaijwQj5ohDUefpdT Public key: EOS5VT8EjARN2SvNNUSwdCo9y25BTpajk3ByRWZRt7wn3gXoBjTL2

//import keys to wallet 3)cleos wallet import --name claudia --private key 5JPWCTptoxdrhX3WTLxsQgeKH1EDFSyRKWjaijwQj5ohDUefpdT

// create an account 4)cleos create account claudia cesar EOS5VT8EjARN2SvNNUSwdCo9y25BTpajk3ByRWZRt7wn3gXoBjTL2

but I have a problem while creating the account:

I don't know exactly what can be the issue.

Thanks for the help!

Environment:

Using MacBook Pro, with chip Apple M1 Pro and running macOS Monterey.

When installing EOSIO with Homebrew

% brew install eosio

the following error is thrown:

eosio: The intel architecture is required for this software.
Error: eosio: An unsatisfied requirement failed this build.

When I try to use this example https://developers.eos.io/welcome/v2.0/tutorials/tic-tac-toe-game-smart-contract-single-node $ cleos wallet list Wallets: [ "local *" ] Excuse me, what is the reason

what a joke how ever single thing i want to code around is perfectly designed to not work for me ....

how is windows not a supported system if you dont have any type of easy way to generate a wallet ... this currency will never thrive

Change Description

Change Type

Select ONE:

• [ ] Documentation

• [ ] Stability bug fix

• [ ] Other

• [ ] Other - special case

Testing Changes

Select ANY that apply:

• [ ] New Tests

• [ ] Existing Tests

• [ ] Test Framework

• [ ] CI System

• [ ] Other

Consensus Changes

• [ ] Consensus Changes

API Changes

• [ ] API Changes

Documentation Additions

• [x] Documentation Additions