https://github.com/novacoin-project/novacoin/wiki/Proof-of-stake
Добавил пример расчета вероятностей вероятностей.
Topic: NovaCoin (scrypt PoW + PoS hybrid) - page 120. (Read 600924 times)
я победитель по жизни. Уже под 2000 веса инпута, а блок не ловится. 
"proof-of-stake" : 0.24028555
Стремимся к 1
Стремимся к 1
Если на странице http://coinmarketcap.com/ кликнуть по Novacoin, то переходим на http://novaco.in/. Там WOT тут же орет. Ну это вы в курсе. Далее, что мы видим: вся инфа
Novacoin is a decentralized digital currency based on an open-source, peer-to-peer internet protocol.
It was introduced by a developer named Balthazar in 2013. Get sources or binaries.
ну и далее инфа о последних блоках. Ни о PoS, ни о прочих преимуществах не говорится.
Novacoin is a decentralized digital currency based on an open-source, peer-to-peer internet protocol.
It was introduced by a developer named Balthazar in 2013. Get sources or binaries.
ну и далее инфа о последних блоках. Ни о PoS, ни о прочих преимуществах не говорится.
Продолжаю потихоньку пополнять доки:
https://github.com/novacoin-project/novacoin/wiki/Proof-of-stake
https://github.com/novacoin-project/novacoin/wiki/Coin-Age
https://github.com/novacoin-project/novacoin/wiki/CoinDayWeight
https://github.com/novacoin-project/novacoin/wiki/Transaction
Пока поверхностно, но уже полезно.
https://github.com/novacoin-project/novacoin/wiki/Proof-of-stake
https://github.com/novacoin-project/novacoin/wiki/Coin-Age
https://github.com/novacoin-project/novacoin/wiki/CoinDayWeight
https://github.com/novacoin-project/novacoin/wiki/Transaction
Пока поверхностно, но уже полезно.
Не сможет, если изначальное условие будет немного более сложным. К примеру, не только соответствие хэша пароля, но и соответствие адреса. Тогда такой скрипт обналичить сможет только его создатель.
А, ну если в redeemScript'е помимо проверки хэша пароля будет ещё и OP_CHECKSIG, тогда да, согласен.Извините что вмешиваюсь в ваш диалог, но стоит ли проблему ментального самоконтроля пользователя (не тратить монеты до XX числа) перекладывать на протокол p2p-сети?
Т.е. не совсем понимаю целесообразность такой разработки.
Это может быть не только проблемой самоконтроля пользователя. Например, можно использовать подобное решение для доп. защиты от троянов. Хотя, конечно, ничто не мешает ради этого создать отдельный кошелёк с отдельным паролем (если троян сможет перехватить пароль к повседневному кошельку, то только повседневные монеты он и уведёт, а для владельца это будет сигналом о том, что машина скомпрометирована, и пароль от основного кошелька на ней вводить больше не стоит). Т.е. не совсем понимаю целесообразность такой разработки.
Насчёт подтверждений я имел в виду то, что в транзакции траты с хэша нет никаких подписей, и если её отправить в сеть, то любой желающий сможет подменить адреса получения монет. Поэтому включать в блок такую транзакцию можно только самому. В отличие от
Не сможет, если изначальное условие будет немного более сложным. К примеру, не только соответствие хэша пароля, но и соответствие адреса. Тогда такой скрипт обналичить сможет только его создатель.Извините что вмешиваюсь в ваш диалог, но стоит ли проблему ментального самоконтроля пользователя (не тратить монеты до XX числа) перекладывать на протокол p2p-сети?
Т.е. не совсем понимаю целесообразность такой разработки.
На самом деле, смысла в этом немного. Скорее, просто иллюстрация гибкости протокола. Хотя в принципе, таким вещам может найтись применение не для прямого использования юзером, а для автоматизации кухни пеймент-процессоров. Естественно, что когда пользователь создаёт такую транзакцию вручную, то это уже симптом серьезного расстройства. Т.е. не совсем понимаю целесообразность такой разработки.
Доп. плюс — подтверждать эти транзакции может кто угодно, в отличие от.
Вообще-то, !IsFinal транзакции не может подтверждать или разослать вообще никто. Подтвердить их можно будет только после того, как наступит указанная в nLockTime дата. Доп. плюс — подтверждать эти транзакции может кто угодно, в отличие от.
Вообще-то, !IsFinal транзакции не может подтверждать или разослать вообще никто. Подтвердить их можно будет только после того, как наступит указанная в nLockTime дата.А транзакцию с отправкой на хэш можно подтвердить, и её будет видно в блокчейне всем...
Кто-то спрашивал о блокировке монет "на будущее".
…
Но естественно, такие транзакции можно создавать лишь вручную, и подтверждать их придется самому. Можно сделать такой тип транзакций стандартным, но не думаю что будет сильно востребовано.
Правильная блокировка выглядит так: создаём кошелёк в ramfs; переводим туда блокируемые монеты; выпускаем транзакцию с nLockTime в будущем, возвращающую монеты обратно на свой первый кошелёк; транзакцию сохраняем, ramfs-кошелёк уничтожаем. Доп. плюс — подтверждать эти транзакции может кто угодно, в отличие от. Правда, с PoS-майнингом это не очень сочетается, на время блокировки монеты расти в объёме не будут. …
Но естественно, такие транзакции можно создавать лишь вручную, и подтверждать их придется самому. Можно сделать такой тип транзакций стандартным, но не думаю что будет сильно востребовано.
Кто-то спрашивал о блокировке монет "на будущее".
Я не так давно спрашивал можно ли сделать так, чтобы пароль открывался только лишь направлением заранее оговоренной суммы на определенный адрес.
Тут есть три проблемы:
1) Монеты залочены намертво, без каких бы то ни было условий. Получить их можно только создав транзакцию с паролем в поле scriptSig;
2) Пароль можно оффлайново брутить на массиве видеокарт или FPGA;
3) После отправки тратящей транзакции пароль навсегда становится публичным, и доступным для просмотра всем желающим.
1) Монеты залочены намертво, без каких бы то ни было условий. Получить их можно только создав транзакцию с паролем в поле scriptSig;
2) Пароль можно оффлайново брутить на массиве видеокарт или FPGA;
3) После отправки тратящей транзакции пароль навсегда становится публичным, и доступным для просмотра всем желающим.
Но естественно, такие транзакции можно создавать лишь вручную, и подтверждать их придется самому. Можно сделать такой тип транзакций стандартным, но не думаю что будет сильно востребовано.
ну почему же
как заначка от продвинутой жены -- самое то
ПыСы главное пароль со временем не забыть
Кто-то спрашивал о блокировке монет "на будущее".
Берем пароль: test123
Получаем от него двойной sha256 хэш: 6db8da2e476f56550406cbf65c8d35edd6070e420675246db8d7c9650cdc2e48
Отправляем монеты на скрипт: OP_HASH256 6db8da2e476f56550406cbf65c8d35edd6070e420675246db8d7c9650cdc2e48 OP_EQUAL
Для траты транзакция будет выглядеть так:
scriptSig: 33323174736574 (test123 в big-endian)
scriptPubKey: куда слать, например pubkey OP_CHECKSIG
В общем, потратить инпут можно будет лишь зная пароль, либо его коллизию. Этакая защита паролем на уровне блокчейна.
Но естественно, такие транзакции можно создавать лишь вручную, и подтверждать их придется самому. Можно сделать такой тип транзакций стандартным, но не думаю что будет сильно востребовано.
Берем пароль: test123
Получаем от него двойной sha256 хэш: 6db8da2e476f56550406cbf65c8d35edd6070e420675246db8d7c9650cdc2e48
Отправляем монеты на скрипт: OP_HASH256 6db8da2e476f56550406cbf65c8d35edd6070e420675246db8d7c9650cdc2e48 OP_EQUAL
Для траты транзакция будет выглядеть так:
scriptSig: 33323174736574 (test123 в big-endian)
scriptPubKey: куда слать, например pubkey OP_CHECKSIG
В общем, потратить инпут можно будет лишь зная пароль, либо его коллизию. Этакая защита паролем на уровне блокчейна.
Но естественно, такие транзакции можно создавать лишь вручную, и подтверждать их придется самому. Можно сделать такой тип транзакций стандартным, но не думаю что будет сильно востребовано.
со штампами времени, пожалуйста...
10/02 17:00 первый пик. Уверен его и без таймштампа легко найти.остальные +/- километр идут
со штампами времени, пожалуйста...
10/02 17:00 первый пик. Уверен его и без таймштампа легко найти. судя по графику связь прямая не прослеживается...
http://clip2net.com/s/6Q2JUnНу да, 4 пика и 3 низины в течении нескольких суток в одно и то же время никак не могут быть связаны ...
по такой картинке можно сказать всё что угодно...
со штампами времени, пожалуйста...
Можно посмотреть на период и вычислить, в каком часовом поясе находится этот майнер
судя по графику связь прямая не прослеживается...
http://clip2net.com/s/6Q2JUnНу да, 4 пика и 3 низины в течении нескольких суток в одно и то же время никак не могут быть связаны ...
Ну что же, основной объем необходимого по 0.4.4.7 сделан, пощупать можно здесь:
https://github.com/novacoin-project/novacoin/tree/current
Из базовых изменений следует отметить концепцию записей об "вычищенных транзакциях". Это транзакции, все выходы которых были потрачены. Ранее 0.4.4.7 просто удаляла такие записи из БД, теперь сохраняет метадату (номер блока, время, флаги coinbase&coinstake) в компактном формате (длина записи о любой такой транзакции укладывается в 13-14 байт).
Таким образом, решается вопрос с синхронизацией клиента при наличии конкурирующих веток. Пока ограничений на время жизни таких записей нет, но в будущем и они будут стираться после 520 подтверждений истратившей транзакции.
В целом все стабильно, но думаю что в ближайшее время дополним формат полем, хранящим смещение транзакции в блоке для того, чтобы упростить текущую реализацию proof-of-stake майнера. Сейчас майнер ищет номер блока в БД, затем загружает блок и считает смещение транзакции, что явно избыточно.
Другие изменения:
Тестовые бинарники будут доступны позже.
https://github.com/novacoin-project/novacoin/tree/current
Из базовых изменений следует отметить концепцию записей об "вычищенных транзакциях". Это транзакции, все выходы которых были потрачены. Ранее 0.4.4.7 просто удаляла такие записи из БД, теперь сохраняет метадату (номер блока, время, флаги coinbase&coinstake) в компактном формате (длина записи о любой такой транзакции укладывается в 13-14 байт).
Таким образом, решается вопрос с синхронизацией клиента при наличии конкурирующих веток. Пока ограничений на время жизни таких записей нет, но в будущем и они будут стираться после 520 подтверждений истратившей транзакции.
В целом все стабильно, но думаю что в ближайшее время дополним формат полем, хранящим смещение транзакции в блоке для того, чтобы упростить текущую реализацию proof-of-stake майнера. Сейчас майнер ищет номер блока в БД, затем загружает блок и считает смещение транзакции, что явно избыточно.
Другие изменения:
- Адекватная обработка конфликтующих транзакций, чтобы не было как недавно с BTC;
- Опция для очистки wallet.dat от мусорных транзакций (смержено из BTC);
Тестовые бинарники будут доступны позже.
Jump to: