Возможен лишь обмен по курсу, равному соотношению номиналов.
А что, реально в сети одной крипты подвесить предложение на покупку другой крипты по соответствующему курсу, чтобы потом в сети второй крипты это предложение увидели и продали ее по этому курсу? (предположим, что одна или обе крипты поддерживают такую фичу) Или это нужен аналог p2pool или еще что-то такое? 
Topic: NovaCoin (scrypt PoW + PoS hybrid) - page 114. (Read 600924 times)
Идея отличная, а В NVC клиент будет встроен такой своего рода "майнинг" с процентами от "отмытого"?
Пока непонятно, но вполне возможно. Кстати, в Bitcoin рано или поздно подобный механизм будет реализован (core девелоперы активно обсуждают такие схемы). Но вряд ли попадет в официальный клиент в ближайшее время, потому что Bitcoin Foundation слишком озабочены "дружбой" с сильными мира сего.И почему не поддержать Zerocoin? В идеале можно было бы еще и рассмотреть возможность обмена валютами через общую поддержку Zerocoin(аля p2p биржа), т.е. когда не только происходит микс, но еще и разные номиналы... Т.е. закидываешь ты в систему монеты с пометкой обменять на столько то другого, и имеешь на выходе права на другую валюту...
Что же до обмена через общую платформу на базе Zerocoin, то это проблематично. Весь смвсл протокола в том, что он не сохраняет никаких связей. Юзер создает одну монету Zerocoin и потом её обналичивает, это атомарная операция. То есть, у монеты Zerocoin есть номинал в валюте сети, и он фиксирован. Пользователь не может указать свой номинал, потому что при обналичивании нельзя будет его проверить. Поэтому кросс-сетевое обналичивание монет серьезно ограничено... Возможен лишь обмен по курсу, равному соотношению номиналов.
Идея отличная, а В NVC клиент будет встроен такой своего рода "майнинг" с процентами от "отмытого"?
Пока непонятно, но вполне возможно. Кстати, в Bitcoin рано или поздно подобный механизм будет реализован (core девелоперы активно обсуждают такие схемы). Но вряд ли попадет в официальный клиент в ближайшее время, потому что Bitcoin Foundation слишком озабочены "дружбой" с сильными мира сего.И почему не поддержать Zerocoin? В идеале можно было бы еще и рассмотреть возможность обмена валютами через общую поддержку Zerocoin(аля p2p биржа), т.е. когда не только происходит микс, но еще и разные номиналы... Т.е. закидываешь ты в систему монеты с пометкой обменять на столько то другого, и имеешь на выходе права на другую валюту...
Собственно, Zerocoin нам и не очень-то нужен для этого. Основной проблемой классических миксеров является то, что они могут сбежать с монетами, т.к. перемешиваемые монеты проходят через их кошелек и временно даются им в полное распоряжение. Однако, это не является единственно возможным вариантом. К примеру, возможен такой концепт:
...
но забыли еще одну проблему миксеров - миксер ЗНАЕТ историю перемешанных монет, так как он определяет чьи входы кому отправлять....
Пример:
10 монет от Алисы => | | => 4.99 монет
| | => 3.99 монет
| | => 1 монета
10 монет от Боба => | | => 10.01 монет
Ну и кто здесь есть кто? Алиса даже не сможет доказать кому-то, что другие 10 монет не принадлежат ей и что транзакция не является обычным переводом 20 монет ХЗ кому. Кроме того, все три первых выхода могут принадлежать совершенно разным людям, которые могут даже и не подозревать о том, что в транзакции имел место какой-то посредник. И это всего лишь единичная ситуация, а что будет в случае массовой автоматизации процесса? А если к выходам добавлять еще выходы с типом SIGHASH_NONE или ANYONECANPAY, которые могут и будут тратить любые участники сети? Полная мозголомка будет, вот что... Что и нужно.
Конечно, лучше Zerocoin пока ничего не придумали, но на практике концепт объединения инпутов тоже способен внести анонимность в псевдоанонимную систему, при этом укладываясь в рамки существующего протокола и не внося потенциальных уязвимостей.
Даешь обработку транзакций на базе гомоморфного шифрования
В блокчейне в принципе не должно быть ничего зашифрованного и закрытого, даже если проверку зашифрованных данных можно сделать без знания ключей. Это главное идеологическое требование к криптовалютам в целом. Оно даже важнее, чем открытость исходных текстов.Идея отличная, а В NVC клиент будет встроен такой своего рода "майнинг" с процентами от "отмытого"?
Пока непонятно, но вполне возможно. Кстати, в Bitcoin рано или поздно подобный механизм будет реализован (core девелоперы активно обсуждают такие схемы). Но вряд ли попадет в официальный клиент в ближайшее время, потому что Bitcoin Foundation слишком озабочены "дружбой" с сильными мира сего. О миксинге и анонимности.
Алиса поддерживает свой сервис для очистки монет, в её распоряжении является некий объем выходов с разными адресами и суммами (публичный, либо доступный по запросу). Боб имеет на руках "серые" 10 NVC, и хочет сделать "неочевидной" их историю.
Для защиты от DoS атак можно использовать proof-of-work таким образом:
Идея отличная, а В NVC клиент будет встроен такой своего рода "майнинг" с процентами от "отмытого"? Алиса поддерживает свой сервис для очистки монет, в её распоряжении является некий объем выходов с разными адресами и суммами (публичный, либо доступный по запросу). Боб имеет на руках "серые" 10 NVC, и хочет сделать "неочевидной" их историю.
Для защиты от DoS атак можно использовать proof-of-work таким образом:
Собственно, Zerocoin нам и не очень-то нужен для этого. Основной проблемой классических миксеров является то, что они могут сбежать с монетами, т.к. перемешиваемые монеты проходят через их кошелек и временно даются им в полное распоряжение. Однако, это не является единственно возможным вариантом. К примеру, возможен такой концепт:
...
но забыли еще одну проблему миксеров - миксер ЗНАЕТ историю перемешанных монет, так как он определяет чьи входы кому отправлять....
Закапывайте!
Даешь обработку транзакций на базе гомоморфного шифрования, вон и генетики задумались о сохранении приватности изучаемых ими генных карт.
О миксинге и анонимности.
Собственно, Zerocoin нам и не очень-то нужен для этого. Основной проблемой классических миксеров является то, что они могут сбежать с монетами, т.к. перемешиваемые монеты проходят через их кошелек и временно даются им в полное распоряжение. Однако, это не является единственно возможным вариантом. К примеру, возможен такой концепт:
Дано:
Алиса поддерживает свой сервис для очистки монет, в её распоряжении является некий объем выходов с разными адресами и суммами (публичный, либо доступный по запросу). Боб имеет на руках "серые" 10 NVC, и хочет сделать "неочевидной" их историю.
Что делаем:
1. Боб создает транзакцию, в которой включает свои 10 NVC на входе плюс взятый из блокчейна выход Алисы.
2. На выходах добавляет возврат монет Алисы на адреса, с которых они были взяты (+ небольшое вознаграждение), и создает выход для своей суммы.
3. Боб подписывает транзакцию ключами от своих входов и отправляет её специальным сообщением JOIN_TX.
4. Алиса получает новое сообщение JOIN_TX, видит что в нем использованы её инпуты. Если в клиенте соответствующие инпуты были ранее ей помечены, как доступные для перемешивания, то происходит проверка суммы на выходе с последующим подписыванием и отправкой в сеть полноценной транзакции.
Результат:
Итогом мы имеем то, что Алиса получила небольшой доход, Боб же получил новые выходы с "отбеленной" историей. При этом Алиса не может поменять выходы "недоделанной" транзакции Боба без инвалидации его подписи, ей остается только согласиться или не согласиться с проведением операции.
Конечно, одностадийный процесс менее эффективен, чем известные миксинг-сервисы, которые делают множество итераций с разбивкой-склеиванием. Однако, и здесь ничто не мешает повторять процесс произвольное количество раз. Для защиты от DoS атак можно использовать proof-of-work таким образом:
Где join_target может определяться миксинг-сервисом, либо меняться в зависимости от количества корректных JOIN-транзакций в буфере, к примеру.
Главное и очевидное преимущество - итоговые транзакции ничем не отличаются от "обычных", а потому не требуется никаких изменений в протоколе.
Возможные вариации:
1. Создание выходов на адреса, указанные Алисой, с рекомендуемым ей распределением части монет, которой она владеет.
2. Использование рандомизированного распределения монет Боба на выходах.
3. <...>
Собственно, Zerocoin нам и не очень-то нужен для этого. Основной проблемой классических миксеров является то, что они могут сбежать с монетами, т.к. перемешиваемые монеты проходят через их кошелек и временно даются им в полное распоряжение. Однако, это не является единственно возможным вариантом. К примеру, возможен такой концепт:
Дано:
Алиса поддерживает свой сервис для очистки монет, в её распоряжении является некий объем выходов с разными адресами и суммами (публичный, либо доступный по запросу). Боб имеет на руках "серые" 10 NVC, и хочет сделать "неочевидной" их историю.
Что делаем:
1. Боб создает транзакцию, в которой включает свои 10 NVC на входе плюс взятый из блокчейна выход Алисы.
2. На выходах добавляет возврат монет Алисы на адреса, с которых они были взяты (+ небольшое вознаграждение), и создает выход для своей суммы.
3. Боб подписывает транзакцию ключами от своих входов и отправляет её специальным сообщением JOIN_TX.
4. Алиса получает новое сообщение JOIN_TX, видит что в нем использованы её инпуты. Если в клиенте соответствующие инпуты были ранее ей помечены, как доступные для перемешивания, то происходит проверка суммы на выходе с последующим подписыванием и отправкой в сеть полноценной транзакции.
Результат:
Итогом мы имеем то, что Алиса получила небольшой доход, Боб же получил новые выходы с "отбеленной" историей. При этом Алиса не может поменять выходы "недоделанной" транзакции Боба без инвалидации его подписи, ей остается только согласиться или не согласиться с проведением операции.
Конечно, одностадийный процесс менее эффективен, чем известные миксинг-сервисы, которые делают множество итераций с разбивкой-склеиванием. Однако, и здесь ничто не мешает повторять процесс произвольное количество раз. Для защиты от DoS атак можно использовать proof-of-work таким образом:
Code:
while (scrypt(tx) < join_target) {
tx = txNew;
tx.nTime = GetTime();
signScripts(tx);
}Где join_target может определяться миксинг-сервисом, либо меняться в зависимости от количества корректных JOIN-транзакций в буфере, к примеру.
Главное и очевидное преимущество - итоговые транзакции ничем не отличаются от "обычных", а потому не требуется никаких изменений в протоколе.
Возможные вариации:
1. Создание выходов на адреса, указанные Алисой, с рекомендуемым ей распределением части монет, которой она владеет.
2. Использование рандомизированного распределения монет Боба на выходах.
3. <...>
Но в сам блок эта множественная подпись не запихивается во избежание конфликта с предыдущими версиями блоков, а используется только пока надо утвердить конкретный PoW-блок в сети. Я правильно понял?
Да, все правильно.P.S. Cкоро 77777 -й блок
Данные сообщения не включаются в блокчейн и не подвергаются дополнительным проверкам. Единственный способ валидации таких сообщений - это сравнение публичного ключа с тем, что прописан в клиенте. Если эту проверку убрать, то можно будет атаковать сеть, отправив набор отличающихся алертов этак в пару терабайт совокупным объемом. То есть, именно недоступность ключа и ограниченность списка отправителей делает возможным безопасное функционирование данного механизма.
В случае с подписями PoW блоков эта проблема решается все так так же, ограничением списка отправителей. Кроме того, в данном механизме будут еще дополнительные ограничения на подписываемые данные (только хэш и только конкретного блока).
В случае с подписями PoW блоков эта проблема решается все так так же, ограничением списка отправителей. Кроме того, в данном механизме будут еще дополнительные ограничения на подписываемые данные (только хэш и только конкретного блока).
Кстати...
The problem is that there is no easy way to communicate between sender and receiver right now, apart from via the block chain (which works, but as a means of communication it is slow, inefficient, expensive and unreliable).
А не захламляя блокчейн способа нет... Бальтазар, а вот эта широковещательная рассылка, которую разраб может кидать всем юзерам сразу, ее можно как-то подкрутить, чтобы сообщения были адресными для какого-то конкретного кошелька?
В предложенном виде никогда, скорее всего.
http://bitcoin.stackexchange.com/questions/5948/can-i-send-message-inside-the-transactions-script
Я думаю, нет причин сомневаться в том, что Pieter Wuille прав в том, что не следует захламлять блокчейн нерелевантными данными. Потому что эти данные не нужны никому, кроме участников сделки. Нет смысла транслировать их по всему свету, расходуя полезный ресурс сети.
http://bitcoin.stackexchange.com/questions/5948/can-i-send-message-inside-the-transactions-script
Quote
Can I send message inside the transactions script?
You can, but you shouldn't. Bitcoin transactions should only contain the information needed for the world to verify your transaction. Anything else is essentially private information between the sender and the receiver, and would be useless bloat to the block chain (making it more expensive to maintain for everyone).
That doesn't mean you can't have messages attached to transactions at all, of course. The problem is that there is no easy way to communicate between sender and receiver right now, apart from via the block chain (which works, but as a means of communication it is slow, inefficient, expensive and unreliable). The payment protocol currently being worked on (see the current draft, or the mailing list archives) should solve this very neatly, as it supports transaction metadata that does not become part of the resulting Bitcoin transaction.
share improve this answer
answered Jan 1 '13 at 23:26
Pieter Wuille
8,3021929
You can, but you shouldn't. Bitcoin transactions should only contain the information needed for the world to verify your transaction. Anything else is essentially private information between the sender and the receiver, and would be useless bloat to the block chain (making it more expensive to maintain for everyone).
That doesn't mean you can't have messages attached to transactions at all, of course. The problem is that there is no easy way to communicate between sender and receiver right now, apart from via the block chain (which works, but as a means of communication it is slow, inefficient, expensive and unreliable). The payment protocol currently being worked on (see the current draft, or the mailing list archives) should solve this very neatly, as it supports transaction metadata that does not become part of the resulting Bitcoin transaction.
share improve this answer
answered Jan 1 '13 at 23:26
Pieter Wuille
8,3021929
Я думаю, нет причин сомневаться в том, что Pieter Wuille прав в том, что не следует захламлять блокчейн нерелевантными данными. Потому что эти данные не нужны никому, кроме участников сделки. Нет смысла транслировать их по всему свету, расходуя полезный ресурс сети.
когда вы уже добавите сообщения к сделке? тут вон всякие нубские ф-орки это себе уже понавставляли
за доп комиссию при переводе конечно же - можно за удвоенную или утроенную за каждый кБ сообщения но немнее 0.00001
за доп комиссию при переводе конечно же - можно за удвоенную или утроенную за каждый кБ сообщения но немнее 0.00001
Неподписанный PoW-блок подписывают PoS-майнеры, попавшие "под раздачу"?
Да, именно так.Это дополнительные подписи к блоку? Или полная замена изначальной подписи PoW-майнера?
У PoW майнера нет подписи.То есть, получается, до введения этой фичи любые PoW-блоки не имели подписи вообще. Теперь она как бы появляется и для PoW-блоков. Да еще и много подписей.
Но в сам блок эта множественная подпись не запихивается во избежание конфликта с предыдущими версиями блоков, а используется только пока надо утвердить конкретный PoW-блок в сети. Я правильно понял?
Code:
13:10:52
getdifficulty
13:10:52
{
"proof-of-work" : 350.25699910,
"proof-of-stake" : 0.27682852,
"search-interval" : 1
}
Драконий хребет сложности переламываться не собирается.
до вики еще надо дойти и иметь к этому мотивацию. Краткие тезисы уж точно лишними не будут. Помле кратких тезисов можно и ссылку на подробности в вики. Кстпти, вики же русскоязычная? Тогда что видит иностранец? Нихера.
ещё раз обновил домашнюю страничку... добавил немного ссылочек и инфы...
Неподписанный PoW-блок подписывают PoS-майнеры, попавшие "под раздачу"?
Да, именно так.Это дополнительные подписи к блоку? Или полная замена изначальной подписи PoW-майнера?
У PoW майнера нет подписи.Эти дополнительные подписи где-то хранятся или используются для текущей работы сети, а потом забываются?
Вот это как раз и непонятно пока, нужно ли их хранить после того, как пройдено окно подтверждения. По идее, они вообще нужны лишь в пределах ограниченного интервала времени, в течение которого пул может поиграться с майнингом шар для потомка орфана. В таком варианте применения их можно даже и на диск не сохранять.
Неподписанный PoW-блок подписывают PoS-майнеры, попавшие "под раздачу"?
Это дополнительные подписи к блоку? Или полная замена изначальной подписи PoW-майнера?
Эти дополнительные подписи где-то хранятся или используются для текущей работы сети, а потом забываются?
Это дополнительные подписи к блоку? Или полная замена изначальной подписи PoW-майнера?
Эти дополнительные подписи где-то хранятся или используются для текущей работы сети, а потом забываются?
Да все очевидно, вроде бы. 
1. Неподписанный блок.
2. Сообщение с подписанным хэшем блока.
3. Из последних блоков непредсказуемым, но однозначным способом выбирается некоторое количество PoS майнеров, которые могут подписать текущий PoW блок.
4. Нисколько и никаких.
1. Неподписанный блок.
2. Сообщение с подписанным хэшем блока.
3. Из последних блоков непредсказуемым, но однозначным способом выбирается некоторое количество PoS майнеров, которые могут подписать текущий PoW блок.
4. Нисколько и никаких.
Так ниже же уже расписано что, и о чем. Хотя в целом, это пока проект проекта, а не полноценная идея.
Да вот в том то и загвоздка, что там не до конца все понятно.Quote
Суть идеи проста и похожа на жеребьевку. По детерминированному алгоритму функция принятия блока выбирает N proof-of-stake блоков из прошлого. Это делается таким образом, чтобы выборка была всегда идентичной для конкретного блока, но нельзя или сложно было бы предсказать результат выборки для блока в будущем. Далее из этих блоков берутся публичные ключи vin[0] коинстейк-транзакции. Вот это и будут те самые холдеры, которым будет предложено подписать блок-кандидат.
Если конкретный юзер, получив блок, видит в списке публичных ключей свой, то он может отправить в сеть специальное сообщение, которое доставит всем нодам его подпись для этого блока. Ну а дальше все просто - чем больше подписей от юзеров из списка собрано блоком, тем больше его приоритет над остальными при прочих равных.
Таким образом, чтобы развлекаться с selfish mining, пулу типа ghash.io придется иметь очень весомую долю proof-of-stake блоков в прошлом. Тогда у него есть шанс того, что в списке окажутся его ключи в достаточном для перевеса количестве. В противном случае у него шансов нет, потому что блок оффлайн-цепочки не сможет набрать больше подписей, чем блок, который видели все.
Если конкретный юзер, получив блок, видит в списке публичных ключей свой, то он может отправить в сеть специальное сообщение, которое доставит всем нодам его подпись для этого блока. Ну а дальше все просто - чем больше подписей от юзеров из списка собрано блоком, тем больше его приоритет над остальными при прочих равных.
Таким образом, чтобы развлекаться с selfish mining, пулу типа ghash.io придется иметь очень весомую долю proof-of-stake блоков в прошлом. Тогда у него есть шанс того, что в списке окажутся его ключи в достаточном для перевеса количестве. В противном случае у него шансов нет, потому что блок оффлайн-цепочки не сможет набрать больше подписей, чем блок, который видели все.
Вообще запутался. Можно по пунктам?
1. Что мы имеем на входе?
2. Что мы имеем на выходе?
3. Если это накопительный приоритет PoS-майнеров, то где он копится и хранится?
4. Сколько это отъедает ресурсов и каких?
Jump to: