Консенсус поддерживается порядковые номера | Биткоин форум

		Биткоин Форум > Разработка и Техническое Обсуждение
Консенсус поддерживается порядковые номера

17 февраля 2016, 5:28:01 PM	# 1
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: Консенсус поддерживается порядковых номеров Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Порядковые номера в настоящее время не подлежит исполнению на Bitcoin. Если две операции проводят одинаковые выходные данные, то шахтер должен выбрать транзакцию (вход) с более высоким номером последовательности. Это не может быть приведено в исполнение и так, шахтер, вероятно, выбрать тот, с самыми высокими налогами. Они могли бы быть исполнено, если замена сделка была возможна в блоках. С жесткой вилкой, правило может измениться так, что сделки с locktimes в будущем может в блоки. Locktime бы предотвратить выходы из тратятся. После этого, если кто-то вещает сделку, которая дважды проводит несколько входов и где все эти входы имеют более высокий порядковый номер, то он будет эффективно отменить первоначальную сделку. После того, как будет достигнут Locktime, тогда выходы высшей транзакции последовательности могут быть потрачены. Можно сделать это (менее эффективно) с мягкой вилкой. Якорь / multisig сделка будет иметь N выходов следующего вида: Код: ЕСЛИ <сейчас + 40 дней> CLTV DROP <возврат открытого ключа> OP_CHECKSIG ELSE CHECKMULTISIGVERIFY КОНЕЦ Государственные операции обновления будет N входных и выходных транзакций N со следующими выходами. Код: ЕСЛИ <сейчас + 30 дней> CLTV DROP <открытый ключ нового владельца> OP_CHECKSIG ELSE <Последовательность чисел> OP_CHECKSEQUENCEVERIFY КОНЕЦ Они бы проводит первые N выходов сделки якорного и тратить их на N новых выходов. Каждый из государственных операций обновления может выступать в качестве связующего звена. До тех пор, как он тратит связь с меньшим порядковым номером, то она является действительной сделкой. После 30 дней CLTV прошел, выходной результат может быть израсходованы. Там должно быть пособие для в некоторых дополнительных входов в сделку, чтобы платить взносы. Это может работать похоже на SIGHASH_ANYONE_CAN_PAY. OP_CHECKSEQUENCEVERIFY означает, что вы можете эффективно использовать scriptPubKeys родительской транзакции вместо этого сделки. Каждая нижняя сделка порядкового номера использует открытый ключ от своего родителя в цепи обратно к сделке корня / анкера. В-псевдо код, он делает следующее Примечание: max_sequence начинается 0xFFFFFFFF если (sequence_number >= Max_sequence) вернуться FAIL; Если (TXID из первых N входов не равны) вернуться FAIL; Родитель = getTransaction (TxIn [п] .getPrevTransaction ()) если (TXID из первых N входов родителя не равны) вернуться FAIL; stack.pop (); // Удалить <Последовательность чисел> stack.pop (); // Удалить <1> для IF subScript.max_sequence = sequence_number subScript.scriptSig = stack.copy () subScript.scriptPubKey = parent.getgetPubKey () transactionCopy = сделка с первыми N txids заменены дедушкой TXID если (subScript.execute (transactionCopy) == СБОЙ) // Использование transactionCopy для всех операций scriptSig вернуться FAIL; проследовать, как будто это был NOP

Как заработать Биткоины?
Без вложений. Не майнинг.

18 февраля 2016, 5:55:32 PM	# 2
jl777 Сообщения: 1162 Цитировать по имени цитировать ответ	Re: Консенсус поддерживается порядковых номеров Получил 1806 Биткоинов Реальная история. Цитата: TierNolan от 17 февраля 2016 года, 5:28:01 PM Порядковые номера в настоящее время не подлежит исполнению на Bitcoin. Если две операции проводят одинаковые выходные данные, то шахтер должен выбрать транзакцию (вход) с более высоким номером последовательности. Это не может быть приведено в исполнение и так, шахтер, вероятно, выбрать тот, с самыми высокими налогами. Это не звучит хорошо ... Как микроплатежей каналы могут быть надежными, если порядковые номера игнорируются? В качестве временного решения, возможно, добавив дополнительный Satoshi для каждого нового платежа будет практическим обходным путем. С микроплатежей, одни и те же входы "используемый" снова и снова, только с суммой платежа, подписью и изменениями sequenceid. Без sequenceid принуждения для обеспечения предшествующих платежей являются недействительными, то если раньше один вещают, это, кажется, означает, что позже обыкновение не может рассчитывать на силу. Означает ли это, что там нет смысла в использовании sequenceid на всех? Кажется, что все протоколы должны быть безопасными без опоры на sequenceids и в предположении, что любая передача offchain знакового ТХ может транслироваться. Джеймс

