EOS Town Hall - May 6, 2019

/

Notes Created By: LibertyBlock

Purpose

  • This week Kedar introduced a pay-to-key tool that uses direct payments to EOS keys, enabling people to hold EOS without needing an account.

    Check it out here.

Key Takeaways

How did the tool come about? (0:00)

Pay to Key was initially developed at a hackathon a few months ago. Usually, a user needs an account to make a transaction or hold EOS. With pay-to-key, a user does not need an EOS account to receive EOS and also enables Dapps to pay for people’s CPU.

Use-cases for the pay-to-key system (4:52)

Kedar is hoping the key system turns into a default way for people to interact with Dapps without having to know they are using a blockchain.

Demo status (6:03)

The version released a few days ago was a demo for the IQ token. Replay protection is almost complete, and a generic UTXO contract template for all tokens is in development.

Pay-to-key Roadmap (11:18)

Once nTimeLock is added, in theory, the UTXO contract will have EOS’ scalability as well as state channels. Also, private keys are the same for EOS and Bitcoin, so a fork of the contract can use Bitcoin instead of EOS addresses. At that point, a Bitcoin relay will be created to make a trustless swap method to move bitcoin into the EOS chain. Kedar is experimenting with running EOS or any EOS-based chain as a layer two solution for Bitcoin.

EEP6 Proposal (16:32)

EOS mainnet extensions are side-chains of the EOS mainnet which share user accounts with the mainnet via an account-synchronizing Oracle. This approach provides easy and linear horizontal scalability, which helps fully realize the scaling potential of EOS, and opens up competition for Dapps.

Find out more here.

Next Week’s Call

To be determined. Stay tuned for an announcement in the EOS Town Hall Telegram!

Connect

A special thank you to:

Telegram

EOS Town Hall - April 29, 2019

/

Notes Created By: LibertyBlock

Purpose

Key Takeaways

High-level Overview of Dan’s Price-pegged Token Algorithm (1:53)

The basis of the algorithm is an over-collateralized short position combined with the Bancor algorithm to provide liquidity to both long and short positions.

Prediqt’s Status (5:56)

Prediqt’s whitepaper was released last week. The back-end is complete, and the front-end is almost ready to go. A primary release is anticipated for June. Prediqt’s initial market could be based around a Game of Thrones finale or potential announcements for B1June.

Differences between Prediqt and Augur (8:06)

The main issue with Augur is that 60-70% of markets are scams. Markets are very close to legitimate but contain wording that makes the market invalid. Rather than a fully decentralized consensus method, Prediqt markets are resolved using trusted community members that have their reputation on the line, preventing markets from being resolved improperly.

Updates in the EOS Ecosystem (15:44)

People have become way too comfortable holding tokens on exchanges. REX might incentivize more people to hodl off-exchange. More hardware wallets supporting EOS and fiat on-ramps will help move the ecosystem forward.

Next Week’s Call

To be determined. Stay tuned for an announcement in the EOS Town Hall Telegram!

Connect

A special thank you to:

Telegram

EOS Town Hall - April 22, 2019

/

Notes Created By: LibertyBlock

Purpose

Key Takeaways

David's Lost Key Situation (1:23)

Key lessons in this segment: Early adopters had issues with hacks, faulty key generators, and occasionally copying down the wrong private key.

Lost Key Recovery Updates and Set Up (5:41)

EOS Authority helped organize eosDAC, EOS Authority, and LibertyBlock to code smart contracts. Work began around New Years, and test cases were successfully conducted on Jungle. EOS Authority will present the system to top BPs on Wednesday, April 24th

Timeline for Lost Key Update Solution (13:25)

You can use this link to see if your account is eligible for recovery. The solution will be available over the next year with a 30-day delay before swapping keys.

EOS New York's Token Proposal (14:53)

Despite being on a blockchain, many dApps aren’t as decentralized as developers think. EOS New York proposes an opt-in method for developers to abstract away control of more mature token contracts.

Token Proposal Benefits (24:24)

Benefits include not needing to maintain the token contract as well as substantial savings for airdrops. Also, the cleos transfer command only works on eosio.token contract. If developers could get their token on the eosio.token contract any site that supports EOS would also support the token.

Next Week’s Call

To be determined. Stay tuned for an announcement in the EOS Town Hall Telegram!

Connect

A special thank you to:

Telegram

EOS Town Hall - April 15, 2019

/

Notes Created By: LibertyBlock

Purpose

