NovaCoin (scrypt PoW + PoS hybrid) [self-mod]

[info_infoman]

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

а чем не подходит на роль отсечки "диагональный чекпоинт"
ну такой чекпоинт который берет все не потраченные старые входы и фиксирует их наряду с текущими

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

[gades]

а чем не подходит на роль отсечки "диагональный чекпоинт"

анонимность монеты возрастет из-за невозможности через время увидеть от куда был вход (разве у кого-то будет клиент для записи архива)

Интересно, а кто-то проводил анализ блоков в которых есть полностью потрачены входы (может из стоит убирать в первую очередь)?

А зачисткой будут заниматься PoS майнеры и в найденом блоке PoS указывать какой блок можно удалить будет (и через 520 подтверждений это делается)

[Foxcool]

норм

[aclon]

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

[RoadTrain]

там суть идеи не состоит в том, чтобы сильно плотно испольховатьблокчеин. Просто отследить, сделан ли перевод с такого адреса на другой или нет. Для этого достаточно консольного валета и достапа к нему по рпц. Как-то более плотно завязываться на блокчеин и тем более хранить в нем важные данные я бы не стал. Думаю, что рано или поздно люди начнут думать, как избавиться от старых частей цепочек, чтобыне хранить терабайты говна у себя. Тем более это актуально для валют типа новы, где по идее майнеров должно быть не 5-10, как в битке (пулов), а тысячи с включенным ПОС.

Как я себе представляю такой плагин. При отправке сообщения плагин формирует "снимок" сообщения и вычисляет его хэш. Затем хэш запечатывается в транзакцию, а id транзакции прикрепляется к письму.
Получатель соответственно тоже формирует снимок, вычисляет его хэш и сверяет его с хэшем в блокчейне (обращаясь к кошельку новы по RPC).

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

[svost]

При отправке сообщения плагин формирует "снимок" сообщения и вычисляет его хэш. Затем хэш запечатывается в транзакцию, а id транзакции прикрепляется к письму.

При повсеместном внедрении что станет с размером блокчейна новы?

[RoadTrain]

При отправке сообщения плагин формирует "снимок" сообщения и вычисляет его хэш. Затем хэш запечатывается в транзакцию, а id транзакции прикрепляется к письму.

При повсеместном внедрении что станет с размером блокчейна новы?

Ничего хорошего, поэтому в первую очередь нужно поработать с масштабируемостью.

[info_infoman]

При отправке сообщения плагин формирует "снимок" сообщения и вычисляет его хэш. Затем хэш запечатывается в транзакцию, а id транзакции прикрепляется к письму.

При повсеместном внедрении что станет с размером блокчейна новы?

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

[alpet]

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

[RoadTrain]

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

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

Если делать как в биткойне - записывать информацию в выход с OP_RETURN, то ограничение на длину данных - 40 байт. Поэтому лучше пихать хэш, ведь почтовый адрес может быть длиннее.
Можно хэшировать только адреса отправителя и получателя, плюс сверка времени транзакции и времени приёма/отправки письма

[penek]

Написал ебилд для сборки любой произвольной версии novacoin-qt.
Если гентушники тут бывают -- тестирование на предмет поиска багов всячески приветствуется.

http://i68.fastpic.ru/big/2014/0925/23/a82b427a01fcb6d8403395cb4f256623.png

novacoin ebuild: novacoin-0.4.4.6-r9.ebuild

выложил на домашнюю страницу https://novaco.in ...
и развил тему до полноценного portage...

[alpet]

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

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

[RoadTrain]

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

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

Как мы узнаём адрес кошелька получателя? Получается, что кроме мейла мы должны знать и адрес кошелька?

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

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

[alpet]

Как мы узнаём адрес кошелька получателя? Получается, что кроме мейла мы должны знать и адрес кошелька?

Мне казалось я это описал в ТЗ. Что по умолчанию плагин отвечает на письмо без транзакции автоматическим запросом, что ему требуется цифровая марка по такому-то адресу.  И с другой стороны плагин должен перехватить запрос, с уведомлением владельца или без оного - повторно отправить исходное письмо уже транзакцией. А платеж в никуда или по произвольному адресу, это уже совсем другая штука получается - гораздо менее мотивирующая пользователей пользоваться данным решением.
Кстати, ещё нужно продумать как избежать подмены адреса в автоматическом запросе потенциальным перехватчиком "man-in-middle".

[fsb4000]

интересный проект попался на глаза:
https://www.bitcoinauthenticator.org/

[RoadTrain]

Как мы узнаём адрес кошелька получателя? Получается, что кроме мейла мы должны знать и адрес кошелька?

Мне казалось я это описал в ТЗ. Что по умолчанию плагин отвечает на письмо без транзакции автоматическим запросом, что ему требуется цифровая марка по такому-то адресу.  И с другой стороны плагин должен перехватить запрос, с уведомлением владельца или без оного - повторно отправить исходное письмо уже транзакцией. А платеж в никуда или по произвольному адресу, это уже совсем другая штука получается - гораздо менее мотивирующая пользователей пользоваться данным решением.
Кстати, ещё нужно продумать как избежать подмены адреса в автоматическом запросе потенциальным перехватчиком "man-in-middle".

Это описано в ТЗ, но как опция
Насчёт подмены адреса, ведь если его поменять, то это инвалидирует подпись (по крайней мере должно, если адреса хэшировать).

[sleekka]

Какой-нибудь пдф с содержанием того что наобсуждали по поводу безспамовой почты кто-нибудь ведет. Описание всей идеи?

[mall]

penek
когда переводы будут опубликованы ?

[penek]

penek
когда переводы будут опубликованы ?

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

[alpet]

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

Имеется в виду запрос цифровой марки плагином получателя. Отправитель должен как-то удостовериться, что отправляет цифровую марку получателю письма (при потенциальном использовании ненадежного сервера).