Журнал змін Nxt Software

From Nxt Wiki
Jump to: navigation, search
This page is a translated version of the page Nxt Software Change Log and the translation is 100% complete.

Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎italiano • ‎português do Brasil • ‎русский • ‎українська

Contents

1 Версія 1.5.11

8 Червня, 2015

  • У цій версії видалена сумісність з вузлами версій старішими чим версія 1.5, і більше не підтримується з'єднання і обмін даними із застарілими вузлами.
  • Умовна логіка залежна від блоку 445000 була видалена, в ній більше немає необхідності, оскільки блок 445000 був досягнутий.
  • Тепер використовується паралельне завантаження blockchain з використанням 36-блокових сегментів, тепер це значення використовується за умовчанням незалежно від висоти. Повертає більше 36 блоків за раз, getNextBlocks більше не підтримується.
  • Максимальний розмір WebSockets повідомлення і Максимально допустимий розмір відповіді на запит getNextBlocks були скорочені з 192 МБ до 10 МБ.
  • Була додана контрольна сума 445 000 блоку.
  • У відповідь API getBlockchainStatus і GetState додане поле ​​isDownload, що вказує на стан завантаження blockchain. Його значення стає true, коли одночасно більш ніж 10 блоків було завантажено з вузла мережі, і скидається в false, коли спроба завантаження блоків від вузлів не призводить до появи нових блоків.
  • Запити до вузлів getUnconfirmedTransactions, getMilestoneBlockIds, getNextBlockIds, getNextBlocks, processBlock, processTransactions, getCumulativeDifficulty тепер відкидаються доки відбувається завантаження blockchain, що відображується у властивості isDownloading.
  • Відмітка часу останньої спроби підключення до вузла тепер включена в об'єкті JSON вузла.
  • Доданий параметр з'єднання DumpPeers в API відладки, щоб прискорити спроби підключень до відомих вузлів, AdminPassword потрібно якщо він необхідно.
  • Скрипт run.bat для Windows більше не використовує прапор -server за умовчанням.
  • Вузли які оновлюються із старих версій до поточної версії 1.5 видалять блоки з висотою більше 445000, щоб гарантувати що таких вузлів в мережі немає, і виключити вірогідність появи галужень версії 1.4.

2 Версія 1.5.10

4 Червня, 2015

  • Створений пакет установника для Windows і Linux, з використанням установника IzPack. Детальніше дивись https://bitbucket.org/JeanLucPicard/nxt/issue/283 (англ.)
  • Додані окремі складки Linux і Windows (cygwin) і сценарії запуску.
  • Трекінг і логирование часу виконання запитів до бази даних. Нові властивості: nxt.statementLogThreshold, nxt.transactionLogThreshold, і nxt.transactionLogInterval може використовуватися, щоб конфігурувати журналювання повільних запитів.
  • Оптимізація і поліпшення продуктивності бази даних . Дані про лізинг (оренду) акаунту перенесені з таблиці облікового запису до окрему таблицю account_lease. У багатьох таблицях були додані індекси, існуючі змінені.
  • Поліпшена продуктивність JSON кодування.
  • Витікаючі websockets з'єднання більше не ініціюються при використанні socks або http proxy (якщо визначені системні властивості socksProxyHost або http.proxyHost).
  • Включає ті, що закінчуються prunable JSON в транзакцію API JSON, за наявності.
  • Щоб захистити загальнодоступні вузли від непотрібного додаткового завантаження, getState API не включає кількість, навіть якщо includeCounts=true, поки не буде заданий параметр adminPassword, або не є необхідним.
  • У getState додані numberOfAccountLeases і numberOfActiveAccountLeases, показують загальну кількість запланованих (які почнуть орендувати), або активні нині договори оренди балансу акаунту.
  • Обмеження довгі деталізації вузлів -10 символів для версії, 20 для застосування, 30 для платформи, і 100 для адреси, яку анонсують.
  • Поліпшення призначеного для користувача інтерфейсу :
    • Виправлений помилка із за якою іноді не відображувався значок повідомлень після входу в систему.
    • Поліпшені переклади болгарську і словацьку мовами.
    • Виправлення помилок при локальному підписанні завантажуваних теговых даних і затвердження транзакції.
    • Ця версія виконає повне пересканирование blockchain при першому запуску.
    • Оновлення jetty до версії 9.2.11. При установці розпаковуванням поверх існуючої установки, заздалегідь видалите стару теку lib.

3 Версія 1.5.9

27 Травня, 2015

  • Активований функціонал Voting System, Phasing, і пов'язаний з ними новий функціонал, починаючи з блоку 445000.
  • Це hard fork, оновлення до версії 1.5.9 або новішою обов'язково для усіх.
  • Якщо ви оновлюєтеся з версії 1.4.x, для вивчення змін які введені у версій 1.5.х прочитайте уважно опис змін і нових можливостей.
  • Поліпшення в роботі вузлів. Вузли, які недоступні більше 7 днів і не перераховані в параметрах nxt.wellKnownPeers або nxt.defaultPeers, видаляються з бази цих вузлів.
  • Оновлені файли перекладів, доданий Болгарський і Каталонський переклади.
  • Інші незначні виправлення і поліпшення.

Важливі зміни в ліцензуванні:

  • Програмне забезпечення ядра Nxt тепер поширюється під ліцензією GNU General Public License version 2, за винятком коду призначеного для користувача інтерфейсу клієнта, який продовжує поширюватися відповідно до ліцензії MIT. Читайте файли LICENSE.txt, COPYING.txt і DEVELOPER-AGREEMENT.txt для отримання додаткової інформації.

4 Версія 1.5.8e

15 Травня, 2015

  • Це експериментальна версія. Необхідно обов'язково відновити усі вузли testnet, також може використовуватися в основній мережі.
  • Встановите тип контенту в "text/plain; charset=UTF-8", коли відправляєте http запити вузлам. Це важливе виправлення помилки, оскільки неправильне кодування витікаючих блоків і транзакцій, що містять деякі символи Unicode, може зупинити їх поширення і привести до галужень. Усi хто використовує експериментальний випуск повинні обов'язково оновитися.

5 Версія 1.5.7e

15 травня, 2015

  • Це експериментальна версія. Її необхідно відновити на усіх вузлах testnet, цю версію також можливо використовувати на основній мережі.
  • Додана підтримка WebSockets для p2p взаємодії мережі. При з'єднанні з вузлами, які не підтримують WebSockets, використовуватиметься HTTP. WebSockets може бути відключений, установкою параметра nxt.useWebSockets в "false" (за умовчанням включено).
  • Реалізовано паралельне завантаження blockchain. Після настання Constants.PHASING_BLOCK (ще не встановленою в основній мережі), блоки і дані транзакцій проситимуться відразу від безлічі вузлів паралельно, пакетами по 36 блоків (коли потрібне завантаження більш ніж 36 блоків), замість того як це було реалізовано раніше - шляхом завантаження 720 блоків від єдиного сусіднього вузла що містить потрібні блоки в blockchain. Як очікується, це значно скоротить час повного завантаження blockchain, як тільки більшість вузлів оновляться, щоб підтримувати протокол паралельний завантаження.
  • Додано завантаження файлу, що використовує множинну форму запитів до API UploadTaggedData, ExtendTaggedData і VerifyTaggedData. Додана кнопка завантаження файлу до відповідних форм на сторінці /test.
  • Доданий API виклик DownloadTaggedData, для завантаження тегированых даних як файл.
  • Доданий опциональный булевий параметр includeData для усіх API викликів GetTaggedData, за умовчанням "true", дозволяє опускати фактичні дані повертаних результатів для збереження пропускної спроможності, оскільки ці дані тепер можна отримати окремо, використовуючи DownloadTaggedData API.
  • Реалізований пошук по тегах. Реалізована перевірка тегированых даних.
  • Доданий параметр includeEffectiveBalance в API виклики getAccount і getBalance, за умовчанням "true". Якщо "false", ефективний баланс і гарантований баланс не включаються у відповідь, це повинно підвищити ефективність роботи вказаних API викликів.
  • Додана утиліта HexConvert API.
  • Поліпшення в GetConstants JSON, тепер дозволяє включати альтернативний тип JSON представлення транзакції.
  • Вузли в списку nxt.wellKnownPeers завжди підтримують з'єднання, незалежно від числа підключених публічних вузлів або загальної кількості відомих вузлів.
  • Доданий API функція GetInboundPeers, яка повертає список усіх вузлів мережі які відправляли запиту вказаному вузлу, в течії останніх 30 хвилин.
  • Додані булеві поля inbound, inboundWebSocket, і outboundWebSocket в JSON вузла, повертаний API запитами getPeer і getPeers, щоб показати стан кожного вузла, що входить, і визначити чи встановило це що входять або витікаючі websocket з'єднання з цим вузлом.
  • Обмеження загальної кількості з'єднань, що входять і витікаючих, використовуючи властивості nxt.maxNumberOfInboundConnections і nxt.maxNumberOfOutboundConnections, за умовчанням 250 і 50 відповідно. Значення nxt.maxNumberOfConnectedPublicPeers не може перевищувати значення nxt.maxNumberOfOutboundConnections (якщо це відбувається, то це задано в nxt.maxNumberOfOutboundConnections).
  • API запити getAccountTransactions і getAccountTransactionIds були обмежені таким чином, що завжди повертають тільки не-фазовані транзакції. Ці API будуть видалені починаючи з версії 1.6. Замість них повинна використовуватися API функція getBlockchainTransactions, яка має той же функціонал, але повертає і фазовані і не-фазовані транзакції (за умовчанням, якщо або phasedOnly або nonPhasedOnly параметри не задані). Не варто просто замінювати getAccountTransactions на getBlockchainTransactions у вашому клієнтському коді без розуміння того, як фазовані (поетапні) транзакції працюють, оскільки ви не будете готові обробляти їх правильно.
  • Додано посилання на Wiki документацію по використанню API запитів із сторінки /test. Посилання генерується автоматично, і таким чином надаються дані тільки на той розділ Wiki який відповідає хэш-тегу, на даний момент, більшість з них ще в доопрацюванні.
  • JavaScript функція NRS.sendRequest() більше не приймає callback функцію як свій другий параметр. Замість цього при відправленні запиту без даних встановите значення {} як другий параметр і функція callback як третій параметр.

Поліпшення призначеного для користувача інтерфейсу :

  • Реалізовано на стороні клієнта підписання тегированых даних транзакцій.
  • Додана форма File Upload (Завантаження Файлу), доступна з меню налаштування параметрів. Допускається розширене тегирование даних транзакції в модальній вікні з інформацією про транзакцію.
  • Інтеграція поточного статусу клієнтських перекладів для нових функцій 1.5 версій, новий "експериментальний" стан для мов із станом перекладу в 40-50%+, додані чеський, грецький, переклад на хінді в експериментальному стані, відновила стан перекладу для інших мов (Бета: 70-80%+, Стабильный:90-95%+).

6 Версія 1.5.6e

28 квітня, 2015

  • Це експериментальна версія. Її необхідно відновити на усіх вузлах testnet, цю версію також можливо використовувати на основній мережі.
  • Поліпшення роботи вузлів мережі.
  • Адреси, що анонсуються, завжди перевіряються на відповідність заданій адресі, і не приймаються якщо виявляється невідповідність. Раніше анонсовані вузли і адреси, будуть видалені при зміні IP у вузла з динамічною IP адресою.
  • Якщо nxt.maxNumberOfKnownPeers (значення за умовчанням 2000) перевищений, розмір пулу вузлів зменшується до nxt.minNumberOfKnownPeers (значення за умовчанням 1000), спочатку зберігши найвищі hallmarked вузли.
  • Вузли тепер ідентифікуються тільки IP -адресом а не адресою і портом. Мульти-узлы, що спільно використовують один і той же IP -адрес, розглядатимуть як один вузол, із заявленою адресою і портом який буде отриманий запитом GetInfo або з відповіді, при відправці або отриманні інформації на/з цієї адреси.
  • Несумісна зміна: При використанні порту що відрізняється від порту за умовчанням, клеймо повинне також включати інформацію про цей порт, інакше клеймо буде проігноровано.
  • Оптимізація поширення непідтверджених транзакцій. Коли вузлам передається нещодавно отримана непідтверджена транзакція, якщо їх кількість перевищує 10, передача відбувається декількома пакетами по 10. При запиті непідтверджених транзакцій від вузлів, ідентифікатори транзакцій в кулі, нині включені в запит, так, щоб видалений вузол не повинен був включати їх у відповідь. Розмір відповіді також обмежений 100 транзакціями, якщо просячий вузол не підтримує параметр, що виключає.
  • У будь-яких тегованих даних тепер також додано поле каналу. API searchTaggedData може фільтрувати результати пошуку по каналу, а новий API getChannelTaggedData був доданий, щоб вибирати теговані дані по каналах, з додатковою фільтрацією по акаунту.
  • Виправлення в призначеному для користувача інтерфейсі для AddPeer і BlacklistPeer, для прийнятті пароля адміністратора у разі потреби.
  • Дії з "Approve Transaction" тепер доступні на вкладці дій інформації про транзакцію.
  • Додано поле "Reveal Secret" у формі "Approve Transaction", при голосуванні по моделі "By Hash".
  • Поліпшена /test сторінка для прийняття і попереднього заповнення тестових форм будь-якими значеннями параметрів, наданими в URL, наприклад: http://localhost: 7876/test?requestType=getBlocks&lastIndex=10&includeTransactions=true
  • Ця версія виконає повне ресканирование blockchain в тестовій мережі.

7 Версія 1.5.5e

23 квітня, 2015

  • Це експериментальна версія. Її необхідно відновити на усіх вузлах testnet, цю версію також можливо використовувати на основній мережі.
  • Виправлена обробка непідтверджених транзакцій ExtendTaggedData.
  • API AddPeer і BlacklistPeer тепер використовують POST метод і вимагають admin пароль.
  • Ця версія виконуватиме повне повторне сканування в testnet.

8 Версія 1.5.4e

22 квітня, 2015

  • Це експериментальна версія. Її необхідно відновити на усіх вузлах testnet, цю версію також можливо використовувати на основній мережі.
  • Виправлена помилка в парсинге json транзакції ExtendTaggedData, яка перешкоджала тому, щоб такі транзакції поширювалися між вузлами.
  • Додана постійна опція повідомлень для більшості діалогів при відправці транзакцій.
  • Інші незначні виправлення і поліпшення.

9 Версія 1.5.3e

19 квітня, 2015

  • Це експериментальна версія. Необхідно її відновити на усіх testnet вузлах, її також можливо використовувати на основній мережі.
  • Ця версія додає опцію Prunable Tagged Data, заплановану до включення з блоку голосування, що включає систему.
  • Теговані Prunable дані подібні до prunable повідомлень c відкритим текстом, без одержувача, але з додатковими доступними для пошуку полями метаданих. Ця функція може бути використана для децентрализованного і довіреного розподіленого зберігання маленьких (до 42KB метаданих включно) частин даних, які за умовчанням зберігаються тільки протягом двох тижнів (24 години на testnet), але опционально можуть бути збережені деякими вузлами на більше тривалий час або навіть нескінченно, і можуть бути перевірені повторно в blockchain навіть після їх видалення.
  • Нині у будь-яких тегованих даних можуть бути наступні поля, на додаток до самих даних: Ім'я(потрібне), Опис, Теги, Тип, isText, Ім'я Файлу.
  • Поля Имя, Опис і Теги індексуються і доступні для пошуку з використанням Lucene. У усіх prunable даних і метаданих, після видалення зберігаються тільки 32-байта хеша.
  • Комісія за будь-яке завантаження або за продовження тегованих даних грунтується на загальному розмірі даних (включаючи метадані) і складає 1 NXT для даних розміром до 1 KB, і 0.1 NXT для кожного наступного 1 KB, на даний момент обмежено об'ємом 42 KB.

Новые программный ИНТЕРФЕЙС приложения :

  • UploadTaggedData - створює і публікує нові теговані дані.
  • ExtendTaggedData - збільшує час закінчення терміну вже завантажених тегованіх даних. Якщо дані все ще доступні, потрібний тільки ідентифікатор транзакції. Інакше вже приділені дані можуть бути відновлені включенням (на додаток до початкового ідентифікатора транзакції) усіх полів, тобто ім'я, опис, і так далі. Забезпечити продовження терміну може будь-який користувач, а не тільки той хто завантажував дані. Кожна транзакції що збільшує термін доступності даних, подовжує його на два тижні (24 ч на testnet). Збільшення терміну доступності тегованих даних іншим обліковим записом не змінює початковий ідентифікатор акаунту submitter, який проиндексирован і доступний для пошуку.
  • VerifyTaggedData - використовується щоб перевірити минулі теговані дані, завантажені з іншого вузла, на присутність хеша в поточному blockchain.
  • SearchTaggedData - повнотекстовий пошук по назві, тегу, і опису, опционально може фільтрувати акаунту який опублікував дані.
  • GetTaggedData - отримує дані тегів по заданому id транзакції.
  • GetAccountTaggedData - повертає усе теговані дані опубліковані заданим акаунтом.
  • GetAllTaggedData - повертає усе існуючі теговані дані.
  • GetDataTags - повертає різні теги усіх тегованих даних, з числом даних, що мають кожен тег.
  • GetDataTagsLike - префіксний пошук тегів даних.
  • GetDataTagCount - загальне число різних тегів.
  • Усе Get* і Search* API може отримати тільки теговані дані, які ще не були видалені (pruned).
  • Зараз немає ніякої підтримки перерахованих API на рівні призначеного для користувача інтерфейсу. Очікується, що будуть розроблені спеціалізовані сторонні плагiни для спеціалізованих тегованих даних, залежно від типу файлу і цільової групи користувачів.
  • Нині видаленням тегованих даних управляють ті ж властивості конфігурації, які використовуються для видалення повідомлень, що видаляються (prunable).
  • По аналогії з prunable повідомленнями, коли використовується broadcastTransaction API, щоб опублікувати вже підписані тегованi дані у вивантажуваній транзакції, prunable частини повинні знаходитися в параметрі prunableAttachmentJSON у разі, якщо використовується параметр transactionBytes. Якщо публікується transactionJSON, він вже містить prunable частини.

Нові API відладки:

  • GetAllBroadcastedTransactions - якщо ретрансляція транзакції включена, повертає непідтверджені транзакції, які були передані від цього вузла, але ще не були отримані назад від вузлів.
  • GetAllWaitingTransactions - повертає непідтверджені транзакції, які нині тимчасово збережені в пам'яті під час обробки транзакцій.
  • RebroadcastUnconfirmedTransactions - якщо ретрансляція транзакції включена, транзакції знаходяться нині в кулі непідтверджених транзакцій, повторно передаватимуться вузлам, поки не не будуть отримані назад від вузлів мережі.

Інші зміни і виправлення :

  • Поліпшена обробка неприпустимих транзакцій під час генерації блоків. Виправлена перевірка допустимості транзакції відміни AE ордерів. Зафіксований витік пам'яті при обробці непідтверджених транзакцій. Межа очікування непідтверджених транзакцій в параметрі nxt.maxUnconfirmedTransactions встановлений за умовчанням в 1000.
  • Розмір даних доставки товарів DGS буде обмежений 1000 байтами після блоку VS.
  • Виправлення в обробці prunable повідомлень.
  • Виправлення у фазуванні з білим списком облікових записів схвалення.
  • На testnet, при першому запуску, ця версія виконає повне ресканирование з наступним відкатом blockchain до висоти 263895.

10 Версія 1.5.2e

15 квітня, 2015

  • Це експериментальна версія. Її необхідно відновити на усіх вузлах testnet, цю версію також можливо використовувати на основній мережі.
  • Доданий getAllPrunableMessages API, повертає усі доступні на даний момент prunable повідомлення, в порядку зворотному мітці часу блоку.
  • Доданий API verifyPrunableMessage, який можна використовувати, щоб перевірити, що prunable повідомлення, отримане від іншого вузла (постачальника послуг), відповідає хешу, знайденому в blockchain, тобто не було підроблено.
  • Відображує maxPrunableLifetime налаштування в getState і getBlockchainStatus. Відображує поточну кількість prunable повідомлень в getState.
  • Змінена властивість nxt.maxPrunableLifetime, тепер також впливає на існуючі prunable повідомлення (будуть видалені при наступному запуску), оскільки тепер використовуються мітки часу транзакції замість міток часу витікання повідомлень.
  • Розмір максимального товару DGS, що доставляється, знову повернувся до 10 Кбайтам, як у версії 1.4. Для товарів більшого розміру замість цього повинне використовуватися зашифроване prunable повідомлення.
  • Видалене базове обмеження на 28-байтову мінімальну довжину prunable повідомлення, ця умова перевірятиметься тільки в призначеному для користувача інтерфейсі.
  • Додана властивість nxt.includeExpiredPrunables, що дає можливість викликати включені prunable частини в повертаному JSON транзакції, навіть якщо у них збіг термін зберігання, але вони все ще доступні. Може використовуватися, щоб змусити архівний вузол завжди повертати ці дані, таким чином дозволяючи іншому архівному вузлу, який отримує від нього інформацію, також отримати усі вказані необхідні дані.
  • Ліміт кількості непідтверджених транзакцій, які можуть бути збережені в пам'яті, задається в nxt.maxUnconfirmedTransactions, за умовчанням обмеження відсутні. Якщо значення задане, транзакції з найнижчим відношенням комісії/розміру видаляються з пулу непідтверджених транзакцій в першу чергу. Порядок такою ж який використовується при виборі транзакцій які включаються в новий блок.
  • Додана API відладки requeueUnconfirmedTransactions .
  • Додана підтримка для не нестислих prunable зашифрованих повідомлень і самостійно зашифрованих повідомлень, як новій версії застосувань, щоб уникнути потреби визначати стан стискування як параметр запиту при читанні цих даних.
  • Доданий setLogging API, який дозволяє міняти рівень логирования без необхідного рестарту сервера.
  • Додані eventRegister і eventWait API, використовуватися для реєстрації публікацій і очікування подій сервера опитування.
  • Змінені параметри broadcastTransaction, що приймаються. Будь-яка prunable частина має бути передана в transactionJSON, або, якщо використовуються transactionBytes, в новому prunableAttachmentJSON параметрі, який має той же формат що і приєднуваний до транзакції json. PrunableAttachmentJSON тепер повертає signTransaction і getTransactionBytes API.
  • Додана підтримка для prunable повідомлень, простих і шифрованих, в призначеному для користувача інтерфейсі.
  • Доданий опциональный параметр buyer в getDGSGoodsPurchases API.
  • Поліпшення і виправлення помилок в інтерфейсі користувача в Voting system.

11 Версія 1.5.1e

11 квітня, 2015

  • Це експериментальна версія, яка додає опцію Prunable Messages. Ця функція буде включена в основній мережі в тому ж блоці що і функції Voting і Phasing.
  • Ця версія обов'язкова для оновлення на усіх вузлах testnet, також може працювати на основній мережі.

Нові функції:

  • Prunable (що видаляються) прості і шифровані повідомлення.
  • Прості і шифровані повідомлення можуть тепер бути створені як prunable. Для prunable повідомлення самі ці повідомлення не є частиною байтів транзакції. Замість цього зберігається 32 байти його хэша SHA256 який включені в байти транзакції, які підписуються і використовуються щоб перевірити підпис або отримати повний хэш транзакції або id. Це дозволяє повністю видалити дані про повідомлення в будь-який час, зберігши тільки 32 байти хэша, при цьому мати можливість перевірити підпис а транзакції, отримати хэш транзакції і id, при цьому видалення ніяк на ці дані не вплине.
  • У prunable повідомлень є заданий період життя, після якого їх prunable частини будуть видалені з blockchain. Відлік періоду життя повідомлення починається мітки часу транзакції. Коли вузол отримує транзакцію або блок від іншого вузла, вимагається щоб prunable частини будь-якого prunable повідомлення були включені, якщо термін їх життя ще не збіг. Якщо це виконується, і коректний хэш повідомлення є присутній, блок або транзакція будуть прийнятий.
  • Нині мінімальний термін життя prunable даних складає 24 ч для testnet, що дозволяє дуже просто тестувати цей функціонал. Для основної мережі цей показник експериментально встановлений в два тижні, але можливо буде змінений перед випуском стабільної версії. Зверніть увагу на те, що видалення виконується в той же час, що і обрізання таблиць, яке відбувається через кожних 1000 блоків, таким чином, фактичне видалення prunable даних з бази даних станеться з деякою затримкою після закінчення часу їх життя.
  • Вузол може зберігати prunable повідомлення довше, шляхом установки більшого значення параметру nxt.maxPrunableLifetime . Цей параметр не може вплинути на видалення даних на більше ранньому етапі. Зміна цього значення зачіпає тільки ті транзакції які були отримані після зміни. Видалення може бути повністю відключене шляхом установки цього параметра в - 1.
  • Prunable повідомлення у яких ще не закінчився термін життя, але пройшов мінімальний термін життя (см вищий), можуть бути тільки відновлені з використанням API getPrunableMessage (s), але вони не включені як частина їх JSON транзакції.
  • Якщо транзакція містить prunable вкладення є поетапно здійснюваною (фазованою), її prunable частини, проте, зберігаються і доступні негайно, а не тільки на кінцевій висоті. Якщо настає їх крайній термін життя, то перед кінцевою висотою фазування вони будуть видалені і не доступні на кінцевій висоті.
  • Комісія за prunable повідомлення складає 0.1 NXT за кожних 1024 байти, з безкоштовними першими 1024 байтами (комісія за транзакцію залежно від його типу також застосовується). Розмір комісії можливо буде змінений перед випуском стабільної версії.
  • Повний розмір вкладених prunable повідомлення обмежений 42 Кбайтами. Зверніть увагу на те, що цей розмір використовується при обчислення повного корисного вантажу блоку, хоча фактично в транзакционых байтах міститься тільки 32-байтовий хэш повідомлення.
  • Розмір звичайних простих і зашифрованих повідомлень в цій версії був знову обмежений 1000 байтами і буде, ймовірно, зменшений ще більше перед виходом стабільної версії. Це робиться для того, щоб заохочувати користувачів перемикатися із звичайних повідомлень на prunable повідомлення. Комісія за звичайні повідомлення також істотно збільшуватиметься.
  • Створення простих prunable повідомлень розміром менше 28 байтів заборонене, оскільки в такому невеликому об'ємі ефективніше зберігати повне повідомлення чим його 32-байтовою хэш. У зашифрованих prunable повідомленнях відсутні які або обмеження на розмір.
  • Транзакція не може мати одночасно і просте prunable повідомлення і зашифроване prunable повідомлення. Також не може мати prunable і звичайне повідомлення того ж самого типу (просте або зашифроване). При цьому можна одночасно мати звичайне просте повідомлення і зашифроване prunable повідомлення, або просте prunable повідомлення і регулярне зашифроване повідомлення.
  • Prunable encrypt - self повідомлення нині не підтримуються, оскільки передбачається відсутність потреби у використанні такого рішення.
  • Зашифровані Prunable повідомлення можуть бути довільно стислі перед шифруванням (стискування за умовчанням). Статус стискування зберігається і немає необхідності його самостійно визначати при розшифровці. Звичайні зашифровані повідомлення за умовчанням стискуються, але тепер це стискування може бути довільно відключене. Для зворотної сумісності з "старими" повідомленнями, оскільки їх байт формат не зберігає статус стискування, це повинно бути визначено при розшифровці, інакше буде повернена помилка або будуть повернені нечитабельні дані.

Нові API:

  • GetPrunableMessage - повертає prunable повідомлення для заданого id транзакції, додатково дешифрує його, якщо повідомлення зашифроване і secretPhrase надана.
  • GetPrunableMessages - повернення усі prunable повідомлення для заданого id акаунту, додатково обмежуючи заданим обліковим записом одержувача або відправника, і дешифрує їх, якщо secretPhrase надана.
  • Prunable повідомлення, які вже були видалені не повертатимуться вказаними API
  • Призначений для користувача інтерфейс для цих API буде реалізований в нових версіях.
  • TrimDerivedTables - API відладки, щоб ініціювати обрізання похідних і prunable таблиць.

Змінені API:

  • Усе API які створюють нові транзакції тепер також опционально підтримують boolean параметри: messageIsPrunable або encryptedMessageIsPrunable (за умовчанням false). Якщо true, тоді приєднано повідомлення або шифроване повідомлення, в будь-якому іншому випадку це створено prunable повідомлення.
  • Щоб управляти, виконувати стискування перед шифруванням або ні, можна використовувати нові параметри compressMessageToEncrypt і compressMessageToEncryptToSelf (за умовчанням true).
  • Prunable повідомлення, якщо ще не видалені, також повертатимуться як частина json транзакції API getAccountTransactions, використовуючи ті ж відповідні поля як і регулярні повідомлення, але додаючи messageIsPrunable або encryptedMessageIsPrunable boolean прапор.
  • ReadMessage тепер також обробляє вкладені prunable повідомлення, якщо такі є. Для цього використовуються додаткові параметри uncompressDecryptedMessage і uncompressDecryptedMessageToSelf (за умовчанням true), використовувані тільки для non, - prunable повідомлень (не є необхідними для prunable).
  • DecryptFrom приймає додатковий параметр uncompressDecryptedMessage, і encryptTo приймає додатковий параметр compressMessageToEncrypt, true за умовчанням.

НЕСУМІСНІ зміни:

  • BroadcastTransaction був змінений, щоб додатково приймати усі параметри, які потрібні, щоб створити просте або зашифроване prunable повідомлення (тільки клієнтське шифрування). Це необхідно, тому що дані для таких повідомлень ніколи не є частиною самих байтів транзакції, таким чином, спроба широкомовно передати транзакцію у якої є prunable частина, тільки представляючи їх як байти broadcastTransaction приведе до ПОМИЛКИ, якщо відповідні параметри, необхідні, щоб додати prunable частину, не будуть також надані. Зверніть увагу на те, що вони повинні точно відповідати початковим параметрам, з якими байти транзакції були створені і підписані.
  • Для повідомлень non - prunable broadcastTransaction поводиться як раніше, але користувачі повинні починати переходити на prunable повідомлення зважаючи на заплановані обмеження розміру і збільшення комісій.
  • Клас EncryptedData java більше не робить внутрішньої обробки стискування, це передається зухвалій стороні щоб використовувати методи шифрування і дешифрування.

Інші зміни:

  • GetPolls тепер підтримує додатковий параметр includeFinished (false за умовчанням).
  • Множинні виправлення і поліпшення Системи голосування і призначеного для користувача інтерфейсу Фазування.
  • Межа крайнього терміну транзакції в 1440 хвилин була видалена. Тепер можливо створити транзакцію строком до 32767 хвилин. Це було зроблено, тому що у багатьох випадках використання фазування потрібно щоб байти транзакції були підготовлені набагато раніше, ніж станеться фактична широкомовна передача транзакції в blockchain.
  • Ця версія при першому запуску виконає оновлення бази даних з повним повторним скануванням. На testnet також станеться відкат до блоку 256935.

12 Версія 1.5.0e

6 квітня, 2015

  • Ця версія є експериментальною, в ній реалізовані Voting System і Phasing. Ця версія є обов'язковою для оновлення на усіх вузлах testnet, вказаний функціонал доступний тільки в testnet.
  • Також можливо запустити цю версію на головній мережі, але блок, з якого будуть активовані нові функції, ще не був встановлений.
  • Нові функції:
    • Voting System / Система голосування.
      • Voting System API :
        • CreatePoll, CastVote, GetPoll, GetPolls, GetPollResult, GetPollVote, GetPollVotes, SearchPolls.
      • Обробка опитувань опциональна. Якщо параметр nxt.processPolls=false (значення за умовчанням - true), то підрахунок голосів не робитиметься, і результати опитування не будуть збережені. Це може використовуватися, щоб зменшити навантаження на вузли з меншою продуктивністю. Збережена можливість отримати результати опитування, використовуючи getPollResult, доки необхідне голосування і дані балансів ще не були обрізані.
      • Незалежно від налаштувань nxt.processPolls голоси до опитувань, які закінчилися перед останньою висотою обрізання (1441 блок за умовчанням) будуть видалені і тільки їх підсумкові результати будуть збережені, якщо обробка включена.
      • Оцінка голосів відбувається на основі вибраної моделі голосування, яка може пов'язана з обліковим записом, балансом, балансом активу або балансом валюти, також може бути заданий мінімальний баланс при якому можна дістати доступ до голосування. Модель голосування задається при створенні опитування, проте альтернативна модель підрахунку голосів може бути використана при виклику getPollResult API, щоб вичислити на льоту голоси альтернативним методом, доки ці голосування все ще доступні.
      • Голосування багатократне, зміна або видалення голосів не можливе.
      • Збір за створення опитування складає 10 NXT для опитування з максимум 20 опціями, і додатковий збір в 1 NXT за будь-яку додаткову опцію (максимально допускається до 100 опцій).
    • Phasing.
      • Phasing API :
        • ApproveTransaction, GetAccountPhasedTransactions, GetAccountPhasedTransactionCount, GetAssetPhasedTransactions, GetCurrencyPhasedTransactions, GetPhasingPoll, GetPhasingPolls, GetPhasingPollVote, GetPhasingPollVotes, GetVoterPhasedTransactions.
        • Транзакція будь-якого типу може бути здійснена поетапно, якщо додати параметр phased=true і відповідний набір параметрів фазування. Поетапні транзакції приймаються в blockchain відразу (проходячи усі звичайні перевірки допустимості), але виконуються тільки на заданій висоті закінчення, якщо транзакція все ще є допустимою і якщо необхідний кворум був досягнутий.
        • Якщо на висоті закінчення транзакція не підтверджена, або не стала неприпустимою, вона залишається в blockchain але ніколи не виконується, і ніякі зміни, які вона провела не будуть підтверджені, а баланс відправника буде відновлений, за винятком того, що збір за транзакцію не буде відшкодований.
        • На додаток до моделей голосування, доступних в опитуваннях, транзакції здійснювані поетапно можуть використовувати whitelist (білий список) облікових записів (максимум 10), яким дозволяється голосувати за транзакцію.
        • Це робить можливим голосування за (твердження) до 10 поетапних транзакцій одиничними підтвердженнями транзакції. Ця транзакція буде прийнята в blockchain тільки якщо усі поетапні транзакції, які голосують за транзакцію, вже знаходяться в нім.
        • Багатократне голосування одним акаунтом дозволене, але не має ніякого ефекту при підрахунку голосів, після першого голосування, повторне голосування від облікового запису ігнорується.
        • Також можливо зробити будь-яку транзакцію такою, що поетапно реалізовується, без необхідності голосування зі схваленням. Це може використовуватися, щоб створити транзакції з відкладеним виконанням.
        • Плата за розкриття секрету підтримується як модель голосування для поетапних транзакцій.
        • Коли використовується ця модель голосування, поетапна транзакція повинна включати хеш секрету, вибраний відправником (100 байт завдовжки), і схвалення транзакції для неї приймається тільки якщо воно включає секрет, який дає цей хеш. Не має значення, хто відправник транзакції схвалення, якщо whitelist не визначений. На даний момент підтримуються хеш-функции sha256, ripemd160, і sha256, з наступним ripemd160. Коди, які необхідно вказати як параметрів доступні з API getConstants.

13 Версія 1.4.18

15 травня, 2015

  • Ця версія виправляє невеликі помилки. Рекомендується для оновлення усім.
  • Встановите тип контенту в "text/plain; charset=UTF-8", коли відправляєте http запити вузлам. Це важливе виправлення помилки, оскільки неправильне кодування витікаючих блоків і транзакцій, що містять деякі символи Unicode, може зупинити їх поширення і привести до галужень.

14 Версія 1.4.17

19 квітня, 2015

  • Ця версія є критичним оновленням. Рекомендована усім для оновлення.
  • Виправлена перевірка допустимості ордера на відміну на біржі активів.
  • Виправлений витік пам'яті при обробці непідтверджених транзакцій.

15 Версія 1.4.16

24 лютого, 2015

  • Оновлення Jetty до версії 9.2.9 через критичну помилку безпеки :

http://dev.eclipse.org/mhonarc/lists/jetty-announce/msg 00074.html Ніяких змін в коді клієнта не проводилися, оновлені тільки jetty бібліотеки. Увага! Перед установкою нової версії обов'язково видалите теку lib, що містить старі бібліотеки jetty.

16 Версія 1.4.15

13 лютого, 2015

  • Можливе виправлення помилки неприпустимого лічильника CurrencyMint.
  • У описі зроблені кликабельные URL і виправлена потенційна проблема з можливістю XSS эксплойта.

17 Версія 1.4.14

9 лютого, 2015

  • Додана налагоджувальна інформація про збої транзакцій при карбуванні (minting) валют.
  • Зменшене значення за умовчанням для параметра numberOfForkConfirmations до 2.

18 Версія 1.4.13

9 лютого, 2015

  • Поліпшення в роботі вузлів мережі, поліпшене журналювання, виправлення помилок.
  • Сторінка новин тепер завантажується правильно, коли гаманець використовує https.
  • Оновлення повідомлень Nxt-форума виводяться на екран зверху нових тем.
  • Оновлення каналу виконується при кожному оновленні сторінки новин.
  • Незначні виправлення в призначеному для користувача інтерфейсі.

19 Версія 1.4.12

5 лютого, 2015

  • Поліпшений дозвіл галужень, дозволяє просувати вузлу складніший блок, щоб замінити поточний останній блок.
  • При форжинге, не приймається блок вузла, з часом попадання після часу наступного попадання

поточного форжащего аккаунта (тобто запобігають випереджаючому виконанню при форжинге).

  • Видалена можливість форжера пропускати його чергу. Навіть якщо із запізненням, блок буде все ще згенерований і представлений.
  • Затримка форжинга і представлення блоків в 20 секунд, настроюється через

параметр nxt.forgingDelay, щоб накопити більше транзакцій у блоці який форжится. Вступ випереджаючого блоку від вузла, проте відмінить цю затримку і наступний блок згенерує на 3 секунд раніше нього, цим можна управляти через параметр nxt.forgingSpeedup.

  • Вищезгадані зміщення часу застосовуються тільки до фізичного часу генерації блоків і

представлення блоків. Мітки часу блоків завжди фіксуються алгоритмом форжинга з точністю в 1 секунду, і не можуть бути змінені.

  • Поліпшена реєстрація помилок вузлів мережі. Реєструються, але не поміщають в чорний список вузли пошкоджені JSON відповіді, що не надали або надали.
  • Доданий призначений для користувача інтерфейс для додавання і поміщення у чорний список вузлів. Поміщення у чорний список з призначеного для користувача інтерфейсу можливо тільки, коли пароль адміністратора не потрібний (відключений або працюючий localhost).
  • Оптимізація бази даних. У окремі таблиці переміщені відкритий ключ аккаунта, посилачі транзакцій, і форжеры блоків, що призводить до 15% -у скороченню розміру бази даних. Ця зміна будуть виконані при першому запуску і займуть деякий час. Для стискування бази даних рекомендуємо після першого запуску перезапустити клієнт.
  • Поліпшення в API форжинга: getForging і stopForging тепер можуть використати для доступу

пароль адміністратора замість секретної фрази аккаунта. Вони отримують ті, що відповідають стан, або зупиняють форжинг, увесь поточний форжинг аккаунта. Як і в інших API защи

20 Версія 1.4.11

27 січня, 2015

  • Виправлена помилка в перевірці транзакцій, яка могла пошкодити завантаження blockchain. За умовчанням (і допустимий мінімум) значення для nxt.maxRollback тепер 1441.
  • Обмежений максимальний розмір HTTP запиту і відповіді до мережевого вузла, щоб запобігти потенційній атаці переповнювання пам'яті.
  • Ctrl-C тепер може зупинити роботу сервера, без необхідності очікування закінчення початкового ресканирования.

21 Версія 1.4.10

25 січня, 2015

  • Поліпшено відображення статусу скачування blockchain в призначеному для користувача інтерфейсі клієнта.
  • Додані переклади клієнта, змінені стан з бета-версії в стабільні для наступних мов: Італійської, Голландської, Української.
  • Виправлена помилка в парсинге байт транзакції, які можуть викликати помилку верифікації підпису і припинення форжинга.
  • При завантаженні blockchain, вимагають більше за одне підтвердження вилки коли висота блоку знаходиться до контрольної точки (нині це MS блок).
  • Нові виклики API для управління вузлами: addPeer і blacklistPeer. AddPeer додає адресу або IP вузла, опционально з номером порту, в список відомих вузлів і намагатиметься підключитися до цих вузлів. BlacklistPeer (захищені паролем) додаватиме в чорний список вузли, для блокування за умовчанням.
  • Ці API, і деякі інші, пов'язані з роботою вузлів мережі, були згруповані на новій вкладці Networking на сторінці тестування.
  • Обробка портів вузлів була поліпшена, щоб дозволити різним вузлам спільно використати один і той же IP -адрес, якщо вони використовують різні порти.
  • Щоб запобігти перевантаженню вузла з недійсними адресами вузлів, максимальна загальна кількість відомих вузлів обмежена параметром nxt.maxNumberOfKnownPeers (за умовчанням 2000).
  • Як тільки це число буде досягнуте, нові адреси вузлів не додаватимуться, а вузли, з якими зв'язок був більше ніж тиждень тому, віддаляться зі списку відомих вузлів, поки вузол має досить з'єднань з публічними вузлами, а кількість відомих вузлів не зменшиться нижче nxt.minNumberOfKnownPeers (неплатіж 1000).
  • Поліпшена продуктивність бази даних, за рахунок зберігання об'єму валюти і резерву за одиницю в окремій таблиці.
  • Цей релиз виконуватиме повторне сканування бази даних при першому запуску.
  • Оновлення jetty до версії 9.2.7. Якщо розпаковування відбувається поверх попередньої установки,

спочатку видалите повністю теку lib, що містить стару версію бібліотеки.

22 Версія 1.4.9

18 січня, 2015

Логіка сервера :

  • Захист паролем API відладки. Параметр nxt.enableDebugAPI більше не використовується. Замість цього API відладка, яка дозволяють на пряму маніпулювати blockchain базою даних, завжди доступна, але тепер захищена паролем, який має бути встановлений в параметрі nxt.adminPassword. Пароль не потрібно, коли сервер API слухає тільки інтерфейс localhost (за умовчанням). Захист за допомогою пароля може бути відключений, установкою nxt.disableAdminPassword=true.
  • Деякий рефакторинг, щоб створювати і підписувати транзакції, використовуючи Java API навіть при повній відсутності даних blockchain, при необхідності для MintWorker.
  • Незначні поліпшення в роботі вузлів мережі, запити addPeers і processBlock тепер виконуються у фоновому режимі.
  • Поліпшення рішень ситуацій з "вилками". Функція мережевого вузла getNextBlocks API більше не обмежує число блоків і повернулася до загального розміру корисного навантаження в 1 МБ, але завжди повертає 720 блоків якщо вони доступні.

MintWorker:

  • Додана властивість nxt.mint.stopOnError, за умовчанням false. Карбування тепер продовжиться, за умовчанням, навіть після того, як сталася помилка коли відсилалася Mint транзакція на сервер.
  • Minting транзакції тепер підписуються локально і відсилаються на сервер використовуючи broadcastTransaction API. Таким чином секретна фраза Minting аккаунта ніколи не посилається на сервер, і сервер або зв'язок з ним не має бути довіреною. Секретна фраза також не логируется ні при якому виводі балка записів.

Призначений для користувача інтерфейс:

  • Доданий другий ряд блоків інформації на основній панелі.
  • Повідомлення для повідомлень, що входять.
  • Перероблена навігація сторінки.
  • Діалог лізингу аккаунта тепер показує число блоків до витікання договору оренди.
  • Виправлено посилання назви аккаунта у вікні інформації про транзакції.

Переклади інтерфейсу клієнта :

  • Доданий вибір мови на екрані вітання.
  • Додані переклади на декількох мовах для MS.
  • Завершені переклади: English, Spanish, French, Lithuanian, Portuguese (Brazilian), Russian, Chinese (Simplified), Chinese (Traditional)
  • В процесі тестування: German, Finnish, Galician, Croatian, Indonesian, Italian, Japanese, Dutch, Slovakian, Portuguese, Serbian (Cyrillic), Serbian (Latin), Ukrainian

23 Версія 1.4.8

11 січня, 2015

  • Видалений деякі перевірки і логіка, які стали непотрібними після блоку Monetary System.
  • Додана контрольна точка у блоці 330000.
  • Різні незначні виправлення в призначеному для користувача інтерфейсі
  • Виправлення в пошуку валют. Виправлена обробка з дуже високою складністю карбування (minting).
  • Усунені проблеми з паралелізмом карбування (minting) Scrypt, тепер можна використати мультипотоки.
  • Дозволено використання https для представлення транзакцій карбування (minting), для цього встановите параметр nxt.mint.useHttps=true. Зверніть увагу на те, що будь-який сертифікат SSL прийматиметься як допустимий, тому система не захистить Вас від атак "man - in - the - middle" при карбуванні.
  • Допускається прийняття в пул непідтверджених транзакцій, не більше за одну непідтверджену транзакцію карбування від обліковий запис що чеканила валюту.
  • Поліпшення перекладів, задокументованих в DEVELOPERS, - GUIDE.md.
  • Поліпшена перевірка клейм (hallmarks) для вузлів з множинними адресами. Не поміщає в чорний список вузли з неприпустимими ознаками, а просто розглядає їх як не hallmarked вузли.
  • У Чорний список потраплятимуть усі вузли з версіями старіше 1.4.
  • Оскільки пройшло більше ніж 720 блоків після блоку MS, вузли старіші чим версія 1.4, знаходяться тепер на галуженні, яке не буде дозволено. Для виправлення цього необхідно відновити такі вузли до версії 1.4.8, при цьому при запуску станеться видалення і повне завантаження blockchain.

24 Версія 1.4.7.1

10 січня, 2015

  • Меню "Monetary System" тепер завжди доступно в призначеному для користувача інтерфейсі після блоку 330000.
  • Більше ніяких змін по відношенню до версії 1.4.7.

25 Версія 1.4.7

6 січня, 2015

  • Це обов'язкове оновлення ! Усі повинні обов'язково оновитися до версії 1.4.7 або новішою до блоку 330000.
  • Шаблони Повідомлень в AccountInfo, введені з версії 1.4.0e, заблоковані, і не будуть активовано у блоці 330000. Це превентивна міра, щоб уникнути атаки відмови сервісів специфічними шаблонами регулярних виразів які за деяких умов можуть створювати дуже велике навантаження на CPU. Ця функція можливо буде включена знову у версії 1.5, але вже з передвстановленим набором допустимих і безпечних шаблонів регулярних виразів.
  • Множинні незначні поліпшення і виправлення призначеного для користувача інтерфейсу.
  • Властивість nxt.allowedBotHosts тепер приймає діапазон адрес, використовуючи нотацію CIDR.
  • Ця версія викличе ресканирование при першому запуску, тільки для testnet.

26 Версія 1.4.6

1 січня, 2015

  • Підтримка роботи з MS в призначеному для користувача інтерфейсі також буде доступна з блоку 330000, меню функцій MS з'явиться після досягнення цього блоку.
  • Функціонал обміну валют буде активований і доступний після досягнення блоку 330000 в blockchain.
  • Рефакторинг HTML UI, index.html розділений на декілька файлів.
  • Пропозиції, що додаються, і трансфери пов'язані з інтерфейсом обміну валюти .
  • Цей випуск виконає пересканування тільки в testnet, з відкатом до блоку 159305.

27 Версія 1.4.5

28 грудня, 2014

  • Monetary System буде активована починаючи з блоку 330000. Це hard fork, тому усім необхідно оновитися до версії 1.4.5 або новішу, до цього моменту.
  • Якщо ви оновлюєтеся з версії 1.3.x, прочитайте список змін від версії 1.4.0e або більш пізнішей щоб ознайомитися з важливими змінами і новими можливостями, реалізованими у версії 1.4.х

28 Версія 1.4.4e

25 грудня, 2014

  • Поліпшення і виправлення в інтерфейсі Monetary System, виплатах дивідендів і лізингу аккаунта.
  • Додана функція експорту/імпорту контактів.
  • Обмежує в обміні валют, пропозиції, що подаються, на продаж і купівлю, вони не повинні перевищувати загальний об'єм купівлі або продажу.
  • У цій версії реалізований виклик рескана (тільки у testnet), видаливши блоки після 159306.

29 Версія 1.4.3e

