Topic: NovaCoin (scrypt PoW + PoS hybrid) [self-mod] - page 42. (Read 744449 times)

Исправлено в репозитории, теперь метод всеядный и понимает адрес, пару ключей или вью.

Нет.

Скажите, с 0.5.5 под 0.5.7 нужно базу перекачивать?

Просто она ожидает пару публичных ключей, а не вью. Изначально в выводе validateaddress была пара ключей, но потом она была убрана, тем самым сломав эту функциональность. В ближайшее время починим.

Понятно и работает.
Только немного неудобно, приходится сначала делать validateaddress

, чтобы узнать key view.

Quote from: Balthazar on March 31, 2016, 11:22:14 AM

importmalleablekey <ключ> - для импорта одной пары ключей, соответствующей такому адресу.

Тоже понятно и работает.

Quote from: Balthazar on March 31, 2016, 11:22:14 AM

Команда adjustmalleablepubkey принимает на вход сериализованную пару публичных ключей (можно получить с помощью validateaddress), выдает новый публичный ключ и параметр R (то же самое происходит при отправке монет на длинный адрес).

Тут уже непонятно
Делаю validateaddress, получаю примерно следующее:

Quote

{
"isvalid" : true,
"ispair" : true,
"ismine" : true,
"KeyView" : "7MBg...Brc"
}

Попытка сделать adjustmalleablepubkey 7MBg...Brc выдаёт:

Quote

CMalleablePubKey::GetVariant() : Unable to decode L value (code -1)

importmalleablekey <ключ> - для импорта одной пары ключей, соответствующей такому адресу.
dumpmalleablekey - вытащить из кошелька пару ключей, соответствующую паре ключей для просмотра, которая соответствует адресу.
newmalleablekey - для создания новой пары ключей.

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

Команда adjustmalleablepubkey принимает на вход сериализованную пару публичных ключей (можно получить с помощью validateaddress), выдает новый публичный ключ и параметр R (то же самое происходит при отправке монет на длинный адрес).

Команда adjustmalleablekey принимает на вход пару закрытых ключей, одноразовый публичный ключ и параметр R, и возвращает соответствующий закрытый ключ в пригодном к импорту формате (аналогичное происходит при трате монет, отправленных на длинный адрес).

Как пример, в комбинации с encryptmessage/decryptmessage может использоваться для реализации какого-нибудь самодельного защищенного протокола обмена информацией, со сменой ключа шифрования для каждого сообщения. Получаем новый публичный ключ с помощью adjustmalleablepubkey, шифруем им сообщение и отправляем его адресату, прикладывая к телу сообщения этот публичный ключ и R. Получатель затем с помощью adjustmalleablekey вычисляет закрытый ключ и им расшифровывает сообщение. Стороннему наблюдателю только что и остается строить догадки, наблюдая поток абракадабры.

Вот так мы только что изобрели PGP

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

А как экспортировать-импортировать длинные адреса?

Об одном способе я догадываюсь - через dumpwallet/importwallet.
А есть ли другой метод?

Например, dumpwallet выдал такую информацию:

Существует ли команда, которой можно создать такой же адрес в другом кошельке?

Вижу несколько команд, относящихся к длинным адресам, но не могу понять, как ими пользоваться 

Будет показывать, что на длинном, потому что у клиента есть ключи.

Они там никогда не появятся, потому что эксплореру не из чего их вычислить.

Для понимания этого достаточно прочитать три строчки здесь:

https://bitcointalk.org/index.php?topic=704756.msg13950325;topicseen#msg13950325

Весь смысл уложен в них полностью.

in100
А в управлении входами на каком адресе лежат монеты отправленые на длинный и т.д. во всех местах в клиенте?
Пока длинных в эксплорере не появится так нефига и не поймем как оно должно работать и показываться.
Нужно бы для понимания увидеть как длинные там так и их вместе кучу с переводами с балансами, тогда поймем.
Только с опытом короче.
Ну а когда по другому было? Управление входами без того чтобы в живую видеть тоже было не понятно на  словах на пальцах.

Увы, исключить возможность отправки на него не представляется возможным. Адрес правилен, просто ни один клиент о нем не имеет понятия.