18 февраля 2016, 6:15:25 PM	# 3
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: Консенсус поддерживается порядковых номеров Цитата: jl777 от 18 февраля 2016 года, 5:55:32 PM Это не звучит хорошо ... Как микроплатежей каналы могут быть надежными, если порядковые номера игнорируются? В качестве временного решения, возможно, добавив дополнительный Satoshi для каждого нового платежа будет практическим обходным путем. Ни одно из последних предложений канала фактически не используют порядковые номера, именно по этой причине. Единственные цифры, что последовательности используются как для включения и выключения Locktime (а также отказаться в заменить плату). Исходные каналы были одним способом. Боб будет иметь много сделок, и каждый из них будет платить ему больше, чем в прошлом. Он может вещать и раньше, но это будет означать, что он получает меньше денег. Сеть Молния использует отменить коды. Вы можете транслировать аннулированные сделки, но если вы делаете, другой человек получает 100% денег в канале. Я пытался придумать способ, чтобы получить порядковые номера для работы. Для того, чтобы быть осуществимым, сделки должны замороженный на некоторое время, чтобы дать более поздние блоки шанс отменить их.

18 февраля 2016, 6:38:31 PM	# 4
jl777 Сообщения: 1162 Цитировать по имени цитировать ответ	Re: Консенсус поддерживается порядковых номеров Цитата: TierNolan от 18 февраля 2016 года, 6:15:25 PM Цитата: jl777 от 18 февраля 2016 года, 5:55:32 PM Это не звучит хорошо ... Как микроплатежей каналы могут быть надежными, если порядковые номера игнорируются? В качестве временного решения, возможно, добавив дополнительный Satoshi для каждого нового платежа будет практическим обходным путем. Ни одно из последних предложений канала фактически не используют порядковые номера, именно по этой причине. Единственные цифры, что последовательности используются как для включения и выключения Locktime (а также отказаться в заменить плату). Исходные каналы были одним способом. Боб будет иметь много сделок, и каждый из них будет платить ему больше, чем в прошлом. Он может вещать и раньше, но это будет означать, что он получает меньше денег. Сеть Молния использует отменить коды. Вы можете транслировать аннулированные сделки, но если вы делаете, другой человек получает 100% денег в канале. Я пытался придумать способ, чтобы получить порядковые номера для работы. Для того, чтобы быть осуществимым, сделки должны замороженный на некоторое время, чтобы дать более поздние блоки шанс отменить их. Так порядковые номера действительно только двоичный флаг? 0xffffffff означает Locktime игнорируется, все остальное означает Locktime почитается. Я думаю, как только порядковые номера аннулируют другие ТЕ с более ранними, он открывает множество крайних случаев о том, когда они транслируются противы подтвердили Джеймс

