Кто может подсказать откуда берутся коэффициенты, лимиты, события? Могу ли я добавить своё событие? Изменение коэффициентов записывается в блокчейн? Как можно связать транакцию в блокчейне с конкретной ставкой из реального мира?

Тебе удалось? Как сформировать запрос? У меня осталось 0.007 BTC там
Окончание SHA256 контракта пишет что 31.08.2018

Народ помоги разобраться с этим дерьмом

Суть такова, скидывал на локальный кошелёк, еще летом.
https://thetangle.org/address/MPSCEZSEDPLXCPUKGJXEPLTQVKCUVEDDLFHDLYPPFCGSEPZANVAJHPVDGSLAJGOFRTLLRGBHRLYU9BRSF
Одна входящая транзакция, но при этом на балансе в эксплорере показывает 0.

Если правильно понял там произошел резервый snapshot, погуглив и поискав в файлах снапшота за сентябрь и октябрь

Нашел свой кошелёк в обеих
Сентябрь
Октябрь

Вроде это уже хорошо

На всякий случай проверил через balance-finder c ключем p (Pre-Transitioned)

Который мне вернул на первом же адресе


Значит всё правильно Seed правильный и соответсвует кошельку

Как понимаю нужно юзать Reclaim Tool?

Под каким Seed заходить в кошелек под старым или под новым? Или это не играет роли. Главное указать Old Seed соответсвующий кошельку MPSCEZS....?
А новый seed также генерируется случайно, и нужно будет просто зайти под ним, после подтверждения транзакции?

И как посмотреть на какой адрес ушли средства после reclain?

Was hoping to find some neighbors so that I can setup a full node. Please send list in PM

@iotatangle

Как понимаю за это отвечает BIP 143.

Нашел в примерах
https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#native-p2wpkh

Все что до hash preimage понятно


А вот тут вот не ясно:

Почему берется первый индекс входа? для outpoint и  nSequence. Что с нулевым входом делается?

Что такое scriptCode

Откуда взялась сумма?

Что-то не получается проверить сигнатуру транзакции.

Допустим есть транзакция
http://learnmeabitcoin.com/browser/transaction/json.php?txid=c586389e5e4b3acb9d6c8be1c19ae8ab2795397633176f5a6442a261bbdefc3a

У которой публичный ключ

А сигнатура

Что используется в качестве дайджеста для верификации?

scriptSig текущей транзакции?
scriptPubKey выхода предыдущей транзакции?
PubKey?
Всё тело транзакции?

Что-то не одно из значений не проходит валидацию. Они претерпевают каких-то модификаций? Хешируются?

Судя из параметров signrawtransaction там еще разные варианты есть
       "ALL"
       "NONE"
       "SINGLE"
       "ALL|ANYONECANPAY"
       "NONE|ANYONECANPAY"
       "SINGLE|ANYONECANPAY"

В чём преймущество каждого из них, где они применяются, а где нет.

Ковыряясь в поисках исходников пула. Наткнулся на такое решение, вроде даже работает.
https://github.com/bonesoul/CoiniumServ

Мультимонетный пул. Нужно только немного подправить исходники, а то там оно лезет на Poloniex который поменял подход к апи и добавил капчу, поэтому ошибки срутся

Спасибо за ответы. Для себя я это нарисовал так

Есть маска блока допустим 00000000FFFFFF.... тоесть нужно найти блок в хеше которого будут первые 4 нулевых байта. Но это сложно, поэтому пул раздает воркерам задачу искать хеши удовлетворяющих маску 0000FFFFFFFFFF... (достаточно первых 2-х нулей в хеше вместо 4-х) тоесть на два порядка проще найти такие. Есть вероятность что одна из таких шар будет решением блока.  Тогда награда за блок делится между всеми участниками которые слали шары.  И так как в блок вписывается кошелёк пула, воркер не может найти решение и сам им воспользоваться

Меня интересует как пул собирает из шар общую картинку, и как проверяет каждую шару на валидность.

Если правильно понимаю то изначально есть кусок работы, который делится на шары, шары даются воркерам и те их считают.
Пул вписывает свой кошелёк в новый блок, поэтому майнер не может найти решение(счётчик) и получить награду за блок сам, так как при этом хеш блока изменится.

Что представляет из себя шара с точки зрения запрос/ответ и их структура.
Как пул валидирует шары? (ведь если бы не было валидации то воркеры могли слать что угодно и получать прибыль даже не перебирая счётчик)
У шар есть TTL какой-то? если допустим воркер не отдает решение шары в какой-то период времени, то по идее его работу пул должен передать кому-то другому

Да, обычный SHA256. У вас хорошая память, что вы всё это в голове держите.

