Комментарии

@alte, there are several links to release notes at the beginning of the article

Proposals for validators can be found here: https://explorer.cyberway.io/account/ggfpapchob2e/proposals

@ropox, так меньше 18000 было же.
а вообще любопытно, что получится

https://explorer.cyberway.io/trx/7d85494c0ec746c234848ab348c5a158bffac765450569f4e8dd04e41763a08e
https://explorer.cyberway.io/trx/fc57792f996f410e6a1d2f8527582eb3609379b343ecbe5dc50de55de816ba5f

между делом выяснилось, что если разрешению привязано напрямую к экшену (а не ко всему контракты), то разрешением для всего контракта нельзя воспользоваться. то есть к upvote было привязано разрешение test, и оно блокировало разрешение posting, пришлось отвязывать:
https://explorer.cyberway.io/trx/9e5f5e1799976a24c35ed518244b0bd624a1e47692c01639dfc7ab5e0b5cf4dd

https://explorer.cyberway.io/trx/ee6e61e4a8cd49caf1451450eb97141405d34d0085994373108d43549f879dcf

@lex, 21 — это 19+случайный+майнер. при производстве блоков таков был состав расписания.
Не помню только, при принятии хф все они учитывались или нет.

@ropox, там несколькими строками выше в change_voter_vests именно вектор используется когда меняется вестинг голосующего. а apply_vote_weight вызывается именно в момент голосования за лидера или снятия с него голоса. если переписать логику для голосования/снятия, можно и дробить голос.
тут вопрос больше в том, как от старой системы голосования перейти к новой — все записи в таблицах разом не изменить. а если по шагам, то надо учитывать возможную смену вестинга голосующих и голоса/снятия во время этих шагов. этот вопрос следует проработать прежде чем начинать что-то менять.

на счёт адаптировать в нерабочее время — у меня тоже его недостаточно, к сожалению. могу ревью пулл-реквеста сделать.

как тестировать — сперва соответствующий юнит-тест адаптировать, проверить, что работает: https://github.com/cyberway/golos.contracts/blob/3e6b43ac70f25de8b877244881565ea3148298dc/tests/golos.ctrl_tests.cpp#L311, для этого тестнет не нужен.

@jul, постинг-ключ — более ограниченный ключ, чем активный. у него нет доступа к средствам на вашем кошельке, поэтому при обычной работе с приложением он безопаснее.
То есть если постинг-ключ окажется скомпрометирован, злоумышленник не получит доступ к вашим активам. А если потерять активный или ключ владельца — можно прощаться с токенами.

С ошибками он вряд ли связан.

@lllll1ll, думаете, никто не терял приватную часть? )

Просто в инструкции опущен кусок про «сгенерировать ключ», поэтому неизвестно, откуда взятые ключи пользователи будут пытаться вставлять в транзакцию

@lllll1ll, в транзакции указывается публичный GLS123…
когда вы им захотите воспользоваться (написать пост, лайкнуть), понадобится приватная часть.

Тут смысл в том, что в транзакции вы можете указать публичный ключ вообще любой, и блокчейн его примет без ошибок (приватный не примет). Но если у вас нет приватной части, то невозможно будет им пользоваться.

Впрочем, если такое случится, первое действие транзакции можно выполнить повторно c правильным ключом

@ropox там просто репостнули с заголовком типа «полезное для новичков», вот за них не уверен )

@denis-skripnik, задумка интересная, но проще всё же связаться с человеком и согласовать время, чем добавлять кучу логики, которая всё равно не гарантирует, что он увидит заявку. или увидел, но не захотел принимать, а ему при каждом заходе заново спамит «выгодным предложением» )

другой вариант решения — делать делегирование через мультисиг-контракт (как пропозал), там срок жизни большой. но сейчас не получится, т.к. у приложения нет необходимых авторити, чтоб предоставить бэндвич в таком пропозале