This week EOS Authority’s Rohan Abraham discussed REX updates. The EOS Resource Exchange (REX) enables token holders to lend/borrow CPU and NET resources.


Check out Rohan’s latest REX update here.

EOS User Agreement Update:

The EOS User Agreement was approved by 15/21 active Block Producers. From this moment on, the old constitution can be considered replaced by the EUA proposed by EOS New York. Congratulations to EOS New York and team on the approval of the User Agreement!

Key Takeaways

REX Background (1:40)

REX (Resource Exchange) started as a proposal by Dan Larimer on Aug 2018. REX lets token holders lease out their spare EOS tokens to Dapps or others that need resources in return for "rent" and access to community funds like RAM fees and name auction fees.

What’s the Difference Between REX and Chintai? (5:00)

REX is a systems level contract. Chintai’s method relies on block producers signing transactions which is not as smooth as a system levels contract. With REX you also get access to ram and namebid fees in addition to income from leasing out tokens.

Preventing Issues with RAM Mispricings (13:18)

The EOS Authority team tested REX on internal machines and Testnets. EOS Authority ran tests on the initialization parameters described by Block.one with positive results.

How to Get Ready for REX (24:44)

REX has built a feature to move tokens from liquid balance or staked CPU directly into REX without having to unstake. No action is necessary at this point.

Track REX Progress

REX Savings Overview and Voting Requirements (35:50)

REX savings accounts do not mature until triggering maturity. This makes the tokens illiquid for 4-5 days. It’s similar to unstaking and staking.

What are the Effects of EUA on REX? (42:54)

The EUA provides guidelines for how the community will behave going forward. REX is providing a secure user experience which establishes best practices while using the blockchain. Both efforts make it easier to adapt and make quick decisions.

Next Week’s Call

To be determined. Stay tuned for an announcement in the EOS Town Hall Telegram!


Connect

A special thank you to:

Telegram

EOS Town Hall - April 8, 2019

/

Notes Created By: LibertyBlock

Purpose

  • This week we took a look at EOS Hackathon finalists Chesnut and All_ebt. The teams discussed their products, hackathon experience, and views on EOS.

Key Takeaways

About Team Chesnut (1:08)

A Chestnut account empowers users to set their own security parameters, including spending limits, white/blacklisted accounts, and time-based transaction limits. It is a multi-signature account that splits the required transaction authorization signatures between the user and a smart contract, which either approves or denies the request, based on predetermined user preferences.

Read More


EOS Issues that Need Addressing (9:45)

More community auditing and helping each other build out smart contracts would be helpful. Newer teams without connections and relationships will face challenges.

EOS.VC Experiences (11:50)

Telegram is an incredibly valuable tool for getting responses from high-ranking members. Another benefit is that the bear market creates more of a community around builders.

All_ebt Background (16:22)

All_ebt is a smart wallet for food stamps. Over 54 million Americans receiving SNAP (food stamp) benefits each year are excluded from e-commerce entirely. All_ebt is serving underbanked and low-income communities through their virtual ebt card.

Read More

All_ebt’s Current Status (27:36)

The first iteration of the product moves money from a physical ebt card into a virtual Stripe card. All_ebt is laser-focused on user growth. They’re working on a pilot program with Instacart and feedingamerica.org to help feed people on food stamps.

Ethernom (31:03)

Ethernom created the world’s lowest power Biometric Smart Card on the market. The second version of the card will allow off-chain transactions, a compelling feature for unbanked people in developing economies.

Read More


Next Week’s Call

To be determined. Stay tuned for an announcement in the EOS Town Hall Telegram!

Connect

A special thank you to:

Telegram

EOS Town Hall - April 1, 2019

/

Notes Created By: LibertyBlock

Purpose

  • EOS Voter Bounties (EVB) began with a vision to pool votes in order to “fund” the development of important EOS infrastructure that lacks post development monetary returns. This week we discussed EOS42’s SWOT analysis of current proposals.


Key Takeaways

Voter Bounty Updates (1:18)

The EOS community quickly rallied behind the idea of funding the development of important EOS infrastructure. Eighteen proxies totaling 28 million votes signaled an intent to commit their voting power to the teams that build an open-source full history solution, or mechanism to test standby performance.


Standby Proposal Overview (6:55)

standby producer overview.png

Kedar’s Thoughts on Standby BP Proposals (9:50)

A major worry is additional bloat from schedule changes. Mandating a schedule change every fours hours would increase the data required to run a light node by 3–5x. That number might be manageable but there’s a concern it could get out of hand.

