cc32d9

CONTRACT=mycontract

all: $(CONTRACT).wasm $(CONTRACT).abi

%.wasm: %.cpp
        eosio-cpp -o $@ $<

%.abi: %.cpp
        eosio-abigen --output=$@ $<

cc32d9

mcleos multisig propose cc32dninewp1 '[{"actor": "atticlabeosb", "permission": "active"},{"actor": "dublinsocial", "permission": "active"},{"actor": "eosasia11111", "permission": "active"},{"actor": "eosauthority", "permission": "active"},{"actor": "eoscafeblock", "permission": "active"},{"actor": "eosgenblockp", "permission": "active"},{"actor": "eosmetaliobp", "permission": "active"},{"actor": "eosnationdon", "permission": "active"},{"actor": "eosnewyorkio", "permission": "active"},{"actor": "eosriobrazil", "permission": "active"},{"actor": "eostribefund", "permission": "active"},{"actor": "goodblockio1", "permission": "active"},{"actor": "lynxlynxlynx", "permission": "active"},{"actor": "teamgreymass", "permission": "active"},{"actor": "worblieosbp1", "permission": "active"}]' '[{"actor": "cc32dninewp1", "permission": "owner"}]' eosio updateauth '{"account": "cc32dninewp1","permission": "owner","parent": "","auth": {"threshold": 1,"keys": [],"accounts": [{"permission": {"actor": "cc32dninexxx","permission"

cc32d9

Repurposing of Telos WP#25

The Telos work proposal #25 was opened with the target of implementing portable snapshots for Chronicle, so that Chronicle data can be easily moved between servers of different OS versions.

As of August 22nd, I added a new feature to Chronicle that allows starting it from a nodeos portable snapshot. So, there's no need to re-scan the whole history in order to get up to date Chronicle data. Now it's enough to point it to a node that just started from a snapshot. This eliminates the need for portable snapshots in Chronicle, so the initial purpose of the WP is obsoleted.

The work proposal asks for 50000 TLOS, which is approximately USD 2500 in current prices.

I propose to re-purpose the WP#25 and set the following deliverables:

cc32d9

Keybase proof

I hereby claim:

• I am cc32d9 on github.
• I am cc32d9 (https://keybase.io/cc32d9) on keybase.
• I have a public key ASB62UjQutf9851px3PcEu9pC1N2YcvkP3UvOc9ImK7RJAo

To claim this, I am signing this object:

cc32d9

// here MYACC is the account sending the transaction
// NEWACC is the name of account being created

  await (async () => {
        try {
            console.info('Creating account');
            const result = await api.transact(
                {
                    actions:
                    [

cc32d9

https://t.me/EOSproject/1561416

Aarin Hagerty, [30.10.20 14:48] [In reply to Luka Perrrcic] I would like to provide some historical context regarding this discussion of DPoS voting mechanisms.

BitShares ended up with an approval voting system (which one can think of as 1 token infinity votes) for voting for BP (block producer) candidates which then ranked them by approval vote and selected the top N as the set of active block producers. I don't remember the exact series of events and reasoning that led to that decision, but I am sure most of it can be found on the old BitSharesTalk forum (e.g. https://bitsharestalk.org/index.php?topic=5205.0).

There are some advantages of an approval voting system over cumulative voting (https://en.wikipedia.org/wiki/Cumulative_voting), which one can basically think of as 1 token 1 divisible vote, particularly in the case of single winner elections. For example it passes the favorite betrayal criterion (https://electowiki.org/wiki/Favorite_betrayal_criterion) whereas cu

cc32d9

MariaDB [eosio_activity]> select sum(counter) S, count(distinct authorizer) A, action, contract from eos20210116_DAILY_COUNTS where xday='2021-02-03' group by contract, action  order by S desc limit 50; 
+-----------+------+--------------+--------------+
| S         | A    | action       | contract     |
+-----------+------+--------------+--------------+
| 192012703 | 4878 | transfer     | eosio.token  |
|  93927965 |   76 | transfer     | eidosonecoin |
|   1972506 |   24 | transfer     | eosiopowcoin |
|    762427 |   26 | mine         | gravyhftdefi |
|    482590 |    4 | stamp        | wordproofcom |
|    416986 |    1 | quietransfer | gravyhftdefi |

cc32d9

From EOSIO Developers Chat: https://t.me/joinchat/0uhWYfXVpPlkNTA1

Jesse - CalEOS.io (caleosblocks), [27.09.21 23:27]
So, KV_DATABASE feature uses disk but when that's activated the current multiindex tables are still in RAM?

Jesse - CalEOS.io (caleosblocks), [27.09.21 23:27]
I thought they went together... both to disk

Todd Fleming, [27.09.21 23:51]
What we created:

cc32d9

#!/bin/sh

## This simple script is copying configuration files and directories
## from your server to your private Git repository. make sure that the
## Git repository is private and under your control.
##
## Put your directory and file names into /etc/backup_configs and run
## the script. It will create a local Git working directory, copy
## files into it, and push the update to your Git repository.
##

cc32d9

@SirFuzzalot presented an idea for a new PB pay model for an EOSIO network in https://t.me/EOSPros

Fuzzy, [12.05.19 04:56]
Here is my thought on fixing dpos away from pageantry though. 
Let me find the discussion (should prob post it on whaleshares first but oh well)

Fuzzy, [12.05.19 05:03]
Ok ill just type it here since i am no longer in the group i posted it in initially.