There is only one solution to this. Russia should provide advanced weaponry to the Donetsk People's Army and the Lugansk People's Army, so that they could liberate the entire Novorussia from Right Sector Nazis. If the Nazis still don't stop their whining, then Kiev and Lvov must be invaded and Nazis kicked out to Poland.
I wouldn't be so sure that Poland wants to see this dirt there. |
|
|
|
Хотя отбой, нашел транзакцию логах и вижу, что в повторной отправке нет никакого смысла. ERROR: Non-canonical signature: S value is unnecessarily high
ERROR: CSCriptCheck() : 96babebf6c VerifySignature failed Такое бывает, если отправляли транзакцию со старого клиента... Если точнее, с очень старого, потому что это правило вступило в силу очень давно, 20 сентября 2014 года.  Самое простое решение - установить крайний клиент и сделать вот так: signrawtransaction <hex дамп транзакции> После чего отправить получившуюся переподписанную транзакцию в сеть с помощью sendrawtransaction. Есть и другие варианты, но прямым решением они не являются. |
|
|
|
getrawtransaction <txid>
sendrawtransaction <hex>
В консоле набрал getrawtransaction 96babebf6cc81be6f63352a48f58abcf76881663de06174f5399bbb896d5ec9a Появилась строка из 6276 символов, я так понял, хэш? Далее набрал: sendrawtransaction <хэш из 6276 символов> Появилось: 96babebf6cc81be6f63352a48f58abcf76881663de06174f5399bbb896d5ec9a То есть, тот же id транзакции. Первая команда выдает шестнадцатеричный дамп транзакции. Вторая отправляет её в сеть и, если все хорошо, возвращает её хэш. Так что вроде бы всё нормально, но что-то я в сети её не вижу. Предлагаю выложить дамп транзакции, попробую переотправить со своего кошелька. Может, там с самой транзакцией что-то не так... |
|
|
|
Всем привет. Некоторое время майнил PoS, затем хотел перевести часть монеток на btc-е. Чтобы не трогать крупные инпуты, выбрал всю мелочь и отправил. Второй день висит с 0 подтверждений. Вероятно, я что-то сделал не так. Прочитав бегло последние страницы, подозреваю, что отправил несколько намайненных манет, которые еще не отлежались. Собственно, вопрос: что делать? Просто ждать или можно откатить как-то операцию?  getrawtransaction <txid> sendrawtransaction <hex> |
|
|
|
|
Как я понимаю, в этой сборке старая функция, так что ничего странного в этом нет. Там же написано красным по белому, какой синтаксис оно хочет.
|
|
|
|
Ну вот, теперь для составных адресов ведется такой же набор метаданных, как и для обычных, и метки работают. Доделаем несколько мелочей и можно будет релизиться. 
|
|
|
|
Не влияет потому что делает то же самое. Функция scaninput составляет набор возможных решений для выбранного выхода, используя в качестве параметров заданные заранее сложность и интервал значений времени. Майнер занимается тем же самым, но в фоновом режиме, используя текущие время и сложность в качестве параметров. Других отличий нет.
Если и можно назвать концептом, то ничего нового он не внесет. Просто оптимизация процесса майнинга, не меняющая положение дел в целом.
Как я понял, происходит просчет хешей "на будущее" при заданной сложности. Верно? Не очень понятно где тут оптимизация, ведь объем вычислений одинаковый, а еще и решения надо запоминать... Объем одинаковый, зато производится один раз и не висит потока в фоне постоянно, процессор больше времени будет работать на сниженной частоте. К тому же, просчитать решения можно и на другой машине, намного более мощной, после чего положить их на нужную. |
|
|
|
шота сканинпут перестал работать ...
один инпут годовалой давнойти... обещался не прошлой неделе разродиться - неразродился...
Он не может перестать или начать работать. Просто находит решения на интервале, а вот воспользуется ли ими клиент в нужный момент - это уже другой вопрос. Может и не воспользоваться, если в этот момент упадет соединение с сетью или загрузка ЦП подскочит достаточно для того, чтобы для работы демона не осталось свободного времени ЦП. Может, по крону запустилась ротация/архивирование логов или что-то вроде этого. Вообще же, по плану сканинпут в обозримом будущем станет рудиментом. Майнер будет сканировать инпуты сам, в момент получения соответствующим блоком модификатора, с последующим сохранением результатов для их использования в нужный момент. Ну или для их просмотра, что тоже может быть полезно. оно тупо вывливает ошибку синтаксиса... т.е. синтаксис каоторы работал еще с мес назад уже не работает... Это у них в мечтах Таких возможностей в стандартном кошельке нет. Ты бы всё-таки прогнал эти "невезучие" выходы командой scaninput в консоли, прежде чем что-то объединять: scaninput '{"txid":" txid", "days":365}' Вместо красного txid вставь id транзакции каждого выхода по очереди (скопируй на вкладке PoS). Уж если в течение следующего года они не дадут блок, тогда можно думать либо о склейке, либо о добыче альтернативного кошелька с изменёнными параметрами автосклейки.  |
|
|
|
А как сейчас работает майнер, он разве не сканирует инпуты?
Не влияет потому что делает то же самое. Функция scaninput составляет набор возможных решений для выбранного выхода, используя в качестве параметров заданные заранее сложность и интервал значений времени. Майнер занимается тем же самым, но в фоновом режиме, используя текущие время и сложность в качестве параметров. Других отличий нет. Это пока только концепт? Не понял как это будет работать, есть какое-то описание? (текущий алгоритм понятен)
Если и можно назвать концептом, то ничего нового он не внесет. Просто оптимизация процесса майнинга, не меняющая положение дел в целом. |
|
|
|
I really wanted to live in Russia.
It is probably only country keep changes all the time. (Imperial -> communist -> capitalist -> imperial again(?)
Republic -> Counties -> Republics -> Kingdom -> Empire -> Republic -> Republics -> Soviet republic -> Federal Republic -> to be continued. |
|
|
|
Looks like this policeman was born on Krypton. |
|
|
|
|
Думаю, что разумнее всего отфильтровывать по статически заданной маске для сложности 1.0, а уже к получившемуся набору применять текущую сложность. Это даст баланс между количеством решений и их полезностью.
|
|
|
|
|
Чтобы обойтись без доверия, нужен соответствующий функционал в виртуальной машине NVC. К примеру, как комбинация выплаты на хэш ключа + CHECKLOCKTIMEVERIVY с альтернативным условием проверки.
В прочем, совсем без доверия все равно не обойтись. Ведь даже в самом защищенном варианте неблагонадежный посредник пусть и не может украсть что-то, он может создать другие проблемы. К примеру, заморозить инпут на предельный по договору срок, результатом этого может быть упущенная прибыль или просто головная боль.
|
|
|
|
шота сканинпут перестал работать ...
один инпут годовалой давнойти... обещался не прошлой неделе разродиться - неразродился...
Он не может перестать или начать работать. Просто находит решения на интервале, а вот воспользуется ли ими клиент в нужный момент - это уже другой вопрос. Может и не воспользоваться, если в этот момент упадет соединение с сетью или загрузка ЦП подскочит достаточно для того, чтобы для работы демона не осталось свободного времени ЦП. Может, по крону запустилась ротация/архивирование логов или что-то вроде этого. Вообще же, по плану сканинпут в обозримом будущем станет рудиментом. Майнер будет сканировать инпуты сам, в момент получения соответствующим блоком модификатора, с последующим сохранением результатов для их использования в нужный момент. Ну или для их просмотра, что тоже может быть полезно. |
|
|
|
|
В общем, да.
Какие-либо нестыковки могут возникнуть только в случае, если сам блок N или его родитель вдруг будут оторфанены, новые клиенты этого не признают продолжат использовать блок N в качестве корня своей ветки.
Но это очень маловероятно, ведь в качестве такого блока навряд ли кто в здравом уме будет выбирать блок менее чем с этак 10000 подтверждений.
|
|
|
|
|
Так монеты в таком случае никуда не деваются. И функционирование клиентов, не признавших новый корень, также остается без каких-либо изменений. Они просто будут хранить всех родителей блока N, в то время как обновившиеся вместо этого будут довольствоваться копией UTXO и блоком N.
|
|
|
|
Или радикальный нацист.  |
|
|
|
|
Это было бы не самым удачным моментом, потому что реализация такого алгоритма лишает юзеров осознанного выбора, признавать блок N в качестве нового начала цепочки или нет. Скачивание клиента это же не какая-то рутинная ерунда, а по сути есть акт принятия обновленного общественного договора. Видели ли, чтобы в каком-нибудь государстве конституция правила саму себя, без вмешательства граждан?
|
|
|
|
Просто обрезать нельзя: дочерние же блоки зависят от родительских.
Это как раз не проблема, если поместить в клиент список инпутов, актуальных на выбранный момент времени. После этого в качестве стартового нужно будет указать соответствующий блок вместо нулевого, и на этом всё. Такой клиент будет продолжать цепочку начиная с этого блока, а не нулевого, а все предыдущие для него перестанут существовать т.к. он в них не будет нуждаться. Из минусов - клиент потяжелеет, т.к. в нем будет содержаться копия UTXO, актуальная на момент удаления "ховна". Сейчас это не является осмысленным занятием, но может быть принято в качестве регулярной практики в случае активного роста блокчейна, к примеру как выпуск своего рода фиксирующего клиента раз в полгода. |
|
|
|
|
Та окцилор сам же либо Иван, либо какой-нибудь Яша, чего греха таить.
|
|
|
|
|
Show Posts