23 грудня, 2014

  • Доданий параметр availableOnly у функції getBuyOffers і getSellOffers, щоб задавати повернення тільки ненульових пропозицій і лімітів, за умовчанням - false. Цей параметр буде проігнорований, у разі коли і валюта і аккаунт задані у вказаному API виклику.
  • Додана API функція getExchangesByOffer, щоб отримати виконані пропозиції по обміну валют.
  • Не логуються операції обміну з нульовою сумою.
  • Виправлена установка стану вузла. Поліпшення в підключенні до вузлів.
  • Додані файли README.md, DEVELOPERS-GUIDE.md OPERATORS-GUIDE.md, та USERS-GUIDE.md.
  • Доданий пошук валют за кодом, назвою, або за ключовими словами опису.
  • Виправлені помилки в обробці непідтвердженого балансу при обміні валют і видаленні валют.
  • Ця версія викличе рескан, але тільки в testnet.

30 Версія 1.4.2e

21 грудня, 2014

  • Додаткові перевірки транзакцій Monetary System, і виправлення в існуючих перевірок.
  • Дозволяють встановити інший файл в якості сторінки за умовчанням для сервера API, в nxt.apiWelcomeFile, за умовчанням index.html.
  • Виправлені помилки в обробці десяткової точки при перетворенні в призначеному для користувача інтерфейсі, що стосуються транзакцій MS і AE.
  • Виправлення помилок при створенні валют і в MintWorker. Діалогове вікно створення було видалене, Ви можете створювати використовуючи утиліти створення валют або вручну опублікувавши currencyMint транзакцію на тестовій сторінці.
  • Виправлена помилка, в наслідку якої призначений для користувача інтерфейс клієнта не відповідав після виконання певних операцій MS.
  • Виправлені транзакції, що дублюються, на панелі інструментів UI.
  • Посилання на таблицю засновників переміщене з таблиці валют в діалог інформації про транзакції. Інші поліпшення призначеного для користувача інтерфейсу Monetary System.
  • Поліпшена робота мережі вузлів, з'явилася можливість реалізувати відправку блоків і транзакцій вузлам у фоновому потоці.
  • Ця версія викличе рескан тільки в testnet, будуть видалені блоки після 159306.

31 Версія 1.4.1e

17 грудня, 2014

Ця версія виправляє помилки виявлені в 1.4.0e.

  • Виправлена помилка що призводить до непрацездатності Обміну Валют (Currency Exchange, CE).
  • Виправлена проблема з десятковими знаками у валют.
  • Виправлені дрібні помилки в перевірці транзакцій MS.
  • Відображає загальну кількість альясов аккаунта, на сторінці альясов.
  • Виправлення в інтерфейсі функцій видалення альясов і виплати дивідендів.

32 Версія 1.4.0e

17 грудня, 2014

Це експериментальний випуск, щоб протестувати нові основні функції Monetary System. Ці функції будуть доступні в testnet, при цьому усі працюючі testnet вузли повинні оновитися до цієї версії, навіть якщо вони не планують використати функції MS, інакше вони підуть в галуженні. Цей випуск також може працювати в основній мережі, але не може вважатися стабільним для реальних операцій в основній мережі. Номер блоку для запуску Monetary System в основній мережі ще не визначений.

Нові функції:

  • Транзакції виплати дивідендів. Емітент активу може робити виплату дивідендів усім утримувачам активу, в одній транзакції. Обов'язкові параметри - висота blockchain, при якої долі утримувачів активу налічуватимуться (має бути менше ніж 1440 блоків у минулому), і сума, яка виплачуватиметься за 1 долю.
  • Транзакція видалення альяса. Власник альяса тепер може може видалити його повністю, зробивши альяс знову доступним для реєстрації будь-яким користувачем.
  • Шаблони повідомлень в AccountInfo. Власник аккаунта може встановлювати шаблони регулярних виразів в AccountInfo цього аккаунта, використовуючи setAccountInfo API. Як тільки такий шаблон буде встановлений, транзакції, що входять, на цей аккаунт прийматимуться тільки якщо вони містять звичайне текстове повідомлення, яке відповідає цьому шаблону. Синтаксис відповідає специфікації java.util.regex.Pattern.

Зміни API :

  • Після блоку MS, додатковий анонс публічного ключа при відправці транзакції аккаунту без публічного ключа стає опциональным.
  • Доданий булевий (boolean) параметр withMessage в getAccountTransactions і getAccountTransactionIds API, для того, щоб повертати тільки ті транзакції які мають приєднані повідомлення, які можуть бути не зашифровані або розшифровані аккаунтом.
  • Додані опциональные булеві (boolean) параметри includeLessors, includeAssets, і includeCurrencies для getAccount API. Встановіть в false коли вам не потрібно отримувати ці дані, щоб підвищити продуктивність getAccount.
  • Після блоку MS, відправка повідомлень, продаж альясов, і передача в лізинг балансу, генезисному аккаунту, буде заборонено.
  • API відладки popOff тепер дозволяє виштовхнути більше, ніж максимальне число відкату блоків, инициировав повне пересканирование в даному випадку.

Внутрішні зміни:

  • Після блоку Monetary System, порядок в якому виконуються транзакції у блоці, визначатиметься форжингом блоку, замість ID, що за умовчанням є часом вступу у вузол форжинга.
  • Поліпшення в завантаженні blockchain, щоб запобігти застряванню на неправильному галуженні. Вузли завантажать блоки пакетами, з не більше ніж 719 блоками за один раз від єдиного вузла, після того, як кожен такий пакет перевірять з nxt.numberOfForkConfirmations інші вузли (значення за умовчанням 5) якщо це буде кращим галуженням, перед продовженням, якщо завантажений пакет має не менше ніж 10 блоків.
  • Стан ресканування тепер зберігається у базі даних, щоб уникнути ситуації коли база даних була залишена в суперечливому стані, коли ресканування перестало працювати або було перервано. Як тільки ресканування буде заплановане, воно буде автоматично розпочато знову при перезапуску, поки воно не завершиться успішно.
  • Поліпшення в обробці непідтверджених транзакцій.
  • Ця версія викличе рескан при першому старті.

33 Версія 1.3.5

14 Грудня, 2014

  • Доданий getDGSTagCount API, getDGSGoodsCount і getDGSPurchaseCount можуть використовуватися щоб отримати загальну кількість товару або кількості покупок.
  • Доданий додатковий параметр в getDGSGoodsPurchases, getDGSGoodsPurchaseCount, getDGSPurchaseCount, getDGSPurchases, щоб мати можливість робити запит тільки для завершених покупок. Доданий параметр withPublicFeedbacksOnly в getDGSPurchaseCount.
  • Вторинне сортування результатів пошуку після сортування по релевантности, по мітці часу, якщо запит був для будь-якого продавця, або по імені а потім по мітці часу, якщо для єдиного продавця.
  • Поліпшена продуктивність сторінки Marketplace, відображає кількість тільки для товарів на складі.
  • Збільшено значення за умовчанням, для терміну доставки покупцеві, до 168 годин (1 тиждень).
  • Включає повну інформацію про кулю в getPeers API якщо параметр includePeerInfo=true, щоб уникнути необхідність робити окремий запит getPeer на кожен вузол.
  • cumulativeDifficulty включений в JSON блоку.
  • Дозволяє транзакції підписаною в signTransaction пропускати перевірку допустимості підписуваних байтів транзакції, якщо доданий додатковий параметр validate=false. Це буде корисно при підписанні байтів транзакції на машині, на якій не завантажений повний blockchain, який зазвичай запобігає перевірці допустимості.
  • Дозволена відправка повідомлень, без вказівки одержувача.
  • Автоматичне додавання в blacklist вузлів версії 1.2.0 або старішою.
  • Поліпшення призначеного для користувача інтерфейсу API/test сторінок.
  • Змінений nxt-default.properties так щоб MVCC використовувався за умовчанням, щоб уникнути блокування бази даних і помилок тайм-ауту.
  • Jetty оновлений до версії 9.2.6. Якщо установку проводити шляхом розпаковування архіву поверх попередньої інсталяції, заздалегідь видалите теку lib, що видалити стару jetty бібліотеку.

34 Версія 1.3.4

20 Листопада, 2014

  • Ця версія фокусується на поліпшенні Nxt Marketplace (Магазин Цифрових Товарів), додаючи можливості поліпшеного огляду і пошуку.
  • Реалізований повнотекстовий пошук з використанням бібліотеки Lucene, з підтримкою H2. Стовпці таблиці, які на даний момент індексуються : asset.name, asset.description, goods.name, goods.tags, goods.description. Перестроювання пошукового індексу може бути реалізоване шляхом використання API відладки luceneReindex.
  • Повнотекстовий пошуковий запит підтримує параметри згідно із стандартним синтаксисом Lucene, який дозволяє використати логічні оператори AND, OR, фрази запити або маски запитів. Оператор запиту за умовчанням АБО (OR), щоб зробити І (AND) необхідно явно вказати AND між ключовими словами.
  • Доданий searchAssets API, який приймає параметр запиту і повертає активи, що мають назву або опис що відповідає запиту.
  • Доданий searchDGSGoods API, який приймає параметр запиту і повертає товар, що має ім'я, теги, або опис відповідає запиту. Отримані результати також можуть бути обмежені певним продавцем, тільки товаром який є в наявності, або товари тих, що містять тільки конкретний тег.
  • getDGSPurchases API тепер приймає необов'язковий параметр withPublicFeedbacksOnly. Якщо цей параметр=true, результат включає тільки покупки із загальнодоступними відгуками.
  • Доданий getDGSGoodsPurchases API для отримання списку закупівель конкретних товарів, необов'язково тих, у яких є публічні відгуки.
  • Доданий getDGSTags API, повертає усі теги товарів в DGS, відсортовані по кількості товару на складі з цим тегом і загальної кількості товарів з цією міткою. Приймає необов'язковий параметр inStockOnly, за умовчанням true, щоб отримати теги тільки для товарів на складі. У товару використовуються більше трьох тегів, теги млинцевої менше 3 символів і більше 20 символів ігноруються, а розбір тегів здійснюється за допомогою Lucene StandardAnalyzer.
  • Показує кількість покупок і кількість публічних відгуків в усіх відповідях API повертаючих JSON товару, якщо параметр includeCounts є false.
  • Включає загальну кількість Товарів, Продажів, і Тегів в getState API.
  • Додані getAccountAssetCount, getAliasCount, getDGSGoodsCount, getDGSGoodsPurchaseCount, getDGSPurchaseCount API, щоб мати можливість безпосередньо отримати відповідні підсумкові лічильники.
  • Для заповнення таблиці тегів у базі даних, blockchain зробить повторне сканування при першому запуску.
  • Оновлення jetty до версії 9.2.5. Якщо ви оновлюєте шляхом розпаковування архіву з файлами поверх існуючої інсталяції, заздалегідь видалите теку lib щоб видалити старі бібліотеки jetty.
  • Зміни інтерфейсу користувача :
    • Сторінка Marketplace тепер показує список тегів/категорій товарів, впорядкованих по кількості товарів в цій категорії.
    • Клацання по тегу повертає список товарів, що мають цей тег.
    • Пошук товарів тепер дозволяє шукати за ключовими словами які можуть розташовуватися в назві товару, описі або тегу.
    • Список товарів також відображає число завершених покупок, і для товарів із загальнодоступними відгуками відображає посилання яка відображає відгуки.

35 Версія 1.3.3

12 листопада, 2014

  • Виправлена помилка гарантованого балансу в getAccountLessors API.
  • Додана функція getAccountBlockCount API що повертає кількість сфорженных блоків аккаунтом.
  • Доданий параметр includeCounts у функцію getAssets API, для уникнення отримання непотрібних(зайвих) даних як те угоди, аккаунти і кількості трансферів.
  • Кэшируется баланс аккаунтів hallmarked вузлів, щоб скоротити кількість викликів бази даних.
  • Інші незначні поліпшення і виправлення помилок.
  • Виправлена помилка розшифровки товарів куплених в DGS. Виправлена помилка відгуків про куплені товари на DGS. Для повторного заповнення таблиці відгуків, ця версія проведе пересканирование blockchain при першому старті.
  • Доданий параметр hideDelisted в getDGSGoods API, за умовчанням false. Якщо він встановлений в true, зняті з публікації товари не будуть включені в результуючу відповідь. Цей параметр матиме ефект, якщо inStockOnly=false, оскільки зняті з публікації товари не знаходяться на складі.
  • Виправлення і поліпшення интерфейсу користувача . Додані налаштування тим і корпоративна тема
  • Приховано введення розміру комісії при відправці NXT в основному режимі, і встановлений в мінімальний розмір комісії.
  • Поліпшений інтерфейс сторінки http://localhost: 7876/test, дозволяє виконувати призначений для користувача виклик API, додано підсвічування синтаксису відповіді JSON.
  • Доданий getAccountAssets API запит, повертає баланс активів заданого аккаунта. Якщо в параметрі asset задані дані, буде повернений балан тільки для вказаного активу. На відміну від getAccount API, цей запит може також приймати параметр висоти, щоб повернути баланс активу із заданою висотою.
  • Доданий getAssetAccountCount API запит, повертає кількість аккаунтів тих, що володіють заданим активом, також з опциональной можливістю задавати параметр висоти.
  • Оновлення jetty до версії 9.2.4. Якщо ви встановлюєте шляхом розпаковування файлів поверх старої інсталяції, на початку видалите каталог lib, для видалення старих бібліотек jetty.

36 Версія 1.3.2

30 жовтня, 2014

  • Дозволяє ретранслювати транзакцій вже в непідтвердженому пулі.
  • Додана відладка clearUnconfirmedTransactions API, щоб викликати очищення непідтвердженого пулу транзакцій.
  • Показують коректні мітки часу в історії передачі активів.
  • Пробує встановити відкритий ключ облікового запису у бази цих транзакцій, виправляючи помилку в установці відкритого ключа для облікових записів, у яких ніколи не було витікаючої транзакції.
  • getAccountLessors API тепер повертає гарантований баланс кожного орендодавця, з висотою, визначеною в додатковому параметрі висоти. Формат поверненого json був змінений, щоб дозволити додавати властивість guaranteedBalanceNQT.
  • getPeers тепер приймає додатковий параметр "стан", щоб повернути тільки вузли в заданому стані. Можливі значення: CONNECTED, NON_CONNECTED, DISCONNECTED. Якщо вказаний параметр active=true він має пріоритет.
  • getBlock тепер приймає додатковий параметр "timestamp", щоб повернути останній блок із заданої мітки часу. Параметри до getBlock: "block", "height", "timestamp" обробляються в такому порядку черговості, тобто якщо і висота і мітка часу задані, висота використовуватиметься, а мітка часу проігнорується. Якщо не задані ніякі параметри, буде повернений поточний останній блок.
  • getState тепер приймає додатковий параметр "includeCounts", true за умовчанням. Якщо встановлено в false, кількість таблиць бази даних, які повільною отримують дані, не буде включена у відповідь.
  • getTrades, getAllTrades, і getAssetTransfers API тепер приймають додатковий параметр "includeAssetInfo", true за умовчанням. Якщо встановлено в false, ім'я активу і десяткові числа не будуть включені в результат Trade json, і із за відсутності необхідності отримати їх - прискорюється обробка запитів.
  • Доданий getBlocks API, повертаючи блоки, впорядковані по убуванню висоти і з використанням параметрів firstIndex, lastIndex для розбиття на сторінки. Обмежено виводом 100 блоків за один раз. Якщо includeTransactions - true, також включає повний JSON транзакції.
  • Поліпшений розподіл кеша H2. Якщо nxt.dbCacheKB не встановлений, кеш H2 змінюватиметься лінійно від 16MB для JVM heap розміром 160MB, до 256MB для heap розміром 640MB або вище. Це дозволить запускати систему на слабких пристроях без необхідності ручного управління і налаштувань для параметра nxt.dbCacheKB, а також запобіжить надмірному використанню пам'яті на пристроях з великою кількістю пам'яті.
  • Відключений SSLv3 протокол коли використовується SSL для API.
  • Поліпшення в інтерфейсі користувача :
    • Додано розбиття на сторінки (пагінація) на сторінці Blocks. Кількість рядків, що відображаються, на сторінці за умовчанням може бути задана в налаштуваннях клієнта.
    • Відображає баланс аккаунта у бічній панелі на усіх сторінках.
    • Поліпшені і виправлені сторінки торгівлі активами і історії переміщень активів.
    • Новий дизайн панелі управління, і поліпшена робота списку останніх транзакцій.

37 Версія 1.3.1

16 жовтня, 2014

  • Це - критичний bugfix, що усі, що використовують версію 1.3.0 повинні оновитися.
  • Виправлена помилка в завантаженні транзакції, яка породжувала ID транзакції і підпису для деяких транзакцій з неприпустимими значеннями ecBlock, змінюючи після збереження і перезавантаження з бази даних.
  • Звіт requestProcessingTime в JSON усіх відповідей API функцій.
  • Затримка завантаження блоків транзакцій з бази даних, поки вони не знадобляться.

38 Версія 1.2.9

16 жовтня, 2014

  • Це - критичний bugfix, що усі, що використовують версію 1.2.8 або більше ранню повинні оновитися.
  • Після установки 1.2.9, встановите властивість nxt.forceValidate=true в nxt.properties і перезапустите, щоб ревалидацию блоків які вже у базі даних. Після першого запуску встановите назад цю властивість в false.
  • Виправлена помилка в завантаженні транзакції, яка породжувала ID транзакції і підпису для деяких транзакцій з неприпустимими значеннями ecBlock, змінюючи після збереження і перезавантаження з бази даних.

Це усе відмінності від версії 1.2.8.

39 Version 1.3.0

14 жовтня, 2014

Це - перша версія, яка зберігає усі похідні об'єкти у базі даних, у відмінності від попередніх версій, де дані зберігалися тільки в пам'яті.

Похідні об'єкти це ті об'єкти які побудовані на основі вже наявної інформації в ланцюжках блоків і угод - тобто аккаунти, альясы, активи, товари, покупки, ордери, продажі. Зберігання їх у базі даних, а не в пам'яті означає що Біржа Активів і Магазин Цифрових Товарів можуть вільно розширюватися і збільшувати число активів, ордерів і товарів, більше не вимагаючи збільшення об'єму використовуваної пам'яті для кожного вузла.

Використання стандартних таблиць SQL бази даних, для зберігання цих даних, також дозволяє робити набагато складніші запити і дозволяє третім сторонам створювати і виконувати призначені для користувача запити з використанням цих таблиць безпосередньо, абсолютно не залежавши від NRS http API.

Зберігання станів усіх похідних об'єктів з поточної висоти, плюс їх попередній стан на висоті до 1440 блоків назад, дає можливість повністю позбавити від необхідності пересканирования blockchain при запуску, і при галуженні.

При оновленні з версії 1.2.8 і старіших, ця версія ініціює створення таблиць похідних об'єктів, що на швидкій машині займає приблизно 4 хвилини, але може зайняти більше часу залежно від Ваших апаратних засобів. Розмір бази даних під час процесу пересканирования знову виросте, але після того, як процес завершиться, база даних повинна знову зменшитися до розміру приблизно 550 Мбайтам.

При подальших перезапусках не відбуватиметься пересканирование, і час запуску тепер зменшений до декількох секунд. Також не проводитиметься пересканирование в часі виконання при появі нових блоків .

Таблиці похідного об'єкту зберігають невеликий об'єм, обрізуючи дані так, щоб зберігати тільки ті записи, які дозволяють відкотитися на 1440 блоків назад. Якщо Ви хочете зберігати і просити інформацію з ширшого діапазону, аж до блоку з висотою 0, це "обрізання" може бути відключене, шляхом установки параметра nxt.trimDerivedTables=false (значення за умовчанням - true) у файлі nxt.properties. Після зміни цього параметра відновлення даних в таблиці може бути ініційоване шляхом використання нового API запиту для сканування, який представлений нижче.

Кількість відкочуваних блоків за умовчанням може бути збільшена, при цьому продовжувати підтримувати "обрізання", для цього необхідно встановити в параметрі nxt.maxRollback більше значення (за умовчанням, і мінімально можливе, 1440). Це повинно забезпечити компроміс для тих, хто хоче зберегти історію із понад 1440 блоків за умовчанням, і якщо ви хочете уникнути штраф по продуктивності ніколи не обрізуйте таблиці похідних об'єктів.

Щоб зробити доступним збільшення кількості звернень до бази, максимальне число з'єднань з базою даних за умовчанням було збільшене до nxt.maxDbConnections=30, і тайм-аут блокування збільшився до nxt.dbDefaultLockTimeout=60 в nxt-default.properties.

Повільніші машини і публічні вузли з інтенсивним трафіком можуть випробувати тайм-аути блокування бази даних з налаштуваннями за умовчанням. Щоб це запобігти, може бути включений режим MVCC, додайте MVCC=TRUE до jdbc URL в nxt.properties. MVCC за умовчанням відключений, тому що при забезпеченні більш високого паралелізму при множинних одночасних з'єднаннях, хоч і запобігає тайм-аутам, він помітно повільніше в цілому і не настільки добре протестований.

Щоб допомогти з відладкою потенційних помилок в цій версії, значення рівня журналирования за умовчанням було встановлене в nxt.level=FINE в параметрі logging-default.properties, що приведе до росту записів даних в журнал.


Зміни API :

  • існуючий API тепер дозволяють додатково робити розбиття на сторінки, використовуючи firstIndex, lastIndex параметри:
    • getAccountBlockIds, getAccountCurrentAskOrderIds, getAccountCurrentBidOrderIds, getAliases, getAllAssets, getAllTrades, getAskOrderIds, getBidOrderIds, getAskOrders, getBidOrders, getAssetIds, getAssetsByIssuer.
  • параметр limit більше не приймається getAskOrderIds, getBidOrderIds, getAskOrders і getBidOrders API, оскільки тепер параметри firstIndex/lastIndex використовуються замість цього для розбиття на сторінки.
  • getAccountBlockIds на додаток до можливості розбиття на сторінки тепер повертає блоки в порядку убування, оскільки це зручніше і корисно коли новітні блоки відображаються на верху.
  • getTrades тепер приймає опционально додатковий параметр аккаунт, на додаток до активу, що дозволяє отримувати торгову історію для певного аккаунта, для усіх активів або тільки для певного активу.
  • getUnconfirmedTransactions і getUnconfirmedTransactionIds тепер також приймають аккаунт у форматі RS.
  • Trade JSON тепер включає ідентифікатори облікового запису покупця і продавця, висоту на якій торгівля сталася, а також ім'я активу, висоти на яких були заявки попиту і пропозиції була прийняті в blockchain.
  • Asset JSON тепер включає загальну кількість передач активу і число облікових записів, що містять актив.
  • parseTransaction тепер не лише повертає помилку при спробі проаналізувати неприпустимі байти транзакції або JSON, але і додає поле validate=false, плюс фактичне повідомлення про помилку, на додаток до проаналізованої транзакції JSON.
  • getState більше не включає загальний ефективний баланс.

Нові API запити:

  • getAccountBlocks - схожий на getAccountBlockIds, але повертає повний JSON блок. Якщо параметр includeTransactions - true, також включає JSON транзакції.
  • getAccountCurrentAskOrders і getAccountCurrentBidOrders - як getAccountCurrentAskOrderIds і getAccountCurrentBidOrderIds, але повертає повний JSON ордера.
  • getAllOpenAskOrders і getAllOpenBidOrders тепер замінюють getAllOpenOrders, але повертають ордери попиту і ордера пропозиції відповідно і підтримують firstIndex/lastIndex розбиття на сторінки.
  • getAssetTransfers - отримує інформацію про трансфер активу, обліковому запису або обох, відсортованих по убуванням висоти.
  • getAssetAccounts - приймає у виді параметр актив і повертає усі аккаунти, що містять цей актив з поточною висотою і кількість активу, яким кожен аккаунт володіє, відсортовані по убуванню кількості активу. Опционально може приймати додатковий параметр висоти, щоб мати можливість отримати утримувачів активу з попередньої висоти blockchain.
  • getAccountLessors - повертає аккаунти, які здали в оренду свій баланс вказаному аккаунту, опционально може приймати додатковий параметр висоти, щоб просити дані попередні заданій висоті blockchain.
  • longConvert - утиліта API, щоб перетворити між signed long ids використовувані у базі даних і unsigned long ids що представляються як рядки. Приймає ідентифікатор у будь-якому форматі і повертає обидві версії - без знаку і зі знаком.
  • getECBlock - повертає ecBlockId і ecBlockHeight, опционально може отримувати мітку часу, якщо не задано - поточний час.