18 февраля 2016, 7:16:07 PM	# 5
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: Консенсус поддерживается порядковых номеров Цитата: jl777 от 18 февраля 2016 года, 6:38:31 PM Так порядковые номера действительно только двоичный флаг? 0xffffffff означает Locktime игнорируется, все остальное означает Locktime почитается. Да, но есть план, чтобы превратить их в систему, чтобы поддерживать относительную locktimes вместо этого. Если последовательность меньше, чем 0x80000000 (и некоторые другие условия), то она будет интерпретироваться как относительной высоты блока или относительной временной метки. Это как CLTV, но это относительно. Вы можете оплатить Код: ЕСЛИ <144 блоков> CSV DROP <ключ паб алиса> CHECKSIG ELSE HASH160 <хэш (отменить код)> EQUALVERIFY <ключ паб боб> CHECKSIG Это означает, что алиса должен ждать, по крайней мере, 144 блоков, чтобы провести этот вывод. Если Боб имеет код Отозвать, он всегда будет иметь по крайней мере 1 день, чтобы претендовать на его выход. Он не должен использовать CLTV и зафиксировать его в течение 30 дней, но он по-прежнему гарантируется окно 144 блока. Это запрос тянуть: https://github.com/bitcoin/bitcoin/pull/7184 и BIP https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki котировка Я думаю, как только порядковые номера аннулируют другие ТЕ с более ранними, он открывает множество крайних случаев о том, когда они транслируются противы подтвердили Первоначальное предложение влияет только пулы памяти, поэтому она не обеспечена военнопленным. Если заблокированные транзакции могут быть включены в блоки, то правило может быть правило консенсуса.

18 февраля 2016, 9:04:16 PM	# 6
jl777 Сообщения: 1162 Цитировать по имени цитировать ответ	Re: Консенсус поддерживается порядковых номеров Цитата: TierNolan от 18 февраля 2016 года, 7:16:07 PM Цитата: jl777 от 18 февраля 2016 года, 6:38:31 PM Так порядковые номера действительно только двоичный флаг? 0xffffffff означает Locktime игнорируется, все остальное означает Locktime почитается. Да, но есть план, чтобы превратить их в систему, чтобы поддерживать относительную locktimes вместо этого. Если последовательность меньше, чем 0x80000000 (и некоторые другие условия), то она будет интерпретироваться как относительной высоты блока или относительной временной метки. Это как CLTV, но это относительно. Вы можете оплатить Код: ЕСЛИ <144 блоков> CSV DROP <ключ паб алиса> CHECKSIG ELSE HASH160 <хэш (отменить код)> EQUALVERIFY <ключ паб боб> CHECKSIG Это означает, что алиса должен ждать, по крайней мере, 144 блоков, чтобы провести этот вывод. Если Боб имеет код Отозвать, он всегда будет иметь по крайней мере 1 день, чтобы претендовать на его выход. Он не должен использовать CLTV и зафиксировать его в течение 30 дней, но он по-прежнему гарантируется окно 144 блока. Это запрос тянуть: https://github.com/bitcoin/bitcoin/pull/7184 и BIP https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki котировка Я думаю, как только порядковые номера аннулируют другие ТЕ с более ранними, он открывает множество крайних случаев о том, когда они транслируются противы подтвердили Первоначальное предложение влияет только пулы памяти, поэтому она не обеспечена военнопленным. Если заблокированные транзакции могут быть включены в блоки, то правило может быть правило консенсуса. Удивительно, что порядковые номера не работают, как это документально ... Я думал, CHECKSEQUENCEVERIFY уже был на mainnet, но если Арент PoW sequenceid в исполнение, это, вероятно, по-прежнему хорошо, но нужно быть очень осторожными с предположениями относительно того, кто получает полностью подписал ТХ с sequenceids в них. без какого-либо принуждения, то в настоящее время CSV только позволяет подписавший выход CSV, чтобы сделать недопустимые расходы? Я хочу, чтобы убедиться, что мое текущее использование является безопасным. То, что я сделать, это установить sequenceid 0xffffffff, для всех ТХ, если он не использует CLTV, то я поставил его на основе текущего UnixTime. Я полагаю, то же +/- 2 часа дисперсия допускается? Поэтому я думаю, что нужно раздуть все время от 2-х часов, чтобы предотвратить несоответствующие метки времени от синхронизирующего кого-то нечаянно Джеймс

