Author

Topic: NovaCoin (scrypt PoW + PoS hybrid) - page 116. (Read 600924 times)

legendary
Activity: 976
Merit: 1003
February 23, 2014, 04:43:40 PM
мне кажется,  что стоит расписать на первой странице про преимущества: гибридная архитектура,  действительно деуентрализованная эмиссия и пооведение транзакций благодаря пос. Энергоэффективность и отсутствие необходимости строить громадные датацентры и другие.
для этого есть вики

Думаю, стоит добавить айдентику и текущий курс к битку\доллару. Ещё прямые ссылки на скачивание кошельков, встроить данные с charts.novaco.in Так же калькулятор вероятности нахождения блока. Не знаю, позволяет ли это формат вики, но таким полезным интерактивным штукам здорово было бы находится на одном легкодоступном ресурсе.

большая часть из этого есть на домашней странице, если не обратил внимание... а калькулятор -- это не для этого ресурса...
legendary
Activity: 3108
Merit: 1359
February 23, 2014, 01:46:37 PM
У новы всегда был такой значок?

Мне казалось, он был каким-то другим? Или я что-то путаю?
Это логотип одного из пулов.
legendary
Activity: 3108
Merit: 1359
February 23, 2014, 01:46:16 PM
Смержено несколько патчей для решения означенной svost проблемы с адресной книгой.

https://github.com/novacoin-project/novacoin/pull/9
https://github.com/novacoin-project/novacoin/pull/10

Windows сборки:

0.4.4.6 update3: [ AMD64 | i686 ]
0.4.4.7 bugfix4: [ AMD64 | i686 ]
hero member
Activity: 994
Merit: 502
February 23, 2014, 01:14:08 PM
У новы всегда был такой значок?

Мне казалось, он был каким-то другим? Или я что-то путаю?
newbie
Activity: 5
Merit: 0
February 23, 2014, 10:22:15 AM
Чуть не забыл: если кто найдёт баги шаблона при отображении Wiki, прошу писать сюда или в личку...

ПыСы принимаются идею по наполнению домена/страниц дополнительной информацией (не относится к wiki)

Думаю, стоит добавить айдентику и текущий курс к битку\доллару. Ещё прямые ссылки на скачивание кошельков, встроить данные с charts.novaco.in Так же калькулятор вероятности нахождения блока. Не знаю, позволяет ли это формат вики, но таким полезным интерактивным штукам здорово было бы находится на одном легкодоступном ресурсе.
sr. member
Activity: 463
Merit: 252
February 23, 2014, 09:33:08 AM
Чуть не забыл: если кто найдёт баги шаблона при отображении Wiki, прошу писать сюда или в личку...

ПыСы принимаются идею по наполнению домена/страниц дополнительной информацией (не относится к wiki)

мне кажется,  что стоит расписать на первой странице про преимущества: гибридная архитектура,  действительно деуентрализованная эмиссия и пооведение транзакций благодаря пос. Энергоэффективность и отсутствие необходимости строить громадные датацентры и другие.
legendary
Activity: 976
Merit: 1003
February 23, 2014, 06:43:17 AM
Чуть не забыл: если кто найдёт баги шаблона при отображении Wiki, прошу писать сюда или в личку...

ПыСы принимаются идею по наполнению домена/страниц дополнительной информацией (не относится к wiki)
legendary
Activity: 3108
Merit: 1359
February 22, 2014, 07:42:20 PM
Помнится, кто-то публиковал фотографии бумажных банкнот. Smiley Не поделитесь шаблонами?

https://github.com/CryptoManiac/bitaddress.org

Адреса генерирует нормально, надо внешний вид допилить и можно выкладывать.  Roll Eyes
legendary
Activity: 3108
Merit: 1359
February 22, 2014, 02:17:41 PM
Опубликованы Windows nosetup сборки 0.4.4.6 update2 и 0.4.4.7 bugfix3.