Another issue is having to hit a threshold of votes for the smart contract to be useful. We could end up in a weird situation where testing standby block production is cycled in and out every twelve hours due to intermittently running out of votes.

Read More

Hyperion Overview (18:52)

The EOS RIO team has a near fully developed full history solution that is ready for deployment. The Hyperion approach prunes a number of redundant and irrelevant fields present in action data, resulting in a much more compact dataset, that still retains all information of interest. EOS RIO and other BPs are also proposing a new API standard to facilitate interoperability between different history solutions and dApps.

Read More

EOS Blocksmith/EOS Detroit Proposal

Blocksmith and EOS Detroit are proposing a history plugin solution to stream data from the chain plugin into a Riak distributed datastore, allowing for a high degree of fault-tolerance. This distributed approach also makes horizontal scaling of the read requests easier.

Read More

EOS Nairobi & EOS South Africa (EOS ZA)

EOS Nairobi and EOS South Africa (EOS ZA) have signaled that they will collaborate to develop an open source Cassandra based History solution. The solution is set to benefit from the advantages of Cassandra, including horizontal scaling, consistent query performance, cost savings by using commodity hardware, and data compression. Given they receive enough support, they plan to start on April 20th and have a functional solution by July 1st, 2019.

Read More

ChainriftEOS’ Solution Overview (30:50)

The ChainRift solution leverages an “opt-in” approach that requires no system code changes. Proxies and regular users can opt-in by adding permission specifically for the contract developed by ChainRift.

The mechanism allocates one voting slot that randomly selects a standby BP, and puts them into the 21st position. All participating proxies are automatically coordinated to randomly select the same standby BP.

Read More

NodeOne’s Solution

NodeOne proposes a dedicated testnet where all paid BP candidates are mandated to run a full node. In the testnet, all participating BPs, regardless of being in top 21 or not in the mainnet, will have their turn producing blocks. Their track record of performance in the testnet will be monitored and fed back into mainnet on-chain in real-time

Read More

LibertyBlock’s Solution

In order to ensure that backup block producers are always ready to produce blocks, LibertyBlock proposes the following:

Replace the 21st slot in active production with a rotating slot that allows backup producers rank 21–25 to rotate into the production schedule. Each of the five backups will take turns producing blocks. Implementing this solution will require a hard fork.

Read More

Next Week’s Call

To be determined. Stay tuned for an announcement in the EOS Town Hall Telegram!

Connect

A special thank you to:

Telegram

EOS Town Hall - March 25, 2019

/

Notes Created By: LibertyBlock

Purpose

Key Takeaways

Introduction to the Cooperative Voting Infrastructure Bounties (1:23)

Instead of having to “guess” what voters want, BPs will have access to known deliverables that will guarantee votes. Similar to the idea of Worker Proposals, voters can “fund” projects that they want by flexing their voting power.


Projects will focus on addressing critical problems in the EOS infrastructure that fall under three categories:

(1) Highly demanding development costs;

(2) No post-development monetary returns; and

(3) Network security


The first bounties are for:

(1) The development of an open source full history solution; or

(2) A mechanism for testing standby production


Requests for Proposals (6:00)

ChainRiftEOS, LibertyBlock, and NodeOne have all submitted proposals with substantial differences. Once submitted, a robust technical assessment of various options should be conducted before moving forward.

ChainRiftEOS’s Proposal (15:16)

The ChainRift solution leverages an “opt-in” approach that requires no system code changes. Proxies and regular users can opt-in by adding permission specifically for the contract developed by ChainRift.

Find out more.


LibertyBlock’s Proposal (36:18)

In order to ensure that backup block producers are always ready to produce blocks, LibertyBlock proposes the following:

Replace the 21st slot in active production with a rotating slot that allows backup producers rank 21–25 to rotate into the production schedule. Each of the five backups will take turns producing blocks. Implementing this solution will require a hard fork.

Find out more.

Gaining Visibility and Next Steps (47:40)

Ryan Bethem from EOS42 is working on a SWOT analysis of the proposed solutions as well as a timeline.

Next Week’s Call

We will discuss CVIB and Ryan’s SWOT analysis of existing proposals.

Connect

A special thank you to:

Telegram

EOS Town Hall - March 18, 2019

/

Notes Created By: LibertyBlock

Purpose

  • This week we took a hiatus from the governance debate and discussed full history solutions.

Key Takeaways

EOS Community Updates (0:20)

The cooperative voting structure was a main area of focus this week. Two initiatives were full history and backup block producer readiness.

Full History and Hyperion Overview (1:10)