Нові запити API відладки :

  • наступні запити використовуються тільки для цілей відладки і не є необхідними для щоденного використання. За умовчанням вони відключені, встановите в конфігурації параметр nxt.enableDebugAPI=true, щоб включити їх. Не включайте ці функції на загальнодоступному вузлі, де API доступний для будь-кого.
    • fullReset - видаляють і повторно завантажує повний blockchain.
    • popOff - приймає параметр numBlocks або висоту, і виштовхує цю кількість блоків або повертає до заданої висоти. Якщо "обрізання" таблиць включене (за умовчанням), в крайньому випадку 1440 блоку виштовхнуть. Таблиці похідних об'єктів відкочуються до заданої висоти і блоки і транзакції після цієї висоти будуть видалені.
    • scan - приймає параметр numBlocks або висоту, відкочує таблиці похідного об'єкту до заданої висоти і відновлює їх, повторно скануючи існуючий blockchain від заданої висоти. Не видаляє блоки або транзакції з blockchain, на відміну від запиту popOff. Запит на пересканирование більше ніж 1440 блоків коли табличне обрізання включене, зробить повне пересканирование, що стартує з висоти 0. При установці параметра в true, також повторно перевірить підписи, підтвердження блоків і транзакцій під час пересканирования.

DbShellServlet: Доступ до бази даних H2 з командного рядка в часі виконання тепер можливий за адресою: http://localhost:7876/dbshell Ця сторінка використовує інструменти роботи з H2, для можливості робити запити до бази даних в часі виконання безпосередньо з браузеру, без необхідності включати автоматичний режим сервера в jdbc URL. Цей сервлет включений, тільки якщо параметр nxt.enableDebugAPI=true, при цьому дуже не рекомендується вмикати цю можливість на публічному вузлі, оскільки ця функціональність дозволяє отримати повний доступ для читання і запису у базу даних.

Підвищення зручності користування http://localhost:7876/test - сторінки доступу до API.

Пакетні зміни: Для запобігання нерозуміння, чому хэши JAR -файлов ніколи не відтворні, файли класу нині розпаковуються в підкаталог класів після компіляції, замість того, щоб упаковуватися в nxt.jar файл. У run.sh і run.bat скрипти були змінені, щоб включити шлях до цього каталогу до класів, а не на nxt.jar файлу. Ті, хто як і раніше вважають за краще створювати nxt.jar файл, можуть легко зробити за допомогою сценарію того, що входить в jar.sh, змінивши шлях до класів. Зібраний nxt.jar файл все одно буде включений декількох подальших релизах, за допомогою коду перезавантаження при оновленні з більше ранніх версій, і тільки для цих цілей.

Інші внутрішні зміни:

  • Скрізь, ідентифікатори об'єктів, які раніше були Longs, тепер primitive longs, оскільки їх використання як ключі HashMap більше не є необхідним.
  • Збереження і повторна обробка непідтверджених транзакцій після відмови дозволу галуження
  • Поліпшено поширення непідтверджених транзакцій.
  • Множинні незначні поліпшення і оптимізація на заснована на профілізації результатів.
  • Об'єднання в коді для того, щоб щоб включити майбутні змінні комісії на основі типу транзакції і розміру транзакції.
  • Оновлений Jetty до версії 9.2.3.
  • Додана опція для відключення ретрансляції транзакцій, встановите параметр nxt.enableTransactionRebroadcasting в false (значення за умовчанням true).

Testnet: Цей випуск скине testnet blockchain назад до висоти 77431. Вузли Testnet, що залишаються на 1.2.8 вже знаходяться на різних галуженнях.

Немає ніякої крайньої необхідності для оновлення в основній мережі до версії 1.3.0., оскільки 1.2.8 і 1.3.0 версій можуть співіснувати в мережі без негативних наслідків включаючи галуження. Проте варто пам'ятати, що зміни локальної бази даних не обратимы, і якщо Ви оновитеся до 1.3.0 і вирішите повернутися до 1.2.8, то Ви повинні будете видалити теку nxt_db і повторно завантажити blockchain.

40 Версія 1.2.8

3 вересня, 2014

Зміни API :

  • Параметр timestamp в getAccountTransactionIds і getAccountTransactions тепер відноситься до тимчасової мітки блоку, в який транзакція була включена, а не самої транзакції. Транзакції сортуються в порядку убування мітки блоку і ідентифікатора транзакції, замість мітки транзакції. Це зроблено для того, щоб сортування відповідало порядку, в якому обробляються транзакції, і тому транзакції з більше ранніми тимчасовими мітками можуть з'явитися в blockchain після транзакції з більше пізніше влучною часу обробки, тим самим будуть ненавмисно пропущені під час навігації за списком транзакцій.
  • Запит getAccountTransactionIds і getAccountTransactions тепер опционально приймає параметр numberOfConfirmations, який може використовуватися, щоб отримати тільки транзакції у яких як мінімум numberOfConfirmations число підтверджень.
  • Запит getBlock API тепер опционально приймає параметр висота замість блоку, щоб отримати блок вказаної висоти. Якщо і блок і висота задані, параметр висоти ігнорується.
  • Запит getBlock API тепер приймає параметр includeTransactions, якщо встановлено в істину, повертається повний JSON транзакції замість тільки ідентифікатора транзакції.

Більше немає ніяких відмінностей між 1.2.7 і 1.2.8, таким чином, ті, хто покладається на "стару" поведінку API, можуть продовжувати використати 1.2.7 і зараз.

Зміни інтерфейсу користувача:

  • Додана опція для продавців щоб визначити повідомлення, що спеціально відформатувало, яке потрібно для додавання до акту платежу або переуступання активів.
  • Щоб активувати цю можливість, ви повинні встановити опис інформації свого рахунку в наступному форматі: #merchant: [0-9] + #
  • Цей приклад дозволить приймати тільки числове повідомлення.
  • Якщо повідомлення має бути заданої довжини, використайте таке рішення: #merchant:[a - zA - Z0 - 9]{4,8}#
  • Цей формат дозволить створювати повідомлення, у яких довжина від 4 до 8 символів, і що містять тільки алфавітно-цифрові символи.
  • Зверніть увагу на те, що регулярні вирази (regex) чутливі до регістра.
  • Усунена проблема з полем відкритого ключа, що не відображається при використанні контакту в полі одержувача.

41 Версія 1.2.7

26 Серпня, 2014

  • Більше не дозволяється створення pre-DGS блоків транзакцій, і ігнорують такі транзакції отримані від вузлів з NRS старих версій.
  • Поліпшення обробки виключень, перевірки транзакцій, реєстрації помилок.
  • Оновлений файл run.bat. У чорний список поміщаються вузли які на даний момент не доступні.
  • Перешкоджають тому, щоб сервер запустився якщо яка або із завдань запуску не выполненна.
  • Доданий додатковий "активний" параметр до API запиту getPeers. Якщо параметр = true, тоді повертаються тільки активні вузли (ті які в стані CONNECTED або DISCONNECTED).
  • Уникає непотрібних запитів DNS.
  • Більше не обробляється і не повертається параметр "коментар" в Переуступанні активів.

42 Версія 1.2.6

17 Серпня, 2014

  • Збереження непідтверджених транзакцій під час пересканирования замість того, щоб покладатися на здатність отримати їх знову від вузлів мережі.
  • Генерація блоків продовжиться у разі, коли вона призводить до збою із-за неприпустимої транзакції. Відвернені відмови генерації блоків із-за змін транзакції до мінімального розміру .
  • Ігнорується вага вузла при виборі випадкового вузла, коли захист клеймом (hallmark) відключений (за умовчанням вона включена). Коли захист клеймом включений, кількість nxt.maxNumberOfConnectedPublicPeers тепер грунтується тільки на захищених вузлах, тобто вузол продовжить намагатися з'єднатися з великою кількістю вузлів, поки це не буде досягнуто з'єднання з тими вузлами, з яким взаємодіє багато захищених вузлів.
  • Доданий запит вузлам мережі addPeers . Після відправлення getPeers запиту і обробки відповіді, вузол також відправить іншому вузлу усі свої адреси вузлів, у якого відсутні ці вузли в наборі вузлів з яким він пов'язаний, щоб поліпшити поширення рівноправних адрес через мережу.
  • Незначні виправлення.

43 Версія 1.2.5

13 Серпня, 2014

  • Додано gzip стискування цих вузлів мережі. Цей параметр включений за умовчанням і зробить завантаження blockchain швидше, але у разі, якщо це викликає додаткове навантаження на Ваш загальнодоступний вузол, може бути відключити його, встановивши nxt.enablePeerServerGZIPFilter=false в nxt.properties.
  • Доступна служба gzip стискування статичних ресурсів (HTML, javascript, css файли) Сервера API. Це прискорює завантаження UI гаманця з видалених серверів. Стислі .gz файли включені в пакет установки.
  • Підтримка gzip стискування відповідей від API Сервера, ця функція відключена за умовчанням. Це буде корисно при виконанні сервера на видаленій машині, для онлайн гаманців, і постачальники послуг, щоб включити цю функцію встановите nxt.enableAPIServerGZIPFilter = true в nxt.properties.
  • Виправлена помилку пересканирования на стороні клієнта, яка відображала застарілі дані в UI.

44 Версія 1.2.4

11 серпня, 2014

  • Виправлена важлива помилка що стосується довільних повідомлень і угод по переуступанню активів, перед блоком DGS.
  • Невеликі виправлення в інтерфейсі користувача.
  • Оновлення jquery до версії 2.1.1 і bootstrap до версії 3.2.0.

45 Версія 1.2.3

  • Усі повинні оновитися до версії 1.2.3 до блоку 213000.
  • Тим користувачам, які оновлюються з попередньої стабільної версії 1.1.6 або більше ранньою, дуже рекомендується ознайомитися з важливими змінами для версій 1.2.0e, 1.2.1e і 1.2.2e, які були введені в лінійці версій 1.2.х.
  • Виправлення незначних помилок.
  • ParseTransaction, signTransaction, і broadcastTransaction API тепер можуть приймати транзакцію у форматі JSON замість байтів транзакції.
  • Блок запуску DGS, перенесений з 210000 на 213000.

46 Версія 1.2.2e

Ця версія випущена тільки для тестування, тобто роботи з тестовою мережею. Початковий код не публікується. Журнал змін :

  • Цей випуск - все ще тестова версія, призначена для роботи з testnet. Будь ласка, відновите свої testnet вузли.
  • Виправлення в операційному управлінні версіями застосування і перевірці версій.
  • Доданий encrypt-to-self тип вкладень повідомлення. Будь-яка транзакція може містити таке вкладення, призначене для використання в приватних примітках, які може прочитати тільки посилач транзакції. Ця функція ще не підтримується в GUI.
  • Додана властивість nxt.isOffline. Якщо встановлено в true в nxt.properties, робота з вузлами мережі не почнеться, ніякі вузли не будуть завантажені у базу даних, і які або витікаючі з'єднання не будуть створені.

47 Версія 1.2.1e

Цей випуск все ще вважається експериментальним, але він також працювати на основній мережі. Запуск DGS встановлений на блок 210000 для основної мережі. Стабільна версія буде випущена до цього блоку, але усі біржі і веб-сайти повинні вже почати тестувати роботу з версією 1.2.1e, оскільки оновлення до стабільної версії 1.2.2 буде обов'язкове перед блоком 210000.

  • Множинні виправлення помилок в DGS і перевірці допустимості транзакцій Передачі Аліаса (Alias Transfer). Обмеження транзакцій для деяких типів псевдонімів і DGS до однієї за псевдонім / DGS купівлю за блок.
  • Транзакції з продажу аліасів тепер використовують порожнього одержувача замість генезисного, коли продаж аліаса відкритий для будь-якого покупця.Транзакція купівлі аліаса використовує параметр amountNQT замість priceNQT, оскільки у будь-якому випадку ціна зберігається в полі суми .
  • Запит GetDGSGoods тепер завжди пропускає викреслені зі списку товари.
  • Поліпшена обробка адрес IPv6.
  • Поліпшений інтерфейс http://localhost:7876/test, додана підтримка тегирования API запитів в множинних категоріях. Усе http API запити тепер класифіковані під окремими вкладками для простішої навігації
  • Зменшений час запуску, за рахунок паралельного запуску ініціалізації завантажених вузлів, визначення адрес, і початкового сканування blockchain.
  • Щоб поліпшити продуктивність бази даних, у транзакцій, у яких немає одержувача, тепер null замість ідентифікатора генезисного аккаунта як одержувач, в таблиці транзакцій. У таких транзакцій також не буде поля одержувача в їх JSON.
  • Додана підтримка розбиття на сторінки до API getAccountTransactionIds. Результати тепер повертаються відсортовані по мітці часу в порядку убування.
  • Доданий API getAccountTransactions також повертає json повної транзакції.
  • Оновлення інформації про вузли, для вже підключених вузлів, кожну годину.
  • Виклик setReuseAddress(true) для усіх jetty ServerConnectors.
  • Рефакторинг обробки приєднуваної транзакції. Додана підтримка версій транзакції і глобальних опцій. Транзакції перемкнуться на версію 1 у блоці DGS
  • Додані вкладення Повідомлення (Message) і Зашифровані Повідомлення (EncryptedMessage) які можуть бути додані до транзакцій будь-якого типу, і можуть включати текст або дані. Усе API, які створюють нову транзакцію тепер приймають додаткові параметри що дозволяють приєднувати Message або EncryptedMessage (чи обоє). Це позбавляє від необхідності створення нових типів транзакції для зашифрованих сполучень або платежів з повідомленнями.
  • Після епохального блоку DGS у транзакцій передачі активів більше не буде поля "коментар". Перемикайтеся на використання приєднуваних простих текстових "повідомлень" замість цього.
  • Додано управління версіями вкладень в транзакції. У транзакцій версії 1 і новіших, буде також поле для версії вкладень, яке дозволяє в майбутньому змінювати тільки один приєднуваний тип, наприклад, додавати поле закінчення терміну активу, без необхідності додавати новий тип транзакції
  • Додано вкладення PublicKeyAnnouncement. Воно будуть прийнято після блоку DGS, але реалізовано після блоку 215000. Після цього блоку транзакції з обліковим записом одержувача, у якого немає відкритого ключа, щоб використати таке вкладення, знадобляться оголосити і встановити відкритий ключ одержувача. Щоб додати PublicKeyAnnouncement, просто додайте "recipientPublicKey" параметр з hex - encoded рядком з відкритим ключем при відправці першої транзакції в той обліковий запис. Це безпечно (але марно) якщо продовжувати додавати той же самий recipientPublicKey для подальших угод c тим же самим рахунком.Але спроба встановити різні відкриті ключі для рахунку, у якого вже є відкритий ключ, приведе до відхилення транзакції.
  • Запит getAccountId може використовуватися, для отримання відкритого ключа для секретної фрази (навіть коли ця інформація ще не оголошена в blockchain).
  • Додана перша частина Економічної Кластеризації (Economic Clustering) - виявлення галуження. Після блоку DGS кожна транзакція включатиме посилання на останній blockId. На даний момент це використовується тільки для того, щоб виявити галуження, і транзакції, що відносяться до галуження, все ще не відхилені.
  • Наступний крок в Прозорому Форжинге (Transparent Forging) буде активований з блоку 215000: облікові записи, які пропускають свою чергу форжинга, не будуть в змозі форжить впродовж наступного однієї години.
  • Оновлений jetty до версії 9.2.2 і bouncycastle до версії 1.51.
  • Ця версія викличе скидання testnet, видаливши блоки і транзакції після блоку 117907.
  • Зміни клієнта :
    • Редизайн сторінки входу в систему.
    • Багатомовний інтерфейс. Деякі переклади неповні і допрацьовуватимуться у міру тестування.
    • Більшість форм тепер дозволяють Вам додавати зашифроване або публічне повідомлення до них.
    • Додана підтримка анонса відкритого ключа.
    • Перевірка довжини секретної фрази.
    • Опції, що автоматично активуються, при настанні блоку DGS.
    • Виправлень декілька помилок DGS.

48 Версія 1.2.0e