Список изменений 0.4.4.6 update2:

  • Добавлены усиленные проверки скриптов транзакции, для предупреждения имевших место проблем с подменой txid;
  • Соединения от старых клиентов (старше 0.4.4.5) теперь отклоняются, предотвращает ненужный флуд запросами блоков;
  • Добавлена новая нода dns seed.

Скачать: [ i686 | AMD64 ]

Список изменений 0.4.4.7 bugfix3:

  • Используется новый тип "сокращенного" представления транзакции на диске. Это решает проблему с синхронизацией;
  • Удаление не только NULL, но и EMPTY выходов из индекса. Сокращает использование дискового пространства coinstake транзакциями;
  • Добавлены усиленные проверки скриптов транзакции, для предупреждения имевших место проблем с подменой txid;
  • Добавлено поле metahash в вывод запросов gettransaction и listtransactions. Это поле содержит хэш метаданных транзакции, который идентичен для всех "транзакций-двойников";
  • Добавлена новая нода dns seed.

Обратите внимание, что формат БД несовместим с предыдущими сборками 0.4.4.7.

Скачать: [ i686 | AMD64 ]

Кроме того, исправлены опечатки локализации в некоторых местах, вроде "сгенерированно".
legendary
Activity: 3108
Merit: 1359
February 22, 2014, 02:01:58 PM
Balthazar,

Подскажите, плиз, какой кошелек сейчас юзать нужно, чтобы все правильно работало, а то что-то отстал от темы.
Выдают предупреждение, но полностью работоспособны до 1 мая 2014:

  • 0.4.4.5
  • 0.4.4.6

Актуальные стабильные версии:

  • 0.4.4.6 update1
  • 0.4.4.6 update2

Актуальная экспериментальная версия:

  • 0.4.4.7 bugfix3

Если используется версия ниже 0.4.4.5, либо экспериментальные сборки ниже 0.4.4.7 bugfix3, то следует обновиться немедленно. Также обратите внимание, что формат БД у 0.4.4.6 несовместим с форматом более старых версий. Поэтому, при переходе на 0.4.4.6 требуется удалить файлы БД блоков и индекс транзакций.

Я так понял отсюда нужно брать?: http://sourceforge.net/projects/novacoin/files/
Да. Можно также скомпилировать свою сборку из исходных текстов:

https://github.com/novacoin-project/novacoin

legendary
Activity: 1208
Merit: 1003
February 22, 2014, 01:58:04 PM
Balthazar,

Подскажите, плиз, какой кошелек сейчас юзать нужно, чтобы все правильно работало, а то что-то отстал от темы.

Я так понял отсюда нужно брать?: http://sourceforge.net/projects/novacoin/files/
legendary
Activity: 3108
Merit: 1359
February 22, 2014, 01:56:59 PM
Он не может знать, сколько подписей попросят для блока в будущем. Он также не может знать, подписи для каких именно публичных ключей будут признаваться корректными. Поэтому, единственный способ получить гарантированный перевес в таком случае - это сгенерировать в пределах отрезка выборки как можно больше proof-of-stake блоков.
legendary
Activity: 1554
Merit: 1008
February 22, 2014, 01:45:03 PM
icreator, прочитайте концепт внимательно. Не может никто наплодить миллион подписей, сколько бы кошельков ни копировал. Даже если плохишу посчастливится оказаться в списке выбранных, он не может дать больше подписей, чем у него попрошено.

Тут актуальны совсем другие вопросы.

вероятность вероятность - если 50% мощности сети у когото есть то почему бы не создать 50% от всего числа кошельков в сети?
legendary
Activity: 3108
Merit: 1359
February 22, 2014, 12:31:38 PM
icreator, прочитайте концепт внимательно. Не может никто наплодить миллион подписей, сколько бы кошельков ни копировал. Даже если плохишу посчастливится оказаться в списке выбранных, он не может дать больше подписей, чем у него попрошено.

Тут актуальны совсем другие вопросы.
legendary
Activity: 1554
Merit: 1008
February 22, 2014, 12:16:24 PM
я к тому что подписи может ставить "плохой кошелек" - кооторых плохиши могут наплодить в сети мульен... и что тогда толку с этих плохих подписей?
legendary
Activity: 3108
Merit: 1359
February 22, 2014, 12:07:13 PM
А дальше - тот блок, о которых говорит большинство текущих доверенных, должен быть прописан в следующем принимаемом блоке, иначе он не будет принят.

Необходимо подобрать интервалы времени, в пределах которых будут выбираться эти метки от стейкхолдеров, чтобы не получилось лавинообразного затыка с принятием блоков, например в момент глобальных проблем с интернетом (проблемы на транснациональных интернет-каналах) когда одна половина земного шара думает одно, а другая - другое, ведь сейчас такие проблемы для сети пофиг - прав тот кто просто быстрее считает.
С интервалом верное замечание, как вариант - брать для выборки блоки за последнюю неделю (для них шанс того, что намайнивший находится онлайн, достаточен). Но все же не совсем понимаю, зачем запрещать использование неподписанного блока в качестве предка? Ведь это как раз и создает возможную проблему с "затыками". Не лучше ли подсчитывать подписи кумулятивно для цепочки, как это сейчас делается со сложностью блоков? Тогда будут легитимными такие равноправные варианты, победа которых будет определяться уже только кумулятивной сложностью:

.. -> A1 [0 подписей] -> B1 [+2 подписи] -> C1 [+1 подпись] -> ..
(3 подписи)

.. -> A2 [+1 подпись] -> B2 [0 подписей] -> C2 [+2 подписи] -> ..
(3 подписи)

.. -> A3 [+1 подпись] -> B3 [+2 подписи] -> C3 [0 подписей] -> ..
(3 подписи)

А не только такие:

.. -> A[+N1 подписей] -> B[+N2 подписей] -> C [+N3 подписей] -> ..
(N1 + N2 + N3 подписей)

Нужно только ограничить временное окно, в течение которого принимаются подписи для конкретного блока. К примеру, принимать только если блок не старше 10/20/30/60 минут, а кто не успел - тот опоздал.
legendary
Activity: 1120
Merit: 1069
February 22, 2014, 08:14:56 AM
Если же хотим строить социализм в отдельно взятом государстве предотвратить вредоносное поведение пользователя, владеющего 99+% из общего объема генерирующих ресурсов, то можно предусмотреть рамки и даже жесткие ограничения. К примеру, запретить указание в prevhash хэша блока, не имеющего "достаточное" количество подписей. И это сработает, но в качестве бонуса это создаст и проблему. А именно, если среди "выборщиков" не окажется никого в онлайне и не будет конкурирующих подписанных блоков, то вся цепь встанет. Посему, подобный вариант в чистом виде является злом.
Я о том и говорю, что необходимы правила, который позволят грамотно использовать эту информацию на узлах.

Еще раз конечная цель то какая? - необходимо отфудболивать блоки, в которых 'злонамеренно' использовался в качестве потомка не тот блок что уже 'вся сеть' знает а более старый.

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

А дальше - тот блок, о которых говорит большинство текущих доверенных, должен быть прописан в следующем принимаемом блоке, иначе он не будет принят.

Необходимо подобрать интервалы времени, в пределах которых будут выбираться эти метки от стейкхолдеров, чтобы не получилось лавинообразного затыка с принятием блоков, например в момент глобальных проблем с интернетом (проблемы на транснациональных интернет-каналах) когда одна половина земного шара думает одно, а другая - другое, ведь сейчас такие проблемы для сети пофиг - прав тот кто просто быстрее считает.
hero member
Activity: 574
Merit: 523
legendary
Activity: 3108
Merit: 1359
February 21, 2014, 03:05:37 PM
Если конкретный юзер, получив блок, видит в списке публичных ключей свой, то он может отправить в сеть специальное сообщение, которое доставит всем нодам его подпись для этого блока. Ну а дальше все просто - чем больше подписей от юзеров из списка собрано блоком, тем больше его приоритет над остальными при прочих равных.

вместо юзера может программа робот кликать
Куда кликать и зачем? о_О