In Greek mythology, Hyperion is the father of the goddess EOS and means “the one who watches from above.”

Hyperion is a two-layer solution: Hyperion History and Hyperion Analytics.

More About Hyperion (6:25)

EOS Rio is already providing History API using Hyperion at https://br.eosrio.io/v2/history. The project code and preliminary set up instructions are available at https://github.com/eosrio/Hyperion-History-API.

Is EOS at a Place Where Lawmakers Can Intervene? (22:22)

The early internet wasn’t at a place where lawmakers could intervene. Right now, there isn’t much of a discussion with lawmakers about people losing private keys and money, but that will change as the network grows.

Light History vs. Hyperion (13:36)

Hyperion takes three or four days to replay versus almost a week using Light History. Time and cost savings using Hyperion are significant, and there’s room to make it even more efficient.

Spinning Up a Full History Node in Less Than 24 Hours? (16:20)

Hyperion is still not fully optimized yet. After optimization, the next step is launching Hyperion Analytics, an advanced layer on Hyperion History API to offer detailed EOS statistics.

Find out more here: https://eosrio.io/hyperion/.

Next Week’s Call

Connect

A special thank you to:

Telegram

EOS Town Hall - March 11, 2019

/

Notes Created By: LibertyBlock

Purpose

  • Open up a dialogue between the EOS User Agreement and EOS Community Constitution.

Key Takeaways

Introduction to the EOS User Agreement (1:27)

The EOS User agreement is meant to minimize and simplify expectations of blockchain governance.

EOS NY wrote the EOS User Agreement (EUA) because they felt that the current EOS constitution is not very effective.

The purpose of the EUA is to simplify the current Constitution. It is not a set of rules; rather, it is a reflection of EOS’ current reality. The EOS User Agreement is not a change to what we do. It is simply a reflection of what we already can do.

Differing Purposes of Voting (5:38)

EOS Amsterdam (Rhett and Jetse): the community constitution is meant to bring back the value of voting and stipulate that block producers are independent entities. 3rd-person arbitrators creating onchain solutions take some of the risks off of the block producers.

Protecting the Liability of Block Producers (13:57)

Are there other DPoS chains where network validators have been held liable? If 15 accountable entities decide not to do something, they can be subpoenaed and forced to do what is right. It hasn’t happened, but that doesn’t mean it won’t.

Is EOS at a Place Where Lawmakers Can Intervene? (22:22)

The early internet wasn’t at a place where lawmakers could intervene. Right now, there isn’t much of a discussion with lawmakers about people losing private keys and money, but that will change as the network grows.

What Rules Does the ECC Have to Prevent Exchanges From Using Token Holder Voting Power to Elect Their Own Block Producer? (37:08)

The ECC says that each block producer to be independent to reduce common control. The document also requires exchanges to vote in accordance with token holder requests. Lastly, block producers are limited to controlling 1% of the vote.

Feedback for the EOS User Agreement (42:40)

The agreement doesn’t address governance, giving room to predictable outcomes that aren’t ideal.

Feedback for the EOS Community Constitution (49:00)

The ECC does not take into account functions built within EOSIO software that could be leveraged to protect token holders.

Working Together to Get Something Passed (59:47)

It may not happen anytime soon, but lack of action on getting something passed does the EOS chain a disservice. Finding the smallest action to move forward with and create momentum is the goal.

Next Week’s Call

  • EOS Amsterdam is writing a long-form Medium article to address some of the questions Kevin raised about the ECC. The call will be centered around discussing the article and continuing the conversation on EOS governance.

Connect

A special thank you to:

Telegram

EOS Town Hall - March 4, 2019

/

Notes Created By: LibertyBlock

Purpose

  • Discuss the Blacklist Update Failure, the EOS User Agreement and the EOS Community Constitution.

Key Takeaways

Is the Blacklist Update Failure a Chain Emergency? (7:50)

An anonymous hacker managed to move 2.09 million EOS ($7.7 million) from a hacked account due to an allegedly failed update by an EOS block producer (BP).

The blacklist was in a text file that is prone to mistakes. It was never intended to be a robust long-term solution and created expectations that could not be met.

Voters keeping tokens on-exchange gives exchanges more influence than they should have. DPoS relies heavily on voter participation which remains at low levels.

The Security Issues of Anonymous BPs (12:24)

When requiring multiple BPs to act, having a point of contact such as Telegram is much more important than knowing the personal identities of people running a specific BP. So far, there hasn’t been any way to contact games.eos.


Introduction to EOS Community Constitution (ECC) (18:04)