До OP_CHECKMULTISIG всё заработо с первого раза) Вау!
https://play.golang.org/p/NIjm1yO4YO

Вернусь с коммандировки, будет мне домашнее задание посчитать мультисигну. И разобраться как формируется сам scriptSig.

Про завернут внутрь P2SH, это вы про P2WSH реализацию?
Рассмотрим транзакцию.
http://learnmeabitcoin.com/browser/transaction/json.php?txid=06c543e4f1f2ff6448e2c370078ac80b1d1ab324aa9dbef8db2202313a70c643

Почему первый элемент txinwitness пустой?
Дальше идут две подписи для каждого из ключей (в данном случае мультиподпись из 2-х ключей)
И вконце и дет pubKeyScript который формируется как MultiSigMOfN

Верно?

Да. Это я на радостях))

Как я понял до BIP16 использовались
P2PK и P2PKH

BIP 16 подарил нам
P2SH
Что в свою очередь очен изменило архитектуру и добавило плюшки вроде MUTLISIG.

А сам SegWit уже в
P2WPK, P2WSH

Да я уже понял что опкоды
01-4B отвечают за копирование данных, указанной длины в стек.

Ура наконец добрались до txinwitness данных. Как они загружаются в стек и выполняются предположу что по той же схеме что и скрипты. Но зачем они, какова их суть?

Спасибо. Так более ясная картинка становится с каждым сообщением.


Минусы в избыточности данных? Или что-то с безопасностью?


Ура. Но все равно у меня вопрос.

Если для новой транзакции
scriptSig что-то делает(главное чтоб не исключение бросал), а после этого scriptPubkey добавляет в стек пустой массив и хеш скрипта, и после этого нет больше никакого опкода. То верхним элементом стека будет хеш скрипта.

scriptHash -> [] -> scriptSigResult(если он есть)

Транзакция будет считаться валидной, но майнеры её не включат из-за полиси по размеру стека

Разберу оптимистический сценарий

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 - это ж набор параметров, почему он должен выполнятся? Во вторых чтоб на выходе scriptPubKey было ненулевое число, сценарий должен дойти до конца и вернуть true. А это значит:

1. scriptSig должен состоять из публичного ключа и сигнатуры
2. сигнатура должна соответсвовать дайджесту
3. еще и полиси правило про один ненулевой элемент не мешало бы соблюсти.

Как на это ответить одним словом?

Причем тут OP_0 и scripthash?

За API, до blk формата файлов я еще не дошел. Но предположу что там тоже levelDb и на выходе будет просто сырые данные, которые после преобразования приймут структуру подобную json дереву из примеров.
http://learnmeabitcoin.com/browser/transaction/06c543e4f1f2ff6448e2c370078ac80b1d1ab324aa9dbef8db2202313a70c643


Так как значения забираются из стека в обратной последовательности, и функция почистит два элемента сигнатуру и публичный ключ, то в стеке останутся остальные элементы. А первый операнд будет заменён на результат функции. Предположу что да, транзакция будет валидной при условии соответсвия адреса и сигнатуры


По идее на первом обращении к функции, так как количество аргументов отличается от задекларированного. Ну или как вариант если аргументы динамические то OP_EQUALVERIFY так как до OP_CHECKSIG  не дойдёт очередь.


OP_0 - добавляет пустой массив в стек.
Значит scripthash любой отличный от нуля. Ненулевое значение в стеке будет если scriptPubkey вернёт не ноль.

Хорошо знаю 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/

К сожалению мой уровень английского крайне плох также как и знание С++.  Поэтому я больше путаюсь в переводах. А все что вы мне говорите мне понятно. Спасибо вам за это. Пробовал разобраться самостоятельно в исходниках, но там черт ногу сломит. Вся логика размазана по абстрактным слоям

Посмотрел BIP16

у входа scriptSig это результат подписи публичного ключа с опкодом подписи, приватным ключом подтверждающим владение кошельком
Я это увидел где-то так

А у выхода scriptPubKey это (в самом простом случае без мультиподписи)

Хотя я вижу и другие сценарии у выхода вроде

Если правильно понял суть, то подпись рассчитывается не сразу

Как пример старой транзакции брал эту
http://learnmeabitcoin.com/browser/transaction/json.php?txid=7a160081db721c1f915d9d5bec8a66fb4b52583188d2dab91ef37264d3534b12

Как еще более старая транзакция до BIP16
http://learnmeabitcoin.com/browser/transaction/json.php?txid=d52e6e7fbc1b5d5bc9177947c0ab276f261a761266aeba69eae413e80055dc57

Преобразование адреса в хеш проверял тут
http://bitcoinvalued.com/tools.php