за такой развал экономики при Сталине расстреливали
Нынче некоторые любят сравнивать «закручивание гаек» с 1937-м годом. Так вот, был бы сейчас 1937-й, вся нынешняя верхушка отправилась бы на нары или лоб зелёнкой мазать. |
|
|
|
|
О да, замучались уже воевать с «миллионами убитых лично Сталиным»...
|
|
|
|
Ага, добрый Сталин задумал озолотить народ, а злые соратники его за это извели... вот уж извечная расейская сказочка о добром царе. Хоть как-то соотносили бы этот бред с исторической реальностью, что ли.
К вам это в полной мере относится. Сталин не только экономику СССР вывел на совершенно новый уровень, но и благосостояние народа в среднем поднял очень сильно. И, разумеется, не давал беспредельничать типам вроде Хрущёва. Это всё (и не только) и послужило поводом для его убийства. Очень жаль, что он так и не успел построить саморегулирующуюся систему ответственности руководителей перед подчинёнными. А что успел, то после него развалили... |
|
|
|
Если не секрет, в каком году намайнил?
Майнить я начал почти сразу, как узнал о проекте, году в 10-м, ещё на CPU, даже пару блоков сгенерил, помнится. Потом собирали уже на видяхах ферму и майнили в пуле... Сейчас вспоминаю, как за телефон платил биткойнами (двузначными суммами) и улыбаюсь... Или как меня «нагрели» на 30 биткойнов, а я махнул рукой и забыл... |
|
|
|
|
Намайненное лежит в кошельке, ждёт своего часа. Я спокоен аки танк.
|
|
|
|
|
Проблема ещё одна есть. Мы в письме хвалим гокс, а он, похоже, каза болду.
|
|
|
|
|
Сто́имость спутникового терминала и его содержания (абонплата и т.п.) весьма высока. Это имеет смысл, если остров будет использован в политических целях, а если просто одному человеку дожить свой век – лишку будет.
|
|
|
|
|
Собака лает, караван идёт. ©
|
|
|
|
остров, затерянный в Индийском океане вряд ли будет интересен покупателю Эксперты такие эксперты... Если на этом острове можно вырастить жратву и можно достучаться то интернетов – я лично готов там жить безвылазно. Да и интернеты не сильно обязательны тащемта... |
|
|
|
Денежная политика Китая привела к сосредоточению кредита на государственных предприятиях и в компаниях, дружественных государству, за счет всех остальных экономических агентов. Это еще больше укрепило контроль коммунистической партии Китая над экономикой. Аплодирую китайцам. Контроль – это то, без чего экономика не будет вылезать из кризисов. Биткойн – отличное средство для демонстрации этого тезиса, потому я всеми руками, ногами и прочими отростками и псевдоподиями за него. Не набив шишек, ничему не научишься. |
|
|
|
|
Ну да, «стандартизировали» – это я громко выразился. Но по крайней мере сделали общеизвестный алгоритм и API с возможностью проверки «правильного» хэша. От этого можно плясать.
|
|
|
|
О, это уже стандартизировали? Прелестно, благодарю за информацию. Кроме того, если у нас нормальный клиент, а не голая система слежения за транзакциями, то необязательно это делать для всех транзакций, пришедших в блоке, достаточно такую операцию производить лишь для всех новых транзакций из listtransactions. А я о том же. По расписанию или по событию ловить новые транзакции и отрабатывать. |
|
|
|
|
1. Ни фига, я так уже делал – баланс изменяется только у лицевого счёта (при использовании «sendfrom», разумеется). Можно переводить и между счетами. Главное – следить, чтоб баланс счёта не уходил в минус. Хотя это уже особенности сервиса – мабуть, вы хотите кредиты выдавать.
2. Да никакого кошмара же. Просто каждую транзакцию в пришедшем блоке пропустить через функцию вычисления «правильного» TXID (назовём это TXID2, чтоб н̶и̶к̶т̶о̶ ̶н̶е̶ ̶д̶о̶г̶а̶д̶а̶л̶с̶я̶ не путаться), и искать это в базе. А bitcoind вам не свяжет оригинальную транзакцию с модифицированной по TXID.
То есть нужна пара функций типа «tTransaction parse_transaction(tTXID txid)» и «tTXID2 generate_txid2(tTransaction transaction)». Первая возвращает разобранную транзакцию по TXID в виде объекта, вторая считает TXID2 по этому объекту. Пришёл блок – парсим все транзакции в нём, считаем TXID2 для каждой – и искать в базе. Что ужасного-то?
|
|
|
|
|
Вот вы и пытаетесь наступить на те же грабли, т.е. использовать хэш двоичного представления транзакции в качестве её идентификатора...
Навскидку альтернативы:
• используйте лицевые счета (accounts) API bitcoind. Грубо говоря, эта штука позволяет поделить общий кошелёк на кармашки, и в каждом кармашке держать свою сумму. TXID здесь вообще не нужны, человек вводит-выводит свои средства и сразу видит сумму лицевого счёта, всем остальным занимаетcя bitcoind. Недостатки: использование bitcoind, который для очень больших нагрузок не очень хорош.
• генерируйте свой TXID на основt входов, выходов и сумм. Например, парсите транзакцию, у вас получается N входов с суммами и M выходов с суммами, подписи, комиссия и т.п. Сериализируете полученный объект в JSON-строчку (или в любой другой последовательный формат) и считаете хэш от неё. Недостатки: TXID, посчитанный вами, нигде нельзя будет проверить, это будет исключительно ваше, внутреннее представление транзакции.
|
|
|
|
|
Да не надо вам ничего запоминать, клиент всё сделает за вас. Естественно, нормальный клиент, а не такой, который запоминает только TXID.
Блок, в который попадёт изменённая транзакция, дойдёт и до вашего клиента, и будет в нём видна.
Пользуйтесь оригинальным клиентом или другим, который знает о transaction malleability, и не будет проблем.
В который раз говорю: у гокса была своя реализация клиента, они про transaction malleability забыли или не стали париться по этому поводу. Вот и результат. Если они, конечно, правду говорят, что их поимели этим методом...
|
|
|
|
|
Закрытый исходник? Не верим тебе, Хитрый Рурк!
|
|
|
|
Но вышло, похоже, с точностью до наоборот. Москва не сразу строилась. Детские болезни. |
|
|
|
http://habrahabr.ru/post/213083/Представьте, что мы живем в мире криптографии, электронной коммерции и свободных экономических отношений. Пользуемся электронными средствами платежей, где в корзине и кошельке операции осуществляет калькулятор, где микроскопические суммы и огромные средства проводятся в многочисленных транзакциях без каких-либо проблем за ничтожное количество времени, с автоматическим учетом налогов, сборов и отчислений, где нам привычны покупки в электронных супермаркетах и доставка до порога по одному прикосновению к экрану телефона или клику мышкой. И вот, в наш прекрасный, удобный и отлаженный мир электронных платежей, построенный на принципах безопасности и криптографии, со всеми присущими ему технологиями и образу мышления, впитанными с молоком матери, приходит причудливый и странный механизм, которым, как говорят средства массовой информации, пользуются только анархисты, конспираторы и преступники.
Вы просыпаетесь утром, наливаете чашечку кофе или чая, включаете ваш любимый информационный оповеститель и слышите новость — с сегодняшнего дня правительства крупнейших мировых государств включают в обращение систему платежей, основанную на бумажных носителях, в официальных источниках называемых «банкноты», или «купюры».
|
|
|
|
ну а как тогда у себя в базе запоминать транзакцию?
вот я получил с кошелька транзакцию что деньги пришли и запомнил ее в базе по ТХ_ИД + ВОУТ
и как меня могут обмануть?
Транзакция – это набор входов и выходов с суммами. TXID в ней вообще не нужен, он применяется до попадания транзакции в блоки для того, чтобы узел, которому от другого пришла транзакция, мог быстро понять, новая она или уже имеется во вре́менном хранилище транзакций. И быстро удалять их из временного хранилища, когда она попадает в блок. По сути это вре́менная штука. Вас обмануть таким образом не могут. Могут обмануть отправителя, да и то только того, кто считает, что транзакция непременно попадёт в блоки в том виде, в котором он её сгенерировал (и не глядя повторит транзакцию, если не найдёт её в блоках, и ещё при этом случится так, что входы все не потрачены за предыдущий раз). А этого никто не гарантирует в сети биткойн. Гарантируется (и подписывается приватными ключами) только результат транзакции, а не её двоичное представление, скажем так. Если надо ключик для локальной базы – соберите времянку из входов и выходов с суммами, а также временем её прихода – она с очень высокой вероятностью будет уникальной. Можно прохешировать её для унификации размера, но тут можно напороться на коллизию... |
|
|
|
|
Совершенно верно, да и публичный ключ не нужен. Фишка в том, что TXID и есть хэш всех данных транзакции.
Но проблема будет только у тех, кто однозначно привязал внутреннюю транзакцию к TXID и отслеживает успешность только по нему, что, видимо, и было у гокса. В референсном коде это давно пофиксили. Да и не было это особой проблемой, биткойны таким образом невозможно увести.
|
|
|
|
|
Show Posts