The Community Constitution is a joint effort of members of the Chinese, Korean, European and North American EOS community.

Differences Between the EUA and ECC (34:34)

The biggest difference is that the EUA provides a simpler framework that sets expectations for how DPoS should work whereas the ECC presents more complex rules for the broader ecosystem.

Getting into a complex legal document will take a good amount of time. The simplicity of the EUA is attractive because it sets the foundation to move toward more complex standards.

Clarifying Enforcement (44:44)

ECAF created unenforceable expectations, resulting in a need for a simple starting point - one that defines the criteria for what is enforceable and what is not.

When engaging with someone in a contractual relationship, we could agree on how to hold both parties accountable. An internationally recognized arbitration forum can work in this scenario. When it comes to theft, a document may not be able to protect people’s property. In this case, multisig, time-delayed transactions can preemptively prevent crimes from happening.

The Practicality of Dispute Resolution at the dApp Layer (50:56)

Why is it necessary for ADR to be included at the protocol level rather and not the smart contract level? There is more flexibility at the smart contract level than the protocol level.

Voter Apathy (1:01:22)

EOS holders store tokens on centralized exchanges which excludes them from referendums or anything related to voting. Efforts to increase voter engagement haven’t been successful and turnout in the Asian community is low.

Next Week’s Call

  • We'll have a debate over several of the various constitution proposals.

Connect

A special thank you to:

Telegram

EOS Town Hall - February 25, 2019

/

Notes Created By: LibertyBlock

Purpose

  • Continue the discussion around the EOS User Agreement and rally support from international BPs and proxies.

Update from Last Week’s Call

Last week’s topic of discussion was figuring out ways to involve more Chinese BPs, proxies, and constituents in the development process. Yves is currently in China meeting with local BPs discussing support for the EOS User Agreement. Since the last call, efforts have been made to translate future proposals and conversations to Chinese and Korean.

Find the notes from last week’s call here.

Key Takeaways

Can the EOS User Agreement Gain More Votes?

If you add Bitfinex and Huobi votes, we have 93 million votes which represent most of the votes that could occur (110 million voting for top BPs). This is out of a total of 240 million tokens staked for BPs. Bitfinex currently polls users to get their votes out. Huobi says that they would vote but the restrictive parameters set–that exchanges must stake for at least 30 days–makes their participation in voting for the constitution unlikely. It is somewhat safe to assume exchanges will not vote on referendum items.

If exchanges abide by the threshold in the current constitution, there is a minimum of 30 days to pass. Exchanges might believe they need to stake for 30 days but, that is not necessary. Putting it up for multisig and having people vote would streamline the referendum passing process.

What do we do to get more active token holders?

EOS is currently at 25% voter engagement (266 million tokens) and with 13.8 million votes, the EOS User agreement is supported by 20% of active voters. The number is even higher when exchanges aren’t factored in. In the long-run, basing decisions around empirical evidence (active token holder signals) rather than arbitrary parameters set at launch might be a better path to follow.

Should BPs be politicized?

“For delegated proof of stake to work you’re not just electing technically brilliant engineers.” – Luke Stokes

Being a BP requires more than technical expertise. With PoW your reputation and trustworthiness aren’t big factors in the ability to support the network. We need proxies to signal to BPs as defined by their responsibility in dPOS. BPs caring about the community and investing value in the network gives a signal to proxies. Brockproxy1 has done a good job of reaching out to BPs to better understand their backgrounds and intentions.

Shifting Opinions as the Network Changes

In the past six months, David’s opinion has gone from believing BPs should stay politically neutral to uptaking elements of leadership. This change is a response to the needs of the network, but we must define when a given referendum can be proposed for implementation.

Open Discussion Topics

Voter Proxy Reward Bounty

The goal here is to allow BPs to run full history nodes without exhausting their resources. The bounty rewards have enabled LibertyBlock and EOSRIO to move forward and submit proposals. Gathering the proxies together to be able to signal votes spurs action in lieu of a worker proposal system. Engineering and development efforts need to be incentivized so platforms such as this can improve network conditions.


Full History Plugin

Michael Yates put out “firehose,” a state history plugin to get real-time information. This is the direction that most applications and systems are moving toward. Once other solutions become available in the ecosystem, a need to demonstrate how newer solutions are more efficient and effective will arise. EOSWeekly’s video did a great job outlining the issue surrounding full history nodes. That said, they stated there are only five BPs running full history nodes. It’s not entirely accurate because EOSAsia, OracleChain, and other Chinese block producers are running full history nodes.

