NovaCoin (scrypt PoW + PoS hybrid)

[mall]

на русский с переводом, думаю, справлюсь, а вот на китайский -- вряд ли уже

с чего вдруг?бюро переводов сквозь землю не провалилось!

[1714615184]

1714615184

[alpet]

идеально, по-моему, было бы исполнить в монетах из золота

У меня есть самые разные монеты из золота и серебра. Но вот фотокамеры пока нет, жду когда в России начнут Panasonic GH4 продавать.

[fruit]

Ты слишком глубоко в будущее копнул, сейчас если такой ИИ инструмент есть, то он не в руках простых смертных.

Не то что тебя не будет волновать судьба других профессий, а даже понятия профессия не будет в той мере в которой было.
Разрядов и категорий считай нет уже. Скоро не будет и профессий.
Так же уже все идет к тому что скоро не будет и денег, их уже нет в том виде в котором они были.
Будет ли вместо этого время жизни в секундах или что-то иное, не известно, но точно не деньги в том виде что были когда-то.

Поэтому масс-медиа просто лишится той роли что у него есть сейчас. У него останется лишь развлекательная и ее порежут.
Зачем что-то одно говорить всей массе? Это же большой труд. Могут и взбунтовать если что не так.
С каждым по отдельности общаться на злободневные темы гораздо перспективней.

Если директора и начальники отделов это поняли, то неужели не поймет правительство?

https://bitcointalk.org/index.php?topic=644662.0

[RoadTrain]

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

[Balthazar]

2) В будущих версиях будет реализован опциональный механизм One-Time Public Key, и вовсе делающий подобную технологию неработоспособной. Потому что адреса будут одноразовые, генерирующиеся из пары публичных ключей и случайного seed. Одна транзакция - один адрес, и никаких повторений. С помощью имеющихся закрытых ключей получатель в любой момент сможет восстановить все свои  одноразовые адреса, использованные в сети когда-либо, но сторонние наблюдатели сделать этого не смогут.

Тестовая реализация генератора готова, в общем-то, будет доступна для экспериментов на этой или следующей неделе.

Пара слов о том, как это работает.

Действия пользователя:

1) Пользователь генерирует и сохраняет пару secp256k1 приватных ключей (l, h);
2) Публикует пару соответствующих им публичных ключей (L, H). Они используются желающими отправить пользователю транзакцию.

Действия отправителя:

Отправитель генерирует секретное 256-бит случайное число r, затем вычисляет одноразовый публичный ключ и несекретное значение следующим образом:

K_p = G * Hash₁₆₀(L*r) + H
R = G*r

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

Действия получателя:

Извлечь из транзакции R, затем для каждого выхода проверить равенство:

K_p == G * Hash₁₆₀(R*l) + H

Если равенство верно, значит выход принадлежит получателю, и он может вычислить приватный ключ следующим образом:

K = Hash₁₆₀(R*l) + h

Hash₁₆₀ - стандартная для сатоши-клиента функция взятия ID ключа;
G - базовая точка secp256k1 (см. тут);
"*" - операция умножения точки эллиптической кривой на число (подробнее здесь).

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

http://www.theregister.co.uk/2013/08/12/android_bug_batters_bitcoin_wallets/

 

[Balthazar]

Не понятно как это в блокчейне будет выводится.

Так же как и сейчас, просто адреса не будут повторяться. К примеру, там где с биржи или пула были регулярные переводы на один адрес, будет множество переводов на разные адреса.

[aclon]

чтото кошелёк перестал блоки закачивать. безо всякого аварийного завершения, на компе который не выключался.
0.4.4.7 b5

[tsrman]

такая же фигня
в логах:
ERROR: ProcessBlock() : invalid signatures found in proof-of-stake block c10c1642eb216cd402af542e6e5aa2ecb113210ddf53b051f614b49bdb2a7731
и
ProcessSyncCheckpoint: pending for sync-checkpoint cf36f96b8a4586b2b8117f61e73ab9db104764c72da98928f36f5d7f44bbb6a6

[fruit]

Для случаев покупки оружия и прочего оно не годится, там всеравно миксеры нужны.

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

