Quote from: rPman on February 21, 2014, 04:43:15 PM

кто такие stakeholders? я в том смысле, кто или что их определяет.

Сейчас подобный механизм уже используется для выборки блоков-источников энтропии stake modifier.

Суть идеи проста и похожа на жеребьевку. По детерминированному алгоритму функция принятия блока выбирает N proof-of-stake блоков из прошлого. Это делается таким образом, чтобы выборка была всегда идентичной для конкретного блока, но нельзя или сложно было бы предсказать результат выборки для блока в будущем. Далее из этих блоков берутся публичные ключи vin[0] коинстейк-транзакции. Вот это и будут те самые холдеры, которым будет предложено подписать блок-кандидат.

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

Таким образом, чтобы развлекаться с selfish mining, пулу типа ghash.io придется иметь очень весомую долю proof-of-stake блоков в прошлом. Тогда у него есть шанс того, что в списке окажутся его ключи в достаточном для перевеса количестве. В противном случае у него шансов нет, потому что блок оффлайн-цепочки не сможет набрать больше подписей, чем блок, который видели все.

Quote from: sir.miklosh on February 21, 2014, 04:52:24 PM

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

Именно.

Quote from: rPman on February 21, 2014, 06:41:24 PM

Интересненько… интервал времени определен алгоритмом как константа (ну, например те кто создал PoS блоки месяц назад) или так же определяется детерменированным алгоритмом?

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

Quote from: rPman on February 21, 2014, 06:41:24 PM

по старинке — верить всему?

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

Quote from: rPman on February 21, 2014, 06:41:24 PM

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

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

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

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

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

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

{
    "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"
    ]
}

{
    "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"
    ]
}

Quote from: rPman on February 22, 2014, 01:14:56 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 минут, а кто не успел — тот опоздал.