Another issue is that different history solutions return different data. EOSNation BP validator has a mark that tells developers which type of history they are running which gives developers a better user experience by providing clear direction on which format to use.

Action Items

  • The group is reaching out to mainnet BPs and proxies to rally support for the EUA.

  • Edit the Block Producer Guide that was proposed during last week’s call.

Next Week’s Call

  • The EUA will be the topic of discussion and EOSAmsterdam will share their perspective as supporters of the EOS Community Constitution.

Connect

A special thank you to:

  • Kedar Iyer and Timothy Lewis — LibertyBlock

  • The Cybercode Twins — shEOS

  • Luke Stokes— eosDAC

  • Kevin Rose — EOS New York

  • Thiago Canellas—EOSRIO

  • Yves La Rose — EOS Nation

Telegram

EOS Town Hall - February 18, 2019

/

Notes Created By: LibertyBlock

Purpose

  • EOS User Agreement and Global BP involvement

  • Reset expectations of what governance really is on EOS

eos user agreement image.png


Key Takeaways

Understanding EOS Governance

“The purpose of the EOS user agreement is to give a hard reset to expectations of what governance is... A lot of the proclaimed failures of EOS governance are merely a result of mismanaged expectations.” —  Kevin Rose, EOS New York

At launch, there was a misunderstanding between architects of the original governance framework and their grasp of the basic feature set of EOSIO software. The original user agreement was intended to set hard governance on EOS. The current state of the ecosystem is the result of a lack in community governance. A system that heavily relies on network validators doesn't presently work.

Resetting Expectations

“EOS is a better-governed blockchain unlike PoW systems where the stakeholder cannot hold the network validator accountable.”  —  Kevin Rose, EOS New York

If ECAF had the permission that allowed them to enforce their findings, the state of the network would be different. They persisted in a state of reliance on network validators which ultimately did not work.

EOS User Agreement establishes an expectation that there is no blanket dispute resolution mechanism on EOS; there is no base layer arbitration.

The community needs to involve more Chinese BPs, proxies, and constituents in the development process itself. The ecosystem could be more inclusive when it comes to collaboration and community involvement with one of the largest EOS participants in the space. The language barrier itself presents a hindrance in relaying information, resulting in a lack of action and feedback from their end. Looping them in on the conversation would be a great way to hear their voices and address their concerns so we can build a more cooperative, global EOS community.

Block Producer Guide

People need more visibility from Block Producers regarding their stance on what they support. We will create a Block Producer Guide that will include the following:

  • Creating a referendum specific voter permission. (not using active key)

  • How to vote for referendum using cleos

  • How to tell if a referendum has garnered enough support (where to look at referendum, how to use eos titan tools)

Next Week’s Call

Continue to base discussions around the EOS User Agreement and getting more BPs involved in building a better framework for the community governance.

Connect

A special thank you to:

  • The Cybercode Twins — shEOS

  • Kedar Iyer and Tim Lewis — LibertyBlock

  • Kevin Rose — EOS New York

  • Josh Kauffman — EOS Canada

  • Yves La Rose — EOS Nation

  • Myles Snyder — Aurora EOS

Links mentioned:

Telegram:


EOS Town Hall - February 11, 2019

/

Notes Created By: LibertyBlock

Agenda:

- Continue the discussion about eos.savings

- NET Optimization (Kedar)

- Continue discussion about the 15% “threshold” for referenda and define a meaningful but achievable level. (David)

- Discuss the case backlog for individuals who filed claims and cases under the interim constitution and suggest potential resolutions. (David)

Guests:

Tim Lewis — LibertyBlock

Kedar Iyer — LibertyBlock

Kevin Rose — EOS New York

Luke Stokes — eosDAC

David Packham — EOS42

Congratulations to Luke for the official launch of eosDAC, a community-owned block producer!

Vote for custodians using the eosDAC member client.

eosDAC Member Client
Come to the eosDAC Member Client to register and interact with the DAC-enabling Decentralized Autonomous Community.

Kevin: Development of the hardware wallet is still underway. Last week, the first proposed replacement to the current EOS constitution went on chain called the EOS user agreement. It currently sits at roughly 6 million votes. This is still not close to the requisite 15% vote of roughly 150 million. Kevin can’t wait to grow after months of stagnation and indecision.

The 15% Threshold is Arbitrary