18 февраля 2016, 10:07:56 PM	# 7
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: Консенсус поддерживается порядковых номеров Цитата: jl777 от 18 февраля 2016 года, 9:04:16 PM Я хочу, чтобы убедиться, что мое текущее использование является безопасным. То, что я сделать, это установить sequenceid 0xffffffff, для всех ТХ, если он не использует CLTV, то я поставил его на основе текущего UnixTime. Я полагаю, то же +/- 2 часа дисперсия допускается? Поэтому я думаю, что нужно раздуть все время от 2-х часов, чтобы предотвратить несоответствующие метки времени от синхронизирующего кого-то нечаянно Насколько я знаю, Locktime работает, просто игнорируя сделки, которые имеют Locktime в будущем, то есть сделки, не пересылаются или добавляются в пул памяти. Если последовательность на всех входах является 0xFFFFFFFF, то он считается окончательным и будет перенаправлен (и могут быть включены в блоки). Вы можете установить последовательность в 0xFFFFFFFE. То есть отказаться от замены на плате. Протоколы не заботятся о замене сделки в любом случае (или, по крайней мере, они не должны). Новый план, чтобы изменить поле последовательности следующим образом: Все входы 0xFFFFFFFF: Final Эта операция может быть включена в любом блоке, как это является окончательным. Эти операции не позволяют заменить плату. Все входы 0xFFFFFFFE или выше: Отключить заменить плату Эта сделка помечается как отказаться от замены на плате. Тем не менее, он все еще имеет Locktime. Все входы >= 0x80000000: Opt-в заменить плату Эти сделки предпочли, чтобы заменить плату. Входы с порядковыми номерами ниже 0xFFFFFFFE могут быть двойными израсходованы и шахтер может заменить сделку. Примечание: шахтер в любом случае может заменить сделку. Любые входы ниже 0x80000000: Проверьте последовательность проверить Операции имеют входы с относительной проверкой Locktime и не могут быть потрачены на задержку после того, UT тратятся включено в blockchain.

19 февраля 2016, 11:13:10 PM	# 8
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: Консенсус поддерживается порядковых номеров Цитата: TierNolan от 18 февраля 2016 года, 7:16:07 PM Первоначальное предложение влияет только пулы памяти, поэтому она не обеспечена военнопленным. Если заблокированные транзакции могут быть включены в блоки, то правило может быть правило консенсуса. Это запутаться. См даже увидеть даже название BIP68: "Относительная блокировка время с помощью номера консенсусной последовательности-исполнение." Идея заключается в том, что это будет консенсус в жизни (с помощью мягкой вилки). То, что вы видели, с "mempool только" из-за обработки в настоящее время используется для мягких вилок в Core: Где можно ядро предпочитает первый реализовать функциональность в качестве политики для того, чтобы получить опыт в разработке и реализации, а также позволит не-очень-безопасное экспериментирование с клиентским программным обеспечением для того, чтобы способствовать развитию и получить опыт эксплуатации. (Это было сделано для CLTV, это также в настоящее время делается для среднестатистического времени прошлого (с 0.11.2) ... и будет сделано с органами последовательности). Ни одна замена сделок в blockchain не требуется, и я не думаю, что это дает какой-либо value--, конечно, не достаточно, чтобы оправдать огромные нарушения наслоения; например было бы полностью разрушить SPV предположения: "Вот доказательство вы заплатили", "Ну, как я знаю, что некоторые позже сделка не заменить его?" "Гм, позвольте мне послать вам всю blockchain для окна тайм-аута", Было бы также быть менее эффективным, чем BIP58, так как вы в конечном итоге с постоянно таскать сделок, которые в конечном итоге были заменены. Обе схемы требуют, что есть по крайней мере один блок с помощью «честного» горняка (это означает, принимая превосходную последовательность тратить, даже если подкупила взять низшее один) до истечения тайм-аута ниже последовательность операций. Вы можете сравнить то, что вы думаете, чтобы BIP68 и выделить какое-либо преимущество? Цитата: jl777 от 18 февраля 2016 года, 9:04:16 PM Удивительно, что порядковые номера не работают, как это документально ... Я думал, CHECKSEQUENCEVERIFY уже был на mainnet, А? Порядковые номера работают именно так, как описано в литературе (они в настоящее время не делать ничего, хотя BIP68 пытается изменить эту ситуацию ...). CSV очень новое предложение, почему вы думаете, он был активен на mainnet?