29 червня, 2014

  • Ця версія виключно для роботи в тестовій мережі ! Встановіть nxt.isTestnet=true у файлі nxt.properties.
  • Нові функції:
    • Магазин цифрових товарів (Digital goods store, DGS).
      • Нові http API виклики для створення транзакцій : dgsListing, dgsDelisting, dgsPriceChange, dgsQuantityChange, dgsPurchase, dgsDelivery, dgsRefund, dgsFeedback
      • Нові http API виклики для запитів до DGS: getDGSGood, getDGSGoods, getDGSPurchase, getDGSPurchases, getDGSPendingPurchases
      • Обмін товарами і повідомленнями між покупцем і продавцем шифруються за допомогою AES, також використовується gzip стискування перед шифруванням. Максимально допустимий розмір цифрового товару не повинен перевищувати 10240 байта після компресії і шифрування. Потрібно розуміти, що продаж "важкого" контенту типу відео файлів, відбувається через "продаж посилання на скачування", яке гарантовано поміститься в 10240 байт, а не через передачу відео файлу через DGS
    • Трансфер альясов.
      • Нові http API виклики: sellAlias, buyAlias
      • Продаж альяса може бути обмежений певним покупцем або відкритий для будь-якого покупця. Продаж альяса з ціною 0 розглядається як безпосередня передача від одного аккаунта іншому, і не вимагає окремої транзакції для купівлі альяса. Щоб змінити запит ціни, створіть нову транзакцію sellAlias. Щоб відмінити продаж, створіть нову транзакцію sellAlias для себе з ціною 0
      • Транзакція купівлі альяса, може тільки бути опублікована, тільки якщо псевдонім вже продається. Нині неможливо просто зробити ставку на альясы, які не продаються.
    • Зашифровані повідомлення.
      • Шифрування повідомлень за допомогою AES тепер підтримується на рівні ядра, таким чином, більше немає необхідності використати зовнішні механізми шифрування довільних повідомлень. Використайте довільні повідомлення тільки для передачі простого тексту, зашифровані повідомлення для конфіденційного обміну повідомленнями.
      • Нові API: sendEncryptedNote і readEncryptedNote. Максимальна довга повідомлення - 1000 байт, після стискування і шифрування.
      • Нові http API виклики: encryptTo/decryptFrom може використовуватися для шифрування і дешифрування довільних повідомлень передаваних до/від аккаунта. Але вони роблять тільки шифрування і дешифрування, але не відправляють повідомлення між обліковими записами.
  • Новий http запит rsConvert для конвертації номерів аккаунта у формат RS і назад.
  • Новий API getBlockId щоб отримати BlockID для заданої висоти блоку.
  • Поліпшене журналирование, для випадків, коли Nxt вбудований як бібліотека.
  • Незначні поліпшення: getState і getBlockchainStatus тепер також відображає ім'я застосування, блок JSON також відображає generatorPublickKey, getAccountId також приймає publicKey як параметр.
  • Оновлення jetty до версії 9.2.1.
  • Оновлення клієнта :
    • Доданий інтерфейс Магазину Цифрових Товарів (Digital Goods Store UI).
    • Доданий інтерфейс Торгівлі Альясами (Alias Trading UI).
    • Шифровані повідомлення.
  • Номери аккаунтів підтримуються тільки у форматі RS. Біржі і сервіси повинні перейти у формат RS Якнайскоріше.
  • Функції декодування токенов.
  • За умовчанням комісія (Fee) / дедлайн тепер приховані, відображаються за допомогою додаткового перемикача.
  • Показує застережливе повідомлення, якщо користувач знаходиться в галуженні (якщо його обліковий запис генерував, принаймні, останні 10 блоків).
  • Декілька додаткових параметрів налаштування (запам'ятати пароль за умовчанням, 12/24 формат відображенні часу).

49 Версія 1.1.6

27 червня, 2014

  • Виправлена логічна помилка в обробці непідтверджених транзакцій і виявленні операцій подвійних витрат.
  • Поліпшена продуктивність запиту getTransactions.
  • Доданий новий параметр nxt.debugLogUnconfirmed (за умовчанням = false), для управління логированием відладки непідтверджених залишків в аккаунті.
  • Поліпшений призначений для користувача інтерфейс тестового API сервлета, патч представленн Holger Drewes.

50 Версія 1.1.5

20 червня, 2014

  • Виправлений особливий випадок в обчисленні непідтвердженого балансу. Додані додаткові перевірки балансу рахунків.

51 Версія 1.1.4

  • http API для роботи з альясами почищений. Тепер існує тільки 2 API запиту, що дозволяють отримати інформацію про альясах :

getAlias
параметри: на вибір "aliasName" (ім'я альяса) або "alias" (id альяса)
відповідь: повний JSON альяса

getAliases
параметри: "timestamp" (опционально мітка часу) і "account" (id аккаунта, обов'язково)
відповідь: список альясов (повний JSON) що належать аккаунту, опционально фільтрується по мітці часу.

  • Старі getAliasId, getAliasIds, getAliasURI і listAccountAliases були видалені, оскільки вони надмірні, а нові запити повертають усю необхідну інформацію.
  • assignAlias був перейменований в setAlias, з "aliasName" і "aliasURI" параметрами.
  • Видалений getAssetsByName API.
  • API функція getAssetsByIssuer тепер приймає тепер приймає багатозначний параметр "account" і повертає і повертає список списків активів, випущених вказаними аккаунтами.
  • Для логирования використовується фреймворк slf4j. Спасибі ScripterRon за адаптацію нашої системи логирования для використання slf4j! Тепер логирование може настроюватися в conf/logging.properties, дивися conf/logging - default.properties для доступних параметрів і їх значень за умовчанням і для створення нового conf/logging.properties файлу з будь-якими призначеними для користувача налаштуваннями, при необхідності.
  • Незначні поліпшення DebugTrace - журнал подій Arbitrary Messages, посилача і одержувача, і згенерованого id блоку.
  • Поліпшення перевірки допустимості транзакції і логіки пересканирования.
  • Оновлення клієнта :
    • Більше не відображається повний список активів. Тепер ви повинні додавати активи в ручну або через ідентифікатор активу або через ідентифікатор аккаунта того, що випустило актив.
    • Миттєвий пошук активів в закладках (не вимагається натискати enter).

52 Версія 1.1.3

  • Відміна дескриптора початкового привласнення псевдоніма, щоб мінімізувати ресканирования. Очищення карти непідтверджених транзакцій не до, а після ресканирования.
  • Доданий параметр nxt.forceValidate для дозволу ре-валидации блоків і транзакцій при запуску.
  • Призначений для користувача Інтерфейс Клієнта :
    • Кодування аккаунтів у форматі reed solomon використовується за умовчанням.
    • Пошук по номеру аккаунта в кодуванні reed solomon.
    • Окремим кольором фону виділені активи користувача в панелі активів.
    • Окремим кольором фону виділені випущені активи у вікні аккаунта.
    • URL автопосилання в описі активу і даних альяса.
    • Відображає підказку при логіні, якщо виявлені оновлення NRS.
    • Додано налаштування попередження максимальної кількості передаваних активів.
    • Додано меню допомоги (help).
    • Коректні суми на сторінці своїх активів (my assets).
    • Пошук альясов на сторінці альясов.
    • Додані глобальні непідтверджені транзакції на сторінці транзакцій.
    • Відображає кількість активу, доступного для передачі у вікні передачі активів.

53 Версія 1.1.2

  • Розв'язана проблема появи галуження, що призводить до занадто частих сканувань.

54 Версія 1.1.1

  • Виправлена ​​проблема появи форка. Сподіваюся.
  • Включений guaranteedBalanceNQT (1440 підтверджень) в getAccount JSON.
  • UI Клієнта :
    • Виправлено ​​відображення AE в Safari.
    • Видалена частина логіки для пре-NQT періоду. А.Е. відображається за умовчанням.

55 Версія 1.1.0

  • Вкладення (аттачи) тепер збережені у базі даних як байтові масиви замість serializedobjects. У зв'язку з цим, матиме місце чергова реструктуризація бази даних після першого запуску цієї версії, що займе деякий час і дисковий простір, але після завершення роботи база даних зменшить ще сильніше (приблизно 25%).
  • У blockchain додана контрольна точка NQT_BLOCK.
  • Полагание на частково-канонічні підписи будуть запущені після NQT_BLOCK, щоб виявляти атаки податливості підпису, видалена логіка встановлююча унікальність хэша транзакції (за винятком підписів). Тільки повний хэш (включаючи підпис) тепер унікальні. Тому властивість "хеш" було видалено з JSON транзакцій, тепер повертається тільки "повний хэш".
  • Використайте повний хэш замість ідентифікатора для залежних транзакцій. Існуючі транзакції у базі даних будуть перероблені у рамках перетворення даних.
  • Залежні транзакції можуть посилатися на транзакції які були створені не більше 60 днів тому. Це обмеження поширюється на усі залежні транзакції в ланцюзі транзакцій, тобто обмеження накладається на усе транзакцій в одному послідовному ланцюжку. Крім того, довжина таких ланцюжків обмежується 10 транзакціями.
  • Прибрані деякі NotYetEnabled контрольні точки, які більше не актуальні. Видалена максимально багато застарілої логіки, яка связанна з кількостями обчислювані в NXT, оскільки усі нові транзакції будуть створені тільки у форматі NQT.
  • Розширений чорний список вузлів, які викликають RuntimeExceptions.
  • Угоди, повертані API функцією getTrades тепер йдуть зворотному порядку, спочатку йдуть найновіші.
  • Оновлення клієнта :
    • Непідтверджені транзакції відображаються на робочій панелі відразу.
    • Показ відповідного повідомлення під час ресканирования blockchain.
    • Історія торгів обмежена 50 останніми угодами.
    • Відображаються повідомлення про те що активи купуються/продаються.

56 Версія 1.0.3

11 травня, 2014

  • Account.getPublicKey() повинен повернути null якщо ключ ще не потрапив у блок. Пов'язана із завантаженням blockchain помилка "залипне" до 133933 блоку.
  • Збільшений таймаут, встановлений за умовчанням в nxt, - default.properties.
  • Інтерфейс користувача :
    • Виправлена помилка парсинга NQT.
    • Усунена проблема смуги прокрутки у біржі активів

57 Версія 1.0.2

10 травня, 2014

  • Додана API функція getUnconfirmedTransactions, яка повертає повний JSON об'єктів для усіх непідтверджених транзакцій, опционально фільтрується в параметрах аккаунта.
  • Доданий скрипт win - compile.sh для компіляції в Windows.
  • GetForging також показує "remaining" (очікуване) час до генерації блоку.
  • Очищення статусу генератора при ре-скануванні, ймовірно, це було причиною повторення проблеми при скануванні.
  • Оновлення клієнта :
    • Форжинг автоматично не стартує, коли завантажується blockchain.
    • Чекає закінчення завантаження blockchain перш ніж надати доступ до форм.
    • Виправлення в нотифікації оновлень.
    • Сторінки блоків і вузлів зроблені авто оновлюваними.
    • Відображає buy/sell (купівля/продаж) сповіщення для активів.

58 Версія 1.0.1

9 травня, 2014

  • Додана API функція getAssetsByIssuer для отримання усіх активів тих, що належать вказаному аккаунту.
  • Додані API функції getAskOrders і getBidOrders, що повертають повний JSON об'єктів.
  • Доданий BlockchainProcessor.getLastBlockchainFeederHeight(), щоб допомогти визначати статус завантаження. Зверніть увагу на те, що це можливо тільки коли діючий вузол також підтримує цю функцію, тобто має цю версію клієнта (1.0.1 або новішу).
  • Додане BlockchainProcessor.isScanning() для перевірки того чи відбувається в даний момент ре-сканування Blockchain.
  • Доданий API getBlockchainStatus, що містить вищезгаданий статус, використання цієї функції ефективніше чим API getState.
  • Розширений DebugTrace щоб реєструвати договір оренди аккаунта, початок і закінчення оренди, що гарантується залишки для кожного блоку, у файлі nxt - trace.csv
  • Додана підтримка на стороні сервера кодування Reed - Solomon номерів аккаунтів, завдяки ChuckOne, який перетворив javascript версію в java.

Усі виклики API, які приймають номери аккаунтів як параметр, можуть тепер використати або ідентифікатор аккаунта або адреси Reed - Solomon. Повертані дані JSON номери аккаунтів, що містять, тепер також можуть використати формат адрес Reed - Solomon.

  • Додані методи Crypto.getPrivateKey() і Crypto.curve(). Додана бібліотека Bouncy Castle, щоб використовуватися для шифрування AES замість обмеженого по складності, використовуваного за умовчанням механізму.
  • Доданий Account.getForgedBalanceNQT() для відстежування комісій за форжинг певним аккаунтом, доступний як forgedBalanceNQT в getBalance і getAccount.
  • Збільшений встановлюваний за умовчанням таймаут для блокування запитів бази даних до 10 сек., nxt.dbDefaultLockTimeout в nxt - default.properties.
  • Повторна перевірка пулу непідтверджених подвійних транзакцій після кожного нового блоку.
  • Підтримка для з'єднань IPv6, патч реалізував ScripterRon.
  • Оновлення jetty до версії 9.1.5. Переконайтеся що ви видалили старі jetty jar файли з тек, якщо ви проводите установку цієї версії шляхом розпаковування настановного архіву поверх встановленої версії.
  • Оновлення клієнта :
    • Вбудована підтримка кодування Reed Solomon. Зараз за умовчанням знаходиться в змозі відключена. Зайдіть в налаштування клієнта щоб змінити.
    • Додано повідомлення/попередження користувача, коли кількість NXT або комісія в NXT перевищує встановлений в налаштуваннях максимум.
    • На основній панелі доданий баланс форжинга.
    • У Біржа Активів тепер доступний пошук.
    • Прогрес завантаження Blockchain використовує новий API.
    • Відображає (непідтверджену) транзакцію на основній панелі відразу після підтвердження форми.

59 Версія 1.0.0

28 квітня, 2014

  • Старий призначений для користувача інтерфейс NRS UI тепер за умовчанням відключений. Увага: доступ до нового призначеного для користувача інтерфейсу клієнта доступний за адресою http://localhost:7876
  • Додані події оренди засобів аккаунта (Account lease events), "Слухач" може відстежувати події LEASE_SCHEDULED, LEASE_STARTED і LEASE_ENDED. Цим на даний момент можна скористатися тільки з Java API.
  • Невеликі виправлення. Обійдена помилка при нової перевірки транзакцій при скануванні blockchain. Видалена перевірка NotYetEnabled для старих блоків, які вже пройшли перевірку.
  • Доданий файл README.txt, в нім ви зможете прочитати детальну інструкцію після інсталяції і конфігурації клієнта.

60 Версія 0.9.10e

27 квітня, 2014

  • Додана нова API функція getAllAssets яка повертає усі активи (Assets), і API функція getAssets яка бере множинні параметри активу і повертає актив (Assets) з відповідним assetIds.
  • Додана API функція signTransaction, яка бере unsignedTransactionBytes і secretPhrase і повертає підписаний transactionBytes, ідентифікатор транзакції, повний хеш і підписаний хеш. Транзакція не передається.
  • Щоб запобігти атакам "відмова в обслуговуванні", транзакції, які повинні знаходитися в кулі непідтверджених транзакцій, чекаючи вступу пов'язаних транзакцій, будуть "заряджені" 100 NXT як поворотним депозитом. Ця сума віднімається з непідтвердженого балансу облікового запису, коли транзакція приймається в пул непідтверджених транзакцій, і повертається назад, коли транзакція або підтверджується, або збігає термін очікування і вона видаляється з пулу.
  • Доданий клієнт від Wesley з новим призначеним для користувача інтерфейсом, доступний за умовчанням за адресою http://localhost:7876

61 Версія 0.9.9

25 Квітня, 2014

  • У усіх http APIs які використовуються в нових транзакціях тепер доступний опциональный параметр "broadcast". Якщо його встановити в значение"false", транзакції не передаватимуться, якщо встановити будь-яке інше значення транзакції передаватимуться. Не підписані транзакції не передаватимуться. Підписані і не підписані байти завжди повертаються в JSON транзакції, таким чином, підписані байти можуть бути передані вручну пізніше.
  • Незначні виправлення помилок в обробці ідентифікатора транзакції, на яку посилаються.
  • Розрахунок повного хэша транзакції (а отже і id transaction) був змінений, ефект від змін набуде чинності з NQT_BLOCK. Замість того, щоб використати підпис в якості частини байтів, по яких вичислений хэш, тепер використовується sha256 підпис.
  • Після NQT_BLOCK, вищезгадана зміна дозволить використати простий спосіб реалізувати умовну оренду, покладаючись на функції транзакцій, на які посилаються, і яку ми вже маємо:
    • Аліса готує і підписує транзакцію A, але не публікує її(шляхом установки параметра broadcast=false, параметр введений в систему з цієї версії). Вона посилає Бобу байти не підписаної транзакції, повний хэш транзакції, і підписаний хэш. Усе це міститься в JSON результаті виклику API. (Увага: упевніться, що ви не послали байти підписані транзакції або сам підпис, оскільки тоді Боб може просто вчинити угоду сам).
    • Боб готує, підписує і публікує транзакцію б, встановивши параметр referencedTransactionFullHash в значення повного хэша транзакції A наданих Алісою. Він може перевірити, що цей хэш дійсно належить транзакції, наданій Алісою, використовуючи нову API функцію calculateFullHash, який бере байти не підписаної транзакції і хеш підпису (обоє з яких Аліса також відправила Бобу). Він може також використати API функцію parseTransaction, щоб декодувати усі неподписаные байти і проглянути усі поля транзакції.
    • Транзакція б потрапляє в пул непідтверджених транзакцій, але, до тих пір, поки але, поки транзакція A все ще відсутня, Транзакція б не буде підтверджена, тобто не буде включена в blockchain. Якщо транзакція А ніколи ніколи не буде підписаної, транзакція б кінець кінцем буде скасована по дедлайну - таким чином, Боб повинен упевнитися, що встановив досить довгий крайній термін, такий як на приклад 1440 хвилин.
    • Жодним способом, в кулі непідтверджених транзакцій, Боб не може відмінити транзакцію б. Тому тепер Аліса може безпечно публікувати свою транзакцію A, просто широкомовно передаючи байти підписаної транзакції, цим вона зробить перший крок в угоді. Після того, як Транзакція A буде включена в blockchain, при наступній генерації блоку в нього буде включена транзакція б Боба.
      • Зверніть увагу на те, що, вищезгадана схема досить хороша для простого умовного депонування, але потрібно пам'ятати, що blockchain не реалізує механізм що забезпечує, що якщо транзакція A буде підтверджена, то транзакція б буде також підтверджена. Це може статися із-за галужень і реструктуризації blockchain, що приведе до того, що транзакція б ніколи не отримає шанс бути включеною у блок і залишиться непідтвердженою у зв'язку із закінчення терміну дедлайну. Проте для Боба практично не можливо навмисно викликати таку низку подій і перешкоджати тому, щоб транзакція б була підтверджена.
  • Оскільки були проведені зміни в механізмі обчислення ідентифікатора транзакцій, тестової мережі, NQT_BLOCK був перенесений на 76500, який приведе до скидання і незначним видаленням блоків після 76000.
  • У основній мережі NQT_BLOCK буде активований з блоку 132.000, FRACTIONAL_BLOCK c 134.000, ASSET_EXCHANGE_BLOCK c 135000. Будь-які помилки в NQT або AE мають бути знайдені і виправлені до вказаних блоків.
  • Дедлайн для оновлення до версії 0.9.9 - це блок 130.000, з цієї миті стане доступна функціональність "безпечна передача засобів аккаунта в оренду". Вузли версії 0.8.13 ймовірно створять галуження в мережі після вказаного блоку. Вузли версії 0.7.7 найбільш вірогідні "винуватці" галуження.
  • Рішення засновані на базі API версії 0.9 використовують кількісні виміри тільки в NQT, будь-який клієнт, вебсайт, або біржа, використовуючі API версії 0.8, все ще використовують кількісні виміри в NXT, тому до блоку 130.000 необхідно відновити їх, і почати використати NQT API 0.9. Інакше, рішення використовуючі API версії 0.8.13, як я раніше говорив, породять галуження, після настання вказаного блоку.

62 Версія 0.9.8e

20 Квітня, 2014

  • Цей релиз тільки для мережі testnet. Використання цієї версії у черговий раз викличе скидання тестової мережі (testnet), таким чином, необхідно, що б усі вузли testnet оновилися до цієї версії.
  • Реалізовано перемикання на використання повного 256-розрядного хеша для ідентифікаторів транзакції, на які посилаються. Повне перемикання на використання повного хеша буде реалізовано тільки після NQT_BLOCK, оскільки це вимагає складного галуження, тому зміна у форматі байтів транзакції від типу long до 256-розрядного хешу для транзакцій, на які посилаються, як тепер планується, станеться до моменту NQT_BLOCK.
  • При першому запуску, буде виконані деякі оновлення структури бази даних а також будуть видалені блоки testnet після 63000. NQT_BLOCK для testnet, тепер буде встановлений в 76000, таким чином, ми маємо останню можливість для тестування не дробових кількостей, плюс поточні зміни транзакцій, на які йдуть посилання до і після NQT_BLOCK. Оренда засобів тепер буде включена в testnet c блоку 75000. Після скидання, testnet запуститься з блоку 74590, таким чином, у нас буде приблизно 1000 блоків перед NQT_BLOCK в testnet.
  • транзакції fullHash (повний, 256-розрядний хеш), включають підпис тепер також доступну в JSON транзакції, на відміну від транзакцій з хешем, який ми нині використовуємо. Також можливо отримати транзакцію на основі свого fullHash, використовуючи getTransaction.
  • параметр http API referencedTransactionId був замінений на referencedTransactionFullHash, з hex - encoded 256-розрядним повним хешем.
  • JSON транзакцій тепер також включає referencedTransactionFullHash, якщо результат не null, і на даний момент також включає referencedTransactionId. Поки NQT_BLOCK не пройдений, користувачі цього API вимушені перевірити обидва параметри,

оскільки для транзакцій до NQT_BLOCK не можна гарантувати, що ReferencedTransactionFullHash буде доступний, тому що це не є частиною формату байтового масиву транзакції. Після того, як NQT_BLOCK буде пройдений, API буде змінений так, щоб завжди включати referencedTransactionFullHash в JSON (також і для старих транзакцій), а referencedTransactionId буде видалений.

  • Доданий nxt.usePeersDb в nxt-default.properties, включений за умовчанням. Це повинно відключити використання збережених рівноправних адрес, буде корисно тільки в тестових цілях.

63 Версія 0.9.7

18 Квітня, 2014

  • Доданий parseTransaction API, який бере transactionBytes і повертає JSON транзакції, включаючи логічну змінну, що відповідає за перевірку коректності підпису. Зверніть увагу на те, що інтерпретація і перевірка допустимості байтів залежать від поточної "висоти" блоку - відбувається це у блоках до або після NQT_BLOCK.
  • Щоб уникнути можливості стати залежними від декількох централізованих керованих загальнодоступних вузлів, усі відомі вузли тепер регулярно зберігаються у базі даних. Коли база даних створюється з нуля, у базі даних знаходиться близько 200-300 спочатку прописаних загальнодоступних вузлів. Після цього, в мить, коли ваш вузол вибирає нові вузли-партнери в мережі, він також зберігає їх в таблиці і видаляє ті вузли, які поміщені в чорний список а також ті, які не доступні по вказаному у базі даних адресі. Це дозволяє отримувати актуальний і незалежний список партнерських вузлів мережі, для кожного окремого вузла.
    • Ця функція опциональна, і параметр nxt.savePeers може бути відключений шляхом установки його значення на fale в nxt.properties для тих користувачів, які не хочуть зберігати на своїх жорстких дисках дані трасувань, зберігаючі дані про з'єднання з партнерськими вузлами, щоб запобігти можливим мережевим кореляційним атакам.
    • Параметри nxt.wellKnownPeers і nxt.testnetPeers все ще використовуються, для тих вузлів, які додаються у базу даних при запуску.

64 Версія 0.9.6

17 Квітня, 2014

  • Перевірка облікової запис одержувача орендованих засобів, на наявність відкритого публічного ключа до того як буде прийнята транзакція оренди. Ця перевірка викличе деякий незначний відкат в testnet, оскільки блоки, такі транзакції, що містять, будуть видалені.
  • Оптимізація оренди засобів. Негативні величини гарантованого балансу зберігаються тільки для внутрішніх обчислень, а ефективний баланс тепер завжди позитивний. Інші незначні виправлення і поліпшення.
  • Оренда засобів ефективного балансу буде включена в основній мережі починаючи з блоку 130000. Це означає, що усі вузли мають бути оновлені до версії 0.9.6 або більше пізніше до цього блоку, інакше отримаємо галуження. Ми повинні цього моменту знайти і виправити будь-які серйозні помилки у функціоналі оренди засобів. І усі клієнти, які використовуватимуться в основній мережі, повинні будуть перемкнутися на обробку сум в NQT до цього, оскільки у версії 0.9 API можуть тільки приймати суми в NQT. Фактичний номер блоку переходу до NQT буде визначений пізніше.

65 Версія 0.9.5e

14 Квітня, 2014

  • Доданий виклик http API leaseBalance, який дозволяє реалізувати оренду ефективного балансу. Параметр "період", вказується як кількість блоків, яким обмежується тривалість оренди. Мінімальний період це 1440 блоків, максимальний 32767 блоків. Оренда починається тільки після 1440 блоків після того, як запит leaseBalance був виконаний. Якщо ви вже здали в оренду частину своїх коштів, і створили ще один запит на подання оренди засобів, нова оренда стане активною після завершення попередньої, але не раніше чим 1440 блоків, вважаючи від поточного блоку.
  • Під час оренди, гарантований баланс облікового запису орендодавця, після 1440 підтверджень, додається до ефективного балансу облікового запису одержувача/орендаря.
  • Зароблена комісія в ході форжинга поступає на аккаунт орендаря (одержувача), при цьому в blockchain відсутні механізми які дозволяють автоматично перераховувати цю комісію на аккаунт орендодавця, таким чином, власник пулу (орендар) повинен сам планувати дії з розподілу отриманого прибутку (комісії) усім орендодавцям.
  • Інформація про орендарів і орендодавців додана у вигляді JSON до результату виклику API getAccount.
  • Ця функція буде активована в testnet з блоку 73000 для повноцінного тестування функціональності

66 Версія 0.9.4e

14 квітня, 2014

  • Доданий Магазин Цифрових Товарів (Digital Goods Store), Ефективний баланс для оренди (передача у безпечну оренду своїх засобів), і Hub Terminal анонса новин. Вони все ще не протестовані, відсутні ті, що відповідають http API, і нині відключені навіть на testnet, так, щоб не заважати тестуванню Asset Exchange (Біржа Активів).
  • Реалізовані канонічні підписи і канонічні відкриті ключі після NQT_BLOCK.
  • Доданий http API виклик setAccountInfo, який використовує інформацію про обліковий запис транзакції, щоб отримати ім'я і властивості облікового запису. Ті поля, якщо встановлено, будуть повернені як частину getAccount JSON. Інформація про обліковий запис буде включена в NQT_BLOCK, таким чином, що це повинно почати працювати в тестовій мережі після цієї версії.
  • Виправлена помилка в Asset Transfer при передачі кількості активу, яка запобігала підтвердженням транзакції в testnet.
  • Дві нові властивості в nxt - default.properties, для спрощення експорту nxt.trace в csv файл:
    1. Знак сепаратора для журналу трасування
      • nxt.debugTraceSeparator=\t
    2. Символ лапки для журналу трасування
      • nxt.debugTraceQuote="
  • Jetty був оновлений до версії 9.1.4, і Н2 до версії 1.3.176 . Не забудьте видалити старі версії з теки lib, або якщо ви робите оновлення, просто розпакуйте файли архіву поверх існуючих.
  • Виправлення і поліпшення в механізмі перевірки угоди. Існуючі угоди перевірятимуться один раз при першому запуску цієї версії, яка може привести до деякої турбулентності в мережі testnet коли недійсні блоки видалятимуться.

67 Version 0.9.3.1e

09 Квітня, 2014

  • Виправлені помилки в парсинге транзакцій Активів, що Випускаються. Вузли Testnet мають бути оновлені.

68 Version 0.9.3e

07 Квітня, 2014

  • Видалені усі повертані значення quantityINT, balanceINT, amountNXT, priceNXT, feeNXT з JSON API, і видалена підтримка парсинга INT і NXT параметрів. Тепер в усіх блоках використовується тільки NQT (для сум) і QNT (для кількостей).
  • Активований запуск цього функціонала в основній мережі. NQT_BLOCK почне працювати починаючи з 150000 блоку для основної мережі, до вказаного моменту дробові суми залишаються відключеними. Цілі NXT суми і комісії повинні працювати нормально в основній мережі, також ця версія має бути сумісна з вузлами мережі версії 0.8.13. ПРИМІТКА: Вузли версії 0.7.* більше не підтримуються. Усі користувачі Nxt повинні відновити свої клієнти до стабільної версії 0.8.13, і бути готовими оновитися до версії 0.9 як тільки буде випущена стабільна версія цієї лінійки.
  • Оскільки NRS javascript UI більше не допрацьовуватиметься, і ні у кого немає часу, щоб перетворити його для використання бібліотеки BigInteger javascript, він все ще прийматиме приймає суми і комісії в NXT, які будуть автоматично перетворені в NQT на стороні сервера. Повертані значення зберігаються в NQT і можуть привести до переповнювання в javascript для сум тих, що перевищують 2^53 NQT (приблизно 90 мільйонів NXT). Таке переповнювання може вплинути тільки на UI, оскільки введення відбувається як рядки і перетворені в longs на стороні сервера. Проте, для транзакцій такого розміру краще залишитися на стабільній версії 0.8.13 або використати сторонні клієнти.
  • При першому запуску в основній мережі, як це відбувалося в тестовій мережі, буде проведено оновлення полів кількості і сум в таблицях блоків і транзакцій до NQT, що займе деякий час. В ході цього процесу, об'єм бази даних тимчасово сильно збільшиться, приблизний до 1 GB. База даних зменшиться при перезапуску клієнта (що також займе деякий час), до приблизно 180 MB.

69 Version 0.9.2e

06 Квітня, 2014

  • Додана підтримка дробового виміру кількості активів. Насолоджуйтеся черговим скиданням testnet
  • При створенні активу, максимально допустима кількість цифр після цілої кількості активу, може бути вказаний в параметрі "decimals" (допустимі значення від 0 до 8). Наприклад, це може бути 2 - для валюти євро, і 8 для Bitcoin.
  • Подібно до цін, кількості активу можуть бути визначені будь-яким зручним чином:
    • у quantityQNT, чисельні показники вказується в мінімальній одиниці виміру ("quant")
    • у quantityINT, в цьому випадку чисельні показники вказуються в цілих одиницях активу (важливо пам'ятати що і в цьому випадку також може вказуватися дробова частина).

Наприклад, 9.97 доларів США можуть бути виражені: в quantityINT = "9.97", або як quantityQNT = "997", встановивши "decimals"=2 наприклад для долара США.

  • Відповіді JSON, кількість, що містять, або баланс активу, знову повертають quantityINT і quantityQNT, як рядки.
  • При розміщенні ордера на купівлю або продаж активу, якщо вказаний quantityQNT, ціна інтерпретується так, щоб можна було використати одиниці виміру QNT (незалежно від того чи була ціна визначена в NXT або в NQT).

Якщо вказується quantityINT, ціна інтерпретується, щоб можна було використати одиниці виміру INT. Наприклад, ордер пропозиції на quantityQNT = "300", priceNXT = "2", за актив в доларі США інтерпретуватиметься як 3.00$ і 1 цент = 2 NXT, тобто 200 NXT за один долар, разом 600 NXT. Якщо параметри будуть представлені як quantityINT = "7", priceNXT = "50", то ордер буде на 7.00$ по 50 NXT за один долар, на загальну суму 350 NXT.

  • Внутрішній ордер, обчислюючий і відстежуючий баланс активу, на рахунку завжди буде представлений в quantityQNT. Незручний побічний ефект на даний момент - це то що, поміщаючи ордер, використовуючи quantityINT, розрахункова ціна в NQT для однієї одиниці QNT має бути цілим числом. Таким чином, Ви не можете розмістити ордер для quantityINT = "1", priceNXT = "10.12345678" (чи еквівалентно priceNQT = "1012345678"), тому що тоді ціна однієї quantityQNT буде 10123456.78 NQT. priceNXT матиме бути також 10.12345600 або 10.12345700. Якщо це збиває з пантелику, вкажіть в ордері quantityQNT = "100", priceNQT = "10123456".

70 Версія 0.9.1e

03 арпеля, 2014

  • Завжди повертають суми і в NXT і в NQT, представленому в JSON як рядки.
  • Рефакторинг коду генерованого JSON, видалений getJSONObject з блоків і транзакцій.
  • Операції некоректні блоки, що породжують, завжди видалятимуться з пулу непідтверджених транзакцій.
  • Усунена помилка переповнювання в обчисленні ваги hallmark.
  • Усунена помилка JSON парсинга.
  • Усі вузли testnet мають бути оновлені до цієї версії.

71 Версія 0.9.0e

03 Квітня, 2014

  • Це - експериментальна версія для попереднього ознайомлення, який працюватиме тільки в testnet. Ця версія не працюватиме в основній мережі Nxt тому не намагайтеся його запустити в основній мережі. Важливо, щоб усі вузли тестової мережі (testnet) оновилися до версії 0.9.0e, для того, щоб усі могли почати тестувати роботу з дробовими частинами NXT.
  • Усі транзакції і комісії почнуть оброблятися в NQT, (це 10^-8 NXT), починаючи з NQT_BLOCK, який для випробувальної мережі встановлений в значення 63000 блоків. Перехід на дробові NXT в основній мережі буде реалізований у декілька етапів, щоб зберегти сумісність із старішими версіями, і для того, щоб не перезавантажувати основний blockchain. Це рішення також буде протестовано в тестовій мережі testnet, тому найближчим часом логічно чекати ще одне скидання testnet. Для сьогоднішньої версії testnet, існуючі активи будуть знову видалені, blockchain скинутий назад до блоку 63000, після чого дробові суми і обмін активів буде доступний починаючи з блоку 63000.
  • Подробиці про цю версію:
    • Усередині усі суми обробляються в NQT, використовуючи Java longs (64 біта). Суми рахунків і комісії у базі даних також будуть перетворені в NQT, і будуть збережені як BIGINT. Ці зміни будуть застосовані для усіх старих (перед NQT_BLOCK) і нових операцій. Тільки після підтвердження підпису, старі операції і блоки будуть представлені у вигляді 32 бітових записів замість типу long (64 біта) для рахунків і комісій. Для усіх вузлів, з метою сумісності, операція JSON для старих операцій міститиме суми і в NQT і в NXT.
    • Щоб запобігти помилці переповнювання, усі операції складання і множення longs зроблені з використанням методів тестування попередньої умови, Convert.safeAdd і Convert.safeMultiply, які перевіряють на можливе переповнювання перш, ніж зробити саме обчислення.
    • Уся відповідні Java API былb перейменовані, щоб вказати, що суми повертаються в NQT, за винятком getEffectiveBalanceNXT, який використовується тільки при форжинге і там необхідно вести облік в NXT.
    • http API був змінений, щоб використати суми або в NQT або в NXT, з дробовими сумами, отриманими як рядки в параметрах запиту http, і потім перетворені безпосередньо до longs. Повертані об'єкти JSON використовують тільки NQT. Усі відповідні http назви параметрів і параметри JSON були змінені, щоб вказувати, являються вони в NQT або NXT.
    • Ціни активів (AE) також змінені, щоб використати NQT замість NXT -центов. Але я не перевірив біржові угоди по активах, я встиг тільки перевірити прості операції по передачі засобів, тому очікуються помилки.
    • Дробові кількості активів ще не впроваджені.

72 Версія 0.8.13

01 Квітня, 2014

  • Виправлена помилка дублювання хеша транзакцій в кулі непідтверджених транзакцій.
  • Додано поле коментаря до транзакції типу Переуступання/Трансферу активів, може містити до 1000 символів. При першому запуску цієї версії станеться видалення усіх блоків на testnet, що розпочинаються з першого блоку того, що містить транзакцію переуступання/трансферу активів.
  • Додана додаткова фільтрація по рахунку в getUnconfirmedTransactions API.
  • Доданий API запит getAllOpenOrders.
  • Додані Слухачі AccountAsset, щоб відстежувати повідомлення про актив для балансування змін, вказує на актив, який змінив баланс.
  • Система повертає помилку при спробі широкомовно передати транзакцію з недостатнім об'ємом коштів, і не намагається повторно ретранслювати такі транзакції.
  • Поліпшена реалізація DebugTrace і VerifyTrace.
  • Jetty оновлений до версії 9.1.3.

73 Версія 0.8.12

21 березня, 2014

  • Ця версія тільки для тестування і відладки. Якщо вам не цікаве тестування - немає необхідності оновлюватися.
  • Доданий DebugTrace.java, який використовується для моніторингу усіх змін у балансі аккаунта і балансі активів, і усіх подій, які викликають зміни, - транзакції, генерація блоків, ордерів на купівлю, випуск активів, продаж активів, відміна ордерів на купівлю, торгівля.
  • Це нововведення використовує 2 нових властивості в nxt - default.properties:
    • nxt.debugTraceLog=nxt.trace
    • nxt.debugTraceAccounts=
  • Для активації трасування балансу аккаунта, встановите в параметрі nxt.debugTraceAccounts tсписок ID аккаунтів для моніторингу, розділені через "; ". Усі дані повинні записуватися в nxt.trace, або файл визначений в nxt.debugTraceLog. Значення/дані в цих файлах записуються з tab розділенням, для того, щоб просто імпортувати в табличний формат.
  • Тепер можливо відстежувати баланси усіх ваших аккаунтів, шляхом установки nxt.debugTraceAccount=* .
  • При рестарті а також при ре-скануванні бази даних, балка файл nxt.trace log тепер перезаписується.
  • Доданий VerifyTrace.java, який займається парсингом файлу nxt.trace (чи файлу вказаного як аргумент в командному рядку), і виконує деякі перевірки. Нині це рішення перевіряє, що для кожного рахунку який ви вказали для перевірки, підсумковий баланс обчислюється як загальну кількість усіх змін, які впливають із цього приводу, і зареєстровані в журналі nxt.trace. Також перевіряє, що для кожного активу, загальна кількість кількість активу на усіх рахунках відповідає первинній кількості випущеного активу. Ця перевірка, як можна припустити, буде не вдалою, якщо не усі рахунки, яким належить частина активу, будуть включені в debugTraceAccounts.
  • Для запуску VerifyTrace, використайте verify.sh скрипт. Nxt сервер має бути зупинений на початку, щоб журнал nxt.trace не продовжував оновлюватися, тоді як VerifyTrace перевіряє його.
  • Непідтверджений баланс і непідтверджений баланс активів будуть логироваться, але не верифицироваться VerifyTrace, тому що присутність відкритих або частково виконаних замовлень робить таке обчислення дуже складним. Швидше за все простіше використовуватиме електронні таблиці, чим реалізувати такі обчислення.
  • Додана подія TRADE, що спрацьовує коли відбувається торгова операція. Зверніть увагу на те, що ця подія відбувається перед оновленням залишків на рахунках.
  • Додані BEFORE_BLOCK_APPLY і BEFORE_BLOCK_UNDO події, що спрацьовують перед відповідними операціями в обробці блоку.

74 Version 0.8.11

19 березня, 2014

  • Введена підтримка не унікальних найменувань активів
  • Доданий новий API getAssetsByName який повертає список усіх активів що містять в назві assetName.
  • Доданий новий API getAllTrades API який повертає усі торги, які були розпочаті після вказаного часу (contributed by Antanst).
  • Поліпшені/оптимізовані JSON відповіді для деяких API викликів : getAsset тепер також повертає numberOfTrades. getAccount тепер також повертає unconfirmedBalance. broadcastTransaction тепер також повертає хеш транзакцийnow. getAsk/BidOrder тепер також повертає "висоту" ордера. Продуктивність getTrades сильно підвищена а також тепер повертає id блоку для кожного торгу.
  • Явно зупиняє усе jetty servers при виклику Nxt.shutdown().
  • Escape текст вставлений як вузол або анонсовану адресу вузла в html код NRS клієнта, для запобігання кросс-сайтового скриптинга і атак із заражених вузлів.
  • Тепер Crypto.sign() не генеруватиме некоректні підписи, немає необхідності робити додатковий виклик verify() після підписання блоку, або при багатократній спробі підпису транзакції.

75 Версія 0.8.10

15 березня, 2014

  • Додана поліпшена перевірка транзакцій. Блоки які були прийняті і визнані некоректними для подальшої обробки ким або, будуть видалені з бази даних.
  • Поліпшена перевірка мінімальної комісії за різні типи транзакції.
  • GetAccount API тепер також повертає непідтверджений баланс активу.
  • BroadcastTransaction тепер перевіряє підпис отриманої транзакції перш ніж її почати передавати через широкомовний запит.
  • Видалений код більше не використовуваного фиржинга. Генерація блоків до 30.000 (transparent forging phase 1/прозорий форжинг 1 фази) більше не підтримується.
  • Db.getConnection () зробив public і додав в методи Blockchain.getBlocks і

getTransactions параметр PreparedStatement, для використання клієнтами API Java.

  • Доданий APITestServlet для ручної відладки і тестування

API. Усі http виклики API будуть тепер автоматично перенаправлені на: http://localhost:7876/test або якщо ви хочете випробувати тільки який те один із запитів, на приклад getBalance : http://localhost:7876/test?requestType=getBalance

    • У відмінності від сторінки admin.html, цей список автоматично генерує і включає усе доступні API без необхідності в ручну додавати нові.
  • Застосований патч до Curve25519.sign () запропонований DoctorEvil. Блок і підписання транзакції тепер не повинні припускатися помилки перевірки.

76 Версія 0.8.9

13 березня, 2014

  • Додана підтримка підпису транзакцій на стороні клієнта. Усе http API запити які створюють нову транзакцію, тепер працюють з secretPhrase або publicKey параметром. Якщо secretPhrase надана, транзакція отримує статус створеної, підписується на сервері і передається сервером, як завжди. Якщо secretPhrase не надана, але є publicKey параметр, у вигляді закодованого байтового масиву, то операція буде підготовлена сервером і повернена в JSON відповіді як transactionBytes. Цей байтовий масив може тепер бути підписаний клієнтом, і потім переданий назад на сервер для широкомовної передачі broadcastTransaction API.
  • Хеши транзакцій, які можуть бути використані, для однозначного визначення транзакцій, щоб уникнути атак пластичної транзакції (подвійний вивід, суть його - в отриманні своїх грошей двічі в результаті повторної транзакції), тепер можуть бути отримані, використовуючи Transaction.getHash () і також доступні в уявленні JSON транзакцій. Хеш може також використовуватися, щоб отримати транзакцію від сервера, замість того, щоб використати ідентифікатор транзакції, надаючи параметр хеша до getTransaction http API замість параметра транзакції.
  • Для підвищення продуктивності getBlockId і getBlockTimestamp методи Java API були додані до Transaction класу, щоб мінімізувати виклики getBlock, що у свою чергу може зажадати додаткових запитів до бази даних. Java клієнти повинні використати їх замість використання getBlock. Так само поле blockTimestamp було додане до JSON, повертаному getTransaction і іншими викликами API, які повертають транзакції JSON. Таким чином, http клієнти можуть також уникнути непотрібних звернень до getBlock.
  • Оновлення до 0.8.9 також модифікує базу даних і додасть поля hash і block_timestamp таблицю транзакцій.
  • Транзакції які визначені як невірні буде тепер також видалені з пулу широкомовної публікації.
  • Усі глобальні константи перенесені в Constants.java.
  • Поліпшена перевірка транзакцій для Біржових (AE) операцій, щоб уникнути введення в оману помилками недійсні операційні.
  • Виправлена обробка операцій з ідентичними мітками часу в генерації блоків і в клієнтові NRS UI.
  • Додані ASSET_BALANCE і подія UNCONFIRMED_ASSET_BALANCE в аккаунт, для вирішення можливої проблеми з обчисленням балансу активу.

77 Версія 0.8.8 / 0.7.7

7 березня, 2014

  • Виправлена проблема установки часу генерації генезисного блоку, коли відбувається перехід на літній час. Це було причиною не можливості форжинга для користувачів тих, що знаходяться в південній півкулі.
  • Оскільки DST в США запускається 09 березня, це критично важливо для користувачів США і їм необхідно оновитися до 0.8.8 або 0.7.7.
  • Більше ніяких виправлень помилок або нових функцій по відношенню до версії 0.8.7 /0.7.6, окрім вказаного рішення проблеми переходу на літній час.

78 Версія 0.8.7

6 Березня, 2014

  • Виправлена помилка обчислення непідтвердженого балансу генезисного блоку.
  • Виправлена помилка відображення балансу генезисного аккаунта в UI NRS.

79 Версія 0.8.6

5 березня, 2014

  • Ретрансляція транзакцій була некоректна в декількох попередніх версіях, тепер повинна працювати.
  • Виправлена помилка оновлення кількості підтверджень транзакції UI NRS.
  • Перевірка непідтверджених транзакцій на коректність, і якщо виявляється їх некоректність, вони видаляються з пулу непідтвердженого транзакцій.
  • Додані декілька відомих testnet вузлів у властивостях за умовчанням.
  • run.bat перетворений до формату закінчення рядка CRLF.

Виправлення специфічних bugfixes у функціоналі Біржі :

  • Ордер на відміну повинен оновлювати тільки непідтверджені баланси.
  • У блоці pop - off, не оновлювався баланс активу.
  • Коли торгівля виконується за ціною нижче, ніж пропозиція, виправляється непідтверджений баланс продавця на виниклу різницю.

80 Версія 0.8.5

4 березня, 2014

  • Велика частина bugfixes має відношення до обчислення непідтвердженого балансу.
  • Незначні виправлення, щоб обійти деякі не критичні помилки.

81 Версія 0.8.4e

3 березня, 2014

  • Декілька виправлень в механізмі в обчислення непідтверджених балансів і непідтверджених балансів активу (як ви розуміє розмову йде про AE). Це - спроба зафіксувати помилку негативного непідтвердженого балансу і помилку "Not enough funds", але доки повна працездатність не була протестована, саме з цієї причини, цей випуск - експериментальний.
  • Активація роботи з тестовою мережею (testnet) відбувається шляхом установки властивості nxt.isTestnet=true в nxt.properties. Більше нічого робити не потрібно !
  • При перемиканні на testnet, шляхом прописування параметра nxt.isTestnet=true, порт вузла призначається 6874, порт UI 6875 і порт сервера API 6876. Ці значення жорстко прописані, щоб запобігти помилкам і забрати пріоритет у будь-якого призначеного для користувача порту, вказаного в nxt.properties. Крім того, якщо не використовуючи testnet, сервер відмовиться запускатися якщо порт вузла встановлений в 6874, знову ж таки, для того, щоб запобігти випадковий змішування реальних і тестових blockchains.
  • Для testnet також автоматично створюватиметься новий підкаталог nxt_test_db, для тестового blockchain.
  • Ви повинні встановити в nxt.testnetPeers список відомих загальнодоступних тестових вузлів. Я встановив bug.airdns.org в коді версії 0.8.4e, і копія blockchain тестової мережі, as obtained from holms (даруйте - не зміг перевести логічно). Я сподіваюся, що і інші люди також встановлять тестові вузли і оголосять про них на форумі.
  • У цій версії, при перемиканні на тестову мережу, Голосування (Voting ) і Біржа (Asset Exchange) включаються автоматично. У реальній мережі, ці функції заблоковані. NRS клієнт зараз не підтримує ці функції, тобто вам знадобиться сторонній клієнт з реалізацією цих функцій, або доведеться користуватися прямими викликами API
  • Доданий параметр nxt.knownBlacklistedPeers, для ручного поміщення у чорний список вузлів в nxt.properties файлі.
  • Більше не перезаписуються адреси вузлів з їх анонсованими адресами в панелі "Active peers", для унікальної ідентифікації вузлів використовуються тільки IP адреси
  • Допускається деактивація DoSFilter для вузлів тих, що є серверами мережі. Доданий параметр nxt.peerServerDoSFilter.maxRequestMs=300000, тому що значення за умовчанням для DoSFilter maxRequestMs блокує вузол у якого запити до сусідніх вузлів перевищують 30 з, що призводить до переривання завантаження blockchain для повільних вузлів. Можливо це було причиною попереджень про помилки Jetty, які ми отримуємо ще з часів 0.5.x версії.
  • Доданий метод Generator.getAccount і START_FORGING і подія STOP_FORGING, інтересу для використання Java API клієнтами.
  • Доданий оригінальний run.bat для користувачів Windows.
  • Початковий код тепер включений в архів клієнта в каталозі src. Скрипти compile.sh і javadoc.sh можуть використовуватися, щоб зібрати первинники і відтворити nxt.jar і javadoc документацію.

82 Версія 0.8.3

26 лютого, 2014

  • Виправлені проблеми з відображенням UI інтерфейсу і оновленням My Transactions. Погоджений підрахунок підтверджень транзакцій. Транзакції, включені в останній блок, автоматично мають 0 підтверджень.
  • При генерації блоку, подія BLOCK_PUSHED тепер обробляється перед подіями REMOVED_UNCONFIRMED_TRANSACTIONS і ADDED_CONFIRMED_TRANSACTIONS.
  • Додане BlockchainProcessor. Події RESCAN_BEGIN і RESCAN_END, спрацьовують до і після повторної перевірки (не регулярний запуск сканування).
  • Виправлена поява декількох порожніх покажчиків (null pointers), викликана поганими даними від інших нод.
  • Поліпшена обробка адрес бенкетів і клейм(Hallmarks).
  • Доданий чорний список до статусу інформації про бенкети.

83 Версія 0.8.2e

25 лютого, 2014

  • В основному, дрібні виправлення проблем після виходу 0.8.1e.
  • Виправлена json-строка клейма в інформації про бенкети.
  • Поліпшена властивість Logger, додав методи RemoveListener.
  • Не треба встановлювати заголовки Content - Length при використанні XMLHttpRequest, для відправки POST запитів.
  • Доданий jetty-security jar.
  • worker_sha256.js переміщений в tools.
  • Крім того, додані випадкові вузли mynxt.info в значення за умовчанням wellKnownPeers.

84 Версія 0.8.1e

24 лютого, 2014

  • Поліпшена взаємодія вузлів при оголошенні адрес і портів. Параметр nxt.myAddress тепер опционален, і допоможе користувачам з динамічними IP -адресами. Якщо nxt.shareMyAddress=True, після підключення до вузла, через який той час він намагатиметься підключиться до вас за оголошеною адресою, і, якщо це не вдалося, за тією адресою з якого прийшов ваш запит. У разі успіху, вузол збереже вашу останню адресу і використовуватиме його для підключення до вас в майбутньому, також він ділитиметься їм з іншими. Додатково, проходить перевірка оголошених адрес, тобто ваш вузол буде підключений тільки після успішного з'єднання. Це дозволить запобігти поширенню некоректно оголошених адрес на інші вузли.
  • Якщо вам треба використати нестандартний порт, його номер має бути доданий до вашої оголошеної адреси. Він не має бути такими ж, як в nxt.myPeerServerPort, так що ви можете запустити сервер на одному порту, і перенаправити до нього інший порт від маршрутизатора. Якщо номер порту не встановлений в оголошеній адресі, а значення nxt.myPeerServerPort не є значенням за умовчанням, номер порту з nxt.myPeerServerPort автоматично буде доданий до оголошеної адреси.
  • Підсумовуючи вищесказане: користувачам з динамічними IP -адресами, не треба змінювати nxt.myAddress, проте необхідно настроїти перенаправлення портів на маршрутизаторі.
  • Перевірка клейма (hallmark) також була поліпшена, щоб спробувати дозволити ім'я хоста в IP-адресе. Зверніть увагу, що якщо ви використовуєте нестандартний порт, в hallmark ви повинні вказати тільки свою адресу, без порту.
  • Додана функція API "generateToken". Параметрами є secretPhrase і host; відповідь: токен, обернутий в JSON. Ця функція також доступна на сторінці admin.html.
  • Поліпшена обробка ініціалізації і завершення роботи. Виклик Nxt.shutdown() тепер доступний усім, включаючи розробників клієнтів. Коли Nxt запускається як окреме застосування викликом main(), виключення буде заплановано як переривання(hook). Якщо для запуску використовується init(), за виключення відповідає виклик shutdown() або заплановане переривання.
  • Додана затримка запуску сканування блокчейна і сервлетов Jetty, поки не завершиться ініціалізація усіх класів. Це дозволить зареєструватися усім службам що слухає порти, і повинно допомогти запобігти помилкам сервлетов, які починають приймати запити, перш ніж система повністю ініціалізувалася.
  • Якщо файл NXT - default.properties не знайдений, Nxt також зробить спробу завантажити його з файлу, визначеного в параметрах запуску, тобто ви можете визначити його в командному рядку: java - Dnxt - default.properties=conf/nxt - default.properties. Це представляє інтерес тільки для розробників клієнтів.
  • Додана підтримка POST запитів, в доповненні до усім API і UI http запитам. Щоб використати тільки POST, для тих запитів, які вимагають від користувача secretPhrase, в nxt.properties можуть бути встановлені параметри nxt.apiServerEnforcePOST і nxt.uiServerEnforcePOST (по умовчання відключено для API і включено для UI). Т. е. розробники клієнтів можуть визначити, який тип запитів застосовуватиметься для конфіденційних даних.
  • За умовчанням інтерфейс NRS був змінений для використання тільки з POST запитами, у тому числі, і в інструментах - admin.html, message.html, alias.html. Таким чином, secretPhrase користувача більше не кэшироваться в пам'яті браузеру.

85 Версія 0.8.0e

22 лютого, 2014

  • У цій версії внесені серйозні зміни в серверній архітектурі Nxt. Тепер, Nxt не сервлет усередині Jetty, а самостійне застосування, яке саме може запускати Jetty сервлеты, коли це необхідно. Це повинно спростити використання Java бібліотек, оскільки вони більше не мають бути запущені усередині контейнера сервлетов.
  • Конфігурація Nxt зроблена гнучкіше, як для кінцевого користувача так і для розробників застосувань. Тепер, Nxt більше не використовує файли web.xml, і XML-файлов в принципі. Замість цього, введені зручні файли конфігурації (*.properties).
  • Компонування дистрибутива, була змінена і спрощена. Розпаковування архіву дасть наступну структуру каталогів :
    • nxt/html/
      • Підкаталог html/nrs потрібний для роботи NRS javascript клієнта, підкаталог html/tools - для html -страниц, таких як admin.html або update.html, і html/doc містить документацію по низькорівневих API функціях.
    • nxt/lib/
      • Каталог для зберігання необхідних Java бібліотек-Jetty, база даних H2, і простий JSON-парсер. Невживані бібліотеки Jetty видалені, що привело до зменшення дистрибутива.
    • nxt/nxt.jar
      • Каталог містить усі скомпільовані класи Nxt.
    • nxt/run.sh
      • Простий скрипт для запуску Nxt, під Linux:

        java - Xmx1024M - cp nxt.jar: lib/*: conf nxt.Nxt

        Як бачите, усе використовувані Java -классы включені в nxt.jar, а усі налаштування зберігаються в каталозі nxt/conf.
  • Зверніть увагу, файли start.jar, webapps і каталог з конфігурацією Jetty більше не потрібні.
  • У доповненні до переходу на вбудований Jetty, значному рефакторингу піддався код, який представляє інтерес для користувачів Java API. Змін надто багато для того, щоб описувати їх тут, але їх легко можна побачити, порівнюючи документацію версії 0.8.* з 0.7.*. Зокрема, були визначені інтерфейси для класів блоків і транзакцій, клас Blockchain був розділений на декілька класів, а деякі класи Peer і User були виключені.
  • Розробники клієнтів, використовуючих Java API можуть перевизначити будь-яка з властивостей за умовчанням, використовуючи об'єкт Nxt.init().
  • Усі властивості, що настроюються, документовані у файлі NXT - default.properties. Ось деякі додаткові подробиці про них:
  • Nxt може запускати до трьох різних екземплярів серверів Jetty, якщо це необхідно.
  • Ноды можуть приймати HTTP запити від інших нод. Це стартове значення умовчанню nxt.shareMyAddress = True. Якщо ви за брандмауером, ви можете відключити цю можливість (False).
  • Номер порту і назву сервера ноды можна змінити. Якщо ви встановили порт не за умовчанням (у nxt.peerServerPort), ця інформація додасться до адреси, яку ви оголосили (адреса встановлюється параметром nxt.myAddress). Хоча, відмінний від умолчального порт не буде часто перевірятимуться іншими нодами.
  • Для машини з декількома мережевими інтерфейсами, тепер можна вказати, конкретний інтерфейс для прив'язки кожного запущеного сервера. За умовчанням nxt.peerServerHost = 0.0.0.0, тобто Nxt слухає інші ноды на усіх інтерфейсах.
  • Тепер, у властивостях за умовчанням, немає жорстко заданого параметра nxt.wellKnownPeers. Ви можете встановити їх, додавши потрібні ноды в nxt.properties. Проте, якщо властивість не встановлена, використовуватиметься випадковий вибір за даними загальнодоступних вузлів nxtcrypto.org і nxtbase.com.
  • DoS фільтр включений тільки для сервера вузлів.
  • Сервер API приймає HTTP / JSON запити API. За умовчанням, нині він працює на порту 7876, і слухає тільки на локальному інтерфейсі 127.0.0.1. Якщо ви запустили загальнодоступний вузол і хочете приймати запити API від усіх, визначите nxt.apiServerHost в 0.0.0.0, і залиште nxt.allowedBotHosts порожнім або зі значенням "*".
  • Nxt.apiResourceBase вказує на каталог статичних HTML -файлов, що обслуговуються сервером API. Розробники клієнтів, використовуючих HTTP / JSON API захочуть настроїти цей параметр, щоб укзаать на їх клієнтські HTML і Javascript файли.
  • Фільтр Jetty Cross Origin Filter може бути включений для API сервера, установкою параметра nxt.apiServerCORS = True (за умовчанням - відключено).
  • У NRS javascript клієнтові використовується UI cервер. За умовчанням він працює на порту 7875 і приймає запити тільки локально. Розробники клієнта, який використовує ті ж виклики API, що і клієнт NRS (а не HTTP / JSON) повинні визначити параметр nxt.uiResourceBase, щоб вказати на свої клієнтські HTML і Javascript файли.
  • SSL може бути включений як для сервера API так і для UI сервера (за умовчанням відключено). Якщо це буде зроблено, то відповідні порти прийматимуть тільки HTTPS -запросы. Зараз немає способу щоб підтримувалися одночасно HTTP і HTTPS, проте це можна додати, просто я не бачу в цьому необхідності. Якщо ви включите SSL, вам необхідно визначити nxt.keyStorePath і nxt.keyStorePassword, і, очевидно, у Вас має бути свій власний сертифікат SSL (самоподписанный або підписаний центром сертифікації) у файлі сховища ключів. Я перевіряв це тільки з власним сертифікатом.
  • Розробники клієнтів на Java API, ймовірно, захочуть, відключити і сервер API і сервер UI, і користувачів, без видимої IP адреси і навіть сервера вузлів.
  • Налагоджувальна інформація тепер відключена за умовчанням, але може бути включена установкою nxt.debug = True. Виключення при трасування стека, проте протоколюватимуться, поки nxt.enableStackTraces = True. Сподіваюся їх там не буде.
  • Підключення до бази, можна настроїти повним JDBC URL і змінювати властивості підключення на льоту. Розробники клієнта, які наполягають на можливості доступу до бази даних з окремого процесу, тоді як Nxt працює, можуть зробити це, додавши AUTO_SERVER = True в JDBC URL, що автоматичний запустить змішаний режим. Це можливість за умовчанням відключена, і якщо ви включите її і проведете запис у базу даних тоді як Nxt працює, чекайте зупинки процесу.
  • Крім того, можна зберігати базу даних у іншому місці, а не тільки в поточному робітнику каталозі, якщо ви зміните JDBC URL відповідним чином.
  • Щоб змінити об'єм пам'яті, використовуваний для кеша бази даних, використайте параметр nxt.dbCacheKB, в кілобайтах. Якщо значення встановлене в 0, JVM використовуватиме для кеша бази даних 50% від кількості доступної пам'яті.
  • Структура бази даних не була змінена. З цією версією, ви можете використати існуючий каталог nxt_db без завантаження блокчейна з нуля
  • Цей релиз помічений експериментальним, проте, будь ласка, спробуйте його. Зокрема, розробники клієнтських застосувань повинні перевірити наскільки добре усе працює. Якщо не буде жодних серйозних проблем, чекайте, що гілка 0.7 застаріє в самий найближчий час.

86 Версія 0.7.6

19 лютого, 2014

  • Стискування бази даних при кожному завершенні роботи клієнта. Це повинно зменшувати розмір каталогу nxt_db після першого запуску. Перевірте до і після запуску нового клієнта використання диска (об'єм теки nxt_db).
  • Запобігання задваивания списку відомих вузлів і списку вузлів поміщених в чорний список, у фреймах WEB клієнта.
  • Відвернена потенційна небезпека з атакою задвоенного ключа аккаунта . Опис тут: https://bitcointalk.org/index.php? topic=397183.msg4569817#msg4569817
  • Додана Система голосувань ще не включена.
  • Деякий рефакторинг класів Block і Transaction.
  • Bugfixes у функціоналі Біржі (Asset exchange) в тестовій мережі і великої кількості API запитів.
  • Поліпшена перевірка коректності транзакцій, щоб запобігти неправильному поміщенню у чорний список вузлів і підвищити якість перевірки транзакцій.

87 Версія 0.7.5

14 лютого, 2014

  • Різні поліпшення продуктивності і поліпшення використання пам'яті.
  • Поліпшена перевірка адрес вузлів і обробка зміни стану з'єднань вузлів. Поліпшений призначений для користувача інтерфейс у блоці відображення інформації про вузли.
  • Додаткова оптимізація в getMilestoneBlockIds, для зворотної сумісності.
  • Подальше очищення ядра nxt, від класів UI.

88 Версія 0.7.4

13 лютого, 2014

  • Ще один bugfix для переходу до Прозорого форжингу, що запускається з блоку 67000. Оновіться до виходу цього блоку, інакше отримаємо галуження.
  • З цієї версії припиняється підтримка старої версії протоколу getMilestoneBlockIds. Клієнти версій нижче чим 0.7.3, не зможуть отримувати блоки від вузлів версії 0.7.4 . Усі повинні відновити до 0.7.4 перед блоком 67000.
  • Деяка оптимізація в запитах до бази даних, використовуваних під час розблокування облікового запису, давайте подивимося, чи допомагає це користувачам Raspberry.
  • Інші незначні поліпшення.

89 Версія 0.7.3

12 лютого, 2014

  • Лінійка 0.6.x більше не підтримується і не розвивається ! Починаючи з цієї версії (0.7.3), розвиватися і оновлюватися будуть тільки версії працюючі з базою даних !
  • Оптимізував протокол getMilestoneBlockIds. Це протокол передачі точка-точка між вузлами, який створює основне навантаження на громадські вузли і створював значний об'єм непотрібного трафіку. Проте для зворотної сумісність, версія 0.7.3 все ще підтримує обидва варіанти протоколу (і старий і новий, оптимізований), тому коли старіші клієнти з'єднуються з вузлами версії 0.7.3 вони, на жаль, все ще передають зайвий, непотрібний трафік.
  • ПОПЕРЕДЖЕННЯ: Підтримка старого getMilestoneBlockIds протоколу буде припинена з версії 0.7.4. Немає необхідності усе кидати і оновлюватися, але якщо не оновитися до виходу версії 0.7.4, твої старіші вузли не буде в змозі отримувати/просити блоки і актуалізувати blockchain. По цьому краще оновитися раніше, чим пізніше!
  • Ще більше за рефакторинга код. Повністю розділена логіка призначеного для користувача інтерфейсу від логіки ядра системи. Більше ніщо не зв'язує ядро nxt з класами в пакеті nxt.user. Instead, a Listeners framework is used, so that the UI can register to be notified of the events in the core that it needs to know about. This is also intended to be used by Java client API developers.
  • Додані ще декілька індексів до таблиць бази даних, щоб поліпшити роботу. Вони будуть створені автоматично при першому запуску клієнта. При цьому вам не потрібно що або видаляти або змінювати з nxt_db.
  • Зміни системи безпеки : Before this release, newly generated blocks and new transactions were broadcasted to peers twice. This could allow your peers to deduce that your node was the generator of the block or transaction in question. This is now fixed. Note that somebody with the ability to monitor all your internet traffic will still be able to tell that it was you who generated a block, because the generating node sends the block before having received it from any other peer. I don't see a physically possible way to avoid that, yet. Also note that the transaction re - broadcasting feature will continue to re - broadcast your transactions until they are received back from at least one other node, but will not do that with transactions received from other nodes. This

could still be used to deduce that your node was the source of a transaction, in case the initial attempt to send it failed, and it was re - broadcasted (but somebody already observed the failed first attempt).

  • Виділений блок логіки форжинга в клас Generator, який може використовуватися клієнтами Java API, щоб починати і припиняти форжинг.
  • Додані API функції startForging і stopForging. Параметри: secretPhrase, вимагається для старту і зупинки дій.
  • Виправлені незначні помилки. Виправлений помилка у вузлі пов'язані з контролем завантажуваного трафіку.

90 Версія 0.7.2

9 лютого 2014

  • Поліпшена продуктивність сканування ланцюжка блоків.

91 Версія 0.7.1 / 0.6.2

8 лютого, 2014

  • Виправлена помилка в обчисленні балансу, що гарантується, який міг в деяких випадках привести до ефективного балансу вище, ніж фактичний баланс. Оскільки ця зміна може провести галуження, перемикання до коректного обчислення станеться після генерації блоку 64000. Усі повинні оновитися або до 0.7.1 або до 0.6.2 перед блоком 64000, або ми отримаємо галуження.
  • Поліпшена перевірка коректності вузлів щоб не допускати синтаксичні помилки, не обчислювані адреси, в списках вузлів.
  • Реалізована можливість реєструвати усю налагоджувальній інформації у файлі журналу. Усе, що було виведено в консолі буде також зареєстровано до файлу nxt.log. Це повинно допомогти в роботі із звітами про помилки у разі катастрофічних відмов і помилок, оскільки тепер закриття вашої консолі не приведе до втрати даних (про помилку). При кожному перезапуску сервера, файл nxt.log буде перезаписаний.
  • Очищені мітки (hallmark) і авторизація по токенам. Додані класи Token і Hallmark, які тепер можуть використовуватися розробниками клієнтів на Java для генерації і перевірки токенов і клейм (hallmarks), без задіювання інтерфейсу http.
  • Поліпшено журналирование відмов при роботі з блоками, і подій з блоками, тепер реєструється ідентифікатор блоку і причина проблеми.
  • Поліпшений механізм приміщення вузлів в "чорний список", при занесенні вузла в "чорний список" реєструється причина таких дій. Http запити від поміщених в чорний список вузлів, тепер повністю ігноруються.
  • Усе API запити управляються класами через nxt.http, видимим в javadoc документації, щоб використовуватися при документування параметрів і повертаних значень http API.
  • У лінійці версії 0.7. не було виявлено яких або помилок при роботі з базою даних.
  • Усі вищезгадані зміни були застосовані і до версії 0.6 і до версії 0.7. Я закликаю людей тестувати версію 0.7.1, оскільки не бачу особливого сенсу в дуже тривалій підтримці і розвитку версії 0.6, якщо ми не виявимо проблеми з версією працюючою з базою даних (0.7.х).

92 Версія 0.7.0e

6 лютого, 2014

  • Це перша версія Nxt клієнта, яка використовує вбудовану базу даних Java (H2), щоб зберігати blockchain, замість об'єктних файлів Java. Оскільки ця істотна зміна, цю версію треба вважати експериментальною.
  • blocks.nxt і transactions.nxt і .bak файли більше не використовуються.

Крім того, вони не будуть завантажені при старті клієнта. Коли ви запустите клієнта перший раз у вас буде створена порожня база даних, яка буде автоматично заповнена завантаженими даними blockchain з мережі.

  • База даних зберігається в каталозі nxt_db каталогом, і на даний момент, після повного завантаження, займатиме близько 100 Мбайт. Якщо що-небудь пішло не так, ви можете просто видалити каталог nxt_db. Після цього база даних перестворюватиме автоматично, і заповниться актуальними даними. (прим. Dr.NXT: Припускаю що перед видаленням варто зупинити клієнта, і після видалення запустити по новій.)
  • У файлі web.xml файлі немає ніяких відмінностей по відношенню до версії 0.6.1. Я додам параметри налаштування бази даних пізніше, у разі потреби.
  • База даних використовуватиме 50% пам'яті, доступною Java для її кеша. Фактичне значення відображатиметься при старті клієнта.
  • На даний момент у базі даних зберігаються тільки блоки і транзакції, усе інше (аккаунти, псевдоніми, активи, замовлення, повідомлення,...) завантажуються при старті зберігаються в пам'яті. При цьому, об'єм пам'яті, яка потрібна для зберігання цих даних значно менше, чим раніше вимагалося для зберігання блоків і транзакцій.
  • При старті сканування blockchain займає трохи більше часу, чим раніше, і це нормально. Якщо що-небудь ще буде помітно повільніше, ніж в попередніх версіях, то я вивчу проблему і оптимізую це.
  • Відсутні які або нові видимі функцій в порівнянні з 0.6.1, код збережений і синхронізований (включаючи критичні bugfixes). Наявність в мережі клієнтів 0.6.1 і 0.7.0e на вузлах мережі не повинно призводити до галужень. Я буду підтримаєте і 0.6.x і 0.7.x відгалуження впродовж деякого часу, до виявлення і виправлення відомих проблем. Будь ласка повідомляйте про виявлені проблеми, бажано надавати трасування стека.

93 Версія 0.6.1

6 лютого 2014

  • Виправлена незначна помилка в критичному bugfix версії 0.6.0. Виправлення не критичне, але не перешкодить оновитися !
  • Портированы деякі незначні зміни з версії 0.7.0.
  • Поліпшена обробка некоректної роботи вузлів, що публікують невірні адреси.

94 Версія 0.6.0

5 лютого 2014

  • Суть критичного bugfix - буде розкрита дещо пізніше (см UPD). Це документ включає тільки опис відмінностей 0.6.0 від 0.5.12

UPD: Кілька днів тому один хлопець, знайшов уразливість в Blockchain.Info і підібравши секретну фразу генезисной облікового запису Nxt, знайшов дефект безпеки в криптографічному алгоритмі NRS. Дефект дозволяв створювати транзакції, які приведуть до збільшення сум переказу, двічі, тричі і так далі. Виявивши цей дефект він провів аудит класу Crypto і виграв спеціальний приз, який ми зібрали саме для такого випадку.

Я не можу розкрити деталі дефекту, оскільки це поза моєю галуззю знань. Ви можете зв'язатися з ним безпосередньо через nextcoin.org форум.

Дефект був виправлений і усі, хто відновив до версії 0.6.0 і вище, знаходяться у безпеці. Користувачі старіших версій знаходяться у безпеці тільки доки вони сполучені з вузлами версій 0.6.0 і вище.

  • 0.5.x доопрацювання цієї лінійки сильно відволікало від повного перегляду коду версій 0.6.x і 0.7.x. Тому, я вирішив становить підтримку 0.5.x повністю перейти до розвитку версії 0.6.x.
  • Останній bugfix в 0.5.12 не був повним, і усі користувачі мережі повинні

оновитися до 0.6.0 якнайскоріше. 0.5.12 має недоліки, який вже не виправлятимуться.

  • 0.6.x версія все ще використовує сериализированные об'єктні файли, проте вони назад не сумісні з 0.5.x. Старі blocks.nxt і transactions.nxt файли версії 0.5.x будуть автоматично перетворений в новий формат, при першому запуску клієнта версії 0.6.0.
  • blockchainStoragePath параметр в web.xml більше не використовується.
  • Код клієнта був значно переглянутий і більше не поставляється як єдиний файл Java. Усі класи, використовувані в клієнтові Nxt, тепер винесені у власні файли.
  • Усі пакети nxt верхнього рівня, і відповідно servlet - class параметри в web.xml має бути змінені на nxt.Nxt. Даруйте, що я забув про це згадати при випуску версії 0.6.0:

<servlet - name>Nxt</servlet - name> <servlet - class>nxt.Nxt</servlet - class>

  • Тепер існують три підпакети, nxt.user, nxt.peer, і nxt.http, які окремо відповідають за обробку запитів до UI (призначений для користувача інтерфейс), peer to peer, і http API запитів, відповідно
  • Уся бізнес-логіка була переміщена з класу сервлета Nxt.
  • Нова ієрархія Transaction.Type була введена щоб обробляти усю логіку для перевірки допустимості транзакції, додаткової обробки транзакцій і транзакцій застосувань. Це рішення повністю замінює перемикачі статусу, які використовувалися для перевірки транзакцій і логіки основних процесів.
  • Відміна транзакцій у блоках pop - off була реалізована для тих транзакцій які можуть бути скасовані. При спрацьовуванні тригерів UndoNotSupportedException triggers відбувається повне пересканирование blockchain.
  • Призначене для користувача виключення NxtException тепер використовується, щоб поліпшити роботу з блоками і перевіркою транзакцій. Most transaction and block parameters are now enforced to be valid in the Transaction and Block constructors, which makes it sort of difficult to forget to validate them.
  • Було застосовано багато незначних і значних виправлень для підвищення продуктивність і оптимізації пам'яті, на основі фактичних вимірів профілів.
  • Усі поля і методи доступу були переглянуті. Ніякі поле або методи Java доступні не більше ніж це необхідно. Усе, що повинно бути "private", тепер "private". Усе, що повинно бути "final", тепер "final".
  • Усі результати повертані JSON і обробки помилок були очищені і оптимізовані.
  • Непотрібний ByteBuffer використовуваний у блоках і обробках транзакцій був видалені.
  • Межа deadline тепер не може бути більше 1440 хвилин для обробки нових транзакцій.
  • Вузли які публікують некоректні блоки або некоректні дані транзакцій, автоматично поміщаються в чорний список.
  • Документація API Java тепер доступна по посиланню http://localhost: 7874/doc/, увесь API схильний до змін, йде активна робота.
  • Незначні зміни UI : додані попередження у вікні разблокирови облікового запису і message.html, доданий sendMoney на сторінці admin.html.

Нові або поліпшені API:

  • getAccount

параметр: обліковий запис (ідентифікатор облікового запису) повертає: відкритий ключ (якщо відомий), баланс, ефективні/підтверджений баланс (effectiveBalance), загальний баланс активів.

  • getAsset

параметр: актив (ідентифікатор активу) повертає: accountId - ідентифікатор аккаунта який випускає актив, ім'я активу, опис і кількість

  • getAssetIds

повертає: усі існуючі ідентифікатори активу.

  • getAskOrderIds і getBidOrderIds тепер вимагають параметра активу і повертають

ідентифікатор замовлення тільки для вказаного активу.

95 Версія 0.5.12

5 лютого 2014

  • Виправлена критична помилка. Усім користувачам слід негайно відновити версію.

96 Версія 0.5.11

30 січня, 2014

  • Розв'язані проблеми продуктивності в getState, getEffectiveBalance і getGuaranteedBalance. При обчисленні getGuaranteedBalance тепер використовує інший алгоритм що може в деяких випадках дати результати що відрізняються від вичислених у версії 0.5.10 guaranteedBalance (у якого були деякі помилки), таким чином, бажано, щоб усі оновилися до версії 0.5.11, щоб уникнути ризику галуження.
  • Виправлений помилка з установкою відкритих ключів облікових записів, які згенерували блоки без витікаючих транзакцій.

97 Версія 0.5.10

23 січня, 2014

  • Це - випуск bugfix. Усі користувачі версії 0.5.9 і більше ранніх повинні обов'язково відновити.
  • Виправляв помилку в Прозорому Форжинге. Це виправлення вступивши силу після генерації 51000 блоку. Користувачі, які не обновлят клієнт до генерації цього блоку, не зможуть прийняти долі у форжинге/здобичі монет.
  • Виправлена незначна помилку в обчисленні ваги вузла.
  • Звіт про виконання робіт :
    • Рефакторинг для версії 0.6.0 йде повним ходом. Проект Nxt тепер складається з 86 файлів Java замість 1. Розробка триває, наступного тижня буде проведена робота над збереженням блоків і транзакцій у базі даних. Це доки не планується реалізувати у версії 0.6.0, тому що це рішення не містить нового для користувачів, які або нові видимі функції. До того ж перші випуски 0.6.х ймовірно, буде менш стабільна, чим 0.5.x лінійка.

Термінові bugfixes і нові API, у разі потреби, будуть додані ще до динейке 0.5.x. Будь-які проекти які планували клонувати Nxt, у зв'язку з чим нетерпляче чекали лінійку версії 0.6.x, для того, щоб отримати безкоштовно вигоду з моєї роботи по рефакторингу, будуть вимушені продовжувати чекати, до тих пір, поки розробники не досягнуть результату.

98 Версія 0.5.9

19 січня, 2014

  • Займався вирішенням питань паралелізму потоків, що залишилися, в обробці транзакції і блоку. Усі помилки "null pointer exceptions", про які повідомляли, а також помилка ділення на нуль і пов'язані з цим помилки більше не повинні повторюватися. Якщо Ви помітите які-небудь помилки в журналі, повідомите про них в нашій базі цих помилок : https://bitbucket.org/JeanLucPicard/nxt - public/issues
  • Додані API функції пов'язані з Asset Exchange : getAskOrder, getAskOrderIds, getBidOrder, getBidOrderIds, getAccountCurrentAskOrderIds, getAccountCurrentBidOrderIds.
  • Виправлена проблема, що виникає у вкладці "Recent Blocks" у браузері, при збільшенні кількості завантажених блоків до 60. Це дозволить уникнути гальмування/уповільнення роботи браузеру і зависання під час завантаження blockchain з нуля.
  • Додана повторна широкомовна трансляція транзакції. Щоб упевнитися що нова транзакція була отримана мережею, вона повторно передаватиметься кожну хвилину, поки вона не з'явиться в списку непідтверджених або підтверджених транзакцій.
  • Журнали відладки тепер стали тихішими, фактично я не спостерігав виключень за ті, що пройшли 24 ч тестування цієї версії. Усі повинні протестувати цю версію, оскільки я сподіваюся, що це - дійсно стабільна версія. Увага: усі ті хто ще використовують версію 0.5.7 будуть поміщені в чорний список, якщо вони не оновляться, тому що вони продовжують широкомовно передавати некоректні блоки JSON і розглядатимуться як "зомбі".

99 Версія 0.5.8

16 січня, 2014

  • Усунена проблема паралелізму потоку, яка є вірогідною причиною помилок OutOfMemory, з якими деякі зіткнулися. Це критичне виправлення, усі користувачі версії 0.5.7 обов'язково повинні оновитися до версії 0.5.8.
  • Доданий "type" і "subtype" фільтри для API функції getAccountTransactionsIds.

100 Версія 0.5.7

15 січня, 2014

  • Після оптимізації використання пам'яті і ЦП, цей випуск присвячений оптимізації роботи в мережі. Тепер, замість відправки усім вузлам, дані вирушають тільки 10 вузлам за умовчанням. Їх число встановлюється у файлі web.xml, в параметрі sendToPeersLimit. Це повинно привести до зменшення мережевого трафіку і також повинно значно зменшити час очікування при відсиланні транзакції. Крім того, відправка тепер зроблена паралельною, використовуючи пул 10 потоків, що означає, що повільні вузли не затримуватимуть відправку даних усім іншим вузлам.
  • Декілька виключень, знайдених в звітах відладчика, а також декілька мережевих виключень, які, як відомо, були безпечні, будуть тепер проігноровано. Журнали відладки стали ще "спокійнішими", тепер навіть з включеною відладкою, тому, я вирішив за умовчанням активувати параметр nxt.debug в nxt.ini.
  • Прозорий Форжинг фази 2 стартує після генерації 47000 блоку. Усі повинні оновитися як мінімум до версії 0.5.7, перш ніж цей блок буде досягнутий, інакше ми можемо отримаємо галуження.
  • На сторінці message.html доданий інструмент Wesley's для відправки повідомлень

101 Версія 0.5.6e

13 січня, 2014

  • Виправлена помилка при логировании і обробці виключень. Тепер є дві системні властивості, які допоможуть збирати розширену інформацію: nxt.debug і nxt.enableStackTraces. Вони описані в start.d/nxt.ini:

    # Enable debug messages
    #- Dnxt.debug

    # Also enable exception stack traces
    - Dnxt.enableStackTraces

    # Disable all jetty warnings and info
    - Dorg.eclipse.jetty.LEVEL=OFF
  • За умовчанням, nxt.debug відключені(не активні). Якщо ви хочете отримувати розширене логирование, будь ласка активуйте цю функцію шляхом раскомментирования рядка - Dnxt.debug в nxt.ini, і передавайте будь-які помилки в наш JIRA в трекер Bitbucket :
    https://bitbucket.org/JeanLucPicard/nxt-public/issues
    Постарайтеся уникати дублювання помилок, заздалегідь ознайомившись із вже опублікованими помилками, можливо виявлена вами помилка вже була заявлена.
  • Параметр nxt.enableStackTraces активує запис трасувань стека помилок в журнал, незалежно від стану nxt.debug, Ви повинні залишити його включеним.
  • Із закоментированным nxt.debug, Nxt все одно реєструватиме частину помилок в журналі, але їх количство буде дуже малим. Якщо з'явиться критичне виключення/помилка, то вони будуть зареєстровані, навіть якщо nxt.debug буде не активний.
  • Що створює багато записів система журналирования Jetty відключена, тепер в журналах буде менше зайвої інформації. Якщо ви хочете насолоджуватися повідомленнями Jetty, раскомментируйте рядок - Dorg.eclipse.jetty.LEVEL=OFF в start.d/nxt.ini, тільки не публікуйте дані звідти як помилки.
  • Причина по якій цей випуск також можна вважати експериментальним, полягає в тому, що я відновив Jetty з версії 9.1.0 до 9.1.1.v20140108. Усі користувачі можуть протестувати наскільки якісно усе працює/не працює, виявити проблеми і несумісності.

102 Версія 0.5.5

11 січня, 2014

  • Додана функція API getGuaranteedBalance:

    http://localhost: 7874/nxt?requestType=getGuaranteedBalance&account=account&numberOfConfirmations=numberOfConfirmations

    Повертає підтверджений баланс аккаунта. Розглядаються тільки ті транзакції у яких кількість підтверджень >= значення numberOfConfirmations.
  • API функції getAccountBlockIds and getAccountTransactionIds тепер повертають результат в сортованому виді.
  • Додані getAccountPublicKey and getGuaranteedBalance на сторінку admin.html.
  • Інші рішення для оптимізації продуктивності.

103 Версія 0.5.4e

10 січня, 2014

  • Доданий сервіс Довільних Повідомлень (Arbitrary Messages), функціонал буде доступний після генерації 40000 блоку.
  • Додані нові API запити:

Це дасть можливість облікового запису створити блок, який буде вичислений користувачем як myEffectiveBalance/totalEffectiveBalance.

  • Поліпшене споживання пам'яті і оптимізація продуктивності, щоб зменшити навантаження на GC і загальні вимоги до пам'яті. Повинно працювати з параметром запуску Java - Xmx512M у разі потреби, звичайно чим більше буде виділено пам'яті тим краще, але це не є обов'язковим. Я сподіваюся, що користувачі Raspberry будуть задоволені цим випуском
  • Це експериментальний випуск із за багатократних експериментів по оптимізації роботи з пам'яттю, але повинен працювати краще, ніж 0.5.3.

104 Версія 0.5.3

8 січня, 2014

  • Виправлена помилка пересканирования blockchain. При пересканировании віддаляються непідтверджені транзакції.
  • Поліпшена перевірка допустимості номера рахунку одержувача. Не дає зробити переклад на номери із занадто великим номером, або негативним номером. Рішення повинне зменшити вірогідність, створення частини некоректних транзакцій, що відправляються неправильним одержувачам із-за помилок користувача

105 Версія 0.5.2

7 січня, 2014

  • Додана перевірка допустимості numberOfTransactions і payloadLength, щоб запобігти атакам типу OutOfMemory.

106 Версія 0.5.1

7 січня, 2014

  • Можливо розв'язана проблема https ://bitcointalk.org/index.php?topic=397183.msg4343616#msg4343616; потрібно додаткове тестування. Будь ласка повідомите про будь-які випадки появи негативних блоків і балансів, і включите журнал помилки, якщо це можливо.
  • Виправлено поміщення у чорний список вузлів помічених hallmarked.
  • Облікові записи з негативними балансами не можуть форжить.
  • Поліпшена перевірка відкритого ключа облікового запису.
  • Оновлений update.html для отримання новітніх версій і змінений url завантаження.
  • Виправлена помилка бракуючих ідентифікаторів транзакцій у блоці "My Transactions".

107 Версія 0.5.0

Цю версію можна вважати стабільною. Журнал змін :

  • Усунена велика частина проблем паралельної обробки, оптимізована продуктивність і проведено очищення коду. Я усунув усі виявлені проблеми в коді, які могли призводити до помилок, які були описані в TODO як помилки і питання рефакторинга .
  • Додана контрольна точка для блоку 30000 (блок, починаючи з якого почне працювати прозорий форжинг).
  • Доданий контроль оновлень wesleyh's : https://bitcointalk.org/index.php?topic=345619.msg4294180#msg4294180
    • Використайте https://localhost:7875/update.html щоб перевіряти наявність оновлень. У роботі цього функціонала ще можуть знаходитися помилки, і я його спеціально включив в це оновлення, щоб користувачі протестували його роботу на різних браузерах.
  • Розробники не змогли виявити причини заявленої критичної помилки при якій транзакції, що посилаються одержувачеві, приходили не тому який був вказаний.

Я переглянув протокол ще раз, але не виявив можливих варіантів, при якому така ситуація може виникнути. Цю помилку ми не ігноруємо, і допускаємо що помилка може мати місце, але доки нам не вдалося відтворити помилку, і відповідно зрозуміти із за чого вона відбувається.

108 Версія 0.4.9e

Цю версію треба вважати ЕКСПЕРИМЕНТАЛЬНОЮ. У ній є присутніми досить багато змін, тому потрібно розуміти риски в'язані з оновленням. Якщо ви не хочете ризикувати - залиштеся на стабільній версії 0.4.8. Але наш вузол NCC - 1701 - D без проблем працює на 0.4.9e відучора.

  • Багато паралельних обробок виправлені і оптимізовані. Це повинно значно поліпшити роботу і стабільність і зменшити вірогідність зависання клієнта і необхідності його перезапуску.
  • Оптимізація продуктивності, скорочена кількість тимчасових об'єктів, що створюються на вузлі. Вимоги до об'єму споживаної пам'яті тепер нижче, на моїх серверах споживання пам'яті ніколи не перевищує 1.5 ГБ. Ви можете запускати без проблем свій вузол на VPS з 2 ГБ з параметром запуску середовища Java - Xmx1536M. Якщо Ви не створюватимете багато трафіку (якщо не публікуватимете свій IP), то споживання пам'яті буде навіть нижче 1 ГБ.
  • Тепер відкрити аккаунт на одному локальному сервері можна тільки в одному вікні браузеру. Якщо у вас були відкриті на цьому ж сервері інші вікна з цим же аккаунтом, вони будуть автоматично закриті(заблоковані).

Іншими словами, якщо Ви відкриваєте декілька вікон браузеру на одному і тому ж сервері (localhost), Ви можете увійти до свого аккаунта тільки в одному вікні, в інших аккаунт автоматично заблокується. При цьому, якщо ви відкриєте свої аккаунти на різних серверах, подібного не станеться, тобто у вас буде запущений декілька копій вашого аккаунта (хоча робити це не рекомендується)

  • При генерації авторизаційного ключа, система також запросить у вас секретну фразу
  • Як Ви помітили (а можливо не помітили), Прозорий Форжинг вже почав працювати. Моє рішення розпочати цей процес з блоку 32000 не було коректно реалізоване у версії 0.4.8 (я припустимо помилку), і вийшло що у версії 0.4.8 процес розпочинався з 30000 блоку. Так блок 30000 був досягнутий - процес працює.
  • Незначні зміни: Додані функції Get Account Aliases, Get Alias URI, і Get Multiple Account Balances на сторінці the https ://localhost:7875/admin.html. Доданий дещо досить відомих вузлів в web.xml.
  • Є одне серйозне питання безпеки, яке не повністю виправлене у версії 0.4.9e. Усі URL запитів зберігаються в кешэ браузеру, при цьому вони не зберігаються в історії браузеру(це пояснює чому ми раніше не виявили цю проблему). Перевірте у себе використовуючи about: cache (у Firefox).
  • І трохи про поганий, враховуючи вищесказане виходить що що Ваша секретна фраза зберігається на диску у відкритому виді, в кешэ браузеру. І я упевнений що рано чи пізно з'являться javascript exploits які зможуть витягати його. Щоб дійсно виправити цю проблему, усе API запити до браузеру, які включають секретну фразу, мають бути посилатися як POST запити, замість GET. Але це зажадає істотних змін в javascript клієнта, що зажадає значного часу.

Оскільки ми не плануємо підтримати тільки javascript клієнт, я не упевнений, що необхідно із за цього переписувати увесь код. У 0.4.9e я, принаймні, додав код в заголовок відповіді, яка запобігає кеширование на диск. Firefox реагує на це, але все одно кеширует URL запити в пам'яті. Щоб гарантувати безпеку, я настійно рекомендую використати окремий профіль браузеру тільки для доступу до Вашого клієнта Nxt або використати приватний режим перегляду. Усі користувачі версії 0.4.8 і більше ранніх, повинні обов'язково очистити кеш свого браузеру

109 Версія 0.4.8

  • Доданий Прозорий Форжинг, Почне працювати після генерації 30000 блоку.
  • Виправлені проблеми з витоком пам'яті.
  • Відправка монет NXT з браузеру тепер обов'язково просить секретну фразу для підтвердження перекладу.
  • Доданий ще один новий параметр в web.xml, myPlatform. Це використовується, щоб оголосити про Вашу платформу - PC, Mac, Raspberry, NeXTstation, VAX, zombie...
  • Починаючи з цієї версії, настановний zip -архив не містить файли blocks.nxt і transactions.nxt. Переконайтеся, що Ви зберігаєте свої власні *.nxt файлів перед оновленням!


110 Версія 0.4.7e (версія, початкові коди якої відкрито публікуються)

  • Alias System не включена в джерело, оскільки це - розширена функція.
  • Прозорий Форжинг також не включений, оскільки цей функціонал буде випущений тільки в 0.4.8 версій. Тому клієнти які будуть скомпільовані з цього початкового коду, зможуть працювати тільки до генерації 30000 блоку на поточному blockchain.
  • Усі мої виправлення проблем з витоком пам'яті і оптимізації продуктивності, які увійдуть до версій 0.4.8 і 0.4.9e, також не включені.
  • Тільки для ознайомлення, розділ завантажень містить скомпільований 0.4.7e двійковий пакет. Json -базовые бібліотеки і Jetty бібліотеки будуть потрібні, щоб скомпілювати початковий код Nxt.java. Як пояснено вище, цей двійковий пакет застарів і не працюватиме з поточним blockchain за межами 30000 блоку.

111 Версія 0.4.6

  • Єдина відмінність від версії 0.4.5 це включені файли blockchain

112 Версія 0.4.5

  • Невеликі виправлення пов'язані з помилкою переповнювання.

113 Версія 0.4.4

  • Додане Jetty DoSFilter (вдячність Edward Elric)
  • Додані параметри myScheme, myPort і shareMyAddress (встановіть їм правильні значення, вони використовуватимуться в наступній версії),
  • Доданий параметр enableHallmarkProtection, встановите цей параметр в"false" якщо Ви хочете вимкнути захист blacklistingPeriod встановлювану в мілісекундах замість секунд!
  • logPeerCommunication замінений на communicationLoggingMask (1 - журнал виключень/помилок, 2 - журнал з відповідями HTTP окрім 200 коду, 4 - журнал з відповідями HTTP, тільки з 200 кодами), значення маски можуть бути об'єднані стандартним способом
  • Блок feeding chunks збільшений з 128 KiB до 1 MiB.

114 Версія 0.4.2

115 Версія 0.4.1e

  • Додана підтримка для CORS (http://publicnxtnode.com:7874/nxt?requestType=getAliasURI&alias=Google тільки запит, включений для перевірки proof - of - concept)
  • JS -скрипты можуть замінити псевдоніми Nxt відповідним URIs за допомогою XMLHttpRequest і document.links
  • Оптимізована алгоритм вибору транзакція. Блоки будуть заповнені на максимальну місткість, попередній алгоритм не вибирав транзакції з низькою комісією, щоб заповнити маленькі проміжки.

116 Версія 0.4.0

  • Додана Alias System, яка буде активована після генерації 22000 блоку
  • Додана сторінка https ://localhost:7875/alias.html для спрощення роботи з аліасами
  • Додані параметри connectTimeout і readTimeout для використання у витікаючих запитах
  • Доданий API https://localhost:7875/nxt?requestType=getAccountId&secretPhrase=123 Повертає номер гаманця пов'язаного з вказаною секретною фразою
  • Доданий API http://localhost:7874/nxt?requestType=getAccountTransactionIds&account=23847569283756&timestamp=0 Повертає ідентифікатори (номери) транзакцій, пов'язаних з вказаним аккаунтом

117 Версія 0.3.20

  • Додана API функція http://localhost:7874/nxt?requestType=getAccountId&secretPhrase=123 Повертає номер гаманця пов'язаного з вказаною секретною фразою.
  • Змінений виклик API функції "sendMoney" (тепер ця функція також повертає байти транзакції)
  • Виправлене "unconfirmedBalance" - проблема з транзакціями які знаходяться в невизначеному стані.
  • Виправлення в API функції "getBalance" при виклику для аккаунтів з генезисного блоку (дивися https://nextcoin.org/index.php/topic, 658.0.html), тепер загальне надання NXTs може бути визначене, через виклик http://localhost:7874/nxt?requestType=getBalance&account=1739068987193023818 (хтось повинен сказати про це власникові coinmarketcap)
  • Додана сторінка http://localhost:7874/admin.html розробка Jean - Luc
  • Додані параметри "pushThreshold" і "pullThreshold" в web.xml, вони допомагають визначити мінімально допустимий рівень ваги для вузла для відсилання/отримання даних (якщо Ви відправляєте багато платежів, Ви повинні встановити значення pushThreshold в 1 або більше, але це збільшує шанс, що транзакції не будуть помічені більшістю вузлів)
  • Видалений файл peers.nxt для відповідності стандартам безпеки BCNext

118 Version 0.3.19e

  • Додані параметри "peerScheme" і "peerPort" d web.xml. "Це зроблено для міграції на HTTPS і інші порти .
  • Доданий параметр "maxNumberOfConnectedPublicPeers" в web.xml. Ваш вузол продовжуватиме спроби з'єднання із загальнодоступними вузлами, поки це число не буде досягнуте. Попередня версія продовжувала підключатися до публічних і приватних вузлів, поки їх кількість не досягала <100
  • Був видалений код пов'язаний з рішенням "Кольорові Монети" (у зв'язку з підготовкою початкового коду до відкритої публікації). Тепер Вам не доведеться копіювати стільки .class файлів.
  • Була зроблена спроба усунути проблему завантаження blockchain із зависанням повідомлення "Catching up.". Я видалив це повідомлення його з .html файлів повністю, таким чином, Ви не бачитимете його більше... Це - жарт, я також змінив декілька рядків серверного коду. Тепер блоки завантажуються значно швидше (2 хвилини в порівнянні з 30 хвилинами в попередній версії), і Ви не повинні блокувати/розблоковувати обліковий запис, щоб "розморозити" завислий виджет "Recent blocks"/"Отримані блоки"(я сподіваюся). Я не зміг перевірити, як зміни обробляють blockchain, коли з'являються "orphaned" блоки, що "осиротіли"/, саме по цьому ця версія "експериментальна". Якщо можливо - встановіть це оновлення і повідомляйте, якщо ви помітите хоч би один "orphaned" блок, що "осиротів"/, або помітите, що blockchain припинив збільшуватися.

119 Версія 0.3.18

11 грудня, 2013

  • Включений hallmark захист для витікаючих запитів
  • Доданий код для використання нестандартних портів для обміну даними між вузлами мережі
  • Доданий код, для міграції до іншого формату файлів blockchain file format (перевірка "blockchainStoragePath" в web.xml, ви можете використати абсолютний шлях)
  • Доданий API виклик http://localhost:7874/nxt?requestType=getUnconfirmedTransactionIds - отримання списку усіх не підтверджених транзакцій.
  • Якщо Ви оголошуєте про адресу свого вузла через "myAddress" ви повинні встановити його в значення повертане параметром "host" з виклику функції http://otherserver.com:7874/nxt?requestType=getMyInfo. У одній з наступних версій вузли почнуть перевіряти, що він відповідає адресі, повертаній із запиту http://docs.oracle.com/javaee/ 6/api/javax/servlet/ServletRequest.html#getRemoteHost()
  • Більше інформації про hallmark захист
    • Тепер помічені (hallmark) вузли притягатимуть більше трафіку. Є 2 типи витікаючих запитів - Send (для отримання невідомих непідтверджених транзакцій, для завантаження blockchain) і SendToAll (для публікації блоків і транзакцій).

Send вибирає один з пов'язаних вузлів залежно від їх ваги (механізм зваженого випадкового вибору зроблений), вузол з вагою = 0 розглядають як вагу = 1, що має. SendToAll відправляє дані вузлам згідно з їх вагами в порядку убування.

120 Версія 0.3.17

10 грудня, 2013

  • Видалений файл accounts.nxt, дані генеририруются на льоту. Якщо ви побачите некоректний баланс - перезапустите клієнт (але обов'язково повідомите про цю помилку, оскільки я на даний момент не можу відтворити цю помилку).
  • Активований механізм автоматизації роботи з чорним списком. Тепер необхідно задавати параметр "blacklistingPeriod" (у секундах) у файлі web.xml для автоматичного видалення вузла з чорного списку, через вказаний час, після попадання в чорний список.
  • Додана API функція http://localhost:7874/nxt?requestType=getPeers для отримання списку усіх вузлів мережі. Детальна інформація про окремий вузол, може бути отримана через виклик функції http://localhost:7874/nxt?* requestType=getPeer&peer=88.198.210.245.
  • Значок Trash тепер працює для видалених користувачів, якщо allowedUserHosts встановлений в що-небудь окрім "*".


121 Версія 0.3.16

8 грудня, 2013

  • Доступно "allowedUserHosts".
  • Доданий параметр "logPeerCommunication" в web.xml
  • Доданий API виклик http://localhost:7874/nxt?requestType=getPeer&peer=88.198.210.245 - дозволяє отримати розгорнуту інформацію про вказаний вузол
  • Доданий API виклик http://localhost:7874/nxt?requestType=getConstants - дозволяє отримати усі доступні вузлу константи і їх значення
  • Заблокований blacklisting (для тестування роботи вузлів при роботі з механізмом вибору)
  • Додана візуалізація ваги вузла

122 Версія 0.3.15

7 грудня, 2013

  • Тепер список відомих вузлів в 0.3.15 формується і вказується гнучкіше і зручно. Подивіться параметр "wellKnownPeers" в nxt/webapps/root/WEB-INF/web.xml. Його можна спокійно міняти, прописуючи необхідні вам дані.
  • Доданий параметр "myHallmark" в web.xml. Якщо Ви - власник значних сум в NXT, Ви повинні запустити свій власний вузол(и), доступний в Інтернеті, щоб захистити мережу. Hallmark використовується, щоб відмітити такі вузли.

123 Версія 0.3.14

6 грудня, 2013

  • Усунена проблема округлення у браузері Opera.

124 Версія 0.3.13

5 грудня, 2013

  • Додано попередження, коли секретна фраза має довжину <30 символів.
  • Додана додаткова перевірка допустимості транзакції (для @hacker: спробуй повторити свій прийом знову)

125 Версія 0.3.12

5 грудня, 2013

  • Оновлення, тільки якщо Ви використовуєте версію 0.3.11 і хочете генерувати блоки. Містить тимчасове обхідне рішення проти непідтверджених транзакцій, що задублювали

126 Версія 0.3.11

5 грудня, 2013

  • Став доступний API виклик "sendMoney".
  • Усунув проблему застарілих непідтверджених транзакцій (@anonymousHacker: перевір це будь ласка).
  • Усунені деякі проблеми, пов'язані з витоком пам'яті при роботі клієнта.

127 Версія 0.3.10

4 грудня, 2013

  • Виклики API тепер доступні на портах 7874 (http) і 7875 (https).
  • Змінений формат виклику API запитів з виду localhost:7876/?request=XXX на localhost:7874/nxt?requestType=XXX
  • Доданий 2 параметри в web.xml:
    • "allowedUserHosts" (зараз доки не активно) і "allowedBotHosts". Приклад значення "allowedBotHosts" - "*" для усіх вузлів або "173.194.70.102; 204.79.197.200" для вказаних.
  • Оскільки швидкий веб-інтерфейс був "відключений", видалите усі *.html файлів в теці "nxt/webapps/root".

128 Версія 0.3.8

4 грудня, 2013

  • Переписаний Web інтерфейс.
  • Тепер HTTP & HTTPS можуть використовуватися (http://localhost:7874 & https://localhost:7875). Останній прийнятніше, якщо Ви використовуєте "онлайн" гаманець. Браузери покажуть попередження про те що сертифікат TLS самоподписаный, постарайтеся додати цей сертифікат в сховище сертифікатів браузеру, щоб позбавитися від попередження.

129 Версія 0.3.6

3 грудня, 2013

  • Доданий "чорний список" вузлів і деякі зміни в інтерфейсі .
  • Залишилося трохи помилок в інтерфейсі, якщо щось не оновилося, використайте F5. На жаль, я деякий час не зможу робити виправлення, оскільки хтось зруйнував мій вузол, використовуючи Jetty уразливість. Зараз мені необхідно в першу чергу виправити проблему Jetty уразливості.

130 Версія 0.3.5

3 грудня, 2013

  • Зменшений тайм-аут вузла з 10 до 2 секунд. Це тимчасове/обхідне рішення для тих, що потрапили в чорний список.

131 Версія 0.3.4

3 грудня, 2013

  • Відновіть, якщо Ви помітили багато непідтверджених транзакцій.
  • Анонімний хакер зробив нам послугу і допоміг з транзакціями, що задублювали. У цій новій версії є швидке/обхідне рішення, щоб позбавитися від таких транзакцій. На щастя блок перевірки був в порядку і не дозволяв, щоб блоки з тими, що задублювали транзакції включалися в ланцюжок.

132 Версія 0.2.20

1 грудня, 2013

  • Включає тільки невеликі виправлення запропоновані Come-from-Beyond.

133 Версія 0.2.19

30 листопада, 2013

  • Виправлення в інтерфейсі, пов'язані з проблемою що виникає при дуже довгому імені вузла.

134 Версія 0.2.18

30 листопада, 2013

  • Зміни в механізмі управління буфером для вузлів API роботів

135 Версія 0.2.17

29 листопада, 2013

  • Деякі незначні зміни в інтерфейсі, тепер Ви можете бачити ідентифікатори транзакції. Встановіть це оновлення, якщо у Вас є проблема зникаючих транзакцій.

136 Версія 0.2.16

28 листопада, 2013

  • Тільки для розробників

137 Версія 0.2.15

28 листопада, 2013

  • Додане 2 API функції

138 Версія 0.2.13

28 листопада, 2013

  • Невеликі виправлення пов'язані з ушкодженням *.nxt фалів

139 Версія 0.2.12

27 листопада, 2013

  • Виправляє зависання "Catching up...".
  • Якщо все ще відбувається зависання, необхідно видалити усі Активні вузли один за одним, після видалення того вузла з якого ви закачали blockchain, завантаження повинне продовжитися з інших вузлів.

140 Версія 0.2.10

26 листопада, 2013

141 Версія 0.2.9

25 листопада, 2013

  • Обов'язкова для усіх, хто зупинився на 303-му блоці.

142 Версія 0.2.8 (минувши версію 0.2.3)

25 листопада 2013

143 Версія 0.2.1

24 листопада, 2013