David: 15% is an arbitrary number that was predicated on the assumption that there would be a high level of voter engagement. What we’re seeing is that engagement isn’t that high, and even the most popular referenda won’t reach 15%. The community needs to signal how to better adapt that to get things passed. We have to completely reassess if 100% approval is the same thing as a vote being popular. How does the group process this and concretely define what is an acceptable level of healthy level of voter engagement? Even 5% could work but is that really what we should be using as the basis?

Kevin: The threshold doesn’t matter. Permissionless voting doesn’t warrant forcing users to vote once something hits a certain threshold. Let’s say there is a 51 million vote threshold, but it only gets 50. If BPs don’t act, standbys can take votes. Once you think that through, any threshold becomes meaningless and becomes a personal threshold of every organization as a Block Producer.

Kevin Wrote about this a few weeks ago here:

Rethinking EOS Referendum Game Theory: Why 15% Token Participation is Irrelevant
A recommendation to clear the way for liquid democracy on the EOS Mainnet

Tim: Can we start talking to mainnet Block Producers that would signal yes so we can start taking action? Another referendum with signals of 15 of the top 21 Block Producers is enough to get started.

Do we have a polling system to see how Block Producers signal towards referendums?

Kevin: EOS Titan made a tool to filter Block Producers in a grid view to see what they support. These UIs will be the key to help voters understand who to vote for.

EOS Titan Heatmap:

EOS Titan
EOS Infrastructure Builders

How do we execute on some of the more significant issues?

Block Producers should vote and signal which referenda they support to spark action by letting people know where they stand.

The Trouble with Voter Engagement:

Luke: eosDAC put the 15% threshold in their constitution as well. Around 2500 member accounts took months to get to 15%. It took forever to get these votes and stakeholders were getting frustrated. The community block producer reached 14.5% and eventually they decided to launch on the 14th. Although eosDAC might have a harder time reaching a consensus, everyone should continue to further any ongoing conversations to push for community involvement.

Luke: The Telos DAC token airdrop for voter incentives was just enough to get people to vote; this could be a viable, temporary solution to increase voter participation in referendums.

Luke: It’s interesting to think of proposals as polls, but we should define what the quorum is for each proposal. For example, one could signal to block producers that they would like to vote when the referendum hits x %.

The 15% Threshold No Longer Makes Sense.

Kevin: We have a more mature blockchain, but we’re applying the same restrictions from launch to less important matters that actually hinder the progress of the ecosystem.

Kevin: People will wake up and realize the threshold doesn’t matter once the first time a block producer moves up 20 million votes because a referendum they support is what people want. It’s up to UI providers to show what block producers support and don’t. We need to communicate with block producers how important it is to voice who they support with the rest of the community.

What referendum item can we test this out on?

Kevin: It’s a good, but an unrealistic, idea to expect voters to go back after the expiration date and check what block producers supported. Eos.savings could be something to start with, but it’s probably the most complex issue to move on.

Eos.savings

Kedar: It’s simple to print savings again if necessary. It’s not difficult to add EOS to the chain, but it is hard to reach a consensus on turning off inflation. Should we act on turning off the spigot and turn off inflation until actions start?

David: There’s an opportunity there to fund unforeseen future needs. That said, there isn’t any justification for the current buildup of token reserves. A controlled burn with referenda proposing burn limits on a quarterly basis could be implemented relatively quickly. Kedar has an existing proposal to get this started.

Kedar: The best way to get them to pay attention is to pose on-chain and include the result of the vote in the referendum. Let token holders know who supported and who didn’t.

Luke: The burn is a complex economic issue and that it might not be the best place to start. Scott from Greymass talks about how inflation is important in democratizing distribution of newly minted EOS to non-block producers.

Scott explained to Luke that the system is not well designed. If inflation to savings is higher than block producers, then it’s okay, but block producers are entrenching their positions due to the lack of structure around savings.

Tim: Maybe we should use savings to incentivize voters.

Luke: This sounds good but could introduce negative externalities. Eos.savings can be seen as insurance in case Block.one doesn’t fulfill its promises to the community.

EOS User Agreement

Kevin: The EOS user agreement might be a better place to start. It creates somewhat of a consensus on-chain to move in a direction and get signaling conversation going with token holders. If and when signaling looks right on the user agreement, we can address larger issues.

Kevin: Block producer incentives set a game theory of referendum. In this case, the threshold for EOS NY is low because they wrote it.

The user agreement poll:

EOS Poll: Should EOS adopt the EOS User Agreement (EUA) in place of the interim Constitution?
EOS poll - Question: Should EOS adopt the EOS User Agreement (EUA) in place of the interim Constitution?

What is Kevin’s expectation on when this could be implemented? How can we help?

Kevin is accepting help to translate the document into Mandarin and Korean. They did not include this in the referendum, but it’s a nice signal to anyone who doesn’t speak English. We should wait till it’s translated, so Block Producers in those regions have time to deliberate over it.

Next Monday’s call is specifically about starting a conversation with international block producers to create signals and pass the user agreement. Any change to the user agreement shows the community of action being taken, encouraging others to do the same.

Kevin will present the case to get the ball rolling on this so we can move towards action.

In the meantime, the group can push for rallying standby block producers and top block producers on the list.

NET Optimization Updates

Kedar has determined parameters they want to change. (from 1mb to 512kb)

The target is 10% and will go down by half. Kedar is hoping more staking is required, and that congestion is triggered 1–2x per day to get people staking NET tokens.

Passing a proposal on Kylin is tough. Kedar is looking to get it passed on Jungle and will submit a mainnet proposal to get things going.

How do we resolve the case backlog?

David: We’re in a situation where the interim arbitrator has not processed cases. The underlying issue is that good faith purchasers bought into missing features. One outcome is that block producers might get class action lawsuits filed against them. We must collectively decide what to do with the backlog of cases. We have a blacklist of accounts that are being frozen. We need to figure out, from a leadership perspective, what to do with these complex cases.

If we enter into a new constitution what do we do with the case backlog?

David: Let’s say agreement gets superseded in 6 months. It’ll be the user agreement that applies. We could choose to say it doesn’t matter, but there will likely be blowback from that. It’s imperative to discuss the unintended ramifications of the actions we take and what we base those ramifications on. Should it be by the present agreement or by the standard at the time?

This is an important issue, however, moving towards a new resolution of the user agreement is still the number one move.

/ /

Ikigai HQ

EOS Town Hall - February 4, 2019

/

Notes Created By: LibertyBlock

Agenda:

  1. EOS DAC

  2. Remove vote decay for proxy if proxy votes regularly

  3. Discuss next steps for a monthly or quarterly vote on the eos.savings bucket.

Guests:

EOS DAC:

- eosDAC is an evolving Decentralised Autonomous Community (DAC) focused on becoming a leading EOS.IO Block Producer serving the EOS communities worldwide.

- eosDAC creates the tools and smart contracts it needs to function and shares these with the EOS community.

- There’s potential for the DAC model to function as a mechanism for multisig control.

- Tim’s initial thought was that every block producer should be a DAC to avoid collusion. He’s extremely excited to see development around this concept.

Tools:

Part 1: Membership Client (https://members.eosdac.io/)

- The client includes voting and proposal system.

Part 2: DAC Factory

- Takes existing functionality and makes it easy to deploy other DACs.

Tutorial: Launching Your Own DAC on the Jungle Test Network with eosDAC

https://steemit.com/dac/@eosdac/tutorial-launching-your-own-dac-on-the-jungle-test-network-with-eosdac

https://www.youtube.com/watch?v=AvM0sA07IME

Remove vote decay for proxy if proxy votes regularly

- Luke’s proxy has around 2.9M EOS staked.

- Ash runs another proxy and is in favor of keeping vote decay to prevent creating two hierarchies of voters.

- Problem is not that people are voting and leaving. It’s that they are not voting. Luke thinks we could remove vote decay but hasn’t voted yes.

- Let people automate their vote to increase voter participation. Should we have a time limit? (ex: 3 month)

- Josh doesn’t think removing vote decay will draw people out but agrees there should be a limit on automated re-voting.

Eos.savings bucket

- Follow up from eos.savings discussion last week. https://medium.com/@eostownhall/agenda-be58876f5c81

- Savings could be drawn from mainnet community if they decide to take control of the development of the codebase.

- The community is looking for a degree of leadership and structure around this.

- Luke would like to explore worker proposal system (smart contract based) within the microcosm of EOS DAC. Next evolution could be a sidechain on EOSIO for system level DACs. From there a long-term solution could be ported into mainnet.

- Lack of clarity creates a need for a structured on-chain mechanism for transparent burns.

- More flexibility around creating burn and initiating fee to raise funds when necessary.

- Just one pull request to do code change on eos.savings can spark conversations.

- Outline code changes and impacts on the economy for more focused discussions. If there are multiple pull requests, weigh the pros and cons of each.

Follow Up:

- Josh to reach out to Block.one to get eeps.io under github.com/eosio.

- Create multisig contract to burn January’s inflation on the savings account. (Jae Chung from HKEOS has been working on WPS)