20 февраля 2016, 12:51:27 AM	# 9
jl777 Сообщения: 1162 Цитировать по имени цитировать ответ	Re: Консенсус поддерживается порядковых номеров Цитата: gmaxwell от 19 февраля 2016 года, 11:13:10 PM А? Порядковые номера работают именно так, как описано в литературе (они в настоящее время не делать ничего, хотя BIP68 пытается изменить эту ситуацию ...). CSV очень новое предложение, почему вы думаете, он был активен на mainnet? Я, наверное, смотрел на неверную документации? Официальное определение: "Ряд предназначен, чтобы неподтвержденные время автоподстройки транзакции, которые будут обновляться до дорабатывается; В настоящее время не используется, за исключением того, чтобы отключить Locktime в транзакции" Если вы читали выше определение и не понимают, что "предназначена" означает, что вся часть о неподтвержденных время автоподстройки сделок не имеет никакого значения, это довольно легко запутаться. Кроме того, bitcoinj документы микроплатежей каналы и использует увеличение sequenceids. Если предположить, что OP является правильным, то, как представляется, противоречит bitcoinj задокументированы поведения. котировка Если две операции проводят одинаковые выходные данные, то шахтер должен выбрать транзакцию (вход) с более высоким номером последовательности. Это не может быть приведено в исполнение и так, шахтер, вероятно, выбрать тот, с самыми высокими налогами Кроме того, каждый вход имеет поле sequenceid, его единственной функцией тока для переключения Locktime вкл / выкл, но есть только один Locktime в ТХ. Много переключает все работает на тот же Locktime является еще одним запутанной частью. Я полагаю, что для SIGHASH_ALL, если таковые sequenceids не -1 Locktime включен, или его, или сделать все должно иметь то же самое. и SIGHASH_SINGLE я понятия не имею, как она должна работать. Я сомневаюсь, что я только один смущены все это и единственная причина, мне нужно знать подробности, потому что я пишу fullnode с нуля, поэтому мне нужно, чтобы быть в состоянии справиться, как это было сделано исторически. Джеймс

20 февраля 2016, 1:16:12 AM	# 10
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: Консенсус поддерживается порядковых номеров Цитата: gmaxwell от 19 февраля 2016 года, 11:13:10 PM См даже увидеть даже название BIP68: "Относительная блокировка время с помощью номера консенсусной последовательности-исполнение." Я отдаю себе отчет в формате CSV, и это было не то, что я имел в виду. Оглядываясь назад, я должен был использовать различные термины. Что должно было случиться, что было порядковые номера позволят замену, но это не было реализовано и не является безопасным в любом случае. котировка Вы можете сравнить то, что вы думаете, чтобы BIP68 и выделить какое-либо преимущество? Это дало бы гораздо более тонко зернистую нумерацию последовательности и ближе к первоначальному намерению. Я не вижу его в качестве замены для CSV. В самом деле, CSV или Locktime могут быть использованы, чтобы убедиться, что более поздние версии сделки имеют время для вещания. Требуемая операция является то, что каждая полностью подписана сделка может выступать в качестве связующего звена в цепи. Было бы считаться действительной сделкой условной на нем строятся по ссылке с более низким номером последовательности (или анкерным / корнем цепи). Это означает, что нет никакого смысла в эфире ничего, кроме последней версии, так как если вы передаете более раннюю версию, и она попадет в блок, один из других партий просто вещает более позднюю версию. Я думал о многопартийных версиях платежных каналов. Молния по своей природе основана на связывая много 2 сторонних каналов. Это означает, что концентратор должен потратить капитал на каждом канале поддерживается. В принципе, концентратор может создать партию канал N с одним вкладом капитала и делиться между клиентами. Даже в простом случае, когда все клиенты имеют 100% времени бесперебойной работы и всегда подписывать переходы между состояниями, которые не снижают их выделения, не существует простой способ сделать это. Штрафы на основе Отозвать коды не работают, а с каналом многопартийного. В канале 2 партии, вы просто высылаете 100% средств каналов на совместимую партию. С каналом многопартийной, что не работает. Оригинальный двусторонний канал будет работать. Вы могли бы начать с Locktime 60 дней в будущем, а затем шаг обратно 2 часа для каждого перехода. Все стороны должны подписать новую сделку, хотя. Было бы лучше, если подпись от партий, не имеющих их распределение уменьшенный не было необходимости.

« Предыдущая тема | Следующая тема »

Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW