Поднят еще один DNS seed, возможно скоро добавится еще один.
Итого, сейчас есть:
- dnsseed.novaco.in
- dnsseed.novacoin.su
Новый, добавлен в репозитории, но сборки о нем пока не в курсе:
- dnsseed.novacoin.ru
New dns seed node is up and added to sources tree. So, currently we have
- dnsseed.novaco.in
- dnsseed.novacoin.ru
- dnsseed.novacoin.su
another one probably will be added later.
A new proposal for Proof-of-Work signing protocol is currently under development. It would provide stakeholders an ability to vote for Proof-of-Work blocks they’ve received. What is interesting, it’s possible to implement without breaking a compatibility with nodes that doesn’t support this protocol.
A main idea is quite simple:
1. Proof-of-Work miner submits a new block over the network;
2. New block is accepted as a “candidate” (score = 1);
3. Each node builds a deterministic list of stake generators from the past (64 items, for example);
4. Stake holder appends own signature to vchBlockSig field (currently it’s not used) and then submits signed block over the network;
5. Once enough signatures collected (16 of 64, for example) new block is accepted into block chain as a “full value” block (score is equal with provided by the current proof-of-work score policy).
This process would be able to prevent malicious miner from creating a secretly pre-mined chain in order to perform 51%+ attack even if he has 99% of hashing power and significant stake volume. Because he can’t collect enough signatures while keeping his chain secret.
A new proposal for Proof-of-Work signing protocol is currently under development. It would provide stakeholders an ability to vote for Proof-of-Work blocks they’ve received. What is interesting, it’s possible to implement without breaking a compatibility with nodes that doesn’t support this protocol.
A main idea is quite simple:
1. Proof-of-Work miner submits a new block over the network;
2. New block is accepted as a “candidate” (score = 1);
3. Each node builds a deterministic list of stake generators from the past (64 items, for example);
4. Stake holder appends own signature to vchBlockSig field (currently it’s not used) and then submits signed block over the network;
5. Once enough signatures collected (16 of 64, for example) new block is accepted into block chain as a “full value” block (score is equal with provided by the current proof-of-work score policy).
This process would be able to prevent malicious miner from creating a secretly pre-mined chain in order to perform 51%+ attack even if he has 99% of hashing power and significant stake volume. Because he can’t collect enough signatures while keeping his chain secret.
https://github.com/novacoin-project/novacoin/pull/6
Навеяно мыслями о транзакциях и их идентификации… Помимо объединения конфликтных транзакций, в 0.4.4.7 будет добавлен хэш метаданных транзакции. Фактически, тут ничего нового нет, потому что этот же хэш подписывается пользователем перед отправкой транзакции. Просто раньше он не выводился, а теперь gettransaction будет его выводить.
https://github.com/novacoin-project/novacoin/pull/6
Not accepted yet, but ready for testing. It introduces metahash field which contains a hash of transaction metadata.
Current 0.4.4.7 testing branch runs pretty stable for now. This branch is available here for public testing:
https://github.com/novacoin-project/novacoin/tree/current
Basic list of changes:
1) Pruned transactions serialization support.
Pruned transaction records are now saved into coinsDB. These records are composed of 13-14 bytes of metadata (block height, coinbase/coinstake flags, block and transaction timestamp). This resolves all syncronization issues. Though currently there is no lifetime limit for such records, cleanup for old records will be implemented in the future versions of NVC client (this cleanup will be performed after reaching the 520-blocks maturity window, I guess).
2) Conflicted transactions handling.
Основной объем необходимого по 0.4.4.7 сделан, пощупать можно здесь:
https://github.com/novacoin-project/novacoin/tree/current
Из базовых изменений следует отметить концепцию записей об “вычищенных транзакциях”. Это транзакции, все выходы которых были потрачены. Ранее 0.4.4.7 просто удаляла такие записи из БД, теперь сохраняет метадату (номер блока, время, флаги coinbase&coinstake) в компактном формате (длина записи о любой такой транзакции укладывается в 13-14 байт).
Таким образом, решается вопрос с синхронизацией клиента при наличии конкурирующих веток. Пока ограничений на время жизни таких записей нет, но в будущем и они будут стираться после 520 подтверждений истратившей транзакции.
В целом все стабильно, но думаю что в ближайшее время дополним формат полем, хранящим смещение транзакции в блоке для того, чтобы упростить текущую реализацию proof-of-stake майнера. Сейчас майнер ищет номер блока в БД, затем загружает блок и считает смещение транзакции, что явно избыточно.
Другие изменения:
- Адекватная обработка конфликтующих транзакций, чтобы не было как недавно с BTC;
- Опция для очистки wallet.dat от мусорных транзакций (смержено из BTC);
Тестовые бинарники будут доступны позже.
