NovaCoin (scrypt PoW + PoS hybrid)

[Balthazar]

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

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

Куда кликать и зачем? о_О

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

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

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

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

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

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

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

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

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

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

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

[1715021538]

1715021538

[1715021538]

1715021538

[bee7]

https://bitcointalk.org/index.php?topic=143221.msg5254880#msg5254880

Едем дальше.

Хорошая идея!

[rPman]

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

Я о том и говорю, что необходимы правила, который позволят грамотно использовать эту информацию на узлах.

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

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

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

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

[Balthazar]

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

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

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

.. -> 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 минут, а кто не успел - тот опоздал.

[icreator]

я к тому что подписи может ставить "плохой кошелек" - кооторых плохиши могут наплодить в сети мульен... и что тогда толку с этих плохих подписей?

[Balthazar]

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

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

[icreator]

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

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

вероятность вероятность - если 50% мощности сети у когото есть то почему бы не создать 50% от всего числа кошельков в сети?

[Balthazar]

Он не может знать, сколько подписей попросят для блока в будущем. Он также не может знать, подписи для каких именно публичных ключей будут признаваться корректными. Поэтому, единственный способ получить гарантированный перевес в таком случае - это сгенерировать в пределах отрезка выборки как можно больше proof-of-stake блоков.

[George5]

Balthazar,

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

Я так понял отсюда нужно брать?: http://sourceforge.net/projects/novacoin/files/

[Balthazar]

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

[Balthazar]

Опубликованы 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 ]

Кроме того, исправлены опечатки локализации в некоторых местах, вроде "сгенерированно".

[Balthazar]

Помнится, кто-то публиковал фотографии бумажных банкнот. Не поделитесь шаблонами?

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

Адреса генерирует нормально, надо внешний вид допилить и можно выкладывать. 

[penek]

Чуть не забыл: если кто найдёт баги шаблона при отображении Wiki, прошу писать сюда или в личку...

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

[Foxcool]

Чуть не забыл: если кто найдёт баги шаблона при отображении Wiki, прошу писать сюда или в личку...

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

мне кажется,  что стоит расписать на первой странице про преимущества: гибридная архитектура,  действительно деуентрализованная эмиссия и пооведение транзакций благодаря пос. Энергоэффективность и отсутствие необходимости строить громадные датацентры и другие.

[aceltradegid]

Чуть не забыл: если кто найдёт баги шаблона при отображении Wiki, прошу писать сюда или в личку...

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

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

[pant-79]

У новы всегда был такой значок?

Мне казалось, он был каким-то другим? Или я что-то путаю?

[Balthazar]

Смержено несколько патчей для решения означенной 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 ]

[Balthazar]

У новы всегда был такой значок?

Мне казалось, он был каким-то другим? Или я что-то путаю?

Это логотип одного из пулов.

[penek]

мне кажется,  что стоит расписать на первой странице про преимущества: гибридная архитектура,  действительно деуентрализованная эмиссия и пооведение транзакций благодаря пос. Энергоэффективность и отсутствие необходимости строить громадные датацентры и другие.

для этого есть вики

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

большая часть из этого есть на домашней странице, если не обратил внимание... а калькулятор -- это не для этого ресурса...

[Balthazar]

Я все же думаю, что содержимое шапки надо чем-то заменить.