12th of September
EOS VOTER PROXIES
Josh Kauffman - EOS Canada posted an article that is relevant for proxies, as it dives into the mechanics and math of vote strength calculation. Super important for a proxy to keep their votes up to date and know how the users who delegate to them are affected when they revote
https://www.eoscanada.com/en/how-is-your-vote-strength-calculated-on-eos
Kai - bpRatings.io
This is our workspace for transparency.
http://bit.ly/bpr_work
Check it out!!
Katie | @eosasia | myeoskit.com (pinned message):
Hi Everyone! A new initiative has arisen!! Thanks to @SirFuzzalot any proxy or community member that participates in conversation in this group can earn free EOSBITS! EOS PROXIES are important and Fuzzy would love to hear more from them!
This initiative will run over the next two weeks! Thanks to you all!
Tanish EOSMetal (eosmetaliobp) shared info about Tungsten:
Gearing up to launch MVP for Tungsten. As of now I working on the post related to governance, reading Colin's rule, Ethan Katsh and everything related to ODR.
Tungsten is our first project related to bond based dispute resolution which enables the following -
- Any party could raise a collateral mentioning few promises and an Arbitration forum to enforce.
- Any person in business with said party could claim against the bond if promises are not followed.
- Brings more trust among the members as bond could not be unstaked for a period of time.
- We are also trying to align our self with V2 constitution and looking to develop methods to get the best of both world.
Pros -
-Self enforceable i.e convenient and fast. Maybe we could be able to use the Bots like Ebay on EOS if Bonds becomes successful.
-Open and Transparent.
-With algorithm used for filing disputes bond based ODR will be efficient and cheaper than any human Arbitration system.
Criticism -
-Increases opportunity costs.
We are looking forward to feedback and suggestion from the community on @eosbond.
Details -
https://medium.com/@EosMetal/introducing-proof-of-concept-tungsten-for-dapplication-level-governance-fea8b0a452e9
Tanish EOSMetal (eosmetaliobp) also wondered “How things are going at @eosasia?”
and Katie | @eosasia | myeoskit.com replied to him:
The convo there is pretty low volume right now, we want more people interacting. Things are going well though, getting ready to release a proto Dapp EOS PIXELS. The EOS community is building Dapps at neck breaking speeds, it’s truly amazing.
Katie | @eosasia | myeoskit.com asked users opinions about BPs agreement, which is not followed by everyone: "I, {{producer}}, agree not to set the RAM supply to more RAM than my nodes contain and to resign if I am unable to provide the RAM approved by 2/3+ producers, as shown in the system parameters."
The basic arguments I can see are as follows:
The chain parameter is; "max_ram_size": "78912975872",
Since that is in bytes, converted to GB that's: 73.49344
So anyone running more than they have are doing it to make tx happen more quickly which itself is limited by the software so is a meaningless metric;
Kevin Rose - EOS New York replied:
I don't know if this is even necessary. I know I'm butting in on a technical conversation but why call this out specifically?
Patrick B - Aloha EOS agreed:
It’s not the most clear statement, like most of regproducer. We (Aloha) of course agree producers should be capable of handling the needs of the network. However they should also be given the flexibility of testing different hardware configurations.
Users had a pretty hot discussion until Josh Kauffman - EOS Canada good Greymass explanation:
please correct me if my paraphrasing is wrong. But Greymass had explained (I'll use made up small round numbers to make it easier to follow) that they have multiple producing nodes with different amounts of RAM. Their main one has 1 GB available, their backup has 2 GB available, and their next backup has 4 GB available. Right now, the chain uses less than 1GB so their main node is producing. As soon as it needs 1.000001 then it'll failover to the backup. There will be no loss of uptime, and they will function as normal. Then, when it hits 2.00000001 GB, it will failover again. Again, with no downtime.
They say that this is suitable and meets the needs of the chain and follows along with the spirit of the clause. Others argued "But we spent all this money on putting 750GB of RAM into all our nodes! That's unfair!"
Also Josh Kauffman - EOS Canada shared a link of BP call:
Katie | @eosasia | myeoskit.com admit:
I’m so happy we can speak about these issues openly and freely. It’s a sign of good community and a great indicator of the future and what EOS has to come.
Users continued the discussion about RAM usage cases from their experience:
Anders ' coachbjork ' eos sw/eden
Except for the reason that you do not need more ram atm. Why wouldn't you want more ram in your main producer? If I pay a storage provider for 1TB disk space, I would want them to have that 1TB ready for me, even though I am only using 200mb atm.
anyx — TeamGreymass replied:
If you pay a storage provider for 1TB they don't go out and buy a 1TB disk for you. They use their infrastructure appropriately and offer you, across their infrastructure, the right to 1TB of storage. It might not be on the same physical device. But they guarantee it will be there when you end up using it, since they have plenty of spare room for all their users and can add more when needed too.
And other users supported him.
Anders ' coachbjork ' eos sw/eden
if a ricardian contract aint clear, isn't it important to rewrite it? so that it can not be a subjective decision?
Katie | @eosasia | myeoskit.com assumed:
think we need to figure out if the wording hurts or helps. Is it needed or not. It seems to me what is not fair is to put rules in place and then those that are rule followers will be seen as less than than those that are and vice versa. After the metrics tool was published I saw a lot of community members commenting on the metrics and saying they were going to base their votes on them, which is kind of not that helpful.
Nate D - Aloha EOS agreed:
I agree that isn't helpful and it's why we tried to clearly state that in the disclaimer. However it sounds like you are saying the only way to "compete" (using your sports and steroids reference) is to have less than the ~73GB of RAM set on the network. This is inaccurate. Look at Rio's benchmarks for an example. While they were in the 21 they were at the same numbers as Greymass and that was using a Xeon with, I assume, greater than 73GB of RAM.
Sharif Bouktila - eosDublin
We (as a community in Telegram) constantly talk about the token holders and what they want, but the concentration of voiceless accounts who hold all the power isn't being consulted as far as I can see.
I have no idea how to contact them, none of them have expressed any wishes that I can see.
Finally, users discussed referendum, vote trading, exchanges etc. They were very active and enthusiastic that day.
EOS WATCHDOGS
Shaheen Counts - EOS BlockSmith presented a new tool:
We just came out with a new EOS Dashboard tool.
Take it for a testspin here:https://dashboard.eosblocksmith.io
Otto positively reacted to previously posted link https://dashboard.eosblocksmith.io “I like how btc is listed in top altcoins :)”
Other users laughed also.
EOS Alliance Open Discussion
Kevin Wilcox organized Call #2 open for English speakers to discuss Articles X - XX of the EOS Constitution. Starts at 7:45 EDT.
Link: https://zoom.us/meeting/register/288238fbdafd61b47c24e00bf0acd2b8
Slides for anyone who wants to review before call: https://docs.google.com/presentation/d/1lbLEw7Nfj8vVnkKWsZ36oBuA55B8N8a613kFIagDJk8/edit?usp=sharing
Livestream: 
Kevin Wilcox admin:
Thank you all for coming - Call #2 discussed Articles XV & XVI. Everyone agreed Article XV should be removed or reworded in its entirety until we have more information about its actual intent. As it is, the article does little more than cause confusion and derision both inside and out the EOS community. Article XV wording:
Article XV - Termination of Agreement
A Member is automatically released from all revocable obligations under this Constitution 3 years after the last transaction signed by that Member is incorporated into the blockchain. After 3 years of inactivity an account may be put up for auction and the proceeds distributed to all Members according to the system contract provisions then in effect for such redistribution.
Article XVI elicited varied opinions about who should be at fault in a blockchain transaction, and how much can be expected of the end user upholding their part by reading the Ricardian contracts. The wording "unintentional mistakes" leaves the door open to subjective debate, which could cause a lot of arbitration cases and other issues. The group compared Article XVI with Dan's proposed change to the article. Original wording:
Article XVI - Developer Liability
Members agree to hold software developers harmless for unintentional mistakes made in the expression of contractual intent, whether or not said mistakes were due to actual or perceived negligence.
Dan's "Intent of Code is Law" v2 Proposal:
Contract developers are not liable for damages caused by bugs in the code. All Parties are responsible for auditing the code and the Ricardian contract before use.
Adam and EOS Detroit, as always, are amazing for livestreaming. If you'd like to go back and review the discussion, Article XV was discussed for the first 20-25 minutes and Article XVI the final 30 -
Joe
https://www.reddit.com/r/eos/comments/9f0m1t/untouched_mainnet_genesis_accounts/
Rhett Oudkerk Pool
74 paid BPs * Rio norm 1,8KW *24 hours = 3196 kWh / day =0,0032 million kWh / day
Dmitri Pro MEET.ONE
Here is link from today call with Russian community. It was very active discussion and i am very glad to do it with Russian community. 
Kevin Wilcox
Korean & English Call is starting shortly - https://zoom.us/j/929724529
Robrigo - EOS Detroit
Livestream is available here: 
BP Call livestream: Livestream
Jose Toriello
Hello Alliance! I think this is a relevant point:
http://uvoh.com/eos/how-will-eos-achieve-mainstream-adoption-when-this-is-what-the-new-user-experience-looks-like/
How are we addressing this in the Alliance? If at all? Please let me know if there is a space for user adoption strategies or if anybody has an opinion on the matter.
Kevin Wilcox
Easing the new user experience is a challenge for all of us with EOS. The tools for simple onboarding are still being built or improved upon; patience will be our guide in the near term. Would highly suggest someone lead the charge to form a user experience working group - study the onboarding process and make recommendations to dapps for improvements.
If you'd like to be a Working Group with the Alliance, please see this template for submitting a proposal: https://eosalliance.io/workinggroups/
EOS BlockPros
Josh Kauffman - EOS Canada posted a link which explains the mechanics AND the math of vote calculation https://www.eoscanada.com/en/how-is-your-vote-strength-calculated-on-eos.
This got a positive reaction from users.
Steve Floyd - eostribe.io replied to Oliver SVK Crypto - LDN question “Is EOS a permission blockchain? Given the fact that BP/s must be voted in?”: EOS is a public permissioned blockchain. With DPOS consensus under the hood, you must have an account to utilize free transactions on the network. You cannot just connect to the network like PoW based chains like ETH or BTC, there are some rules. This is all by design though.
You must stake the amount of CPU/NET or RAM you intend to use. There is talk of a REX and projects like Chintai to lease tokens your dApp may need for resources on the network in the event you don’t have enough tokens to run your dApp.
Oliver SVK Crypto - LDN asked the community:
Does it make sense for bp's to run the eos mainnet as well as other eos forks like telos?
Steve Floyd - eostribe.io replied:
That's up to BPs themselves.
@eostribe supports the the Worbli sister chain, but decided to not participate in Telos. We like Telos and the work they are doing, but decided to not actively participate. Partially because of time / resources, partially a philosophical decision.
Xavier Riba asked:
What is the minimum of eos you can have staked in an account?
Kevin Rose - EOS New York answered:
Try a few, 3 or 4. We're still amidst benchmarking these stats.
Josh Kauffman - EOS Canada
Didn't have a chance to watch the Block Producer call :calling: today? Here are EOS Canada's notes on the top four things that were discussed and a link to the recording. :movie_camera:
https://www.eoscanada.com/en/block-producer-community-call-september-12-2018
EOS Mainnet BPs
Bart Wyatt
https://github.com/EOSIO/eos/releases/tag/v1.2.5 includes the leak fixes from earlier today. we are very interested in whether this addresses the concerns. Please feel free to DM me with questions, concerns and/or reports of the results
Devin Lee KOREOS.IO indicated his problem: @ogbitcoin What's wrong with eosfishrocks? It seems that node is missing blocks.
Boram - EOSeoul.io offered a solution bot “https://t.me/eosmainnetstatus there you go” and it worked out
Link to meeting in regard of the EOS Constitution, Russian group: https://eosalliance.io/event/eos-russia-constitution-discussion/
Users were checking an issue with CPU usage for 1.2.5 version, and got improved results comparatively to previous version. Some users didn’t get a significant difference. Some stated that version 1.2.3 provides 100% CPU.
Zhao Yu@EOSLaoMao.com “my test result is not that significant though.
I have restarted a full node with 1.2.5, and restarted another full node with same config using 1.2.3
not seeing much difference in terms of CPU usage.”
Bohdan CryptoLions there are new system contracts 1.3.0:
https://github.com/EOSIO/eosio.contracts/releases/tag/v1.3.0
I am going to deploy it in Jungles right now
Users discussed https://t.me/eosmainnetstatus and it’s results.
Zhao Yu@EOSLaoMao.com
dive into the source code if you have time : https://github.com/EOSBIXIN/eostoolkit/tree/master/bpmonitor
Robrigo - EOS Detroit
Livestream
anyx — TeamGreymass
In regards to what I was saying on the call about exponential backoff and LRU contract behaviour, this is what I was thinking about:
Imagine storing per-contract a single entry that is a metric of "recent usage". This metric is updated on every transaction that touches that specific contract.
This stored value would thus enable global objective understanding that metric (as each bp can update that metric with soft consensus, with no extra communication).
Subjective usage could then factor in this metric with exponential backoff — if a contract is being "spammed" this metric would have a high value of "recent usage" and subjective TX assignment can use that to to avoid applying too much of that contract. This would be akin to "greylisting" a contract while it cools down in recent usage.
Josh Kauffman - EOS Canada
https://www.eoscanada.com/en/block-producer-community-call-september-12-2018