Можно посмотреть код скрипта. Если там "... ... OP_DROP OP_CHECKSIG", то показываемый эксплорером адрес ведет в никуда. По-хорошему, эксплореру надо просто не пытаться вычислять адреса, и как-то обозначить что такой выход не совсем обычен.

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

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

https://gist.github.com/badmofo/92a0aa7c305b44ed1de8

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

Спасибо за разъяснение о том, что не нужно ничего посылать на такие короткие адреса Написал всё в одну строчку, поэтому и не понятно.

А этот адрес является корректным с точки зрения клиента? Лучше бы нет, чтобы исключить возможность отправки на него... Мало ли кому придёт в голову послать "сюрприз"


Хотелось бы на это посмотреть в действии, а то в голове куча вопросов, а как их правильно задать - не понимаю

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

Не совсем понял, как это связано с моим дополнением. Используемый эксплорером алгоритм будет с тем же успехом показывать некие адреса и в том случае, если мы разорвем связь между входами и выходами. Вот только со входами и выходами уже будет не всё так однозначно.

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

Последнее не является эффектом. Видимо, просто эксплорер пока не обновлен и не принимает такие транзакции вне блоков.

Что же до применения, то это является одним из шагов на пути к анонимности, но не гарантирует её само по себе, потому что связи между входами и выходами никуда не деваются. Для гарантии нужен либо миксер, либо разрыв видимой связи между входами на уровне протокола.

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

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

Пример транзакции на длинный адрес: https://explorer.novaco.in/tx/5c449ab3f8442054f0cd92a990d1ad028643c99c0b962c69116b6e54a6d6480e. Потом я перевёл монетку на короткий адрес - это прекрасно видно.
Тут адрес 4SyBKWHZP9cmn3CmKAfbaUj1r6rE9B71q3 - это результат использования длинного адреса. И скорее всего, если снова отправить монеты на тот же длинный адрес (попробую позже), короткий адрес будет уже другой.

И ещё один эффект от использования длинного адреса - транзакция не была видна в эксполорере до её включения в блок.

и насчёт визуализации. правильно ли я понимаю процесс транзакций в этих тёмно-длинных адресах?

A1 (светлый) -> B1 (тёмный)
B2 (тёмный)-> B3 (тёмный)
B4 (тёмный)-> A2 (светлый)

причём то что монеты ушедшие на В1 и монеты отправленные с В2, а также полученные на В3 и полученные на А2, одни и те-же, сторонний наблюдатель знать не может?
т.е. со стороны фомы неверующего выглядит ситуация именно как печатанье монет на адреса В3 и А2 из воздуха, так как невидно откуда изначально те монеты появились. со спекуляциями на тему возможного бага о котором багоюзеры молчат или закладки от разрабов, которой они пользуются.
или тут именно миксер работает, где сумма входов с разных адресов скорее всего разных владельцев равна сумме выходов? и это видно в блоке

Только бы понять, что "мутим" и какие "навороты" имеются в виду. Если юзер хочет сделать перевод с адреса А на адрес Б, то пусть переводит. Вот только то, что адрес Б был юзером опубликован где-то под своим профилем, клиента уже никак не касается. Равно как и следующая из этого деанонимизация связанных переводов.  Неужели действительно не кажется, что смысл таких вещей самоочевиден?

Да ничего не будет ровным счетом, с чего бы быть иначе.

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

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

https://bitcointalk.org/index.php?topic=704756.msg13950325;topicseen#msg13950325

Ничего не имею против абстракций и люблю их, но ехать из СПБ в Москву через Комсомольск-на-Амуре совершенно не считаю обязательным.

P.S. Впрочем, у меня с накручиванием тоже хорошо получается, чуть выше предложение aclon интерпретировал так, что аж испугался от сложности получившейся системы. А ведь речь шла всего-то о мультиподписи.

ё моё! ну вы и мутите))) Вы потом только документацию к этим наворотам сделайте плиз, а то уже стрёмно монеты с кошелька переводить, не дай бог с короткого на длинный или наоборот адрес переведёшь и усё, капец...