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

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

Если ботнет льет, значит кто-то покупает ее)
Весь криптомир живет на форках. Это как раз та ситуация где он как никогда кстати. Раскол сообщества. Почему бы не создать форк с CRP и пусть живет отдельной жизнью. Другие разработчики, другая история, другой проект по сути. Можно в форке уменьшить граничное количество монет, чтоб они быстрей накопались.  Это повысит цену монеты к тому же. И те кто был с проектом вначале, обретут свои монеты вновь.

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

Суть такова, скидывал на локальный кошелёк, еще летом.
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/

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