Ninazu (OP)
Newbie
Offline
Activity: 58
Merit: 0
|
|
August 24, 2017, 08:02:42 PM |
|
Оговорюсь сразу с С++ я не дружу. Поэтому курить исходники не посылайте. Но представление о информации, и технологиях применимых в программировании имеется, также как и принцип работы биткоина по старой схеме.
Если правильно понимаю то основная идея это вынесение подписи в отдельный тип блока. То есть в выходе остается отправитель и получатель, а подпись считается позже и сохраняется в отдельный безразмерный блок. Получается что-то похожее на сайдчейн. И еще добавляется какой-то SegWit адресс. Не понимаю как он обезопасит от фальшивых транзакций, ведь получается что транзакция добавляется в блок а только потом проверяется ее валидность.
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
amaclin1
|
|
September 04, 2017, 12:59:49 PM |
|
Оговорюсь сразу с С++ я не дружу. Поэтому курить исходники не посылайте. Но представление о информации, и технологиях применимых в программировании имеется, также как и принцип работы биткоина по старой схеме.
Если правильно понимаю то основная идея это вынесение подписи в отдельный тип блока. То есть в выходе остается отправитель и получатель, а подпись считается позже и сохраняется в отдельный безразмерный блок. Получается что-то похожее на сайдчейн. И еще добавляется какой-то SegWit адресс. Не понимаю как он обезопасит от фальшивых транзакций, ведь получается что транзакция добавляется в блок а только потом проверяется ее валидность. Понимаешь неправильно. Подпись не выносится в отдельный тип блока. И даже из транзакции она не выносится. Просто подпись не учитывается при формировании txid, но при определении валидна транзакция или нет подпись учитывается.
|
|
|
|
|
amaclin1
|
|
September 04, 2017, 03:19:51 PM |
|
Я тебе советую не перепрыгивать через ступеньку а сперва разобраться что такое BIP16 то есть что было до внедрения этого изменения протокола, в чем заключается это изменение и что стало лучше по сравнению с оригинальным концептом. Потом сегвит становится понятнее - это дальнейшее развитие той же идеи что старый клиент проверяет тупо хэш, а новый клиент кроме этого делает некоторые магические пассы.
|
|
|
|
Ninazu (OP)
Newbie
Offline
Activity: 58
Merit: 0
|
|
September 08, 2017, 10:03:31 AM |
|
Я тебе советую не перепрыгивать через ступеньку а сперва разобраться что такое BIP16 то есть что было до внедрения этого изменения протокола, в чем заключается это изменение и что стало лучше по сравнению с оригинальным концептом. Потом сегвит становится понятнее - это дальнейшее развитие той же идеи что старый клиент проверяет тупо хэш, а новый клиент кроме этого делает некоторые магические пассы. Посмотрел BIP16 у входа scriptSig это результат подписи публичного ключа с опкодом подписи, приватным ключом подтверждающим владение кошельком Я это увидел где-то так scriptSig = sign(pubkey + OP_CHECKSIG, privKey), А у выхода scriptPubKey это (в самом простом случае без мультиподписи) scriptPubKey = OP_HASH160 + hash(pubkey + OP_CHECKSIG) + OP_EQUAL Хотя я вижу и другие сценарии у выхода вроде scriptPubKey = OP_DUP + OP_HASH160 + hash(pubkey + OP_CHECKSIG) + OP_EQUALVERIFY + OP_CHECKSIG Если правильно понял суть, то подпись рассчитывается не сразу Как пример старой транзакции брал эту http://learnmeabitcoin.com/browser/transaction/json.php?txid=7a160081db721c1f915d9d5bec8a66fb4b52583188d2dab91ef37264d3534b12Как еще более старая транзакция до BIP16 http://learnmeabitcoin.com/browser/transaction/json.php?txid=d52e6e7fbc1b5d5bc9177947c0ab276f261a761266aeba69eae413e80055dc57Преобразование адреса в хеш проверял тут http://bitcoinvalued.com/tools.php3QVitrqkY1ddvWqVhCwAZteERFfv2MZ2hz -> FA281A32566066CC8BCA5E9FCD4051C66C690279 -> 1PohyKMJz7KFqM94a7Ga9GHJGjPCWD6FyP 1pGcRWf6XVg3z7susY1nGMMfnhv3M3Zsf -> 08F094D5EAF2F1C52E572F17828EFE12E4C52398 -> 1pGcRWf6XVg3z7susY1nGMMfnhv3M3Zsf
|
|
|
|
amaclin1
|
|
September 08, 2017, 10:50:59 AM |
|
у входа scriptSig это результат подписи публичного ключа с опкодом подписи, приватным ключом подтверждающим владение кошельком Я это увидел где-то так scriptSig = sign(pubkey + OP_CHECKSIG, privKey), Не в этом суть. есть scriptPubKey - это некоторая функция есть scriptSig - по сути дела это параметры передающиеся в функцию валидация проходит если scriptPubKey ( scriptSig ) = 1 Это оригинальный концепт. Потом подумали - а нахер нам иметь разные функции? давайте сделаем одну но будем выполнять её хитро. То есть выполнение такое return scriptPubKey ( scriptSig ) == 1 && executeLast ( scriptSig ) == 1 условно говоря, сперва выполняется по-старому алгоритму завещанному сатоши, а потом еще выполняется сам последний операнд при этом выполняются всякие проверки подписей. Это BIP-16 А потом еще подумали и решили, а давайте если последний операнд имеет определенный формат, то будем еще одну проверку делать, а сам код этой проверки вынесем в другое место? Ладно, смысл в том, что пока вы не поймете в чем суть BIP-16 вы о сегвите не поймёте Я вас только запутаю
|
|
|
|
Ninazu (OP)
Newbie
Offline
Activity: 58
Merit: 0
|
|
September 09, 2017, 01:44:42 PM |
|
Ладно, смысл в том, что пока вы не поймете в чем суть BIP-16 вы о сегвите не поймёте Я вас только запутаю
К сожалению мой уровень английского крайне плох также как и знание С++. Поэтому я больше путаюсь в переводах. А все что вы мне говорите мне понятно. Спасибо вам за это. Пробовал разобраться самостоятельно в исходниках, но там черт ногу сломит. Вся логика размазана по абстрактным слоям
|
|
|
|
amaclin1
|
|
September 11, 2017, 05:50:02 AM |
|
К сожалению мой уровень английского крайне плох также как и знание С++. Поэтому я больше путаюсь в переводах. А все что вы мне говорите мне понятно. Спасибо вам за это. Пробовал разобраться самостоятельно в исходниках, но там черт ногу сломит. Вся логика размазана по абстрактным слоям А не надо читать чужие исходники. Сделайте свои. Конечно, надо хоть один язык программирования знать. Бейсик и Паскаль тоже подойдут кстати. Возьмите простую задачу, допустим в файл распечатать все адреса из блокчейна. (будем считать что блокчейн уже скачан) Пока будете разбираться - как раз и поймете как выглядят транзакции и что такое bip16 и segwit
|
|
|
|
Ninazu (OP)
Newbie
Offline
Activity: 58
Merit: 0
|
|
September 11, 2017, 10:17:49 AM |
|
Пока будете разбираться - как раз и поймете как выглядят транзакции и что такое bip16 и segwit
Хорошо знаю PHP и PureBasic Немного хуже Go Все адреса из блокчейна вытащил) Вначале пробовал в MySQL на PHP, но получилось сильно долго и много места. Более компактно и быстро получилось с levelDb и хранением адресов в бинарном виде. Да именно такую задачу я перед собой и ставлю. Разобраться и попробовать реализовать segWit самому. Но для того чтоб сделать, нужно вначале понять как это сделать) Я ведь правильно понимаю? Что раньше скрипт разблокировки включался в выход транзакции. Сейчас там содержится только хеш Меркля (P2SH), само дерево представляет из себя возможные вариации скрипта (для мультиподписи или блокировки по времени к примеру). Дальше в следующей транзакции на вход добавляется cамо тело скрипта который сработал, и используя рутовый хеш из предыдущего выхода, можно проверить находился ли этот скрипт где-то в хешируемом дереве. Но это всё в теории из того что я смог понять. И тут у меня ступор, ведь на практике если взять segWit транзакцию http://learnmeabitcoin.com/browser/transaction/json.php?txid=06c543e4f1f2ff6448e2c370078ac80b1d1ab324aa9dbef8db2202313a70c643То scriptSig - это тело скрипта, или очередной хеш? И что такое txinwitness P.S. Как оно работает брал отсюда https://bits.media/news/sleduyushchiy-etap-po-uluchsheniyu-bitkoina-nazyvaetsya-mast/
|
|
|
|
amaclin1
|
|
September 11, 2017, 10:56:54 AM |
|
Все адреса из блокчейна вытащил) Вначале пробовал в MySQL на PHP, но получилось сильно долго и много места. Более компактно и быстро получилось с levelDb и хранением адресов в бинарном виде. Прекрасно. Половина дела сделана. Базу вы как парсите? Дергаете клиент за API или самостоятельно открываете читаете blk-файлы? Я ведь правильно понимаю? Что раньше скрипт разблокировки включался в выход транзакции. Сейчас там содержится только хеш Меркля (P2SH), само дерево представляет из себя возможные Ой-вей. Всё смешалось в доме Облонских. Меркля забудьте. И не вспоминайте. Этот хэш вообще из другой оперы. Есть несколько "разновидностей" использования сегвита. Два (по-моему) нативных и два завернутых в P2SH Начнем с нативных. А, не, давайте вспомним сперва как работает самый популярный p2pkh scriptPubKey = OP_DUP OP_HASH160 <address> OP_EQUALVERIFY OP_CHECKSIGтакой скрипт в обычных условиях вернет в стеке "1" если в scriptSig будет два пуш-элемента: сигнатура и публичный ключ. Причем хэш публичного ключа (не Меркль, а посчитанный по-биткойновски) должен быть равным адресу (иначе OP_EQUALVERIFY бросит исключение), а сигнатура должна правильно подписывать подписывать дайджест (иначе OP_CHECKSIG вернет "0" или вообще бросит исключение) Задание на проверку навыков. Что если scriptSig состоит не из двух, а из трех и более элементов? последний - это публичный ключ, предпоследний - валидная сигнатура, а остальные - какие-либо другие? Что будет в стеке после выполнения? Будет ли транзакция валидной? Подтвердят ли её майнеры? И второе задание на проверку навыков: а если в scriptSig будет одна или ноль пуш-операций? На какой команде произойдет сбой выполнения? Теперь переходим к нативным. Я по памяти буду писать. Идею изложу, но могу где-то напутать. Нативный pubkeyScript имеет вид OP_0 <scripthash>Про сегвит пока забыли. Давайте проверим навыки. Каким должен быть scriptSig чтобы после последовательного выполнения scriptSig и scriptPubkey наверху стека оказалось бы ненулевое значение. (ответ на этот вопрос можно высказать одним словом)
|
|
|
|
Ninazu (OP)
Newbie
Offline
Activity: 58
Merit: 0
|
|
September 11, 2017, 03:06:48 PM |
|
Прекрасно. Половина дела сделана. Базу вы как парсите? Дергаете клиент за API или самостоятельно открываете читаете blk-файлы?
За API, до blk формата файлов я еще не дошел. Но предположу что там тоже levelDb и на выходе будет просто сырые данные, которые после преобразования приймут структуру подобную json дереву из примеров. http://learnmeabitcoin.com/browser/transaction/06c543e4f1f2ff6448e2c370078ac80b1d1ab324aa9dbef8db2202313a70c643Задание на проверку навыков. Что если scriptSig состоит не из двух, а из трех и более элементов? последний - это публичный ключ, предпоследний - валидная сигнатура, а остальные - какие-либо другие? Что будет в стеке после выполнения? Будет ли транзакция валидной? Подтвердят ли её майнеры?
Так как значения забираются из стека в обратной последовательности, и функция почистит два элемента сигнатуру и публичный ключ, то в стеке останутся остальные элементы. А первый операнд будет заменён на результат функции. Предположу что да, транзакция будет валидной при условии соответсвия адреса и сигнатуры И второе задание на проверку навыков: а если в scriptSig будет одна или ноль пуш-операций? На какой команде произойдет сбой выполнения?
По идее на первом обращении к функции, так как количество аргументов отличается от задекларированного. Ну или как вариант если аргументы динамические то OP_EQUALVERIFY так как до OP_CHECKSIG не дойдёт очередь. Каким должен быть scriptSig чтобы после последовательного выполнения scriptSig и scriptPubkey наверху стека оказалось бы ненулевое значение.
OP_0 - добавляет пустой массив в стек. Значит scripthash любой отличный от нуля. Ненулевое значение в стеке будет если scriptPubkey вернёт не ноль.
|
|
|
|
amaclin1
|
|
September 11, 2017, 03:48:18 PM |
|
Так как значения забираются из стека в обратной последовательности, и функция почистит два элемента сигнатуру и публичный ключ, то в стеке останутся остальные элементы. А первый операнд будет заменён на результат функции. Предположу что да, транзакция будет валидной при условии соответсвия адреса и сигнатуры Да. Лучше конечно называть "элемент на вершине стека", а то непонятно откуда мы считаем. Транзакция валидна, но майнеры её не включат, так как по полиси-правилам (это нестрогое правило) на стеке должен остаться только один ненулевой элемент. По идее на первом обращении к функции, так как количество аргументов отличается от задекларированного. Ну или как вариант если аргументы динамические то OP_EQUALVERIFY так как до OP_CHECKSIG не дойдёт очередь. Почему не дойдет? Проверка необходимого числа элементов в стеке происходит при выполнении каждой команды Если в scriptSig только публичный ключ - то OP_EQUALVERIFY сработает, а OP_CHECKSIG сломается - ему надо два аргумента, а в стеке только один Если в scriptSig вообще пусто - то сломается на OP_DUP OP_0 - добавляет пустой массив в стек. Значит scripthash любой отличный от нуля. Ненулевое значение в стеке будет если scriptPubkey вернёт не ноль. Не-не-не Вы неправильно поняли мою запись. OP_DUP OP_HASH160 <address> OP_EQUALVERIFY OP_CHECKSIG - в этом скрипте <address> значит "положить 20 байтов в стек" то есть здесь пять операций делается OP_0 <scripthash> - тут две операции - положить в стек пустой массив и положить в стек 20 байт (или 32 байта - я ведь не указал сколько разрядов у scripthash) (Вероятность того, что результат хэш-функции нулевой настолько мала, что это можно не упоминать специально) Но это scriptPubkey Повторяю вопрос. Каким должен быть scriptSig чтобы после выполнения сперва scriptSig а потом этого scriptPubKey на вершине стека было бы ненулевое число? Ответ - одним словом.
|
|
|
|
Ninazu (OP)
Newbie
Offline
Activity: 58
Merit: 0
|
|
September 11, 2017, 08:41:45 PM |
|
Не-не-не Вы неправильно поняли мою запись. OP_DUP OP_HASH160 <address> OP_EQUALVERIFY OP_CHECKSIG - в этом скрипте <address> значит "положить 20 байтов в стек" то есть здесь пять операций делается
Разберу оптимистический сценарий 1. Заносим scriptSig в стэк pubKey->signature 2. Дублируем верхний элемент стека pubKey->pubKey->signature 3. Находим хеш публичного ключа pubKeyHash->pubKey->signature 4. Помещаем хеш адреса в стек addressHash->pubKeyHash->pubKey->signature 5. Сравниваем addressHash и pubKeyHash (функция OP_EQUAL) true->pubKey->signature 6. Если валидация не прошла помечаем транзакцию как невалидную (процедура OP_VERIFY) pubKey->signature 7. Проверяем подпись OP_CHECKSIG true Повторяю вопрос. Каким должен быть scriptSig чтобы после выполнения сперва scriptSig а потом этого scriptPubKey на вершине стека было бы ненулевое число? Ответ - одним словом.
Что-то тут неясно. Во первых scriptSig - это ж набор параметров, почему он должен выполнятся? Во вторых чтоб на выходе scriptPubKey было ненулевое число, сценарий должен дойти до конца и вернуть true. А это значит: 1. scriptSig должен состоять из публичного ключа и сигнатуры 2. сигнатура должна соответсвовать дайджесту 3. еще и полиси правило про один ненулевой элемент не мешало бы соблюсти. Как на это ответить одним словом? Причем тут OP_0 и scripthash?
|
|
|
|
amaclin1
|
|
September 12, 2017, 05:02:47 AM |
|
Разберу оптимистический сценарий 1. Заносим scriptSig в стэк pubKey->signature Всё правильно. Только что значит "заносим в стек"? Кто его заносит? Поймите: scriptSig - это тоже скрипт и его просто выполняютКогда-то раньше не было ограничений на этот скрипт - можно было любые конанды использовать. Потом решили что достаточно только пуш-операций. Остальное тоже можно (вроде софт-форк ограничивающий множество доступных в scriptSig операций не вводили), но нестандартно. Повторяю вопрос. Каким должен быть scriptSig чтобы после выполнения сперва scriptSig а потом этого scriptPubKey на вершине стека было бы ненулевое число? Ответ - одним словом. Что-то тут неясно. Во первых scriptSig - это ж набор параметров, почему он должен выполнятся? Во вторых чтоб на выходе scriptPubKey было ненулевое число, сценарий должен дойти до конца и вернуть true. А это значит: Каждый отдельный скрипт не обязан, чтобы на стеке после его выполнения было ненулевой значение на вершине. Транзакция считается валидной если после последовательного выполнения scriptSig и scriptPubKey на вершине стека ненулевое значение. Вам надо понять, что проверка транзакции - это именно что выполнение scriptSig и scriptPubKey над одним объектом стека. scriptSig туда кладет, scriptPubKey - забирает и проверяет. В первых версиях биткойна вообще проверка транзакции проходила так, что scriptSig и scriptPubKey склеивались в один байтовый массив и выполнялись как один скрипт. Потом Сатоши допёр почему так нельзя делать. 1. scriptSig должен состоять из публичного ключа и сигнатуры 2. сигнатура должна соответсвовать дайджесту Это только для расходования p2pkh-выходов. Есть же еще другие типы выходов например pay-to-public-key в этом случае scriptPubkey <publickey> OP_CHECKSIG (когда я пишу в угловых скобках - это значит операция:положить в стек) и scriptSig соответствующий этому scriptPubkey - это просто <signature>3. еще и полиси правило про один ненулевой элемент не мешало бы соблюсти. Как на это ответить одним словом? Причем тут OP_0 и scripthash? Мы к сегвиту уже перешли. Рассматриваем как видит сегвит-транзакции обычная старая нода.
|
|
|
|
Ninazu (OP)
Newbie
Offline
Activity: 58
Merit: 0
|
|
September 12, 2017, 09:52:04 AM |
|
Спасибо. Так более ясная картинка становится с каждым сообщением. Потом Сатоши допёр почему так нельзя делать.
Минусы в избыточности данных? Или что-то с безопасностью? Мы к сегвиту уже перешли. Рассматриваем как видит сегвит-транзакции обычная старая нода.
Ура. Но все равно у меня вопрос. Если для новой транзакции scriptSig что-то делает(главное чтоб не исключение бросал), а после этого scriptPubkey добавляет в стек пустой массив и хеш скрипта, и после этого нет больше никакого опкода. То верхним элементом стека будет хеш скрипта. scriptHash -> [] -> scriptSigResult(если он есть) Транзакция будет считаться валидной, но майнеры её не включат из-за полиси по размеру стека
|
|
|
|
amaclin1
|
|
September 12, 2017, 11:03:25 AM |
|
Транзакция будет считаться валидной, но майнеры её не включат из-за полиси по размеру стека Ну да. Именно этот финт я пытался использовать вот тут: https://bitcointalk.org/index.php?topic=1759350.0Ответ на мой вопрос я хотел получить одним словом: scriptSig может быть любой в том числе и пустой. После выполнения scriptSig и scriptPubkey на вершине стека остается ненулевой элемент и транзакция с точки зрения старых клиентов валидна, то есть имеет право жить в блоке. А новые клиенты имеют костыль - они видят что scriptSig пустой а scriptPubkey имеет определенный формат и вытаскивают из witness-данных транзакции код и начинают исполнять его тоже.
|
|
|
|
amaclin1
|
|
September 12, 2017, 11:11:03 AM |
|
Потом Сатоши допёр почему так нельзя делать. Минусы в избыточности данных? Или что-то с безопасностью? С безопасностью. Если scriptPubkey состоит из N байтов (что внутри неважно, 0 < N < 72), то я scriptSig сделаю из одного байта со значением N и после конкатенации результирующий скрипт будет в стек класть сам scriptPubKey - то есть я таким образом могу потратить любой чужой выход Вот тут есть наша с theymos (это владелец этого форума) дискуссия https://bitcoin.stackexchange.com/questions/29754/history-behind-the-scripting-language-in-bitcoin
|
|
|
|
Ninazu (OP)
Newbie
Offline
Activity: 58
Merit: 0
|
|
September 12, 2017, 02:35:47 PM |
|
Да я уже понял что опкоды 01-4B отвечают за копирование данных, указанной длины в стек.
Ура наконец добрались до txinwitness данных. Как они загружаются в стек и выполняются предположу что по той же схеме что и скрипты. Но зачем они, какова их суть?
|
|
|
|
amaclin1
|
|
September 12, 2017, 03:18:23 PM |
|
Да я уже понял что опкоды 01-4B отвечают за копирование данных, указанной длины в стек. Мне пора брать бабло за репетиторство Ура наконец добрались до txinwitness данных. Как они загружаются в стек и выполняются предположу что по той же схеме что и скрипты. Но зачем они, какова их суть? Мы немного перепрыгнули BIP-16. Ладно. Сегвит решает несколько задач. 1. Он обратно совместим со старым биткойном. То есть не надо пересаживать 100500 юзеров на новый клиент, что в децентрализованном мире нелегко или даже невозможно. Достаточно чтобы проголосовали хэш-мощности. 2. Он уменьшает размер транзакции, если считать "по старым правилам". Вкупе с пунктом 1 это дает большую пропускную способность сети. 3. Он устраняет проблемы с пластичностью транзакций, то есть если вы посылаете транзакцию с каким-то txid то она не сможет подтвердиться с другим txid 4. Самое главное - это позволяет узнать txid до подписывания транзакции.
|
|
|
|
Ninazu (OP)
Newbie
Offline
Activity: 58
Merit: 0
|
|
September 12, 2017, 07:46:19 PM |
|
Мы немного перепрыгнули BIP-16. Ладно.
Да. Это я на радостях)) Как я понял до BIP16 использовались P2PK и P2PKHBIP 16 подарил нам P2SHЧто в свою очередь очен изменило архитектуру и добавило плюшки вроде MUTLISIG. А сам SegWit уже в P2WPK, P2WSH
|
|
|
|
|