Интересно, если сценарий транзакции, как это будет разрешено: Если высота блока < х, использование условие А; если высота блока >= Х, использование условие В
Это может быть очень полезным в качестве доверительного бесплатно, нулевого подтверждения обмена кошелька
Если предположить, что обмен имеет закрытый ключ E, пользователь имеет секретный ключ U, а х высота блока ближайшего будущего (например, текущая высота блока + 10000), сценарий транзакции будет выглядеть следующим образом: Если высота блока < х, 2-на-2 multisig с Е и U требуется; если высота блока >= Х, U требуется. Хэш сценария является производным
Пользователь будет удобно отправлять любое количество монет этого сценария хэш. Если секретный ключ E был скомпрометирован, фонд не может быть украден. Даже если оператор обмена исчез (как Torwallet), пользователь может получить монеты обратно после того, как блок-х.
Если пользователь хочет, чтобы продать монеты перед блочным х, он будет подписывать multisig сделку, чтобы отправить монеты в адрес ключа Е (или любых других адресов исключительно принадлежащих обмена). Так как оно связано с multisig требованием до блока х, пользователь не представляется возможным удвоить расходы. Таким образом, BTC легко доступен для торговли с нулевым подтверждением.
Во избежание двойных расходов или атак Финни, то multisig сделка должна быть подписана пользователем задолго до того, генерируются блок х, например, х - 10. После этого, обмен не будет принимать его на ноль-подтверждение. Тем не менее, он все равно будет принимать его после 6 подтверждений.
Это также работает для интернет-провайдеров бумажника, фондового рынка, рынка или услуг Bitcoinica типа. Он не будет полностью устранить риск, но люди могли бы внести большое количество BTC на эти услуги и провести мгновенно в любое время.
EDIT: Для Bitcoin покупателя, обмен будет отправлять свеже купленных монет в его сценарий хэш. Таким образом, покупатель также защищен, в то время как он мог также продать монеты мгновенно.
|
|
||||||
3 октября 2012, 4:45:45 AM
|
# 1 |
Сообщения: 1750
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru |
|
|
|
Как заработать Биткоины?
Без вложений. Не майнинг.
|
4 октября 2012, 4:47:54 PM
|
# 2 |
Сообщения: 1302
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Получил 1806 Биткоинов
Реальная история. Что касается сделок беспокоит, нет блоков, нет никакой цепи, нет высоты. Это не случайность или недосмотр. Пожалуйста, поиск в следующий раз.
|
|
|
|
|
4 октября 2012, 5:25:06 PM
|
# 3 |
|
Сообщения: 1750
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Что касается сделок беспокоит, нет блоков, нет никакой цепи, нет высоты. Это не случайность или недосмотр. Пожалуйста, поиск в следующий раз. Я думаю, что вы полностью поняли мое предложение. Позвольте мне объяснить это так: пользователь не полностью доверяет обмен, но он хочет продать его БТД через биржу. Он хочет передать БТД в обмен на последнюю минуту, прежде чем он продает. Тем не менее, обмен требует 6 подтверждения, чтобы предотвратить двойные расходы. Один из способов сделать это, чтобы иметь 2-на-2 multisig счет, который обмен владеет одним из ключей (E), и пользователь имеет другой ключ (U). Пользователь будет отправить его BTC на этот счет multisig. Когда пользователь хочет продать BTC позже, он подпишет сделку по U отправить BTC в multisig счета на счет принадлежащего обмена исключительно. Обмен будет завершить сделку, подписав его с Е. Поскольку пользователь не представляется возможным дважды провести обмен может принять его с нулевым подтверждением, и пользователь может продать его BTC немедленно. Однако, если обмен полностью исчезли, BTC в нескольких сиг счетов будут потеряны навсегда. Поэтому нам нужны "механизм аварийного выхода", Когда multisig счет установки, добавляется дополнительное условие: (например) "После 1 января 2013 года, монеты в этом счете могут быть потрачены подписи ключа U только", Это означает, что в худшем случае, если обмен не может завтра, пользователь может получить свои монеты обратно после того, как 1 января 2013 года. Конечно, в Bitcoin мире, время измеряется по высоте блока, а не дней. Таким образом, условие становится "после того, как высота блока > 220000, монеты в этом счете могут быть потрачены подписи ключа U только", Если пользователь пытается провести (высота блока = 201800) монеты сегодня без участия обмен, сделка считается недействительной. И следующее уведомление объясняет, почему нам нужна эта система: котировка GLBSE вне форума Для тех, кто беспокоится о своем Bitcoin, пожалуйста, успокойтесь там не было рубить и ваши монеты являются безопасными, и все приходилось. Прошу прощения за отсутствие уведомления и простой, но не так много выбора. Мы будем обновлять наши пользователи в субботу. |
|
|
|
|
4 октября 2012, 5:43:37 PM
|
# 4 |
|
Сообщения: 1050
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Сделки на самом деле имеют редко используемую функцию под названием nLocktime. Он может быть использован для определения высоты блока или UNIX метки времени, после которого сделка позволило стать хранится в блоке цепи.
|
|
|
|
|
4 октября 2012, 6:18:44 PM
|
# 5 |
|
Сообщения: 1302
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Я думаю, что вы полностью поняли мое предложение. Нет, я получил его, я понимаю, что вы говорите. Вы хотите, чтобы скрипт, который знает, сколько времени (или какой-либо прокси-сервер для времени), и могут быть действительными или не действует на основе этого времени. Это плохая идея, и есть целая куча нитей, которые объясняют, как и почему это плохая идея. Не принимайте это лично, это очень популярная идея, но все-таки плохой. И следующее уведомление объясняет, почему нам нужна эта система: котировка GLBSE вне форума Ваша схема, вероятно, не поможет. Если получатель был сбит автобусом, вы могли бы иметь способ вспомнить сделку. Но если получатель планирует украсть ваши деньги, они сначала выкупить сделку, делая это бессмысленно. Как отмечает Питер, есть инструменты (nLockTime и P2SH), которые в конечном итоге будут использоваться для выполнения в основном те же конечные цели, и они не связаны с добавлением представления о времени в системе сценариев. |
|
|
|
|
4 октября 2012, 7:02:44 PM
|
# 6 |
|
Сообщения: 1652
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Однако, если обмен полностью исчезли, BTC в нескольких сиг счетов будут потеряны навсегда. Поэтому нам нужны "механизм аварийного выхода", Когда multisig счет установки, добавляется дополнительное условие: (например) "После 1 января 2013 года, монеты в этом счете могут быть потрачены подписи ключа U только", Если вы провели предварительно подписали сделку, которая отправляет денежные средства обратно к вам с Locktime 1 янв 2013, который будет работать. Давайте посмотрим ... мысли вслух ... Начните с просьбой обмена для открытого ключа новенькой использовать для своей половины сделки 2-в-2. Вызов посыл-монета-в-2-из-2 сделки "F" (Для фонда). Вы можете создать и подписать эту сделку, но не транслируют его еще. Используйте это идентификатор транзакции, чтобы создать вторую, один-два вход-подписи, Locktime = 1 / 1/2013 сделки, что возврат монет вам. Вызов, который "р" (Для возврата). Отправить R для обмена и попросить их подписать его, используя этот совершенно новый открытый ключ, они дали вам. Обменный проверяет Locktime, а затем возвращает R и подписи к вам. Вы проверить подпись, и если это хорошо, передача F (и держать половину подписал R где-то в безопасности). Если 1/1/2013 катается, и вы хотите, чтобы ваши монеты обратно, вы подписываетесь половину R и транслировать его. Я должен был бы думать немного сложнее, чем я хочу прямо сейчас о том, или не подписывать R, зная только TXID == HASH (F) открывает обмен атакам. Я не могу думать ни о ком, но обмен обеспечивает подпись, когда он не знает подробности, что именно он подписывает заставляет меня нервничать. Вы можете отправить неподписанный R и подписанные но-не-вещания F для обмена и доверия, что обмен не будет транслировать F, если они не согласятся подписать R. Я думаю, что проведение на предварительно зарегистрированны но-не-широковещательных пока операции является метод "мы" не думать о достаточно. |
|
|
|
|
5 октября 2012, 2:29:55 AM
|
# 7 |
|
Сообщения: 416
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Если вы провели предварительно подписали сделку, которая отправляет денежные средства обратно к вам с Locktime 1 янв 2013, который будет работать. Я был из петли на некоторое время .. Работает ли Locktime правильно в настоящее время? Если нет, то когда это планируется реализовать?Я должен был бы думать немного сложнее, чем я хочу прямо сейчас о том, или не подписывать R, зная только TXID == HASH (F) открывает обмен атакам. Я не могу думать ни о ком, но обмен обеспечивает подпись, когда он не знает подробности, что именно он подписывает заставляет меня нервничать. Ну, в худшем случае (при правдоподобных предположениях) для обмена подписывающего что-то произвольное с некоторым ключом потерять контроль (или невольно совершить) все связанное с этим ключом, поэтому очень важно, что ключ не используется ни для чего другого , Теперь, конечно, если мое предложение о идентификаторе транзакции хэш не было приняты в том числе подписей, то сделка финансирования может быть отправлена в беззнаковой форме обмена и обмен может убедиться, что возврат провел сделку финансирования, потому что, конечно, идентификатор транзакции Wouldn» изменение т при подписании. ByteCoin |
|
|
|
|
5 октября 2012, 2:53:51 AM
|
# 8 |
Сообщения: 1750
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Однако, если обмен полностью исчезли, BTC в нескольких сиг счетов будут потеряны навсегда. Поэтому нам нужны "механизм аварийного выхода", Когда multisig счет установки, добавляется дополнительное условие: (например) "После 1 января 2013 года, монеты в этом счете могут быть потрачены подписи ключа U только", Если вы провели предварительно подписали сделку, которая отправляет денежные средства обратно к вам с Locktime 1 янв 2013, который будет работать. Давайте посмотрим ... мысли вслух ... Начните с просьбой обмена для открытого ключа новенькой использовать для своей половины сделки 2-в-2. Вызов посыл-монета-в-2-из-2 сделки "F" (Для фонда). Вы можете создать и подписать эту сделку, но не транслируют его еще. Используйте это идентификатор транзакции, чтобы создать вторую, один-два вход-подписи, Locktime = 1 / 1/2013 сделки, что возврат монет вам. Вызов, который "р" (Для возврата). Отправить R для обмена и попросить их подписать его, используя этот совершенно новый открытый ключ, они дали вам. Обменный проверяет Locktime, а затем возвращает R и подписи к вам. Вы проверить подпись, и если это хорошо, передача F (и держать половину подписал R где-то в безопасности). Если 1/1/2013 катается, и вы хотите, чтобы ваши монеты обратно, вы подписываетесь половину R и транслировать его. Я должен был бы думать немного сложнее, чем я хочу прямо сейчас о том, или не подписывать R, зная только TXID == HASH (F) открывает обмен атакам. Я не могу думать ни о ком, но обмен обеспечивает подпись, когда он не знает подробности, что именно он подписывает заставляет меня нервничать. Вы можете отправить неподписанный R и подписанные но-не-вещания F для обмена и доверия, что обмен не будет транслировать F, если они не согласятся подписать R. Я думаю, что проведение на предварительно зарегистрированны но-не-широковещательных пока операции является метод "мы" не думать о достаточно. Я прочитал предыдущее обсуждение в а также Satoshi отверг идею OP_BLOCKNUMBER из-за этого: котировка Если язык сценариев не является лицом без гражданства, если он имеет доступ к любой внешней информации, которая изменяет или изменяется между узлами, злоумышленники могут использовать его раскошелиться цепью. Единственное исключение, если оно всегда ложно до определенного времени и постоянно верно после, который реализуется с nLockTime. Да, он прав. Таким образом, можно включить идею nLockTime в сценарии? Например: 1. Монета может проводиться 2-по-2 multisig с ключом Е и ключа U в любое время 2. Если высота блока >= Х, монета может быть проведена по ключевым Ю. multisig 2-на-2, однако, по-прежнему непросроченный способ провести монету. Таким образом, первое условие постоянно верно, независимо от высоты блока. Второе условие всегда ложно, прежде чем высота блока = х, и постоянно верно после. Это лучше, чем при использовании nLockTime, поскольку пользователь может внести в хэш сценария в любое время, без необходимости отправки nLockTime сделки назад и вперед и хранить их. Это также позволяет избежать проблем с просьбой обмена подписать неизвестную сделку |
|
|
|
|
6 октября 2012, 12:12:46 AM
|
# 9 |
|
Сообщения: 1050
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Если вы провели предварительно подписали сделку, которая отправляет денежные средства обратно к вам с Locktime 1 янв 2013, который будет работать. Я был из петли на некоторое время .. Работает ли Locktime правильно в настоящее время? Если нет, то когда это планируется реализовать?nLocktime когда-либо работал, так как он был введен. Что еще не существует замещение сделки (которая необходима для многих, но не все, приложений nLocktime в). К счастью, осуществление замены транзакций не нуждается в каких-либо изменениях протокола или вилки или шахтер поддержке. |
|
|
|
|
6 октября 2012, 2:09:10 AM
|
# 10 |
|
Сообщения: 2366
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Да, он прав. Таким образом, можно включить идею nLockTime в сценарии? Например: Проверка, что использование высоты на самом деле без гражданства в сценарии были бы ужасающими и более или менее неразрешимыми. Если сценарий был разработан таким образом, что существует таблица вариантов выкупа, которые имели свое собственное время блокировки, то это могло бы быть сделано ... но увы. 1. Монета может проводиться 2-по-2 multisig с ключом Е и ключа U в любое время 2. Если высота блока >= Х, монета может быть проведена по ключевым Ю. multisig 2-на-2, однако, по-прежнему непросроченный способ провести монету. Это не большое дело в любом случае: Вы продаете мне автомобиль. Мы решили использовать 2-в-2 эскроу. Но я боюсь, что вы будете поддерживать эти средства, если сделка сорвется. Я вычислить компенсацию в эскроу и подписать его. Но я не объявить об этом еще. Я также вычислить сделку тратить сделку депозитного и оплачивая все это обратно ко мне с Locktime установить несколько месяцев с этого момента. Я подписываю эту сделку. Я даю его вам (вместе с txout его расходы, но не весь платеж). Вы можете посмотреть на него и убедиться, что он не будет действительно разблокирована до тех пор, когда, таким образом подписать его и вернуть его обратно. Тогда я объявляю компенсацию в условном депонировании. Вам не нужно высота в сценариях, чтобы получить возврат таймаут. QED. |
|
|
|
|
15 октября 2012, 5:24:29 PM
|
# 11 |
|
Сообщения: 338
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Есть ли активно прорабатывается позволяет замену сделок?
Большое приложение для nLockTime будет мертв человек-переключатель для шифрованных кошельков. Основная проблема, которую я вижу с зашифрованными бумажниками для среднего пользователя, что если пароль потерян, монеты будут потеряны, тоже. Я думал в течение длительного времени о растворе, где хранить пароль (кроме моего мозга), так что в случае, если я страдаю от амнезии, я до сих пор доступ к своим монетам. Но самое лучшее решение, которое я могу себе представить, чтобы хранить подписанную сделку с nLockTime набора в какой-то момент в будущем, которое посылает монеты в зашифрованном бумажнике другой адрес. Секретный ключ к этому новому адресу можно было бы дать кому-то / хранится где-то вы верите в случае, если вы страдаете от амнезии, но не доверяют для использования изо дня в день. До тех пор, как вы помните пароль к кошельку, то nLockTime-транзакция может быть refresehed, поэтому он никогда не блокируется. В случае, если вы забыли пароль, монеты становятся после Доступно замков nLockTime-транзакций. Я считаю, что эта идея не нова, но было бы неплохо, чтобы он реализован в ближайшее время, потому что это помогает сделать Bitcoin более надежным и, следовательно, более доверяют средним людям. |
|
|
|
|
15 октября 2012, 6:30:19 PM
|
# 12 |
|
Сообщения: 1652
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
... Но самое лучшее решение, которое я могу себе представить, чтобы хранить подписанную сделку с nLockTime установить на какое-то время в будущем, которое посылает монеты в зашифрованном бумажнике на другой адрес .... Вам не нужна вся сеть для поддержки замены транзакций, чтобы сделать это; просто написать код, который содержит время автоподстройки сделки, есть способ заменить его другим временем автоподстройки сделки, и он автоматически транслировать транзакции в сеть, если не заменить до истечения времени блокировки. Было бы удобнее иметь всю опорную сеть замены транзакций, но я не думаю, что это разумно для всей сети, чтобы помнить должные мертвые человек-переключатель операции. И даже если бы они сделали, вы рискуете, что шахтер хочет получить дополнительную плату за транзакцию будет игнорировать новую версию сделки и моей старые сделки. |
|
|
|
|
15 октября 2012, 8:53:37 PM
|
# 13 |
Сообщения: 338
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Вам не нужна вся сеть для поддержки замены транзакций, чтобы сделать это; просто написать код, который содержит время автоподстройки сделки, есть способ заменить его другим временем автоподстройки сделки, и он автоматически транслировать транзакции в сеть, если не заменить до истечения времени блокировки. Я имел в виду, чтобы не транслировать время автоподстройки ТХ, пока это не нужно. Но что произойдет, если он будет транслироваться как-то прежде, чем я могу заменить его? Есть ли получить включены в блок? Есть ли торчать в сети, как некоторые зомби-TX, которые пока не могут быть включены в блок, но действует и не может быть выброшен? Насколько я знаю, единственный способ заменить такую сделку, потратив те же выходы без nLockTime набора. Но тогда клиент не будет ретранслировать сделку, потому что замена не включена, и это будет рассматриваться как двойной тратить, не так ли? |
|
|
|
|
15 октября 2012, 10:02:40 PM
|
# 14 |
|
Сообщения: 1526
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Я не думаю, что 2-из-2 депозитного покупает вам что-нибудь, поэтому я не обсуждал это ни в одном из моих сообщений / переговоров / вики-страниц.
Если я хочу, чтобы ввернуть продавец, то я буду просто транслировать сделку на возврате разогнавшись, и он будет входить в пул памяти, предотвращая любые другие сделки от расходов на выходе 2-в-2. Я получаю деньги (после нескольких месяцев). Если продавец хочет, чтобы ввернуть меня, после создания сделки 2-в-2, и мы согласны на продажу как подписание для multisig выхода, он передает ТХ, давая себе деньги, а потом отказывается дать мне ключи от машины. Он отгоняет и я теряю деньги. Ни в коем случае мы лучше, чем просто с помощью регулярного платежа. 2-в-3 с посредником не имеет эти проблемы, и не делает конструкцию интеллектуальной собственности, в котором сделка осуществления платежа также передает управление автомобиля атомарна. "мертвый переключатель мужчин" идея не работает. Если ключ транзакция, что восстановление также зашифрована, то это не поможет, если вы забыли пароль. Если он не зашифрован, то если кто-то получит доступ к вашему кошельку, они могут передать транзакцию восстановления и сделать ваш кошелек unspendable, а затем транслировать расходы на выходе операций восстановления. Вор придется подождать несколько месяцев, чтобы претендовать на деньги, но они получат его в конце концов. Не говоря уже о том, что сделка восстановления необходимо будет перестроен каждый раз, когда содержимое кошелька изменилось! Любой, кто подумывает о nLockTime должны помнить об этом - сделка, которая время заперто входит в пул памяти и остается там до тех пор, время блокировки не будет достигнуто. После трансляции входы, которые тратит транзакции используются и дважды проводит не будут приняты. |
|
|
|
|
17 октября 2012, 1:13:09 PM
|
# 15 |
|
Сообщения: 338
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
сделка, которая время заперто входит в пул памяти и остается там до тех пор, время блокировки не будет достигнуто. После трансляции входы, которые тратит транзакции используются и дважды проводит не будут приняты. Это может быть изменено путем осуществления замены транзакций (поправьте меня, если я ошибаюсь) и сделал бы время автоподстройки сделок (и как упоминались случаи использования) полезные. Вот почему я спрашиваю, если там активно работали над этим. |
|
|
|
|
21 октября 2012, 6:39:13 PM
|
# 16 |
|
Сообщения: 1526
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Замена операция должна иметь одни и те же материалы, что и операции, которые они заменяют, так что нет, это не имеет никакого значения.
|
|
|
|
|
22 октября 2012, 9:40:14 AM
|
# 17 |
|
Сообщения: 338
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Замена операция должна иметь одни и те же материалы, что и операции, которые они заменяют, так что нет, это не имеет никакого значения. Конечно, я хочу, чтобы заменить сделку с теми же входами. Как еще это можно сделать недействительным время автоподстройки сделки? я думал "замена сделка" позволяет заменить (или лучше "Обновить") Незавершенных операций в пуле памяти. Или это еще один несчастливый называние вещей, которые на самом деле сделать что-то еще? |
|
|
|
|
22 октября 2012, 12:33:52 PM
|
# 18 |
|
Сообщения: 1526
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Замена транзакций позволяет заменить операции в пуле памяти, да. Однако эта сделка должна иметь те же входы, как предыдущая транзакция. Может быть, я не понял, что вы говорите. Даже при включенной замене транзакции, после трансляции какой-то вариант сделки находится в пуле памяти в любое время и все входы помечены как расходуется. Вы не можете изменить, какие входы расходуются, заменив его.
|
|
|
|
|
22 октября 2012, 1:52:15 PM
|
# 19 |
|
Сообщения: 338
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Спасибо за ваше время, чтобы объяснить эти вопросы для меня. Но unfortunateley я до сих пор не может следовать за вами, вы explanaitions.
Оставим более сложные сценарии в стороне на данный момент, и сосредоточиться только на замену одного транслировался, но время автоподстройки сделки. При включенной замене транзакции, представляется возможным сделать только, что, до тех пор, как одни и те же входы используются в заменяющей сделке. Поэтому предположим, этот порядок действий: Предварительные условия: - замена транзакций включена. Инварианты: - Вход A не используется в какой-либо другой не явно указанной сделки. 1.) Создание и вещание по времени не заблокировано (до t_lock) транзакции с входными А и выходом 1 2a.) Перед t_lock создавать и транслировать без времени запертых сделок с входным А и выходом 2 (отличным от выхода 1) 2b.) После того, как t_lock создавать и транслировать без времени запертых сделок с входным А и выходом 3 (другая формой вывода 1 и 2) Что происходит в 2а.) И 2б.)? Мое предположение: 2a.) Сделка с 1.) заменяется в пуле памяти. Поскольку время-ограничение теперь снимается он может быть включен в блок. Сделка вступает в силу, выходы вход А становятся доступными на выходе 2. 2b.) Сделка с 1.) входит в блок, так как время-ограничение удовлетворяется. Сделка с 2б.) Будет считаться недействительным, поскольку входы были уже потрачены. Выходы входного А являются воевавшими на выходе 1. Что произойдет, если нет замены транзакции (= текущая реализация?)? Мое предположение: 2а. и 2b.) Сделка с 1.) находится в пуле памяти и не могут быть заменены. Он остается там до тех пор, по времени ограничение не будет выполнено. Выходы вход А, наконец, стать на выходе Доступно 1. |
|
|
|
|
25 октября 2012, 3:51:51 AM
|
# 20 |
|
Сообщения: 1260
цитировать ответ |
Re: Transaction скрипт с высотой блока как условие
Я не думаю, что 2-из-2 депозитного покупает вам что-нибудь, поэтому я не обсуждал это ни в одном из моих сообщений / переговоров / вики-страниц. Он покупает мгновенное подтверждение для приемника, если депонированная 2-из-2 с возвратом был поставлен прежде, чем это было необходимо, поскольку приемник должен знать любой двойной тратит просто потому, что они должны были бы подписать их. Это идеально подходит для постановки Bitcoins на бирже, так что вам не придется ждать 6 подтверждений, прежде чем сделать торговлю, но без риска их кражи в хака или потеряны из-за сайт идет вниз. "мертвый переключатель мужчин" идея не работает. Если ключ транзакция, что восстановление также зашифрована, то это не поможет, если вы забыли пароль. Если он не зашифрован, то если кто-то получит доступ к вашему кошельку, они могут передать транзакцию восстановления и сделать ваш кошелек unspendable, а затем транслировать расходы на выходе операций восстановления. Вор придется подождать несколько месяцев, чтобы претендовать на деньги, но они получат его в конце концов. Не говоря уже о том, что сделка восстановления необходимо будет перестроен каждый раз, когда содержимое кошелька изменилось! "После трансляции входы, которые тратит транзакции используются и дважды затрачивает не будут приняты" ... в пуле памяти. Если я не совершенно неправильно, это означает, что все, что вам нужно сделать, это удается получить замену транзакции в блок до времени заперт транзакции может быть введен в блок (который, если вы сделали это правильно, должно быть несколько месяцев). Для предприятия, как MtGox, даже без замены транзакции обычно включена в сети, это не было бы никаких проблем.Любой, кто подумывает о nLockTime должны помнить об этом - сделка, которая время заперто входит в пул памяти и остается там до тех пор, время блокировки не будет достигнуто. После трансляции входы, которые тратит транзакции используются и дважды проводит не будут приняты. |
|
|
|
Как заработать Биткоины?
Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包
bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru
3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW
Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包
bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru
3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW
Регистрация для новых участников, на данный момент не доступна. Просим извинения за временные неудобства.