Если речь о политическом убийстве, опять же - покупка оружия не нужна.

А по поводу анонимности и криптографии вот:
"За последние 10 лет в США было лишь 13 случаев, когда криптография помешала расследовать преступления"
http://habrahabr.ru/post/228727/

[Balthazar]

К сожалению, в 0.4.4.7 обнаружилась критическая ошибка. Всем следует откатиться до 0.4.4.6 update 3 до тех пор, пока она не будет обнаружена и исправлена.

Соответствующие бинарники выложены на sourceforge для платформ, на которых собрать самостоятельно будет проблемой. Исходники же доступны в бранче legacy:

git clone -b legacy https://github.com/novacoin-project/novacoin

Причина проблемы выясняется.

Проблема же заключается в том, что некоторые блоки "не нравятся" новому клиенту.

Правильная цепочка на данный момент состоит из 107621 блоков, блок #107620 имеет хэш 000000000070ac2d51c8b288dcb18adca11bd4571a8e8c7e27fad3994980c7fd.

[sleekka]

Тестовая реализация генератора готова, в общем-то, будет доступна для экспериментов на этой или следующей неделе.

Пара слов о том, как это работает.

Действия пользователя:

1) Пользователь генерирует и сохраняет пару secp256k1 приватных ключей (l, h);
2) Публикует пару соответствующих им публичных ключей (L, H). Они используются желающими отправить пользователю транзакцию.

Действия отправителя:

Отправитель генерирует секретное 256-бит случайное число r, затем вычисляет одноразовый публичный ключ и несекретное значение следующим образом:

Kp = G * Hash160(L*r) + H
R = G*r

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

Действия получателя:

Извлечь из транзакции R, затем для каждого выхода проверить равенство:

Kp == G * Hash160(R*l) + H

Если равенство верно, значит выход принадлежит получателю, и он может вычислить приватный ключ следующим образом:

K = Hash160(R*l) + h

Hash160 - стандартная для сатоши-клиента функция взятия ID ключа;
G - базовая точка secp256k1 (см. тут);
"*" - операция умножения точки эллиптической кривой на число (подробнее здесь).

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

Я конечно прикладной программист, но мало что понятно, это типа darkwallet - чтоли?

[Balthazar]

Подтверждено, что в 0.4.4.6 никаких проблем с синхронизацией нет. Также известно, что принадлежность к версии 0.4.4.7 не означает, что клиент гарантированно не сможет синхронизироваться, это плавающая ошибка и она проявляется не всегда. В любом случае, следует пока откатиться на 0.4.4.6 u2/u3.

Отправил в сеть алерт клиентам 0.4.4.7b5, чтобы зашли в тему.

Я конечно прикладной программист, но мало что понятно, это типа darkwallet - чтоли?

Скорее, deterministic wallet, только механизм прозрачен для получателя и отправителя.

[sleekka]

У меня 0.4.4.6 update beta1 - все ок

[alpet]

В районе часа ночи тоже заметил отставание, списал это на проблемы с переключением роутера сначала. А потом поставил базу с нуля перезакачиваться, и она закачалась.

[Balthazar]

В районе часа ночи тоже заметил отставание, списал это на проблемы с переключением роутера сначала. А потом поставил базу с нуля перезакачиваться, и она закачалась.

Именно так это и выглядит почти в 100% таких случаев.

[alpet]

Именно так это и выглядит почти в 100% таких случаев.

Так есть веский резон откатываться или можно подождать фикса 4.4.7 ?

[svost]

debug.log поможет чем?

[Balthazar]

Так есть веский резон откатываться или можно подождать фикса 4.4.7 ?

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

debug.log поможет чем?

Привет. Если выложишь каталог с данными, без wallet.dat, то он был бы полезен для статистики.

[alpet]

Моя копия поврежденной БД здесь 191Mb.

[Balthazar]

В качестве оптимального решения вопроса будет проделано следующее.

Ветка 0.4.4.6 будет разморожена и станет основной. Для неё выйдет обновление, интегрирующее последние изменения интерфейса и протокола из 0.4.4.7b5.

Ветка 0.4.4.7 пока отправится обратно в песочницу, до устранения проблем с движком CoinsDB.

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