Интересненько... интервал времени определен алгоритмом как константа (ну, например те кто создал PoS блоки месяц назад) или так же определяется детерменированным алгоритмом?
Это интересный вопрос само по себе. Для модификатора coinstake сейчас используется выборка блоков за 18 часов с расстоянием между выборками, составляющим 6 часов. Очевидно, что для получения списка "выборщиков" (украдем терминологию у избирательной системы США) нужен более длинный интервал. Можно, конечно, сделать этот интервал расчитываемым исходя из последних битов хэшей блоков за какой-то период, чтобы сделать его труднопредсказуемым, но это выглядит бессмысленным.


по старинке - верить всему?
В каком смысле верить всему?

Я так понимаю, если ни одного юзера онлайн вдруг не окажется, то как должны поступать те кто надеется на отклик от стейкхолдеров, по старинке - верить всему? и какой вообще алгоритм использования этих откликов? Какие то зашитые проценты наличия при принятии блока? и алгоритм этот всплывает в момент оторфанивания блоков/цепочек?
Для начала, следует углубиться в принцип, по которому строится цепочка. Как ни странно, цепочка не является абстракцией, и имеет вполне осязаемое представление на диске именно в том виде, в котором мы её привыкли видеть. С той лишь разницей, что это не линейная структура, а древовидный список. На диске она представлена двусвязным древовидным списком, в который сохраняются все корректные с точки зрения протокола блоки, орфаны в том числе. Собственно, это как раз орфаны и являются абстракцией...  Smiley

В узлах дерева, помимо заголовков блоков и их оффсетов, хранятся также и некоторые метаданные. Такие, как расстояние от генезиса, количество эмитированных в блоке монет, объем выполненной в блоке работы или уничтоженных монетодней (в виде частного от текущего таргета на базовый), и некоторые другие параметры. Обычно, будучи однажды записанным, содержимое узлов дерева уже не изменяется. Однако, ничто не мешает редактировать его, если это необходимо. К примеру, в клиенте есть множество режимов восстановления поломанного индекса, которые это делают. Мы же можем сохранять в индексе запись о полученном блоке как обычно, но дополняя его в дальнейшем полученными из сети новыми данными. К примеру, подписями в пришедших сообщениях, если они корректны и пришли от тех, чье мнение нас интересует. Ну а далее возможны уже варианты в зависимости от того, чего мы хотим достигнуть.

Если мы хотим предотвратить возможность манипуляций вроде ссылки на свой собственный блок в процессе майнинга новых шар, как это делают некоторые BTC пулы, то никаких жестких рамок и соотношений не нужно. Достаточно просто сравнивать количество подписей в конкурирующих ветках, и все... И тогда среди веток с равной кумулятивной сложностью победит та, в которой больше подписей.

Если же хотим строить социализм в отдельно взятом государстве предотвратить вредоносное поведение пользователя, владеющего 99+% из общего объема генерирующих ресурсов, то можно предусмотреть рамки и даже жесткие ограничения. К примеру, запретить указание в prevhash хэша блока, не имеющего "достаточное" количество подписей. И это сработает, но в качестве бонуса это создаст и проблему. А именно, если среди "выборщиков" не окажется никого в онлайне и не будет конкурирующих подписанных блоков, то вся цепь встанет. Посему, подобный вариант в чистом виде является злом.

P.S. Проба пера, так сказать Smiley

Code:
{
    "hash" : "00000000004734afbead0024e80c4d59adbd8d6914f8d195d1ff1d2e0b226b93",
    "confirmations" : 8,
    "size" : 474,
    "height" : 76775,
    "version" : 6,
    "merkleroot" : "2de3f2cd22f4048fb76d601fa86c60b2880ea09bac7ea6d3c7aa0829016bd490",
    "mint" : 9.45000000,
    "time" : 1393026968,
    "nonce" : 91171841,
    "bits" : "1c00c00b",
    "difficulty" : 341.25175437,
    "blocktrust" : "442a9148",
    "chaintrust" : "8dba95e420b",
    "previousblockhash" : "6bf729168883faf4b3124a53749671d90723f695d91a7fabf72e5a9ff3f3ec44",
    "nextblockhash" : "b1bb723b97f50fd21a4da240b4a94a213caabe959c6598feb9fc109371a4abd2",
    "flags" : "proof-of-work",
    "proofhash" : "00000000004734afbead0024e80c4d59adbd8d6914f8d195d1ff1d2e0b226b93",
    "entropybit" : 1,
    "modifier" : "de4259d4c2d9f395",
    "modifierchecksum" : "18a3a2e5",
    "tx" : [
        "934adcda0d5413280c7fd24a8caaf25917e98078e6d4c02b890567f609666c13",
        "16196095787a8d18048b65bff1eeaa33bf27773b534ce5c9cd70f6be508edced"
    ],
    "electorals" : [
        "4cUJYwu9kZ9wpK9XwLtH7Cf5dEKF8CKoJ6",
        "4X9CPaeyURnbz2kF72M9jwWAKyTEGh9pof",
        "4KHrxBNZDaJj2BvUT4RLGMm3sCdLkzHRvD",
        "4VMBU8CGJ8tUL8e7MCF5LvKfuBifgafe3Z",
        "4Nps12pbyQwk2P2pFSZDLiBzgjpGnHEMnh",
        "4Z8eoaTac1LerjiMZbJJNyBEzMaREGqzNP",
        "4YCszNqvyw5152aztYhj1zfpnNXEoPWXZZ",
        "4bhgbUqW7FhgXut7CfYJr2DmGzwKJKq2RM",
        "4bZaUMfgS43TtXqjzPPdq9yGmPBqWpL5wu",
        "4WPpjyPNpqzhFBqhEQciQoq6t2AkXExEaE",
        "4RQGbWp4Ht6f5WH6RVcTBGRRi9jUpGmym8",
        "4Zow33eSgqFDLDoMiLW3rsjxJ2Xfdsh6i9",
        "4LsRHEwQv19rkzkgTvSmMbUxH5353ZwGkg",
        "4VyZu3VoryxUk4wtpQsTBU6EeNPJ9VApuR",
        "4TvmMnd1yebbWsBTBKUoQzgNgjFwK6sbqE",
        "4GaNBPeEekfqByxaYe8JmoQWhvFYVhJv5C",
        "4KkjJTQxXqcRKvDVRig9gC7Ga5JchDHLsG",
        "4VwZFTSRodKpLEvZ9t6U4SfruXFKWtz2Tt",
        "4PMSX2RcQAyRGUUZTvuhiREE3rDM997arv",
        "4YUtqKH4Qnx3ZAX2udmKkcViknBjd6cEQA",
        "4Dqwp1sFnsYyr8cuCD2wNA7rMF4onrFUt3",
        "4W4jsLvjZcQJ77FjD8K6MjEeG15bVgB8My",
        "4RtMxfXszhtUinHyikkXQiqcudFjTPw6AH",
        "4YVibSnXZyfvKXAA5RaWnBvnMWSL3p99x5",
        "4L1ea27EzDpUVCtotiJhcrps1eiMEGGqhJ",
        "4XGHUpxaJhgoEne6nEym8BMCFsQbKF9qC6",
        "4YgUBbcpckeKdoyLdHBLrDWNjAdbtGsiBs",
        "4GQ19dy3axx9UASyt4YYkYijFnkmtEeBib",
        "4LqumwCqDWG4mrj1otcuysEFcdzgTozP5M",
        "4HeDQyVaBje3SFHHby8mX2MuDbv4c1s73J",
        "4WNVyodwLZ9oouraH9agA4TESRDU9oZ2Yo",
        "4QdurSaHMt6FHGVJeYatef69xefUbCJfKr",
        "4Ukgq3J3zS7vmsQAauS2nCAzPSC3F65V5G",
        "4TSm79nZAf2vUkMCUmASv2fpWbpsbzn2Ko",
        "4QbUdDhsK5sp78T65L9Bx5gV36U6nhgrc2",
        "4cA7cqeLonrgE4CSF4w8TtV7KkiEmrFNoV",
        "4Zqbti9khUsrH3jZ57sAE9YwhanekPGnsQ",
        "4RwhSLp4kDFZEWXG7KQPx957AUGV7Hvagf",
        "4YGgVTWVuRnaV1QsEYckiUoyzPDNd5wZe6",
        "4K3rvvyKYABVuRs4tzr8r8Ee1mPXwy9SQt",
        "4S6WQv2rY83qmnXq3v7WTAXCXbFPdS9DAG",
        "4F37kaj9YcNQJLNcdsSWsDbGn9vjQfzWwd",
        "4JD1Qj2QRxVCF4CoegebukSbF2DkvvPrY2",
        "4FYmsSpYGucbdyghxc1fYTK15mF4ch22KQ",
        "4ZdbmbnXXhTMwLFNVGEyAPXhKkyYKBYg8m",
        "4cApTzwgn44pMN8BjUeoMBXVgoTZWU73VC",
        "4FsScpuxBtu1ZF3T7fcTrHF7zYmXfjVc2D",
        "4NyssqG4Cqs251yAxWXd9H42u52zJdUD1j",
        "4YZFuykZAUy5n5a1ycwHLEv5zt2QBYh34Q",
        "4TXgsvbhbVEc7h9KT57YgdG8ws2z2d9u8A",
        "4GY1Lbojf54JiM77CZ5Vgk9YYw1pvUx1j2"
    ]
}

Code:
{
    "hash" : "00000000006702a472b5470f9c595f6aa5140cc44220fc1f19859ce7b754e2a7",
    "confirmations" : 284,
    "size" : 220,
    "height" : 76501,
    "version" : 6,
    "merkleroot" : "c81870aa993fb8dcc7069e2a8cb80202a36a7e68c04cac514d0e8a42db7637d9",
    "mint" : 9.45000000,
    "time" : 1392924920,
    "nonce" : 738124544,
    "bits" : "1c00bf5a",
    "difficulty" : 342.48479157,
    "blocktrust" : "2ac3dad4",
    "chaintrust" : "8b78e54a274",
    "previousblockhash" : "cdad9fea2c050f833af064110f5a6b6b05b32e7efb050d0f9dab46797fd358a6",
    "nextblockhash" : "0000000000a24f1184699c7c2bee72c0876af4578f35ff72a3fd6180c53024b1",
    "flags" : "proof-of-work",
    "proofhash" : "00000000006702a472b5470f9c595f6aa5140cc44220fc1f19859ce7b754e2a7",
    "entropybit" : 1,
    "modifier" : "2983583a2109e661",
    "modifierchecksum" : "a222860b",
    "tx" : [
        "c81870aa993fb8dcc7069e2a8cb80202a36a7e68c04cac514d0e8a42db7637d9"
    ],
    "electorals" : [
        "4cUJYwu9kZ9wpK9XwLtH7Cf5dEKF8CKoJ6",
        "4KHrxBNZDaJj2BvUT4RLGMm3sCdLkzHRvD",
        "4VMBU8CGJ8tUL8e7MCF5LvKfuBifgafe3Z",
        "4Nps12pbyQwk2P2pFSZDLiBzgjpGnHEMnh",
        "4Z8eoaTac1LerjiMZbJJNyBEzMaREGqzNP",
        "4YCszNqvyw5152aztYhj1zfpnNXEoPWXZZ",
        "4bhgbUqW7FhgXut7CfYJr2DmGzwKJKq2RM",
        "4JAgJMPHoQkFWNAZTDsMvHJ31Ptjun59MY",
        "4bZaUMfgS43TtXqjzPPdq9yGmPBqWpL5wu",
        "4WPpjyPNpqzhFBqhEQciQoq6t2AkXExEaE",
        "4UBKRV2EYjR4wHyT1sfkT2yEvou8AXGQHx",
        "4RQGbWp4Ht6f5WH6RVcTBGRRi9jUpGmym8",
        "4Zow33eSgqFDLDoMiLW3rsjxJ2Xfdsh6i9",
        "4LsRHEwQv19rkzkgTvSmMbUxH5353ZwGkg",
        "4ZcPUmCEt6WLXKThm8K4FooEV7zaCsHFX5",
        "4VyZu3VoryxUk4wtpQsTBU6EeNPJ9VApuR",
        "4TvmMnd1yebbWsBTBKUoQzgNgjFwK6sbqE",
        "4GaNBPeEekfqByxaYe8JmoQWhvFYVhJv5C",
        "4VwZFTSRodKpLEvZ9t6U4SfruXFKWtz2Tt",
        "4PMSX2RcQAyRGUUZTvuhiREE3rDM997arv",
        "4NmaXmznE9yXrjK9hckypovxL8ApkF8oQj",
        "4Dqwp1sFnsYyr8cuCD2wNA7rMF4onrFUt3",
        "4W4jsLvjZcQJ77FjD8K6MjEeG15bVgB8My",
        "4RtMxfXszhtUinHyikkXQiqcudFjTPw6AH",
        "4L1ea27EzDpUVCtotiJhcrps1eiMEGGqhJ",
        "4YgUBbcpckeKdoyLdHBLrDWNjAdbtGsiBs",
        "4GQ19dy3axx9UASyt4YYkYijFnkmtEeBib",
        "4LqumwCqDWG4mrj1otcuysEFcdzgTozP5M",
        "4HeDQyVaBje3SFHHby8mX2MuDbv4c1s73J",
        "4WNVyodwLZ9oouraH9agA4TESRDU9oZ2Yo",
        "4QdurSaHMt6FHGVJeYatef69xefUbCJfKr",
        "4Ukgq3J3zS7vmsQAauS2nCAzPSC3F65V5G",
        "4TSm79nZAf2vUkMCUmASv2fpWbpsbzn2Ko",
        "4YXuko4TaCZt4kYWd2ArTWArGVjs8Nf2Vp",
        "4QbUdDhsK5sp78T65L9Bx5gV36U6nhgrc2",
        "4cA7cqeLonrgE4CSF4w8TtV7KkiEmrFNoV",
        "4SuKUqNZ2up6u28jZEFgc6uwmy6okmEVMM",
        "4Zqbti9khUsrH3jZ57sAE9YwhanekPGnsQ",
        "4YGgVTWVuRnaV1QsEYckiUoyzPDNd5wZe6",
        "4K3rvvyKYABVuRs4tzr8r8Ee1mPXwy9SQt",
        "4S6WQv2rY83qmnXq3v7WTAXCXbFPdS9DAG",
        "4F37kaj9YcNQJLNcdsSWsDbGn9vjQfzWwd",
        "4JD1Qj2QRxVCF4CoegebukSbF2DkvvPrY2",
        "4FYmsSpYGucbdyghxc1fYTK15mF4ch22KQ",
        "4ZdbmbnXXhTMwLFNVGEyAPXhKkyYKBYg8m",
        "4cApTzwgn44pMN8BjUeoMBXVgoTZWU73VC",
        "4b8NPHLoNFHJRNU8UFYXwP5eGJCTcB9jLw",
        "4T7zxWW3isCVbeuhByS7csaAtY44VsJbHP",
        "4FsScpuxBtu1ZF3T7fcTrHF7zYmXfjVc2D",
        "4TpLy5gA9K2PeikhnGkA9r7MUckURqB8vr",
        "4NyssqG4Cqs251yAxWXd9H42u52zJdUD1j",
        "4YZFuykZAUy5n5a1ycwHLEv5zt2QBYh34Q",
        "4TXgsvbhbVEc7h9KT57YgdG8ws2z2d9u8A"
    ]
}
legendary
Activity: 1554
Merit: 1008
February 21, 2014, 02:22:33 PM
Если конкретный юзер, получив блок, видит в списке публичных ключей свой, то он может отправить в сеть специальное сообщение, которое доставит всем нодам его подпись для этого блока. Ну а дальше все просто - чем больше подписей от юзеров из списка собрано блоком, тем больше его приоритет над остальными при прочих равных.

вместо юзера может программа робот кликать
Jump to: